写在前面
NL2SQL 这个方向乍看是个“老问题”——把一句自然语言翻译成一条 SQL,似乎属于经典语义解析范畴。但从三代评测基准的分数变化,就能看出这个赛道的难度在急剧升级:
| 基准 | 年份 | 特点 | 顶尖模型表现 |
|---|---|---|---|
| Spider 1.0 | 2018 | 单句 → 单条 SQL | o1 达 91.2%,语义解析趋近上限 |
| BIRD | 2023 | 复杂 SQL + 脏数据 | o1 降至 73.0%,考验噪声鲁棒性 |
| Spider 2.0 | 2024 | 企业级真实工作流 | o1 骤降至 17.1%,难度断崖式上升 |
也就是说,当任务从“写对一条 SQL”变成“在真实企业数据库里,结合项目上下文、多方言 SQL、上百列的大表完成一次完整分析”,模型的能力几乎被打回原形。这也是本文六个案例集体在做的事情:把 NL2SQL 从一次性生成任务,重构为一个多步骤、可反馈、可纠错的 Agent 工作流。
一、三大评测基准速览
BIRD-Bench
12,751 个问题,覆盖 95 个数据库、37 个领域,并且故意包含“脏数据”。评价指标不只看对错(EX 执行准确率),还引入了效率分(VES)。目前 SOTA 是蚂蚁的 81.67%,而早期的 o1-preview 只能解出 17.1%。
Spider 2.0(ICLR 2025 Oral)
Spider 2.0 进一步拆成三个难度递增的子集:
| 子集 | 样本数 | 特点 | 当前榜首分数 |
|---|---|---|---|
| Lite | 547 | 跨方言(BigQuery/Snowflake/SQLite) | DivSkill-SQL 73.13% |
| Snow | 547 | Snowflake 云端真实执行 | Sentinel v2 Pro 96.70% |
| DBT | 68 | 完整 dbt 工程项目 | Databao 60.29% |
值得注意的是,Spider 2.0 的样本平均涉及 1000+ 列,单条 SQL 常常超过 100 行——这已经不是“写一条查询”,而是“完成一次工程级的数据探索任务”。
注：榜单本身也不完全可信
一篇题为《Pervasive Annotation Errors》(2026.01)的论文指出,Spider 2.0-Snow 的标注错误率高达 62.8%,BIRD Mini-Dev 也有 52.8%。这意味着排行榜上几个百分点的差距,很可能并没有统计显著性。这个问题会在后文的“六重挑战”部分再展开。
二、BIRD 榜三强技术路线
蚂蚁·Agentar-Scale-SQL —— BIRD 81.67%,效率榜 77 分 #1
蚂蚁的核心思路是“编排式测试时扩展”:不是靠一次调用把模型“喂大”,而是在推理阶段同时从三个维度扩展算力——内部扩展、序列扩展、并行扩展协同工作,目前 32B 模型已经开源。
- 内部扩展(GSPO 强化学习):用组内相对排序信号优化策略梯度,让模型学会偏好“执行结果更准”的候选 SQL。消融实验显示,去掉这一模块准确率会下降 4.89%。
- 序列扩展(多轮反思修正):生成 → 执行 → 拿到反馈 → 修正,循环若干轮,并保留前几轮的上下文,形成一条闭环修正链路。
- 并行扩展(锦标赛筛选):多模型、多温度并行生成一批候选 SQL,再用一个 32B 的 Selection 模型做两两配对打分,通过累积胜率排序——这比传统的自一致性投票更精细。
底层还配了一套 Schema 引擎:向量检索(SentenceTransformer + Chroma 存 SQL 骨架)+ BM25 索引做召回补充。
Google·CHASE-SQL —— BIRD 73.0%,Spider 87.6%(ICLR 2025)
Google 团队的一个核心洞察很有意思:如果把“自一致性”投票的理论上限算出来,是 82.79%,但实际只做到 68.84%——中间这 14% 的差距,说明光靠“多生成几个再投票”是不够的,必须靠更好的生成策略 + 更好的选择机制来填补。
CHASE-SQL 的做法是“三路生成 + 成对选择器”:
- 值检索(LSH):LLM 先提取问题中的关键词,再通过局部敏感哈希(LSH)去检索数据库里相似的取值,并用嵌入 + 编辑距离做重排,专门用来抗拼写错误和口语化表达。
- 三种候选生成路径:分治式 CoT(把子查询拆开分别求解再合并,适合嵌套查询)、查询计划式 CoT(模拟数据库执行引擎的 EXPLAIN 步骤做推理)、以及在线合成示例。
- 修正器:对生成结果做最多 3 轮修正,逐轮消除 JOIN 冗余、WHERE 条件遗漏等问题。
- 成对选择器:不是让所有候选一起打分排序,而是两两比较,这种方式被证明优于传统的自一致性投票。
腾讯·TCDataAgent —— BIRD 75.74% #3,Snow 93.97%(VLDB'25 + ICDE'26)
如果说蚂蚁和 Google 都在“算力”和“生成策略”上做文章,腾讯的路线明显更工程化——不追求复杂的生成技巧,而是把验证前置、做好语义对齐、再用数据飞轮持续迭代。
- 约束验证前置:通过 AST 解析 + DDL 交叉比对,在生成阶段就拦截类型错误、主外键错误、非空约束违反,这一项让准确率提升了 18.3%。
- 内容感知(语义对齐):动态加载字段的分布、取值范围、文本长度等摘要信息,比如系统能知道“冷门商品”在这份数据里对应的是“月销 < 100”,而不是凭空猜测——这让意图理解提升了 30%。
- 择优迭代(数据飞轮):从正确性、效率、质量三个维度打分,只保留 Top 10% 的高质量样本做微调,复杂查询能力因此提升 22%。
团队随后推出的 CYANSQL(ICDE'26)进一步把 SQL 按逻辑结构聚类,不同结构簇并行生成,再做执行增强排序,在 BIRD 上做到了 87%。
三、Spider 2.0 榜三强技术路线
阿里·DB-Surfer —— Snow 59.78%,2025.08 曾登顶
阿里的设计哲学是“先规划、后执行”,整体是一个总-分-总架构:先做意图预处理规划出“路线图”,再由 3 个 Agent 分别负责 Schema 探索、SQL 生成(支持多方言)、执行验证,最后按结果一致性分组、按扫描行数/耗时排序,做二次执行验证再输出。这套方案在真实的 DataWorks 场景(6 万+用户)中得到过验证。
Genloop·Sentinel Agent —— Snow 96.70% #1
Sentinel 走的是经典的 Agentic 闭环:感知 → 规划 → 执行 → 反思,三代迭代下来分数从 83% 一路涨到 97%。
- 感知:不是一次性把 schema 全灌给模型,而是主动探索——先推断业务域,再逐层展开表名、列名/类型、采样数据,动态回溯补充。
- 规划:把复杂查询拆成一个个独立子任务,画好路线图。
- 执行:每一步生成的 SQL 都立即在 Snowflake 上真实执行验证,执行结果直接注入下一步推理。
- 反思:报错或者返回空集会触发即时修正;子任务完成后,经验会被总结写入上下文,供后续子任务复用,避免反复踩同一个坑。团队透露,这个“跨轮反思”机制是 v2 到 v2 Pro 提升 8% 的关键因素。
JetBrains·Databao —— DBT 60.29% #1,从约 25% 基线迭代而来
Databao 的洞察可能是本文最反直觉、但也最实用的一条:“stability beats cleverness”(稳定胜过聪明)。团队发现,最大的提升并不来自换更强的模型,而是来自更朴素的工作流设计:
- 上下文精准投喂:启动前只展示关键项目文件和数据库概览,把 dbt run 日志压缩成结构化摘要,让 Agent“一目了然该看什么”,而不是被信息轰炸。
- 权限收紧:移除通用文件操作能力,只保留 dbt 命令;编辑范围限制在 models/*.sql;设置硬规则——不碰项目外的表,且必须通过验证。
- 策略文档取代 Prompt 洋葱:把层层叠加、互相矛盾的规则重写成线性、人类可读的策略文档,Agent 的行为因此从“随机”变成“一致”。
同场竞技的 SignalPilot 走了一条类似的路:把 dbt 工作流封装成 Claude Code 的 Skills(标准作业流程),让 Agent 按预定义流程执行——本质上也是“用限制自由换取稳定性”的思路。
四、六案例横向对比
| 机构/Agent | 基准 | 分数 | 范式 | 生成策略 | 验证方式 | 核心亮点 |
|---|---|---|---|---|---|---|
| Agentar | BIRD | 81.67% | 算力编排 | 强化学习+并行 | 锦标赛筛选 | GSPO 强化学习微调选择器 |
| CHASE-SQL | BIRD | 73.0% | 生成-选择 | 分治/查询计划/在线合成 | 成对比较 | LSH 值检索抗噪声,成对选择器 |
| TCDataAgent | BIRD+Snow | 75.7% / 94.0% | 工程闭环 | 约束前置 | AST+DDL 交叉比对 | 内容感知元数据链接 |
| DB-Surfer | Snow | 59.8% | 总-分-总 | 3 Agent 分步探索 | 结果一致性分组 | DataWorks 场景验证 |
| Sentinel | Snow | 96.7% | Agentic 闭环 | 分步子任务 | 云端实时执行 | 跨轮反思 |
| Databao | DBT | 60.3% | 工作流纪律 | Skill SOP | dbt build | 权限收紧 |
六家公司几乎覆盖了四种典型范式:生成-选择、规划-执行、分步子任务、算力编排。单一 LLM 调用已经无法覆盖 NL2SQL 全流程,这是行业的共识。
五、五大技术趋势
- 多智能体协同:单一模型调用让位于多 Agent 分工协作。
- 执行反馈闭环:从“生成完就交卷”到“生成-执行-反馈-修正”的闭环,介入深度也在递进——TCData 是事后在线质检,Sentinel 是边做边验,Databao 则是直接跑 dbt build,验证粒度随基准难度同步升级。
- 稳定性 > 聪明度:Databao 的经验很有代表性——80% 稳定的方案,往往比 85% 但不可预测的方案更适合上生产。系统设计的重要性正在超过模型能力本身。
- 结构化推理:从“字符串生成”转向“逻辑结构理解”,DC-CoT 分治、QP-CoT 查询计划、CYANSQL 聚类都是这个方向的体现,推理过程按 SQL 结构组织,而不是纯文本续写。
- 评估标准企业级进化:三代基准(Spider 1.0 → BIRD → Spider 2.0)的演进路径清晰可见——从单句语义解析,到脏数据鲁棒性,再到真实企业工作流中的环境交互与项目工程能力。Snow 子集已逼近 97%,而 DBT 子集只有 60%,后者才是下一个真正的战场。
六、六重挑战
报告把六个挑战分成了两类,这个划分本身很有价值:前三个是工程优化问题,可以逐步缓解:
- 推理成本:像 CHASE-SQL 这类方案每题需要 21+ 次 LLM 调用,企业每天要处理数万次查询,成本压力很大,可能的出路是分级策略、缓存、模型蒸馏。
- 数据隐私:多数 SOTA 方案依赖云端大模型,在金融、医疗、政务等强合规场景存在天然的风险;Agentar 虽然开源了 32B 模型,但性能与顶尖闭源方案仍有差距。
- 累积误差:规划错误会级联传播到后续所有步骤——子任务 1 出错,子任务 2 的输入就已经是错的。硬约束和跨轮反思能缓解,但无法彻底消除。
后三个是范式性瓶颈,需要根本性的思路转变:
报告给出的一个判断很值得记住:NL2SQL 的能力上限,未来将由语义理解决定,而不是 SQL 生成能力本身。
结语
把六个案例放在一起看,一个清晰的脉络浮现出来:NL2SQL 正在从一个"语义解析"问题,演变成一个"Agent 工程"问题。谁能把 Schema 探索、执行反馈、错误修正、成本控制这些环节编排得更精细、更稳定,谁就能在真实企业场景里跑得更远——而不只是在榜单上多拿几个百分点。
尤其是 Databao 那句"stability beats cleverness",可能比任何一个具体的技术细节都更值得工程团队记在心里。
- 基准失真:前文提到的标注错误率(Snow 62.8%、BIRD 52.8%)意味着超过一半的评估样本可能本身就是错的,出路可能在于多标注交叉验证 + 多维度评价体系。
- 鲁棒性:"上月销售额"和"最近一个月卖了多少钱"这种同义改写,可能会导致模型生成完全不同的 SQL,单纯靠数据增强或语义归一化只能治标不治本。
- 语义鸿沟:像"哪些产品需要补货"这种问题,根本不对应一条确定的 SQL,而是需要理解业务定义、跨多数据源、结合领域知识才能回答。可能的方向包括语义中间层、本体论建模,或者干脆引入交互式澄清机制。
