← 返回 PaperDaily 大模型与智能体

IBM巴里理工新作：ORM给Text-to-SQL做验证，最高提4.33%

Text-to-SQL 真正难的不是“生成”，而是“别把错答案挑成正确答案”。这篇论文把 ORM 拉进测试时验证，思路很朴素，但效果相当能打。

龙哥读论文发布于 2026-08-14 09:11:00 阅读 3 查看原文

#大语言模型 #人工智能

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

龙哥导读：
Text-to-SQL 真正难的不是“生成”，而是“别把错答案挑成正确答案”。这篇论文把 ORM 拉进测试时验证，思路很朴素，但效果相当能打。

原论文信息如下：

论文标题:
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.31811v1.pdf 开源代码链接:
Code1 开源数据集链接:
datasets2 项目链接:
models3

测试时验证的新探索：用ORM替代启发式策略

Text-to-SQL 看起来像“把人话翻成 SQL”这么简单，真正难点却藏在最后一步：同一批候选答案里，怎么把最靠谱的那个挑出来。很多系统在测试时会生成一堆 SQL，再靠执行是否成功、结果集是否非空、或者多数投票来拍板。问题也很直白：这些信号太粗糙，能判断“像不像能跑”，却不一定能判断“语义对不对”。

这篇论文的核心想法很朴素，也很实用：让 Outcome Reward Model，简称 ORM，来做测试时验证。ORM 的英文全称是 Outcome Reward Model，中文可以理解为“结果奖励模型”或者“结果评分模型”。它不是去看中间推理过程，而是直接给完整输出打分：这个 SQL 到底有多像正确答案。

图2：基于 ORM 的推理流程。先由大模型生成多个候选 SQL，再由 ORM 对每个候选进行排序，最后选出得分最高的那个。

这个流程听上去像“再加一个裁判”，但价值在于裁判的判分标准更聪明。执行验证只能告诉系统“这个 SQL 能不能跑出和金标准一样的结果”，多数投票只能告诉系统“大家都觉得谁更像对的”。而 ORM 学的是一种更细的语义判断：候选语句是否真正贴合问题意图、是否更像一个正确的结构化查询。对于多表连接、嵌套子查询、约束条件很细的题目，这种判断比“能跑”更关键。

论文没有把 ORM 包装成什么玄学新玩具，而是把它放进一个很工程化的测试时框架里：生成、筛选、重排。说白了就是，让模型多写几份草稿，再找一个更懂 SQL 的“阅卷老师”挑卷子。这比单纯赌一次生成结果靠谱得多。

GradeSQL揭秘：一个自动化的验证器训练框架

问题来了：ORM 想当裁判，总得先学会怎么判。可 Text-to-SQL 领域的验证数据本来就稀缺，人工标注“这个候选 SQL 对不对”又慢又贵。论文给出的答案叫 GradeSQL，它不是一个新模型，而是一个自动化训练 ORM 的数据构建框架。

图1：GradeSQL 框架总览。整个流程分为三步：候选生成、数据标注、监督微调。

第一步是候选生成。给定自然语言问题和数据库结构，生成模型一次吐出多个 SQL 候选。这里的关键不是“只生成一个看上去最顺眼的”，而是故意让候选池更丰富，因为验证器只有见过足够多的“对的、错的、半对不对”的例子，才学得会分辨。

第二步是数据标注。论文采用的是执行等价标注：把候选 SQL 跑到数据库里，如果结果集和金标准一致，就标为正确；否则标为错误。执行报错的候选会被丢掉。这个策略的好处很现实：不用人工一条条判题，也能快速构造出大规模训练集。

第三步是监督微调。这里的 ORM 被训练成一个二分类器，输入是“数据库结构 + 问题 + 候选 SQL”，输出只有两个词：Yes 或 No。论文还用了 LoRA（Low-Rank Adaptation，低秩适配）来做参数高效微调。LoRA 的意思很简单：不把大模型全身上下都拧一遍，只在少量低秩参数上动刀，省显存，也省训练成本。

表3：BIRD 和 Spider 训练集统计。可以看到，经过去重和候选扩增后，标注数据规模明显变大，但类别分布并不完全平衡，这也为后面的消融实验埋下了伏笔。

这个框架最值得肯定的地方，不是“把 ORM 训练出来了”，而是把训练 ORM 这件事做成了流水线。很多论文喜欢说“我们提出一个 verifier”，但真到数据环节就开始含糊。GradeSQL 则把数据从哪来、怎么标、怎么训说清楚了，这才是能落地的关键。

优势何在？ORM vs. 多数投票与执行验证

论文最直接的比较对象有两个：多数投票和基于执行的 Best-of-N。前者靠“大家投谁”，后者靠“谁能执行、谁返回结果”。这两种方法都不算错，但都偏粗。

表2：OmniSQL-7B 在 BIRD、Spider dev 和 Spider test 上的执行准确率。ORM-based Best-of-N 在三个数据集上都优于执行验证和多数投票，提升幅度最高达到 BIRD 上的 +4.33% 和 Spider 上的 +2.10%。

为什么 ORM 更强？因为它不是只看“结果像不像”，而是学习“这个候选为什么更像正确答案”。执行验证会被很多细节坑到：有些 SQL 虽然能跑出非空结果，但语义其实偏了；有些 SQL 和金标准结果一样，却只是碰巧撞上了。ORM 学到的是更细粒度的判别信号，因此在复杂查询上更占便宜。

更关键的是，ORM 不是靠“改生成器”取胜，而是靠“改选择器”取胜。这个思路很有工程味：生成模型不动，测试时多花一点验证成本，就能换来更稳定的输出质量。对于实际系统来说，这比重新训一个更大的生成模型要现实得多。

图3：BIRD dev 上，不同候选数量 N 下三种方法的执行准确率对比，并按题目难度分层。可以看到，ORM-based Best-of-N 在复杂题上优势更明显。

这里有个很重要的现象：候选越多，ORM 越能发挥价值。原因不难理解。候选池越大，里面混进来的“差不多对”“结构像但语义歪”的 SQL 就越多，单靠执行结果或投票更容易糊成一锅。ORM 反而能从一堆半吊子候选里，挑出那个更接近语义正确的答案。

论文还给了一个很实在的结论：在大多数设置下，ORM 的改进是稳定的，不是某个数据集上偶然“炸了一下”。这说明它不是靠某次幸运抽样赢的，而是确实学到了可迁移的语义评分能力。

深入剖析：消融实验与大模型扩展性

一篇方法论文到底能不能站住脚，最后还是要看消融。论文在这部分没有玩虚的，主要看了三件事：候选数 N、训练数据是否平衡、换更大的生成器会不会更强。

表6：不同候选数 N 下，执行验证、多数投票和 ORM-based Best-of-N 的对比。ORM 随着 N 增大持续受益，而启发式方法很快就趋于饱和。

这其实很符合直觉。候选数少的时候，大家差距不大；候选数一多，真正厉害的选择器才开始拉开差距。执行验证和多数投票都像“看表面现象”，而 ORM 更像“看门道”。所以 N 增大后，ORM 离上限更近，说明它更会从候选池里“捞金子”。

表5：平衡与非平衡训练集的效果对比。总体变化不大，说明 ORM 对类别偏斜比较稳；同时，平衡训练还能明显减少训练样本规模，训练成本更低。

这部分最值得记住的一点是：数据平衡并没有把性能搞崩。这意味着 ORM 不是那种“喂得越多越乱、稍微偏一点就翻车”的脆弱模型。对工程落地来说，这个特性很重要，因为训练 verifier 时，数据构造往往很难天然均衡。

表7：当候选由 7B、14B、32B 生成器产生时，ORM 依然稳定有效。更大的生成器能提高候选质量，但 ORM 仍然能在此基础上继续提升最终准确率。

这说明 ORM 不是只会“捡漏小模型的烂摊子”。即便生成器换成更大的 14B 或 32B，ORM 依然能继续把候选池再筛一遍，而且还能带来稳定收益。换句话说，生成器越强，ORM 越像锦上添花；生成器一般，ORM 更像救命稻草。

表8：验证提示词设计消融。不同提示词会影响 ORM 的判断质量，说明 verifier 不是“随便问一句就行”，而是对输入组织方式比较敏感。

表10：自回归目标与二元交叉熵微调的对比。结果显示，训练目标的选择会影响不同难度题目的表现，说明 ORM 的训练方式也不是完全“随便配方就能出锅”。

综合这些消融，论文给出的结论比较一致：ORM 的效果不是偶然堆出来的，而是候选池、训练数据、提示词和训练目标一起配合出来的。这类结果虽然没有“惊天动地”的戏剧性，但反而更可信，因为它告诉读者哪些地方真的重要，哪些地方只是表面热闹。

总结与启示

这篇论文最有价值的地方，不是发明了一个神秘新模块，而是把一个很常见、但经常被忽略的问题说透了：测试时到底该靠什么挑答案。在 Text-to-SQL 这种结构化任务里，启发式策略容易“看起来合理，实际上粗糙”；ORM 则提供了一个更语义化、更可训练的替代方案。

如果把这篇工作放到更大的图景里看，它其实在讲一个很现实的趋势：大模型系统的竞争，正在从“谁会生成”转向“谁更会验证”。生成器负责铺量，验证器负责提纯。以后很多任务未必需要把生成模型卷到天上，反而更需要把测试时选择机制做扎实。

当然，这套方法也不是没有代价。它需要额外的候选生成和离线训练，推理时虽然不改生成器参数，但仍然增加了测试时计算；而且 ORM 的判断质量高度依赖训练数据的覆盖范围。换句话说，它适合“候选很多、验证很关键”的场景，不适合所有任务一股脑照搬。

对做研究的人来说，这篇论文也有一个很清晰的启发：别总盯着“生成得更像人话”，有时候“挑得更像答案”更值钱。对做产品的人来说，它提醒了一件更朴素的事：在高风险结构化任务里，验证器往往比生成器更能决定系统上限。

龙迷三问

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

这篇论文到底解决了什么问题？它解决的是 Text-to-SQL 测试时“从一堆候选里挑谁最靠谱”的问题。论文证明，ORM 这种学出来的验证器，比多数投票和执行启发式更会挑答案。

ORM 和执行验证有什么区别？执行验证看的是“能不能跑、结果像不像”，ORM 看的是“语义上像不像对的”。前者是粗筛，后者是精筛，所以在复杂 SQL 上更有优势。

GradeSQL 为什么重要？因为它把 ORM 的训练数据自动化了。没有这个框架，验证器就容易停留在概念层；有了它，ORM 才能在 BIRD 和 Spider 这类数据集上真正训练起来并发挥作用。

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

龙哥点评

论文创新性分数：★★★☆☆。ORM 本身不是新概念，但把它系统化地放进 Text-to-SQL 测试时验证，思路是对的，也有实际价值。

这个创新更像“把该做的事做扎实”，而不是发明全新范式。

实验合理度：★★★★☆。对比了多数投票、执行验证和 ORM-based selection，候选池也控制得比较统一，实验设计比较干净。

不足是主要依赖固定生成器，虽然公平，但也意味着结论更多是在“选择器层面”成立。

学术研究价值：★★★★☆。对测试时验证、奖励模型、结构化推理都有启发，尤其适合后续继续研究 verifier 训练与候选重排。

它不是理论大开山，但方向很扎实。

稳定性：★★★★☆。跨模型、跨数据集表现较稳，平衡与非平衡训练也没明显翻车。

不过它仍依赖候选生成质量，生成器太差时，验证器也只能在垃圾堆里挑相对不那么垃圾的。

适应性以及泛化能力：★★★★☆。对不同模型家族都能工作，说明泛化不错。

但当前验证对象主要还是 Text-to-SQL，跨任务迁移还需要额外验证。

硬件需求及成本：★★★☆☆。离线训练 verifier 需要额外算力，候选生成也会增加测试时开销。

好在推理阶段不必改生成器参数，属于“能花钱换效果”的类型。

复现难度：★★★★☆。论文给了代码、数据和模型链接，实验流程也比较清晰。

真正麻烦的地方主要在候选生成和执行标注的工程细节，而不是算法本身。

产品化成熟度：★★★☆☆。适合做 Text-to-SQL 系统里的候选重排器或验证模块。

如果数据库变化快、执行环境复杂，仍需额外做鲁棒性和延迟优化。

可能的问题：方法提升不算夸张，但很实用；局限是强依赖候选池质量，且验证器训练数据的覆盖面决定上限。

如果候选本身太差，ORM 也只能在有限空间里做优化，别指望它凭空变出答案。

主要参考文献

Tritto, M., Farano, G., Di Palma, D., Rossiello, G., Narducci, F., Subramanian, D., & Di Noia, T. Test-Time Verification for Text-to-SQL via Outcome Reward Models. arXiv:2606.31811v1, 2026.

原文链接：https://arxiv.org/pdf/2606.31811v1.pdf

开源代码：Code1

开源数据集：datasets2

项目链接：models3

*SQL 不是越会写越稳，关键是会不会挑对答案。想继续看这种“测试时加脑子”的论文，欢迎加入龙哥读论文星球，前沿论文、开源代码、招聘信息一站式更新～

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群