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。缺点：
- Text2API 类方法：通过固定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暴露一组"工具式命令"，典型包括：
- 初始时，LLM只看到自然语言问题和可用命令的说明，而看不到任何具体schema细节 。 arxiv
- LLM基于问题内容，首先调用
GetDBDescription，选择1个或少数几个最相关的数据库，然后对这些库调用GetTables，进一步筛选候选表。 arxiv - 对于候选表，再调用
GetColumns获取更细粒度的schema信息，如主键、日期列、数值列等，为后续构造SQL做准备。 arxiv
（2）迭代精炼（Iterative Refinement）
- LLM以"层级方式"推进：
- 先在数据库层面决定用哪个DB或哪些DB；
- 再在表层面缩小到几张候选表；
- 最后在列层面 获取必要字段信息。 arxiv
- 在这个过程中，LLM始终运行在一个"推理框架"里：
- 每次调用工具后，模型会得到结构化返回结果（如表/列列表）；
- 模型基于当前已知信息更新自己的"内部计划"和"中间推理"，决定下一步是：
- 深入某个表查看更多列；
- 回退到数据库层重新选择库；
- 直接进入SQL生成阶段。 arxiv
- 这一循环可以多次往复，直到模型认为已获取足够schema来写出正确SQL。论文中提到，为避免LLM陷入无限请求同类信息的循环，系统在同一任务最多允许10次请求，超过后强制要求LLM给出SQL结果。 arxiv
（3）查询生成（Query Formulation）
- 当LLM判断信息已足够时，会调用最后一个专用命令：
DBQueryFinalSQL，其角色是"请你现在根据已知schema和问题，生成最终SQL"。 arxiv - LLM输出的SQL会被 Datalake Agent 通过一个"访问层（access layer）"发送到真实数据库执行，并获取执行结果。访问层负责：
- 面向多种数据库后端提供统一接口；
- 保障系统模块化，未来新增数据库只需在访问层做最小改动。 arxiv
- 最终系统返回给用户：
- 生成的SQL语句；
- SQL执行得到的表格答案。
输出：
- 正确的SQL查询（如果模型足够准确）；
- 对应的查询结果，用于Table-QA任务评估。 arxiv
- 模型结构与模块协作
论文不是新的神经网络结构，而是一个"基于LLM的代理系统框架"，主要模块包括：
-
LLM 推理核心
- 论文以 GPT-4-mini 作为主要模型，温度设为0.1，强调可替换为任何强NL2SQL能力的LLM。 arxiv
- LLM负责任务理解、工具选择和SQL生成等所有"智能决策"。
-
工具/命令接口模块
- 对LLM暴露统一的"工具规范"，包括
GetDBDescription、GetTables、GetColumns、DBQueryFinalSQL等； - 返回值格式严格结构化（如JSON），便于LLM解析和后续推理。
- 对LLM暴露统一的"工具规范"，包括
-
迭代控制与状态管理模块
- 负责记录当前任务中的所有工具调用历史和返回结果，即"已发现的schema子图"；
- 控制循环次数（例如最多10次信息请求），防止无限循环；
- 将历史上下文（已经获取的DB、表、列信息）与用户问题一起打包进下一轮LLM调用。
-
数据库访问层（Access Layer）
- 接收
DBQueryFinalSQL生成的SQL，负责在真实数据库执行； - 对不同DB系统做统一封装，保证扩展性和可维护性。 arxiv
- 接收
模块协同方式：
- LLM 通过工具接口向数据库访问层"间接"提问；
- 迭代控制模块串联每一步LLM调用和工具返回，形成一个完整的推理-查询循环；
- 访问层对外暴露统一执行界面，使系统可以无缝接入更多数据库。
- 公式/算法的通俗解释
论文没有严格的数学公式，而是描述了一个通用的层级搜索算法：
- 把"所有可见schema"看成一个巨大的搜索空间：
- 第一层是数据库列表；
- 第二层是每个数据库的表列表；
- 第三层是各表内部的列列表。
- 传统直接提示等价于"把整个搜索空间一次性铺开给模型"，而 Datalake Agent 相当于：
- 在树结构上进行有引导的深度/广度混合搜索；
- 每一步只展开最有用的节点（相关DB/表/列），并允许回退到上一层重选。
- 这一策略在算法上实现了两点：
- 避免全空间穷举，只访问必要节点；
- 利用LLM推理能力控制搜索方向 ，而不是预先写死规则。 arxiv
四. 与其他方法对比
- 本方法和现有主流方法相比的本质不同
- 主流 Direct Solver：
- 一次性给全量schema + 问题 → 单轮推断出SQL；
- 核心特征是"静态提示+单步决策"。 arxiv
- Datalake 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 Solver） | Text2API 类方法 | Datalake Agent |
|---|---|---|---|
| 信息获取方式 | 一次性全schema输入 | 通过固定API获取少量数据 | 按需、多轮、分层获取schema |
| 令牌/成本 | 随表数近线性增长，高 | 依赖API设计，中等 | 在大规模DB显著降低（最多减87%） arxiv |
| 对复杂查询的表现 | schema大时性能严重下降 | 受API限制，复杂性受限 | 在复杂多表任务上表现更稳、更优 arxiv |
| 工程复杂度 | 实现简单 | 需要API设计和维护 | 需要实现代理框架与工具接口 |
| 适用数据库规模 | 小到中等 | 取决于API覆盖 | 中到超大规模数据库湖 |
| 主要缺点 | 成本高、不扩展 | 能力受限 | 可能出现重复请求和循环，需要上限控制 arxiv |
五. 实验表现与优势
- 有效性验证方式
- 数据与场景：
- 对比设置：
- 三种数据库规模：42表、159表、319表（逐步增加可见表数量） arxiv
- 两种方法：Direct Solver（基线） vs Datalake Agent（本文方法）。
- 模型与参数：
- 使用 GPT-4-mini，温度0.1；
- 评估指标包括：SQL正确率、平均输入令牌数、折算成API成本。
- 关键结果与超越点
- 令牌使用：
- 成本：
- 将平均token折算为1000个任务的API成本，42表时Direct约为Datalake的2倍，319表时高达约8倍，对o1模型来说差额超过450美元/1000任务。 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并执行拿结果。