Text-to-SQL 与数据分析智能体：用自然语言查询数据库

为什么需要：只有懂 SQL 的人才能取出数据

企业数据大多存放在关系型数据库（用键将多张表关联起来存储的系统）中。要从中取出想要的数字，必须使用一种叫 SQL 的查询语言。即使是“上季度各地区复购率”这样看似简单的问题，也需要对多张表做 JOIN（连接表）和 GROUP BY（分组聚合）才能得到答案。因此，业务人员向数据团队提交需求后等待结果的情况很常见。

Text-to-SQL 就是弥合这一差距的技术。人用自然语言提问，系统把问题转换为 SQL 执行并返回结果。BIRD 论文（paper）将这项研究的动机描述为“让非专家的分析人员也能用自然语言从关系型数据库中取出所需信息”。

然而，早期研究所做的测试比实际情况更容易。根据 Spider 论文（paper），以往的数据集大多在同一个数据库上进行训练和测试，同一条 SQL 仅换了问题的表述，就同时出现在训练集和测试集中。论文指出，一些现有基准测试上的准确率超过 80%，但模型只是记住问题与 SQL 的配对来挑选模板，因此这些准确率是被夸大的。相反，WikiSQL 这类规模较大的数据集只包含单表的简单查询。

核心思想：数据库专属翻译

Text-to-SQL 系统可以比作数据库专属翻译。好的翻译不只是替换词语。他们会先熟悉对方公司的账本是什么样子，也就是哪张表里有哪些栏、表与表之间如何关联。然后找出问题中的“销售额”对应账本里的哪一栏，再转写成账本能理解的语句。话说得含糊时会追问，并先确认转写后的语句是否行得通。

在这个比喻中，“账本结构”就是模式（表、列和关系的设计图），把问题中的词语与模式对应起来的工作就是模式链接（schema linking）。BIRD（paper）在此基础上又补充了一点：仅有模式还不够，还必须理解实际值。例如，如果工资以混有“US$”和逗号的字符串形式存储，就要先去掉特殊字符并转为数字才能求平均值。还要知道“只有所有者（OWNER）账户才有贷款资格”这类业务知识（外部知识），才能正确设置条件。

因此，如今的 Text-to-SQL 与其说是“句子翻译”，不如说更接近“先理解数据库再寻找答案的工作”。LLM（大语言模型）出现后，将这项工作拆分为多个步骤、借助工具来处理的 AI 智能体形式越来越多。

如何运作：从问题到答案

基于 LLM 的 Text-to-SQL 系统大体按以下顺序运作。具体实现因系统而异，但骨架相似。

第一，接收问题。与数据库无关的问题或无法回答的问题在这里过滤掉，含义模糊时进行追问。第二，进行模式链接。从大量表和列中只挑出问题需要的部分。此时会参考列说明、值示例、业务术语定义等元数据（描述数据的信息）。因为如果把整个模式都放进提示词，上下文窗口会溢出，token 成本也会变高。第三，输入挑出的模式和问题，必要时一并输入相似的问题-SQL 示例，让 LLM 编写 SQL。

第四，执行前进行验证。先试运行（dry run）检查是否有语法错误，如果出错，就把错误信息再交给 LLM 让它修改。这个“生成-验证-修改”循环在很大程度上决定准确率。第五，在真实数据库上执行通过验证的 SQL，并把结果表用易懂的话解释出来。

各项研究侧重于这一流程的不同环节。如下面的发展脉络所示，DIN-SQL 专注于问题分解和自我修正，DAIL-SQL 专注于提示词构建，CHESS 专注于模式选择和验证。

发展脉络：基准测试把问题做大，方法随后跟进

起点是 2018 年发布的 Spider（paper）。11 名大学生花了 1,000 小时，构建了 200 个数据库（138 个领域）、10,181 个问题和 5,693 条复杂 SQL。关键在于测试方式：训练和测试使用不同的数据库，要求模型泛化到从未见过的模式。在这一设定下，当时最好模型的精确匹配（exact matching，检查是否与标准答案 SQL 写得完全相同的指标）准确率只有 12.4%。

2023 年，LLM 的加入改变了格局。DIN-SQL（paper）把 SQL 生成拆分为若干小的子问题，依次将其答案输入 LLM，并结合了自我修正（self-correction）。该方法比只给几个示例的简单少样本提示提升了约 10% 的性能，并将 Spider 非公开测试集上的执行准确率提高到 85.3。执行准确率是实际运行 SQL、检查结果是否与标准答案相同的指标。同年，DAIL-SQL 研究（paper）系统比较了问题表示方式、示例选择、示例排列等提示工程技术。它将这些结果整合在一起，在 Spider 上取得了 86.6% 的执行准确率，同时还考察了 token 效率以及对开源 LLM 进行微调的可能性。

随着 Spider 分数上升，出现了“LLM 是否已经能充当数据库窗口”的疑问。2023 年的 BIRD（paper）给出的回答是还不能。BIRD 涵盖 37 个专业领域、95 个数据库（共 33.4GB）和 12,751 个问题-SQL 对，测试庞大而杂乱的实际值、外部知识和 SQL 执行效率。为防止数据泄露，另外构建了 15 个测试用数据库并将其隐藏。GPT-4 的执行准确率也只有 54.89%，与人类的 92.96% 差距很大。DIN-SQL 在 BIRD 非公开测试集上取得了 55.9%。

2024 年的 CHESS（paper）把工作分给四个智能体：查找相关值和说明的信息检索、把大模式缩减为小子模式的模式选择、生成 SQL 候选并反复修改的候选生成，以及用自然语言单元测试进行验证的单元测试智能体。仅模式选择一项就让准确率提高约 2%，LLM 的 token 用量减少到五分之一，并在 BIRD 测试集上取得 71.10%。同年，Spider 2.0（paper）把考场搬到了企业现场。它基于 BigQuery、Snowflake 等云数据仓库中、列数有时超过 1,000 的真实数据库，构建了 632 个工作流问题。解题需要查阅元数据、SQL 方言（各数据库略有不同的 SQL 语法）文档乃至项目代码，有时还要编写超过 100 行的 SQL。基于 o1-preview 的代码智能体在 Spider 1.0 上解出 91.2%，在 BIRD 上解出 73.0%，但在 Spider 2.0 上只解出 21.3%。

最新方向：会追问、会停止、会行动的数据智能体

2026 年研究的关注点正从“SQL 写得对不对”转向“能否放心使用”以及“能否完成 SQL 之外的工作”。

第一个分支是模糊性。ARCS（paper）认为，在实际部署环境中，问题的模糊性是主要错误来源。因此它提出了“结构化消歧”，不通过自由对话追问，而是通过明确且受约束的交互来消除模糊性。该研究在真实数据库中标注了自然产生的模糊之处、可能的解释以及每种解释对应的 SQL 来构建基准测试，结果 gpt-6-sol 从头到尾全部答对的执行准确率也只有 51%，开源模型则未超过 27%。

第二个分支是知道何时停止的能力。针对医疗记录查询的 Sentinel 研究（paper）加入了一个可信度判定层，分析智能体的推理过程、代码和数据库输出，在三个节点决定是否停止：执行前拒绝无法回答的问题，执行中中断没有希望的 Trajectory，最后不输出难以置信的答案。在 EHRSQL 基准测试上，给出答案的比例从 84% 降到 55%，但已输出答案的准确率从 54% 升至 69%。

第三个分支是向数据智能体的扩展。Argo-Bench（paper）指出，现有 Text-to-SQL 基准测试只评估查询生成，而且审查发现标准答案中也常有错误。该研究在 235 张表、75 亿行规模的 ERP（企业资源计划）数据仓库上构建了 210 个数据科学与分析任务。智能体还要采取行动，例如封禁欺诈账户、分配配送员激励预算，评分则依据这些行动在模拟器中产生的结果。在 14 个模型中，即使是最强的模型，得分在 95 分以上的任务也只占 34.8%。

局限与争议

最大的局限在于“执行成功”与“答对”是两回事。即使 SQL 没有语法问题，如果误解了问题的含义，也会返回看似合理却错误的数字。由于结果以整洁的表格呈现，用户很难产生怀疑。正如 ARCS（paper）所指出的，模糊性很微妙，并且因领域和数据而异，会让系统悄悄偏离用户意图。因此在实践中，常常会同时展示生成的 SQL 和系统所做的假设，并设置由人工核对重要数字的人在回路机制。

第二，评估本身并不稳固。基准测试分数并不能如实反映实际业务表现。在 Spider 1.0 和 BIRD 上得分很高的智能体在 Spider 2.0（paper）上大幅下滑，Argo-Bench（paper）则把现有基准测试标准答案中的错误列为问题。指标本身也有弱点：精确匹配会把写法不同但结果相同的 SQL 判为错误，执行准确率则可能把只是碰巧结果相同的 SQL 判为正确。

第三，是运维问题。正如 BIRD（paper）单独设置了效率指标，在大型数据库中，SQL 即使正确，如果很慢也会降低实用性。此外，由于是直接执行 LLM 编写的 SQL，只读权限、执行时间限制、对敏感列的访问控制等基本安全措施必须独立于模型性能而配备。如果列名难以辨认，或业务术语定义分散在各处，任何模型都会迷失。这就是为什么像数据目录或语义层这样整理数据“含义”的工作是准确率的基础。

延伸学习

如果是初学者，建议先读 Spider（paper）的引言。为什么要“用从未见过的数据库进行测试”，是这一领域问题定义的核心。接着看 BIRD（paper）图 1 中的三个示例（杂乱的值、外部知识、执行效率），就能体会到真实数据为何困难。

方法方面，可以依次通过 DIN-SQL（paper）了解“拆分求解并自我修正”，通过 DAIL-SQL 研究（paper）了解提示词各组成部分的效果，通过 CHESS（paper）了解智能体分工结构。如果考虑企业环境，可以看看 Spider 2.0（paper）比现有基准测试多要求了什么。

关于最新动向，通过 ARCS（paper）了解模糊性问题，通过 Sentinel 研究（paper）了解可信度与停止判断，通过 Argo-Bench（paper）了解超越 SQL 的数据智能体评估，就能大致浏览 2026 年的主要争议点。