一句话总结
学术榜单上 90 分的 Text-to-SQL 模型，换到真实企业库上基本不能用。基准一代代把题目出得更真实，Spider 2.0 之后任务已经不是 "生成一条 SQL" 而是 "在数据库里多轮探索"
一、动机
早在大模型问世之前，Text-to-SQL 就已在学术界和业界广泛探索：输入一句自然语言问题，输出一条可执行的 SQL，让积累的业务数据发挥更大价值
但在真实业务场景里，数据资产往往没那么干净：库表划分不规范、字段名带缩写、存在脏数据等，光看基础 schema 经常难以理解字段含义还得查阅外部文档。学术界的成果因此难以应用，实践中往往通过槽位填充的形式输出可控 SQL，泛化性很差
后续的研究重点便在于补齐上述落差：测试问题应当尽量向真实场景看齐。text-to-sql 的具体实现方案也随着各代基准的升级补充而持续迭代
二、benchmark 演进
1.1 跨领域泛化
Spider 提出跨领域的设定，核心就是训练库和测试库不重叠，模型不能靠背某个库的表结构蒙对，必须真的读懂当前 schema
1.2 迈向真实、混沌的业务场景
BIRD 把测试的库换成了真实世界的脏库，有些字段可能还需要外部知识才能理解。在这一设置下，当时学术界的 SOTA 便很快露怯：人类执行准确率 92.96%，而模型只有 40.08%
这个差距说明难点不在 SQL 语法本身，而在数据库知识。列名缩写意味着什么、脏值怎么处理、业务口径从哪查
Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs（NeurIPS 2023）
1.3 上下文瓶颈
既然缺的是数据库的解释信息，那自然的想法是把 schema、样例、业务文档全塞进提示里。这一做法在中小规模的库上确实有效，但在真实的企业级环境中，可能有上千列的 schema、繁琐的业务文档、需要基于业务知识做拆分规划的查数任务等，让信息量超出单次提示能承载的范围
Spider 2.0 就是从真实生产环境中，整理出的跨库、跨项目、承载业务复杂性的 NL2SQL 基准，要求模型与复杂的 SQL 工作流环境交互，处理极长的上下文、执行复杂推理，生成的 SQL 语句通常超过 100 行。之前在 Spider 上能拿 91 分、BIRD 上拿 73 分的智能体，到 Spider 2.0 只有 21 分
到这一步，任务已经被重新定义了：不是 "把问题翻译成 SQL"，而是 "给你一个库，自己去摸清楚"。要先看有哪些表、查 schema、试探性地跑几条查询、看报错、再改
Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows（ICLR 2025 Oral）
三、解决方案
2.1 推理时扩展与模型训练
基准建好后，解决方案随之迭代出来。传统学术玩具、简单依赖大模型零样本能力的做法在 Spider 2.0 上基本不可行，优化方案主要有两类：
- 推理时修正： 不改模型权重，在推理阶段加流程堆效果，如列探索、自我修正、多次采样取共识等。代表是 ReFoRCE，当时登顶 Spider 2.0 榜单
- 训练模型： 把能力内化进模型。OmniSQL 走大规模高质量合成数据，Arctic-Text2SQL-R1 用执行结果当奖励做强化学习
ReFoRCE: A Text-to-SQL Agent with Self-Refinement, Consensus Enforcement, and Column Exploration
OmniSQL: Synthesizing High-quality Text-to-SQL Data at Scale（PVLDB 2025）
Arctic-Text2SQL-R1: Simple Rewards, Strong Reasoning in Text-to-SQL
尽管有了初步的效果，但这两类方案都面临缺陷：训练与推理不一致。在训练或调试推理流程时，基于 <问题，SQL> 对，模型被要求一次性输出完整答案并保证正确性；而部署时面对的是有状态的交互环境：查表、处理报错、检查执行状态等，这些能力难以训练或调试到位。换言之，基准演进推动了测试样本 更接近生产场景，但测试环境上依然存在明显的不一致
2.2 环境对齐
HarnessSQL 是港大、微软、清华等机构开源的 NL2SQL 的环境基座，它让数据采集、模型训练和最终评测跑在同一套交互接口上
HarnessSQL: Harness-Native Training for SQL Agents in Realistic Database Environments
理想的 NL2SQL 系统应当包含数据库和交互接口，接收输入问题并agent 反复调用接口、看返回、规划下一步，这是静态训练解决不了的，后者只监督最终那条 SQL，中间怎么探索、什么时候收手没人教，训练里从没见过报错和空结果，学到的输出方式和部署时能调用的工具无关
HarnessSQL 基于 DeepSeek Harness 实现，关闭 shell、读写文件、跑代码、联网、子 agent 等能力，只留数据库相关的四个工具：
sql_list_tables：看库里有哪些表、每张表多少行sql_schema：看某张表的建表语句和几条样例数据sql_exec：跑一条只读查询，拿到结果或报错sql_submit：交卷
基于 Spider 2.0-Lite、Spider 2.0-DBT 共 79 个库构造数据：先采样一条可执行的 SQL（按难度控制），再从它反推自然语言问题和标准执行过程，清洗后得到 2512 条多轮轨迹作为训练数据。训练时先 SFT 冷启动然后用 DAPO 在 Harness 环境中做强化学习
训练数据构造环境与真实情况完全一致，都是运行在 Harness 管线中，甚至保留了语法报错、环境失败等情形。更一般地，77.83% 的 SFT 轨迹包含至少一次失败的中间查询，99.92% 包含查询修订
四、评测 agent 化
在 NL2SQL 开始用 agent 多轮探索解决业务问题的同时，评测流程也逐渐 agent 化
BIRD-Interact 进一步把动态交互引入评测。它不再假设用户一开始就能准确描述需求，而是通过 Function-driven User Simulator 模拟用户：先提出含糊的需求，Agent 可以主动追问，用户根据预设的业务知识回答；Agent 也可以探索数据库、查询文档，或者在 SQL 执行失败后进行修正
它提供两种评测模式：一种是按照既定对话流程进行澄清，另一种允许 Agent 自主规划交互顺序，考察 Agent 能否在有限的交互预算下理解需求，并正确完成整个任务
BIRD-Interact: Re-imagining Text-to-SQL Evaluation via Lens of Dynamic Interactions（ICLR 2026 Oral）