🤖 AI

SIRIUS-SQL: Anchoring Multi-Candidate Text-to-SQL in Execution Feedback

SIRIUS-SQL 是一种新颖的 Text-to-SQL 框架，它通过用于多样化生成的难度平滑强化学习训练策略、用于针对性错误修复的执行落地生命周期，以及用于置信度门控的混合选择器，解决了现有多候选系统的局限性，从而提升了在复杂模式下的准确性，并在 BIRD 和 SPIDER 基准测试上实现了最先进的性能。

原作者： Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

发布于 2026-06-02

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正试图给一个机器人厨师（AI）下达一个非常具体且复杂的指令，让它根据一本极其庞大且杂乱的食谱（数据库）来烹饪一道菜（编写一条 SQL 查询）。

如果你只要求机器人做一次，它往往会出错，因为食谱很混乱，食材名称很奇怪，或者指令很模糊。

旧方法：“群众投票”问题
最近，其他系统尝试通过让机器人做 16 次而不是 1 次来解决这个问题（即多数投票法）。

SIRIUS-SQL 的作者指出，这种“群众投票”的方法存在三个大问题：

回声壁效应： 如果你让同一个机器人做 16 次，它会不断重复同样的 16 个错误。这就像让同一个人猜 16 次密码；他们很可能会一遍又一遍地猜出同一个错误的答案。
“一刀切”的修复方式： 当一道菜做得不对时，旧系统只会说：“噢，它坏了，再试一次，”而不会观察它是如何出错的。是锅烧焦了？是忘了放盐？还是用了错误的锅？这些都需要不同的修复方法，但旧系统将它们一概而论。
错误的赢家： 有时，正确的菜肴其实就在 16 道菜的堆里，但群众投票选出了错误的那个，因为他们关注的点不对（比如关注的是味道而非食材清单）。

SIRIUS-SQL 的解决方案：大师级主厨与全才
SIRIUS-SQL 通过三部分的策略解决了这些问题：

1. “专家”与“全才”（解决回声壁效应）

他们不是让一个机器人做 16 次，而是使用了两位不同的厨师：

专家 (SIRIUS-32B)： 这是一个专门针对烹饪（SQL）训练的机器人。它通过一种特殊的“奖励机制”（强化学习）进行训练，只有当菜肴真正成功时，它才会获得奖励。它学会了制作正确菜肴的许多不同版本，而不是仅仅重复同一个错误。
全才： 这是一个超级聪明的全能型机器人（类似于著名的 AI 模型），擅长理解复杂的语言和古怪的指令。
结果： 通过将专家的深度知识与全才的广泛理解相结合，他们得到了更丰富的尝试版本。这就像是一位寿司大师和一位极具创意的法国大厨共同协作；你们更有机会做出完美的食谱。

2. “分诊护士”系统（解决“一刀切”问题）

当一道菜做得不对时，SIRIUS-SQL 不仅仅是说“再试一次”。它像医院里的分诊护士一样，诊断出具体出了什么问题：

运行时错误（锅烧焦了）： 机器人尝试使用了一个不存在的工具。系统会立即修复语法。
超时（炉灶太慢了）： 食谱太复杂，耗时太长。系统会在不改变味道的前提下，重写食谱以提高效率。
空结果（锅里是空的）： 机器人完美地遵循了食谱，但结果却是空的，因为它寻找了错误的食材。系统会尝试特定的“结构化”修复，以找到正确的食材。

只有在经过这些特定的修复之后，机器人才能再次尝试。这节省了时间，并防止系统在不可能实现的修复上浪费精力。

3. “智能评委”（解决“错误的赢家”问题）

最后，当需要从一堆菜肴中挑选出最好的那道时，系统使用了一个两步投票过程：

第一步：味觉测试： 它观察实际的结果。如果 10 道菜的味道是一样的，它们就会获得高分。
第二步：决胜局： 如果有两组菜肴的味道得分相同，系统不会仅仅靠猜测。它会查看食谱的“蓝图”（结构）。它会问：“是否有多位不同的厨师（专家和全才）独立地提出了相同的蓝图？”如果是，那么这个蓝图很可能才是真正的赢家。

结果
通过使用这个“专家 + 全才”团队、“分诊护士”修复系统以及“智能评委”，SIRIUS-SQL 成为了该领域的佼佼者。

在 BIRD 测试（一个处理真实世界杂乱数据的困难测试）中，它的准确率达到了 75.88%，超越了之前的最优系统。
在 SPIDER 测试（一个标准测试）中，它的准确率达到了 91.20%。

简而言之，SIRIUS-SQL 不再依赖单个机器人盲目猜测 16 次。相反，它使用了一个由不同专家组成的团队，通过诊断特定错误来进行精准修复，并使用一套智能的多步投票系统来找到唯一的正确答案。

技术摘要：SIRIUS-SQL

问题陈述

Text-to-SQL 系统在处理现实世界数据库中的复杂模式时面临挑战，因为在这些场景下，单次生成的生成过程往往会因为模式异构性、隐式约束和歧义值引用而失败。虽然近期的研究通过生成多个 SQL 候选对象并使用投票来过滤错误来缓解这一问题，但本文指出，现有的多候选流水线存在三个耦合的结构性缺陷：

收益递减采样 (L1)： 从单一生成器中采样更多候选对象会导致输出日益冗余，因为生成器的分布是由其训练决定的。仅仅增加样本预算 ( $k$ ) 并不能可靠地在生成器偏好区域之外挖掘出新的正确假设。
执行信号浪费 (L2)： 现有流水线对所有非“干净”执行结果应用统一的通用修正策略。然而，不同的失败模式——运行时错误（语法/类型不匹配）、超时（效率低下的执行计划）以及空结果（语义漂移）——指示了与正确性之间的不同距离，并需要截然不同的修复策略。
投票–预言机差距 (L3)： 即使正确的 SQL 存在于候选池中，多数投票也可能无法选中它。这是因为选择过程需要在两个空间进行联合判断：结果空间（其中不同的 SQL 可能产生相同的输出）和逻辑空间（其中相同的意图可以有多种表现形式）。现有的选择器通常仅在其中一个空间内运行。

方法论：SIRIUS-SQL

SIRIUS-SQL 通过将流水线的每个阶段都锚定在执行反馈之上，来解决上述局限性。该系统由三个核心组件组成：

1. 源互补型候选构建

为了克服收益递减问题 (L1)，系统从两个互补的来源构建初始候选池：

专家模型 ( $G_{sp}$ )： 一个经过基于可验证执行奖励的强化学习 (RLVR) 训练的任务专用模型 (SIRIUS-32B)。训练采用了难度平滑的数据合成策略，以专注于模型可以改进的实例，并使用带有阈值门控熵正则化的两阶段 DAPO 调度，以防止熵崩溃并保持候选对象的多样性和可执行性。
通用模型 ( $G_{ge}$ )： 一个通过少样本示例引导的现成强力 LLM（如 Qwen3-235B, Gemini-3.1），用以覆盖专家模型可能遗漏的长尾表达和隐式约束。
这两个来源的并集确保了候选对象能够暴露不同的失败模式，从而降低错误相关性。

2. 执行驱动的候选生命周期

系统并非将执行视为最终的二元检查，而是利用执行结果驱动动态修复循环 (L2)：

执行前筛选： 在执行前通过确定性的基于规则的过滤器移除格式错误的 SQL（例如语法错误、模式不匹配），以节省修复预算。
诊断与类型化： 对存活的候选对象进行执行，并将其分为四类：干净 (clean)、运行时错误 (runtime error)、超时 (timeout) 和 空结果 (empty result)。
特定类型修复：
- 运行时错误： 将引擎的异常文本原样输入给修正器。
- 超时： 重写过程在保留意图的同时，通过重构连接顺序或子查询形状来提高效率。
- 空结果： 采用两阶段方法：首先，高精度的结构化算子（如字面量重绑定、谓词调整）尝试进行局部恢复；如果失败，则触发基于诊断条件的 LLM 回退机制。
候选池整合： 修复后的候选对象会被重新执行并重新加入候选池。如果候选池崩溃，则使用压缩后的负反馈信息来重新生成候选对象。

3. 置信度门控混合选择

为了弥合投票–预言机差距 (L3)，系统采用了结合结果级和逻辑级信号的两阶段选择器：

第一阶段（结果级评分器）： 通过累加以下项计算粗略得分 ( $S_{coarse}$ $S_{co a r se}$ )：
- 元组级共识 ( $S_{maj}$ )： 候选集中单元格级三元组的出现频率。
- 位置去偏成对偏好 ( $S_{rm}$ )： LLM 裁判通过比较结果签名等价类的代表，来对逻辑质量进行排序。
第二阶段（结构支持重排序器）： 一种置信度门控机制。如果顶层候选对象在所有信号上都处于持平状态（低边际），则介入确定性的、无需 LLM 的重排序器。它分析 AST 级别的结构签名（表、投影、聚合），并选择由最多不同溯源组支持的候选对象（跨生成器一致性）。这作为一个零成本的平局决胜机制。

核心贡献

难度平滑 RL 配方： 一种针对 SIRIUS-32B 的训练方法，能够产生广泛且经过奖励验证的候选分布，有效缓解了采样中的收益递减问题。
执行驱动的生命周期： 一个分类执行结果并应用针对性、类型特定修复（运行时、超时、空结果）的修复框架，最大化了执行信号的效用。
置信度门控混合选择器： 一种融合了元组级共识与成对 SQL 偏好的选择机制，仅在存在歧义时才将案例升级到确定性的结构检查，从而在不产生过度计算成本的情况下解决了投票–预言机差距。

实验结果

SIRIUS-SQL 在标准基准测试中达到了最先进的性能：

BIRD Dev： 执行准确率达到 75.88%（使用 SIRIUS-32B + Gemini-3.1 Pro），超越了目前最强的已发表多候选系统 Agentar-Scale-SQL (74.90%) 0.98 个百分点。相比单次生成基准（如 Qwen3-Coder）也有显著提升（+11.54%）。
SPIDER Test： 执行准确率为 91.20%，展示了强大的泛化能力，无需任务特定的微调。
消融实验：
- 难度平滑数据合成在训练期间将 BIRD 的验证奖励提升了 1.8 pp，将 SPIDER 提升了 0.5 pp。
- 互补型候选构建（专家 + 通用）优于单源扩展，证明了多样化的失败模式比单纯增加样本数量更有价值。
- 类型特定的生命周期比统一修正策略高出 0.13–0.71 pp。
- 混合选择器（合并 + 门控）比单信号选择器提供了 0.20 pp 的增益，主要体现在解决低边际平局方面。

意义

本文认为，多候选 Text-to-SQL 的主要瓶颈不在于生成更多的候选对象，而在于在训练、修复和选择过程中对执行信号的系统性利用不足。通过将整个流水线锚定在执行反馈之上——训练专家模型产生多样化的可执行候选、根据特定错误类型进行修复、以及基于结果共识与结构逻辑的混合信号进行选择——SIRIUS-SQL 证明了执行驱动的精炼是提高复杂模式下可靠性的关键手段。该系统通过两种不同的通用模型配对即可超越强力基准，表明其具备一种稳健且与任务无关的架构，适用于高要求的 Text-to-SQL 应用场景。