这项由韩国电子通信研究院（ETRI）、首尔国立大学与Snowflake AI Research联合开展的研究，以预印本形式于2026年4月28日发布在arXiv平台，论文编号为arXiv:2604.25325。感兴趣的读者可通过该编号检索完整论文。
**研究背景：一场关于"翻译"的挑战**
每天都有无数人对着各种数据库系统提出这样的问题——"今年销售额最高的产品是什么？"或者"哪位客户购买次数最多？"。对普通人来说，这些问题听起来再自然不过，但数据库只懂一种语言：SQL（结构化查询语言）。SQL看起来像这样：`SELECT product_name FROM sales ORDER BY revenue DESC LIMIT 1`，完全不是人类日常说话的方式。
"Text-to-SQL"技术的使命，就是充当这两种语言之间的翻译官——把人类的自然语言问题自动转化为计算机能执行的SQL语句。随着大型语言模型（LLM，可以理解为具有强大语言理解能力的AI）的崛起，这项技术有了质的飞跃。现代系统通常采用一种策略：先让AI同时生成一批候选SQL语句（就像同时请十个翻译给出不同版本的翻译），然后由另一个评审程序从中挑选最好的一个。
这篇论文的研究团队发现，这种"生成再筛选"的流程存在两个根本性的漏洞，并为此设计了一套名为**R?-SQL**（Ranking Reward and Resampling for Text-to-SQL，即"排名奖励与重采样"）的解决方案。在业内广泛使用的BIRD数据集评测中，R?-SQL以75.03%的执行准确率创下了使用公开规模模型的方法中的最高纪录。
---
一、两个让"翻译官"频频出错的顽固毛病
要理解这个研究在解决什么问题，先来看一个生活中的类比。假设你是一家餐厅的老板，你想知道"本月哪道菜最受欢迎"。你雇了十个助理，每人各写了一份调查报告给你，其中有几份报告的结论其实是完全一样的——都说"红烧肉"最受欢迎——只是措辞和格式略有不同。你还找了一个审核员来评判哪份报告写得最好，准备依据最高分的报告做决策。
这里就出现了第一个毛病，研究团队称之为"功能不一致性"。审核员因为写法不同，给说同一件事的报告打了不同的分数——也许某份措辞更流畅的报告得了高分，但那份报告恰好搞错了数据，而措辞稍显笨拙但结论正确的报告却得了低分。在SQL的世界里，同一个问题可以用多种完全等效的写法来表达，执行结果完全相同，但评分系统却因为写法不同而给出截然不同的评分。这就导致正确答案可能因为"表达方式不够优雅"而被错误地排在后面。
现有的一种补救方法叫做"功能多数投票"（FMV）：先把执行结果相同的SQL语句归为一组，然后看哪组人数最多，就选哪组。但这个方案有一个致命弱点——如果错误答案那组人数更多，正确的少数派就会被压制。回到餐厅的比喻：如果六个助理都写了"青椒肉丝"（但实际上是错的），四个助理写了"红烧肉"（才是正确的），多数投票就会错选"青椒肉丝"。
第二个毛病叫做"有限召回"（bounded recall）。这个问题更加根本：如果十个助理里，没有任何一个写出了正确答案，那么不管评审员水平多高、方法多精妙，最终的选择都必然是错误的。这在信息检索领域早有研究，但在SQL自动生成这个场景里，却一直没有人系统地解决它。就像是警察局里，如果凶手的名字从未出现在嫌疑人名单上，再厉害的侦探也无从破案。
---
二、R?-SQL的核心思路：给候选答案做"家族归类"再"能力比武"
研究团队针对这两个毛病，设计了一套两阶段的应对策略，整体逻辑可以用"先扩大侦查范围，再精准锁定目标"来理解。
**解决功能不一致性：按执行结果分组，组与组之间展开较量**
R?-SQL的第一步，是把所有候选SQL语句按照执行结果进行分组。执行结果完全相同的语句被划入同一个"家族"。这样一来，评分的对象从单个SQL语句变成了"家族"。同一家族内部的成员不再互相竞争，从根本上消除了"同样正确却打分不同"的问题。
接下来，不同家族之间如何排出高下？研究团队引入了两种互补的信号，并把它们结合起来使用。
第一种信号来自"两两比武"。研究团队训练了一个专门的AI裁判（称为"列表式排名器"，即R?-7B），它的工作方式类似于一场擂台赛：从两个不同家族各取一名代表，让AI裁判评判哪个更像正确答案。这个过程对每一对家族都进行，最终统计每个家族"赢了几场"，得出一个胜场数评分。为了避免两个代表都不正确时产生噪音（例如两个错误答案对打，胜出的那个并不真的正确），系统引入了一个门槛设定：只有当某家族明显胜出时（胜出概率超过设定阈值，论文中固定为5%），才算一场"决定性胜利"，否则不计入评分。
第二种信号来自"个人积分"。研究团队同时使用了另一个AI评分员（称为"逐点式排名器"，即R?-POINT-32B），它会独立地给每一个SQL语句打出一个绝对分数，不受其他候选答案的影响。对于每个家族，取其成员中最高的那个绝对分数代表该家族，再乘以家族的人数（成员越多，说明大家越倾向于给出这个答案，一致性越强）。这个"个人积分乘以家族人数"的组合，既反映了单个成员的质量，也体现了家族内部的集体共识。
两种信号按照优先级排列：先看"两两比武"的胜场数，如果两个家族平局（胜场数相同），再用"个人积分"来打破平手。这就像是先看选手的胜负场次，当场次相同时再比总得分。最终排名最高的家族，其内部得分最高的成员，就是R?-SQL的输出答案。
---
三、用"一致性训练"让AI裁判不再受座位顺序影响
这套比武机制本身也面临一个潜在的问题：AI裁判可能存在"位置偏见"。就像考场上坐在第一排的考生往往更紧张一样，当两个SQL候选答案以不同的顺序呈现给AI裁判时（先A后B，还是先B后A），它给出的判断可能不一致。这在学术界被称为"位置偏见"（position bias）。
为了根治这个问题，研究团队在训练AI裁判时加入了一项额外的奖励机制，称为"一致性奖励"。训练方法很直观：对于每一对"正确SQL vs 错误SQL"，不仅用正常顺序（先正确后错误）训练AI，还同时用颠倒顺序（先错误后正确）训练。如果AI裁判在两种顺序下都能正确识别出哪个是更好的答案，就给它额外的奖励分（1.5分）；如果只在一种顺序下判对，则只得基础分（1分）；如果两种顺序都判错，则得0分。
研究团队使用了一种名为GRPO的强化学习框架（可以理解为通过反复做对题得奖励、做错题受惩罚来提升能力的训练方式）。实验数据非常直观：没有经过任何强化学习训练的AI裁判，在两种顺序下给出一致判断的概率只有37.82%；加上基础GRPO训练后，提升到了45.60%；进一步加入一致性奖励后，进一步提升到了57.49%，整整提高了约11.89个百分点。此外，由于逐点式排名器不受输入顺序影响（它只看单个SQL），它还被用作一个稳定的"锚点"，在列表式裁判存在偏见的场合提供额外的参照。移除逐点式排名器后，整体准确率会下降0.84个百分点，证明它的存在确实有价值。
---
四、"侦探式重采样"：当答案不在候选池里，就重新找
解决了"评分不公平"的问题，研究团队把目光转向第二个更根本的挑战：如果正确答案从一开始就没有被生成，怎么办？
R?-SQL引入了一个"智能审核代理"（agentic resampling agent），可以把它理解成一个经验丰富的侦探。侦探不只是在给定的嫌疑人名单里推理，他还会判断这份名单本身是否有遗漏——如果觉得真正的凶手不在名单上，他就会申请扩大调查范围，重新生成一批嫌疑人。
具体流程是这样的：首先，系统正常生成32个候选SQL语句作为初始候选池。然后，这个AI审核代理会仔细审查这批候选答案，考察它们是否与用户提的问题意图相符、是否正确使用了数据库表格和字段、执行结果看起来是否合理。如果审核代理判断这批候选答案中很可能没有正确答案（输出结果为"likely_has_correct = false"），就会触发重采样机制：丢弃原来的32个候选，重新生成多达1024个新候选，再用逐点式评分器从中筛选出质量最高的32个，替换原来的候选池。
这个"判断-重采样"的设计经过了仔细的权衡。实验表明，如果不加判断地永远都重新采样，准确率反而只比原始候选池提高了微弱的0.07个百分点；如果把新旧候选直接合并，准确率甚至会下降（因为引入了太多噪音，让裁判更难找到正确答案）。只有在AI审核代理认为有必要时才替换，效果才最显著，准确率达到了75.03%。
在实际测试中，AI审核代理只对37.01%的测试问题触发了重采样，这意味着大多数问题的初始候选池已经足够好，不需要重新生成。得益于这种精准触发机制，R?-SQL的平均每题处理时间（1.56秒）比一直重采样的方案（1.96秒）节省了0.40秒。
更细致的分析显示，在触发重采样这件事上，AI审核代理表现出很高的精确率（93.27%）——它不轻易触发重采样，一旦触发基本都是真的有必要。而在决定跳过重采样时，召回率也达到了83.17%——绝大多数情况下，当初始候选池已经包含正确答案时，审核代理都能正确判断出不需要重采样，从而节省计算资源。
---
五、实验数据说话：五个测试场景，全面验证效果
研究团队在五个不同的Text-to-SQL基准测试上验证了R?-SQL的效果，这五个测试覆盖了从通用跨领域到专业垂直领域的广泛场景。
BIRD-dev是业内最具挑战性的综合性测试之一，包含1534个问题、涵盖37个以上不同领域的数据库。R?-SQL在此取得了75.03%的执行准确率，超过了其他所有使用公开模型规模的方法。对比而言，排名第二的CSC-SQL（使用70B规模模型）只有71.69%，而R?-SQL使用的是更小的32B规模模型。Spider-test包含2147个跨领域问题，R?-SQL取得了87.19%的准确率，同样领先。Spider-DK专门测试需要领域知识的问题，R?-SQL以77.92%胜出。
两个专业垂直领域的测试则考验模型在陌生场景下的泛化能力。EHRSQL是一个面向电子病历系统的SQL测试，R?-SQL取得了46.30%的准确率；ScienceBenchmark专注于科学数据库，R?-SQL取得了66.82%的准确率。五个数据集的平均准确率为70.65%，R?-SQL是唯一突破70%门槛的方法。
为了确保比较的公平性，研究团队在所有对比方法上使用了相同的逐点式排名器和列表式排名器，唯一的区别是排名选择的策略。这意味着准确率的提升完全来自R?-SQL独特的组合框架，而非模型本身的差异。
研究团队还做了四轮随机种子的重复实验来测试稳定性。结果相当有说服力：R?-SQL在四次重复中的最低得分（73.99%）依然高于最强竞争对手CHASE-SQL的历史最高得分（73.27%）。这说明R?-SQL的优势不是偶然性的波动，而是系统性的稳健提升。
此外，研究团队还在更具挑战性的真实世界场景——Spider 2.0-SQLite子集——上进行了测试。这个测试模拟了真实企业级数据库查询的复杂性。R?-SQL以29.17%的准确率位居首位，而最强竞争对手CHASE-SQL只有20.83%，差距非常明显。
---
六、深挖细节：每个组件的独立贡献有多大？
研究团队还进行了一系列"拆解实验"，逐一移除R?-SQL中的不同组件，来验证每个设计决策的必要性。
移除代理重采样后，准确率从75.03%降至74.25%，下降了0.78个百分点——这说明扩大候选池的能力至关重要。移除逐点式候选筛选（在重采样后对1024个候选进行初筛的步骤）后，进一步降至73.92%，再降0.33个百分点。移除执行分组评分（即不再把相同执行结果的SQL归组，而是直接对个体评分）后，降至73.47%。仅使用列表式排名器（不用逐点式）得到73.34%；仅使用逐点式排名器（不用列表式）得到73.14%——两者都不如组合使用。每个组件的移除都会导致性能下降，证明它们共同构成了一个缺一不可的整体。
---
七、局限与展望
研究团队非常坦诚地指出了R?-SQL目前的局限性。逐点式排名器（R?-POINT-32B）完全基于BIRD训练集进行训练，这意味着它对训练集涵盖的领域最为熟悉，在电子病历和科学数据库等完全陌生的领域表现略有折扣。数据显示，在这两个域外测试集上，如果去掉逐点式排名器，反而能获得略微更高的准确率（EHRSQL: 46.97% vs 46.30%；ScienceBenchmark: 67.28% vs 66.82%）。不过即便包含逐点式排名器，R?-SQL在这两个测试上依然超过了所有竞争对手，说明这个局限对整体表现的影响有限。研究团队也明确提出，未来开发一个具有更广泛领域适应性的逐点式排名器，是改进方向之一。
---
说到底，这项研究做的事情听起来很简单：让自动把人话翻译成SQL语句的AI系统，选出更好的答案。但要把这件"听起来简单"的事情做好，需要同时解决两个相互独立却又相互关联的难题——不能让"说法不同但意思一样"的答案因为风格问题被误排，也不能接受"正确答案根本没被生成出来"的无解局面。
R?-SQL通过三个协同工作的机制——执行分组、双重信号排名、代理重采样——形成了一套完整的解决方案。整套系统在测试环境中跑通了，数据集覆盖面广，对比方法也经过了精心设计以确保公平。对于每天需要从数据库中提取信息的企业和个人来说，这类技术的持续进步意味着未来人们用自然语言提问就能获得准确数据库查询结果的门槛会越来越低。
有兴趣深入了解技术细节的读者，可以通过arXiv论文编号2604.25325查阅完整论文，原始代码和实验细节均在论文附录中有详细说明。
---
Q&A
Q1：R?-SQL中的"功能不一致性"具体是什么意思？
A：功能不一致性指的是，当多个SQL语句写法不同但执行结果完全相同时，现有的评分系统会因为写法上的差异给它们打出不同的分数，导致正确答案可能因为"表达方式不讨好"而被排在错误答案之后。R?-SQL通过把执行结果相同的SQL归为一组统一评分来解决这个问题，从根本上消除了写法带来的评分偏差。
Q2：R?-SQL的代理重采样为什么不直接每次都重新生成候选答案，而要先判断一下？
A：实验证明，如果不加判断地每次都重新生成，准确率只比原始候选池提高约0.07个百分点，而且每题处理时间会从1.56秒增加到1.96秒。更关键的是，如果把新旧候选合并，准确率甚至会下降，因为多余的候选引入了噪音，反而干扰了裁判的判断。只有在AI审核代理认为确实有必要时才替换候选池，才能在不增加太多计算成本的情况下获得最优效果。
Q3：BIRD-dev测试集是什么，为什么在这个测试上的表现特别重要？
A：BIRD（Big Bench for Large-Scale Database Grounded Text-to-SQL）是目前业内最具挑战性、最被广泛引用的Text-to-SQL综合评测基准之一，涵盖超过37个领域的1534个真实问题，问题复杂度和数据库规模都远超早期的Spider测试集。在BIRD-dev上的表现被业界普遍视为衡量一个Text-to-SQL系统综合能力的标准参照，因此R?-SQL在此创下的75.03%最高纪录具有较强的行业参考价值。
