技術要約: SIRIUS-SQL

問題提起

Text-to-SQLシステムは、現実世界のデータベースにおける複雑なスキーマへの対応に苦慮している。そこでは、単一パスの生成では、スキーマの異質性、暗黙的な制約、および曖昧な値の参照によって失敗することが多い。近年のアプローチは、複数のSQL候補を生成し、投票を用いてエラーをフィルタリングすることでこれを緩和しているが、本論文は既存のマルチ候補パイプラインにおける3つの結合された構造的弱点を特定している。

1. 収穫逓減型のサンプリング (L1): 単一の生成器からより多くの候補をサンプリングしても、生成器の分布は学習によって固定されているため、出力の冗長性が増すだけで、収穫は逓減する。サンプル予算（$k$）を単純に増やすだけでは、生成器が好む領域の外側にある新しい正解の仮説を確実に提示することはできない。
2. 実行シグナルの浪費 (L2): 既存のパイプラインは、すべての「クリーンではない」実行結果に対して、単一の汎用的な修正戦略を適用している。しかし、異なる失敗モード（実行時エラー：構文や型の不一致、タイムアウト：非効率なプラン、空の結果：意味論的なドリフト）は、正解からの距離が異なり、それぞれ異なる修復戦略を必要とする。
3. 投票とオラクルの間のギャップ (L3): 候補プール内に正しいSQLが存在する場合でも、多数決による投票が失敗することがある。これは、選択において2つの空間における共同判断が必要となるためである。すなわち、「結果空間」（異なるSQLが同一の出力を生成し得る空間）と「ロジック空間」（同一の意図が多くの表面的な形態を許容する空間）である。既存のセレクターは通常、これらの一方の空間でしか動作していない。

手法: SIRIUS-SQL

SIRIUS-SQLは、パイプラインのあらゆる段階を実行フィードバックに立脚させることで、これらの制限に対処する。本システムは、3つのコアコンポーネントで構成されている。

1. 源泉補完的な候補構成

収穫逓減（L1）を克服するため、システムは2つの補完的なソースから初期候補プールを構築する。

• スペシャリスト ($G_{sp}$): 検証可能な実行報酬からの強化学習 (RLVR) を用いて訓練された、タスク特化型のモデル（SIRIUS-32B）。この訓練には、ポリシーが改善できる箇所に焦点を当てるための難易度平滑化データ合成戦略と、エントロピーの崩壊を防ぎつつ多様な実行可能な候補を維持するための、閾値ゲート付きエントロピー正則化を用いた2段階DAPOスケジュールが採用されている。
• ジェネラリスト ($G_{ge}$): 高性能な既成のLLM（例：Qwen3-235B、Gemini-3.1）を用い、Few-shotのデモンストレーションによってプロンプトを与えることで、スペシャリストが見落とす可能性のあるロングテールな言い回しや暗黙的な制約をカバーする。
  これら2つのソースを結合することで、候補が異なる失敗モードを露呈するようにし、エラーの相関を低減させる。

2. 実行に基づいた候補のライフサイクル

実行を最終的なバイナリチェックとして扱うのではなく、本システムは実行結果を用いて動的な修復ループを駆動する（L2）。

• 実行前スクリーニング: 修復予算を節約するため、実行前に決定論的なルールベースのフィルタを用いて、不正なSQL（構文エラー、スキーマの不一致など）を除去する。
• 診断とタイピング: 生き残った候補は実行され、4つのカテゴリ（clean、runtime error、timeout、empty result）に分類される。
• タイプ別修復:
  • 実行時エラー (Runtime Errors): エンジンの例外テキストがそのまま修正器に送られる。
  • タイムアウト (Timeouts): 意図を保持したまま、効率を向上させるために結合順序やサブクエリの形状を再構成する。
  • 空の結果 (Empty Results): 2段階のアプローチを用いる。まず、高精度な構造的オペレータ（リテラルの再バインド、述語の調整など）による局所的な回復を試みる。それが失敗した場合は、診断条件付きのLLMフォールバックがトリガーされる。
• プールの統合: 修復された候補は再実行され、プールに再加入される。もしプールが崩壊した場合は、凝縮された負のフィードバックを用いるリカバリ生成器が候補を再生成する。

3. 信頼性ゲート付きハイブリッド選択

投票とオラクルの間のギャップ（L3）を埋めるため、システムは結果レベルとロジックレベルの両方のシグナルを組み合わせた2段階のセレクターを採用する。

• ステージ1 (結果レベル・スコアラー): 以下を合算して粗いスコア（$S_{coarse}$）を算出する。
  • タプルレベルのコンセンサス ($S_{maj}$): 候補セット全体におけるセルレベルのトリプルの頻度。
  • 位置バイアス除去済みペアワイズ選好 ($S_{rm}$): LLMジャッジが、結果のシグネチャが等価なクラスの代表者を比較し、ロジックの質をランク付けする。
• ステージ2 (構造的サポート・リランカー): 信頼性ゲート付きメカニズム。すべてのシグナルにおいてトップ候補が同点（低いマージン）である場合、決定論的なLLMフリーのリランカーが介入する。これは、ASTレベルの構造的シグネチャ（テーブル、射影、集計）を分析し、最も多くの異なるプロベナンスグループによって支持されている候補を選択する（クロスジェネレーターの合意）。これは、計算コストを抑えたタイブレーカーとして機能する。

主な貢献

1. 難易度平滑化RLレシピ: 広範かつ報酬によって検証された候補分布を生み出す、SIRIUS-32Bのための訓練手法であり、サンプリングにおける収穫逓減を効果的に緩和する。
2. 実行に基づいたライフサイクル: 実行結果を分類し、特定のタイプ別の修復（実行時、タイムアウト、空）を適用してから候補を再投入する修復フレームワークであり、実行シグナルの有用性を最大化する。
3. 信頼性ゲート付きハイブリッドセレクター: タプルレベルのコンセンサスとペアワイズ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は実行に基づいた洗練が複雑なスキーマに対する信頼性を向上させる重要なレバーであることを示している。3つのジェネラリストの組み合わせのうち2つで強力なベースラインを上回る本システムの能力は、極めて重要なText-to-SQLアプリケーションのための、堅牢でパートナーに依存しないアーキテクチャであることを示唆している。