Agentic NL2SQL to Reduce Computational Costs arxiv下面是在原有框架基础上按你要求“最开头附上链接并给出文章名”整理后的完整分析。一. 翻译摘要原文将自然语言查询转换为SQL查询NL2SQL 或 Text-to-SQL最近得益于大型语言模型LLMs的发展而取得进展。 在大量SQL数据库上使用LLMs执行NL2SQL方法时需要处理海量关于数据库的元信息这会导致提示变得很长、令牌数量很多以及较高的计算成本。 为解决这一挑战我们提出 Datalake Agent这是一个代理系统旨在让LLM更高效地解决NL2SQL任务。 与一次性在提示中加入所有元信息并调用LLM的直接求解器不同Datalake Agent 采用交互循环来减少使用的元信息。 在这个循环中LLM被置于一个推理框架中只有选择性地请求解决表格问答任务所必需的信息。 我们在包含23个数据库、100个表格问答任务的集合上评估了 Datalake Agent。 Datalake Agent 将LLM使用的令牌数量最多减少了87%从而在保持有竞争力性能的同时实现了显著的成本降低。 arxiv二. 方法动机作者为什么提出这个方法企业级环境中往往存在大量SQL数据库和表若使用LLM做NL2SQL必须把大量schema元信息送入模型导致提示极长、调用成本高这严重限制了实际落地。 arxiv作者希望在不显著牺牲准确率的前提下大幅削减LLM调用时的令牌数以降低在企业场景中运行NL2SQL系统的总体成本。 arxiv现有方法的痛点/不足是什么直接求解Direct Solver将“当前可见的所有数据库元信息”一次性塞进prompt让LLM直接输出SQL。缺点随可见表的数量增加提示长度近似线性增长导致成本和延迟急剧上升。 arxiv大schema下模型准确率下降尤其在多表和复杂查询结构时性能劣化明显。 arxivText2API 类方法通过固定API端点请求数据存在只能访问有限API暴露的信息不能像SQL那样灵活检索所有数据。 arxiv对表规模大、结构复杂的数据湖适应性差。现有NL2SQL基准如 Spider、Bird通常只提供和当前问题相关的schema子集无法模拟企业真实情况模型名义上可以访问“整个数据库湖”但事先不知道哪些表和列真正相关。 arxiv论文的研究假设或直觉是什么大多数具体NL2SQL任务只需要数据库元信息的一个很小子集如果让LLM在一个代理框架中分步思考、按需拉取信息就能在几乎不损失准确率的前提下显著减少令牌和成本。 arxiv通过“信息获取→迭代精炼→查询生成”的层级推理循环比一次性把所有东西都给LLM更接近人类分析数据库的过程也更有助于处理复杂查询。 arxiv三. 方法设计方法流程总结pipeline输入自然语言问题 (q)Table Question Answering。一组可用的SQL数据库及其schema表名、列名、类型等元信息规模可达数百张表。 arxiv核心思想不直接把所有schema送入LLM而是通过一系列“命令式交互”让LLM逐步探索先选数据库再看相关表再看必要列最后在掌握的子schema上生成SQL。 arxiv具体步骤1信息获取Information Acquisition系统为LLM暴露一组“工具式命令”典型包括GetDBDescription返回各个数据库的高层描述比如业务域、数据大致内容用于帮助LLM先选择最可能相关的数据库。 arxivGetTables给定一个具体数据库名返回此数据库中所有表的名称和简短说明。 arxivGetColumns给定一个表名返回该表所有列名、数据类型及简要描述。 arxiv初始时LLM只看到自然语言问题和可用命令的说明而看不到任何具体schema细节。 arxivLLM基于问题内容首先调用GetDBDescription选择1个或少数几个最相关的数据库然后对这些库调用GetTables进一步筛选候选表。 arxiv对于候选表再调用GetColumns获取更细粒度的schema信息如主键、日期列、数值列等为后续构造SQL做准备。 arxiv2迭代精炼Iterative RefinementLLM以“层级方式”推进先在数据库层面决定用哪个DB或哪些DB再在表层面缩小到几张候选表最后在列层面获取必要字段信息。 arxiv在这个过程中LLM始终运行在一个“推理框架”里每次调用工具后模型会得到结构化返回结果如表/列列表模型基于当前已知信息更新自己的“内部计划”和“中间推理”决定下一步是深入某个表查看更多列回退到数据库层重新选择库直接进入SQL生成阶段。 arxiv这一循环可以多次往复直到模型认为已获取足够schema来写出正确SQL。论文中提到为避免LLM陷入无限请求同类信息的循环系统在同一任务最多允许10次请求超过后强制要求LLM给出SQL结果。 arxiv3查询生成Query Formulation当LLM判断信息已足够时会调用最后一个专用命令DBQueryFinalSQL其角色是“请你现在根据已知schema和问题生成最终SQL”。 arxivLLM输出的SQL会被 Datalake Agent 通过一个“访问层access layer”发送到真实数据库执行并获取执行结果。访问层负责面向多种数据库后端提供统一接口保障系统模块化未来新增数据库只需在访问层做最小改动。 arxiv最终系统返回给用户生成的SQL语句SQL执行得到的表格答案。输出正确的SQL查询如果模型足够准确对应的查询结果用于Table-QA任务评估。 arxiv模型结构与模块协作论文不是新的神经网络结构而是一个“基于LLM的代理系统框架”主要模块包括LLM 推理核心论文以 GPT-4-mini 作为主要模型温度设为0.1强调可替换为任何强NL2SQL能力的LLM。 arxivLLM负责任务理解、工具选择和SQL生成等所有“智能决策”。工具/命令接口模块对LLM暴露统一的“工具规范”包括GetDBDescription、GetTables、GetColumns、DBQueryFinalSQL等返回值格式严格结构化如JSON便于LLM解析和后续推理。迭代控制与状态管理模块负责记录当前任务中的所有工具调用历史和返回结果即“已发现的schema子图”控制循环次数例如最多10次信息请求防止无限循环将历史上下文已经获取的DB、表、列信息与用户问题一起打包进下一轮LLM调用。数据库访问层Access Layer接收DBQueryFinalSQL生成的SQL负责在真实数据库执行对不同DB系统做统一封装保证扩展性和可维护性。 arxiv模块协同方式LLM 通过工具接口向数据库访问层“间接”提问迭代控制模块串联每一步LLM调用和工具返回形成一个完整的推理-查询循环访问层对外暴露统一执行界面使系统可以无缝接入更多数据库。公式/算法的通俗解释论文没有严格的数学公式而是描述了一个通用的层级搜索算法把“所有可见schema”看成一个巨大的搜索空间第一层是数据库列表第二层是每个数据库的表列表第三层是各表内部的列列表。传统直接提示等价于“把整个搜索空间一次性铺开给模型”而 Datalake Agent 相当于在树结构上进行有引导的深度/广度混合搜索每一步只展开最有用的节点相关DB/表/列并允许回退到上一层重选。这一策略在算法上实现了两点避免全空间穷举只访问必要节点利用LLM推理能力控制搜索方向而不是预先写死规则。 arxiv四. 与其他方法对比本方法和现有主流方法相比的本质不同主流 Direct Solver一次性给全量schema 问题 → 单轮推断出SQL核心特征是“静态提示单步决策”。 arxivDatalake Agent起点是只给问题和“工具接口描述”不直接给schema通过多轮交互动态选择性地拉取小块schema然后再生成SQL核心特征是“动态信息获取 多步推理”。 arxiv创新点提出一个通用的agentic NL2SQL 框架而不是简单的prompt工程即让LLM在结构化工具环境中自主探索schema。 arxiv设计“信息获取–迭代精炼–查询生成”的三级推理流程有效避免大schema下的令牌爆炸问题。 arxiv构建新的评测基准23个数据库、319张表、100个手工设计的Table-QA任务其中同时包含简单单表和复杂多表任务更接近企业数据湖场景。 arxiv在数据库规模增长时展示出较传统方法更平缓的性能下降曲线同时令牌数和API成本显著降低。适用场景企业级数据湖多业务线、多数据库、多表的大型环境如金融、电商、SaaS平台等。 arxiv需要长期运行的NL2SQL系统对成本和延迟敏感需要平衡效果与预算。查询复杂度高的BI分析、内部报表生成和交互式数据分析。方法对比表维度直接提示Direct SolverText2API 类方法Datalake Agent信息获取方式一次性全schema输入通过固定API获取少量数据按需、多轮、分层获取schema令牌/成本随表数近线性增长高依赖API设计中等在大规模DB显著降低最多减87% arxiv对复杂查询的表现schema大时性能严重下降受API限制复杂性受限在复杂多表任务上表现更稳、更优 arxiv工程复杂度实现简单需要API设计和维护需要实现代理框架与工具接口适用数据库规模小到中等取决于API覆盖中到超大规模数据库湖主要缺点成本高、不扩展能力受限可能出现重复请求和循环需要上限控制 arxiv五. 实验表现与优势有效性验证方式数据与场景使用 RelBench 中5个真实数据库并扩展出18个模拟数据库总计23个数据库、319张表。 arxiv设计100个Table-QA任务覆盖简单单表和复杂多表查询每个数据库约20个任务。 arxiv对比设置三种数据库规模42表、159表、319表逐步增加可见表数量 arxiv两种方法Direct Solver基线 vs Datalake Agent本文方法。模型与参数使用 GPT-4-mini温度0.1评估指标包括SQL正确率、平均输入令牌数、折算成API成本。关键结果与超越点令牌使用在42张表时Direct Solver 平均需要约7407个输入token而 Datalake Agent 约3670个。 arxiv在319张表时Direct Solver 上升到34602个token而 Datalake Agent 约4264个削减约87%。 arxiv成本将平均token折算为1000个任务的API成本42表时Direct约为Datalake的2倍319表时高达约8倍对o1模型来说差额超过450美元/1000任务。 arxiv性能准确率在小规模数据42表下Direct Solver略优于Datalake Agent。 arxiv随着表数增加和任务复杂度上升Direct Solver准确率下降更快而Datalake Agent下降较慢在大规模与复杂任务上整体表现更好。 arxiv优势最明显的场景/数据集当表数从42增长到159、319时特别是包含多表联结、复杂过滤和聚合的任务中Datalake Agent在保持较低令牌的同时准确率相对Direct Solver有更明显优势。 arxiv对企业真实类似的“全库可访问但不知哪些相关”的场景Datalake Agent缩小搜索空间效果尤其显著。局限性在部分任务中LLM可能多次重复请求同一类信息形成“自旋”需要通过“最多10次请求后强制输出SQL”的策略防止无限循环。 arxiv论文只在GPT-4-mini上评估对其他模型尤其更强或更弱的模型泛化效果目前未知。 arxiv模拟数据库的部分是“只有schema、没有真实数据”的环境可能与真实生产数据库存在差异。 arxiv六. 学习与应用是否开源及复现关键步骤论文正文未明确给出GitHub链接推测暂不保证有官方开源实现。 arxiv自己复现时的关键步骤搭建数据库访问层将企业内的多个SQL数据库统一抽象为“DB列表 表列表 列列表 SQL执行接口”实现GetDBDescription、GetTables、GetColumns、DBQueryFinalSQL四类接口逻辑。设计LLM提示规范明确告诉模型有哪些命令、每个命令输入输出格式要求模型始终以结构化JSON形式回复如{ action: ..., arguments: {...} }。搭建代理循环主循环接收模型输出判断是工具调用还是最终SQL执行工具获取结果并追加到上下文再调用LLM下一轮限制最大循环次数如10防止死循环。评估构造代表性Table-QA任务集检查SQL正确性与成本令牌。实现时需注意的超参数、预处理、训练细节无需额外训练属于“纯推理提示工程”范式。 arxiv关键超参数LLM温度建议较低论文用0.1以减少不稳定行为 arxiv最大工具调用次数如10在复杂查询中可适当增大但要防止成本反弹。数据预处理对所有数据库统一提取schema元信息并加上简短自然语言描述帮助LLM理解每个表/列的大致语义尽量避免过长、冗余的列名说明控制每次工具返回内容长度。提示设计清晰区分“思考部分”和“工具调用部分”要求模型在调用前先给出简要的自然语言计划便于调试强调“避免重复请求相同信息”可在系统提示中加入相关约束。迁移到其他任务的可行性对任意“信息空间巨大、但每次任务只需要局部信息”的场景都可以迁移这一框架知识图谱问答将GetTables/GetColumns替换为GetEntities/GetRelations按需探索图结构再生成查询如SPARQL。文档检索问答RAG用GetDBDescription对应“文档库/主题概览”GetTables对应“文档列表”GetColumns对应“段落/章节摘要”最终生成检索回答策略让LLM先确定相关文档集再按需拉取内容避免一次性索引所有长文。多模态数据库图像表格等通过工具接口暴露“图像集合”“特征索引”等元信息LLM按需选择查询对象。迁移时的关键是用“工具访问层”的方式把底层复杂系统抽象为若干可调用接口保留“信息获取–迭代精炼–结果生成”的三段式循环结构。七. 总结一句话概括核心思想按需分步查询数据库元信息用代理式LLM生成高效SQL。速记版 pipeline避免论文原词汇先粗略看各个数据库的简介挑出最相关的库在选中的库里列出表再挑出可能有关的几张表查看这些表里的具体字段只取问题需要的那些用已经选出的库、表和字段写出SQL并执行拿结果。