Text-to-SQL中的“纪录”有何危险
每个月都会出现新的声明，称又一款LLM在SQL基准测试上几乎与人类持平。但仔细看，这些数字背后隐藏着截然不同的条件：有人使用简单的提示词且不访问数据库，有人允许模型迭代执行查询，还有人将推理直接嵌入模型权重。直接比较这些结果，就像把一辆带机械师的汽车和一辆能在行驶中自我修复的无人驾驶汽车放在一起比较。
arXiv上最新预印本（2608.15389）的作者正是关注到了这个问题。他们提议不再用排行榜上抽象的高度来衡量“进步”，而是首先诚实地记录系统在生成SQL时拥有多少自主性。没有这样的限定，任何工作之间的比较都会变得不稳定：基准测试、基础模型甚至推理协议的细微变化都可能改变结论。
自主性轴：从提示词到自给自足的智能体
研究人员没有简单地将所有数字汇总到一张表中，而是重新定义了Text-to-SQL领域本身，将其视为“排行榜聚合”。他们收集系统作者自行报告的指标，并将其沿着推理自主性轴展开。由此得到五个层级：
- 受限生成 — 模型仅从严格受限的合法查询空间中挑选答案，通常带有外部语法检查。
- 上下文内生成 — SQL在单次遍历上下文（含示例和模式描述）时构建。
- 迭代生成 — 系统可进行多次尝试，根据执行结果或数据库响应来细化查询。
- 智能体生成 — 模型像智能体一样工作：自行探索数据库模式、运行查询、对错误做出反应并规划后续步骤。
- 推理内化生成 — “推理”预先嵌入模型中，因此在推理时直接输出查询，无需外部编排或中间步骤。
这样的标尺并不表示某一层级“优于”另一层级。它只是明确了公平比较的条件：不能将具有内部推理的系统与单纯的单次输出模型相提并论，同样，有权执行查询的智能体回路也不应与未被赋予该权利的模型进行比较。
重要的是，这种排行榜的每个单元格都保留了指标的可追溯来源。这意味着读者总能理解是哪种具体配置产生了结果，而不是试图从实验部分的片段中猜测。
Spider及其之外的实验揭示了什么
为了将指标聚合与现实挂钩，作者在Spider基准上进行了针对性研究。他们比较了开源的8B模型（有和没有CoT监督）与基于DeepSeek V3和GLM-4的few-shot基线。有趣的是，他们使用的是few-shot协议而非完整的微调版本，因此对比相当干净。
从实验中提炼出对实践者至关重要的四个模式。
首先，在Spider上获得的改进向BIRD和Spider 2.0的迁移并不均匀。模型可能在一组查询上表现亮眼，在另一组上却几乎毫无进展。这再次证实：盲目追逐单一热门基准上的统一分数会制造整体进步的假象。
其次，自主性增加了鲁棒性，但代价不容小觑。智能体回路确实能更好地处理多步骤和模糊任务，但token消耗和执行时间显著增加。如果对交互式分析师来说这种代价是合理的，那么对批处理而言，它可能吞噬掉因错误减少而带来的全部收益。
第三，推理内化模式出人意料地处于中间位置。它介于“盲目”解码答案（无推理）和外部编排的智能体之间。对于许多任务，这种模式几乎能达到智能体级质量，却无需构建复杂的工具回路。尽管并不存在通用的“免费午餐”：内化推理也有其自身的局限性。
第四，CoT监督带来的收益集中在Hard和Extra-Hard级别的查询上。在简单问题上，差异几乎不可见甚至为负——当答案一目了然时，模型何必出声思考？但在复杂的多步骤任务上，能够口头陈述步骤的能力带来了显著优势。这对构建SQL助手的人来说是个重要信号：应将额外的计算资源集中在高复杂度查询上，而不是浪费在典型的简单案例上。
如何在实际中运用这一标尺
这项工作最有用的成果甚至不是分类法本身，而是作者随预印本一同发布的公开Python测试框架。该框架复现了自主性轴，并允许在不重写整个环境的情况下向排行榜添加新方法。如果你正在开发另一种Text-to-SQL方法，只需指明它在哪个自主性层级运行——社区就能在公平条件下将你与之前的系统进行比较。
当然，基于自行报告指标的聚合仍然需要谨慎对待。并非所有人都有预算复现他人的实验，但统一的标注已是向前迈出的一大步。与此同时，在阅读又一个“state-of-the-art”时，请在脑海中记住一个简单的问题：模型在生成查询时到底能做什么？如果这个问题没有答案，那么论文中的数字就只是一个没有坚实支撑的漂亮数字。
