← 返回 PaperDaily 大模型与智能体

IBM提出GradeSQL：Text-to-SQL测试时验证提升4.33%

Text-to-SQL 最怕的不是“写不出来”，而是“写出来也不一定对”。这篇论文把验证器搬到测试时，用学出来的语义打分替代拍脑袋规则，思路很朴素，但确实更像工程上能落地的解法。

龙哥读论文发布于 2026-08-17 00:20:05 阅读 3 查看原文

#NLP

🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！ 👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
Text-to-SQL 最怕的不是“写不出来”，而是“写出来也不一定对”。这篇论文把验证器搬到测试时，用学出来的语义打分替代拍脑袋规则，思路很朴素，但确实更像工程上能落地的解法。

原论文信息如下：

论文标题:
Test-Time Verification for Text-to-SQL via Outcome Reward Models 发表日期:
2026年06月发表单位:
Polytechnic University of Bari; IBM T.J. Watson Research Center 原文链接:
https://arxiv.org/pdf/2606.31567v1.pdf 开源代码链接:
https://github.com/GradeSQL/GradeSQL 项目链接:
https://gradesql.github.io

测试时推理的新思路：从启发式到学习型验证

Text-to-SQL 看起来像“把人话翻成数据库语言”，实际更像在和细节掰手腕：少一个条件、多一个表、一个字段名对不上，结果就可能完全跑偏。传统做法常常靠启发式选择，比如谁能执行、谁返回非空、谁出现得更频繁，就把谁拎出来当答案。问题也很直白：能跑，不等于对；看起来像，不代表真懂。

这篇论文的切入点很朴素，也很工程：既然测试时会生成一堆候选 SQL，那就别再只靠“拍脑袋规则”挑答案，而是训练一个会打分的验证器，让它学会判断哪个候选更接近题意。这个验证器不是单独发明一套新模型，而是把现成的 Outcome Reward Model，ORM 用在结构化查询生成上。ORM 的英文全称是 Outcome Reward Model，中文可理解为“结果奖励模型”或“结果打分模型”，它给完整输出一个分数，而不是只盯着中间步骤。

这就把 Text-to-SQL 的测试时推理，悄悄从“谁更像正确答案”升级成了“谁更值得信任”。听起来像一句废话，落到工程里却很实在：如果验证器真能学到语义差异，就能比执行成功、结果频率这类粗信号更稳地筛掉“表面正确、实际翻车”的 SQL。🤨

GradeSQL框架：三步法构建SQL验证器

论文把这套方法命名为 GradeSQL，核心不是“再造一个更大的生成模型”，而是围绕验证器搭一条能自动造数据、自动打标、自动训练的流水线。它的逻辑很像训练一个“SQL 裁判”：先让裁判看很多候选，再告诉它哪些真对、哪些假对，最后让它在测试时替大家做选择。

图1：GradeSQL 训练 ORM 的整体框架。流程分成三步：候选生成、执行打标、监督微调。图里最关键的信息其实只有一句话——验证器不是凭空学出来的，而是从大量候选 SQL 的“执行结果”里长出来的。

第一步是候选生成。给定问题和数据库结构，基础大模型会生成一组 SQL 候选，论文里用随机采样来增加多样性。这个设计很重要，因为验证器最怕只见过“同一种错法”。候选越丰富，越能逼着验证器学会区分“语义正确但写法不同”和“看着像对其实差一点”。

第二步是自动打标。每个候选 SQL 都会被执行，如果它和标准答案返回的结果集一致，就标为正确；如果执行报错，直接丢掉；如果能执行但结果不同，就标为错误。这里的关键缩写是 SFT，Supervised Fine-Tuning，监督微调：也就是把这些自动生成的“对/错”样本拿去微调验证器。

第三步是验证器训练。论文没有把它做成一个硬分类器，而是把“是否正确”写成一个自回归生成任务：输入问题、数据库结构和候选 SQL，模型输出 Yes 或 No。训练时使用的是 LoRA（Low-Rank Adaptation，低秩适配）做参数高效微调。推理时，模型不直接拍板，而是读取“输出 Yes 的概率”作为分数，谁分高谁上位。

图2：ORM 参与测试时推理的选择流程。候选 SQL 先由生成器批量产出，再交给 ORM 逐个打分，最后选分数最高的那个。这个过程没有额外环境交互，也不需要把数据库结果拿来回算一遍，属于很典型的“把算力花在刀刃上”。

论文这里的思路其实挺聪明：执行信号只告诉系统“结果对不对”，但 ORM 试图学习“为什么这个候选更像正确答案”。这意味着它不仅能识别显式错误，还能对一些“多表连接方向不太对”“过滤条件差一点”“子查询层级跑偏”的候选给出更低分。换句话说，验证器不再只是数据库门口的保安，而是开始学会看门牌号、看路线图、看是不是走错楼层。😂

实验结果：ORM一致超越传统方法

论文把实验放在两个经典跨领域基准上：Spider 和 BIRD。前者是 Text-to-SQL 的老牌标尺，后者更贴近真实数据库查询场景，难点都不轻。评价指标主要看 Execution Accuracy，EX，执行准确率，也就是预测 SQL 和标准 SQL 是否返回相同结果；另外还看 Pass@N，表示 N 个候选里至少有一个是对的。

表2：ORM 与传统测试时选择方法的对比结果。可以看到，ORM-based Best-of-N 在 BIRD、Spider dev 和 Spider test 上都拿到了最高执行准确率，并且相较于基线和启发式方法都有稳定提升。

最值得看的不是“涨了多少点”这件事本身，而是它的稳定性。论文里，ORM 在 BIRD dev 上比基线提升到 68.90%，在 Spider test 上也达到 87.47%。和执行式 Best-of-N、Majority Voting 相比，它不是偶尔赢一次，而是几乎每个设置都更稳。对于工程系统来说，这种“每次都多一点”的提升，往往比某次实验里突然暴涨更有价值，因为它更像可复制的收益，而不是运气开挂。

论文还做了一个很老实的复现检查：先复现生成器 OmniSQL-7B 的原始结果，确认自己的实验环境和公开结果差距不大，再把 ORM 加进去比较。这个动作不花哨，但很关键。很多方法不是输在模型不行，而是输在实验链路不干净；这篇至少把“是不是自己复现歪了”这件事先排掉了。

表1：OmniSQL-7B 复现结果对比。复现值与原始结果基本接近，说明后续 ORM 带来的提升更可信，不太像是“环境抖了一下”的假象。

还有一个容易被忽略但很有意思的点：ORM 的提升并不依赖特别大的验证器。论文里拿不同骨干模型训练 ORM，结果整体很接近，说明这个方法的收益更多来自“验证信号更聪明”，而不是“模型更大更能打”。这对实际落地很友好，因为它暗示验证器不一定非得上超大号，轻量一些也能干活。

深入分析：ORM在复杂查询和更大候选集上表现更优

如果只看总分，容易把这篇论文看成“又一个小幅涨点的方法”。但真正有价值的地方，在于它解释了为什么 ORM 会在复杂场景里更占优。Text-to-SQL 的难点本来就不是简单问答，而是多表连接、嵌套子查询、约束条件叠加这些“组合拳”。启发式规则在这种地方很容易失灵，因为它只能看表面症状，看不懂语义结构。

图3：不同候选集规模下三种选择策略的表现。随着候选数 N 增加，ORM-based Best-of-N 持续受益，而执行式 Best-of-N 和 Majority Voting 很快就出现了收益变平的情况。

图3 说明了一个很现实的问题：测试时多采样，不等于多采样就能更强。如果选择器本身不够聪明，候选再多也只是把“垃圾堆”扩容；而 ORM 能把更多候选变成更多有效信息，所以当 N 增大时，它的收益更稳定，也更接近 oracle 上限。简单说，别人的 Best-of-N 像“在一堆答案里碰运气”，ORM 更像“在一堆答案里认真挑”。

论文还专门分析了难度分层。简单问题上，三种方法差距不算特别夸张，因为本来就容易；但在中等和困难问题上，ORM 的优势更明显。原因也不难理解：简单题靠规则就能蒙对，难题才真正考验“语义辨别力”。越复杂的 SQL，越容易出现“执行结果碰巧对了，但语义其实不对”这种坑，而 ORM 正是冲着这个坑来的。

表8：不同训练提示对 ORM 的影响。结果显示，直接给 SQL 结构的提示更有效，说明验证器最需要的不是长篇大论，而是把候选 SQL 本体喂进去，让它学会盯住结构差异。

另一个值得说的分析是“验证器要多大才够”。论文把 ORM 从 7B 扩到 14B、32B，结果提升并不稳定，甚至有时更大模型还不如 7B。这个结论很有现实味道：验证器不是越大越灵，超过某个规模后，收益会明显递减。这也从侧面说明，当前瓶颈更多在训练信号和候选质量，而不是单纯堆参数。

表10：自回归微调与 BCE 的对比。论文发现，把验证任务当作自回归生成来学，效果比直接做二分类更好，尤其在中等和困难问题上更明显。

这点其实挺有启发。很多人会本能地觉得“验证不就是分类吗”，但论文告诉大家，把验证写成生成式目标，反而更能捕捉语义边界。原因可能在于，自回归训练保留了语言模型原本擅长的序列建模能力，而不是把它硬掰成一个只会吐 Yes/No 的按钮机。对于复杂结构化任务，按钮机往往不如“会思考的按钮机”。😏

总结与展望：简单有效，为结构化推理提供新方向

这篇论文最值得肯定的地方，不是“发明了一个前所未有的大模型结构”，而是把一个老问题讲清楚了：测试时选择策略，完全可以从启发式走向学习型。GradeSQL 的价值在于，它给 ORM 提供了一个可复制的数据构建方式，也给 Text-to-SQL 的 test-time scaling 提供了更像样的判别器。

不过，这个方向也不是没有边界。首先，ORM 的训练依赖候选生成和执行打标，意味着它的上限仍然受生成器质量影响；其次，执行等价并不总能完美代表语义等价，某些复杂数据库场景里可能会有“结果一样但语义不完全一样”的灰区；最后，离线训练虽然能摊薄成本，但对数据、数据库执行环境和流程稳定性还是有要求。换句话说，它很实用，但不是“装上就无敌”。

如果把眼光放宽一点，这套思路不只适合 Text-to-SQL。任何“先生成一堆候选，再从中挑最靠谱的”任务，都可能从学习型验证器里受益，比如代码生成、检索增强问答、结构化规划等。只要候选之间存在细粒度差异，而启发式规则又不够聪明，就有 ORM 的用武之地。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是 Text-to-SQL 在测试时“怎么从多个候选里选出更靠谱答案”的问题。以前很多方法靠执行结果、投票次数这类粗规则，现在论文改成训练一个 ORM 来学语义打分，选择会更细。

ORM 和普通分类器有什么区别？这里的 ORM 不是简单输出“对/错”，而是把候选 SQL、问题和数据库结构一起输入，再输出 Yes 的概率作为分数。它更像一个会排序的验证器，而不是只会判死刑的法官。

为什么复杂查询上提升更明显？因为复杂查询里的错误更隐蔽，启发式规则很难分清“看上去能执行”和“语义真的对”。ORM 学到的是更细的语义差异，所以在多表连接、嵌套子查询、约束条件多的场景里更占便宜。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★☆☆

创新点不在“发明全新理论”，而在把 ORM 很自然地接到 Text-to-SQL 的测试时验证链路上，思路实用，但不是那种一眼惊艳的结构创新。

实验合理度：★★★★☆

对比了启发式选择、不同候选规模、不同骨干和不同提示，设置比较完整；复现生成器结果也做了检查，整体比较可信。

学术研究价值：★★★★☆

它给结构化推理中的 test-time verification 提供了可落地范式，尤其对“候选多、选择难”的任务有参考意义。

稳定性：★★★★☆

跨模型、跨数据集表现较稳，且轻量 ORM 也能工作；但依赖候选质量和执行打标，边界仍然存在。

适应性以及泛化能力：★★★★☆

方法对不同生成器和不同规模候选集都能用，泛化不错；但对非结构化任务是否同样有效，还需要更多验证。

硬件需求及成本：★★★☆☆

推理阶段成本不高，但训练阶段需要批量生成候选并执行标注，离线成本不算小；好在可摊薄到后续大量查询上。

复现难度：★★★★☆

代码、数据和模型已公开，复现门槛不高；主要难点在于数据库执行环境和候选生成链路要搭得干净。

产品化成熟度：★★★☆☆

适合接入现有 Text-to-SQL 系统做 rerank/verifier；但要进生产，还得看数据库复杂度、响应时延和错误容忍度。

可能的问题：提升幅度不算夸张，且依赖执行打标与候选多样性；如果生成器本身太弱，验证器也很难凭空救场。

主要参考文献

[1] Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia. Test-Time Verification for Text-to-SQL via Outcome Reward Models. arXiv:2606.31567v1, 2026.

[2] GradeSQL 项目主页：https://gradesql.github.io

[3] 开源代码：https://github.com/GradeSQL/GradeSQL

SQL 不是只会“写”，还得会“验”！如果也想持续追踪这类能落地、能提效、还能少踩坑的论文，欢迎加入龙哥读论文星球，每天少读一点废话，多看一点真东西。

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称，方便更快通过并拉进对应交流群。
图像处理、大模型、机器人、医疗、金融都能找到同路人，别让自己在论文海里单打独斗。
wechat_helper