🤖 machine learning

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

本論文は、中間フィードバックに基づいてSQLサブタスクを動的に選択するためのポリシーモデルを学習させるためにSearch-to-Policy Learningを採用した段階的なオーケストレーション・フレームワークであるSQLConductorを紹介しており、これにより、固定されたパイプラインや直接的なバックボーン学習と比較して、複雑なText-to-SQLベンチマークにおいて優れた実行精度と汎用性を実現している。

原著者： Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

公開日 2026-06-23

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、膨大な、そして整理されていない情報のライブラリ（データベース）に対して、自然な英語で質問を投げかけ、非常に具体的な答えを得ようとしているところだと想像してください。これが「Text-to-SQL」問題です。つまり、人間の質問を、コンピュータが理解できる命令（SQL）へと変換することです。

長い間、コンピュータはこの問題を解決するために、厳格に決められたレシピに従おうとしてきました。どんな質問をしても、コンピュータは同じ手順を踏まなければなりませんでした：ステップ1、ステップ2、ステップ3、ステップ4。もしあなたが「フランスの首都は何ですか？」のような単純な質問をしたとしても、コンピュータは依然としてこれら4つのステップすべてを経由しなければならず、時間を浪費し、時には混乱してしまいました。もしコンピュータがステップ2でミスをした場合、そのミスを抱えたまま突き進んでしまい、誤った答えを導き出すことになりました。

SQLConductorは、このゲームのルールを変える新しいシステムです。硬直したレシピに従う代わりに、これはスマートなプロジェクトマネージャーや**指揮者（コンダクター）**のように、今起きていることに基づいて次の動きを決定します。

その仕組みを、簡単な比喩を用いて説明します。

1. 道具箱（アクション・スペース）

コンピュータには、専門化されたさまざまな道具が入った道具箱があると想像してください。

ブレイカー（分解者）： 大きな質問を小さなパーツに分解します。
ファインダー（探索者）： データベース内の特定の数字や名前を探し出します。
フィルター（選別者）： 無関係な情報を切り捨てます。
ライター（執筆者）： 実際のコンピュータ命令を書き込みます。
エディター（編集者）： 命令のミスを修正します。
フィニッシャー（完了者）： 「作業は終了です、こちらが答えです」と告げます。

従来のシステムでは、コンピュータは特定の順序（例：ブレイカー $\to$ ファインダー $\to$ ライター $\to$ フィニッシャー）で道具を選ぶことを強制されていました。しかし、SQLConductorは「指揮者」が、今まさに必要とされる道具を自由に選べるようにします。もしファインダーがさらなる情報を必要だと判断した場合、指揮者は再びブレイカーを呼び出すことができます。もしライターがミスをした場合、指揮者は即座にエディターを呼ぶことができます。

2. トレーニングキャンプ（Search-to-Policy Learning）

指揮者はどのようにして、これらの賢い判断を下す方法を学ぶのでしょうか？単にマニュアルを読むのではありません。それはSearch-to-Policy Learningと呼ばれる、過酷なトレーニングキャンプを通ることによって学びます。

シミュレーション（MCTS）： チェスのプレイヤーがコンピュータ相手に練習している場面を想像してください。コンピュータは、どの経路（ワークフロー）が勝利につながるかを見るために、何千もの異なるゲームの経路を試します。SQLConbrductorも同様に、質問を解決するための何百万もの異なる方法をシミュレートし、さまざまなツールの組み合わせを試します。
安定性のチェック： たまたま一度うまくいったからといって、それが良い戦略であるとは限りません。それは単なる運かもしれません。システムは、どの経路が一貫して機能するかを調べます。これは、コーチが「一度だけ運良く勝った方法を真似するのではなく、10回中9回勝てる戦略をコピーしなさい」と言うようなものです。
「カリキュラム」（より難しい問題）： 指揮者が簡単な問題に慣れてくると、トレーニングキャンプはより難しく、トリッキーな質問を投げつけます。システムは、通常失敗してしまうような困難なケースを扱う方法を、集中的に学習していきます。

3. 結果：柔軟で効率的なワーカー

訓練を終えたSQLConductorは、実際の質問を解決するために配備されます。

適応性： もしあなたが単純な質問をした場合、指揮者は「エディターやブレイカーは必要ない。ライターとフィニッシャーだけを使おう」と判断します。これにより時間を節約できます。複雑な質問を受けた場合は、立ち戻り、証拠を集め、答えを洗練させる必要があることを理解しています。
効率性： 実際に必要なツールのみを使用するため、すべての質問を長い固定されたパイプラインに通すシステムよりも、計算資源を節約でき、コストも抑えられます。
正確性： テストにおいて、このシステムは、質問が非常に難しかったりデータベースが乱雑であったりする場合でも、従来の方法より高い頻度で正解を導き出しました。

大きな全体像

従来のText-to-SQLシステムを、工場のベルトコンベアだと考えてください。すべての製品が、必要なくても同じ機械を通っていきます。もしベルト上の部品が壊れたら、ラインはそのまま動き続け、不良品を生み出し続けます。

SQLConductorは、ワークショップにいる熟練した職人のようなものです。彼らは品物（質問）を見て、どの道具を手に取るかを決め、作業を試し、結果を確認し、次に何をすべきかを判断します。もしミスをすれば、すぐに修正します。仕事が単純であれば、素早く終わらせます。複雑であれば、正しく行うために時間をかけます。

この論文は、コンピュータに硬直した機械ではなく、このような熟練した職人のように振る舞うよう教えることで、データベースへの質問をより正確に、より効率的に、そしてさまざまな種類の問題に対して優れた適応力を持って解決できると主張しています。

技術要約: SQLConductor

1. 問題提起

現実世界のText-to-SQLは、複雑でヘテロジニアスなデータベース環境における協調的な推論の必要性から、依然として困難な課題となっています。既存のシステムは一般に以下の2つのカテゴリに分類されますが、どちらも適応性に限界があります。

固定パイプライン (Fixed Pipelines): これらは、定義された硬直的なステージ順序（例：スキーマリンキング $\to$ 値の取得 $\to$ 生成 $\to$ 修正）に依存しています。これらは構造化されてはいるものの、中間的なフィードバックや実行エラーに基づいて以前の決定を再考することができず、エラーの伝播を招きます。
プランニング・実行型オーケストレーション (Plan-then-Execute Orchestration): これらの手法は、実行前に完全なワークフロー計画を生成します。固定パイプラインよりは柔軟ですが、一度実行が始まると静的なシーケンスに固執するため、解決プロセス中の中間的なアーティファクトや実行フィードバックに適応することができません。

核心となる課題は、人間が作成したワークフローデータに頼ったり、推論時に膨大なオンライン探索コストをかけたりすることなく、現在の解決コンテキストと中間的な証拠に基づいて次のアクションを動的に選択できるステップ単位のオーケストレーション・ポリシーを学習することです。

2. メソドロジー: SQLConductor

SQLConductorは、プロセスの組織化（オーケストレーション）とサブタスクの実行（推論）を分離する、ステップ単位のオーケストレーション学習フレームワークです。これは、広範なオフライン・ワークフロー探索を、効率的な推論のためのデプロイ可能なポリシーへと変換する**「探索からポリシーへの学習 (Search-to-Policy Learning)」**パラダイムを採用しています。

2.1 アクション空間

本システムは、凍結された大規模言語モデル（LLM）によって呼び出される、7つの特化したモジュールからなるモジュール化されたアクション空間 $\mathcal{A}$ を定義しています。

質問の分解 ( $a_{dec}$ ): 複雑な質問を細粒度な要件へと書き換えます。
関連する値の抽出 ( $a_{val}$ ): SQL述語のための条件値を特定します。
操作の特定 ( $a_{op}$ ): 必要なSQL操作（例：集計、並べ替え）を記録します。
スキーマの枝刈り ( $a_{sch}$ ): 関連するテーブルとカラムを選択します。
SQLクエリの生成 ( $a_{gen}$ ): SQL候補を合成します。
SQLクエリの洗練 ( $a_{ref}$ ): 構文エラーまたは実行エラーを修正します。
終了および出力 ( $a_{term}$ ): ワークフローを終了し、最終的なSQLを返します。

2.2 探索からポリシーへの学習 (Search-to-Policy Learning)

学習プロセスは、オフラインフェーズとオンラインデプロイフェーズで構成されます。

フェーズ1: オフライン探索・ポリシー学習

MCTSに基づくワークフロー探索:
- 各学習インスタンスに対して、SQLConductorはアクション空間上でモンテカルロ木探索（MCTS）を実行します。
- ノードはオーケストレーション状態を表し、エッジはアクションの選択を表します。
- 探索は、実行の一貫性報酬（生成されたSQLが複数のサンプル間で一貫した結果を生成するかどうかを測定するもの）に導かれながら、多様なアクションの構成と深さを探索します。
- これにより、多様な候補軌跡 $\mathcal{X}(q, D)$ が生成されます。
ワークフロー監督キュレーション:
- スケルトン抽出: 軌跡は、そのアクションシーケンス（ワークフロー・スケルトン）ごとにグループ化されます。
- 安定性推定: 探索空間は組合せ爆発的でノイズが含まれるため、SQLConductorはラプラスの継承則を用いて各ワークフローの安定性を推定します： $\hat{p}_\tau = \frac{s_\tau + 1}{n_\tau + 2}$ （ここで、 $s_\tau$ は成功した実行回数、 $n_\tau$ は総回数）。
- 選択: 最も高い安定性スコアを持つ上位- $k$ のワークフローが選択されます。各グループから、代表として一つの成功した軌跡がサンプリングされます。
- 推論の拡張: デプロイされたLLMが、現在のコンテキストに対して特定の理由でそのアクションが選ばれたことを説明するステップレベルの推論 ( $e_t$ ) を生成し、拡張された軌跡 $\bar{\xi}$ を作成します。
安定性重み付き教師あり微調整 (SFT):
- ポリシーモデルは、キュレートされた拡張軌跡を用いて学習されます。
- マスキング: 損失関数は <results> トークン（アクションの出力）をマスクし、ポリシーがアクションの出力を予測することを防ぎ、代わりにオーケストレーションの決定に集中させます。
- 重み付け: 堅牢なオーケストレーションパターンを優先しつつ多様性を維持するために、軌跡はそれらの安定性スコア ( $\hat{p}_\tau$ ) によって重み付けされます。
カリキュラム強化学習 (RL):
- 成功した軌跡が乏しい困難なクエリに対処するため、システムは困難なインスタンス（MCTSの成功率が低いもの）のカリキュラムセットを構築します。
- グループ相対方策最適化（GRPO）を用いて、ポリシーはこれらの難解なケースに対して自己ロールアウトを行います。
- 報酬: 報酬関数は、実行可能性（有効なSQL）と結果の品質（グランドトゥルースに対する実行F1スコア）を組み合わせ、ポリシーが複雑なケースに対するリカバリ戦略を学習するように促します。

フェーズ2: オンラインデプロイ

学習済みポリシーモデルが、凍結されたアクションモジュールをステップごとに調整します。
各ステップにおいて、ポリシーは現在の状態（蓄積された証拠とフィードバック）に基づいて、推論を生成し、次のアクションを選択します。
ワークフローは実行中に動的に構築され、クエリの特定の要求に適応します。

3. 主な貢献

ステップ単位のオーケストレーションフレームワーク: SQLConductorは、プロセスの組織化とサブタスクの実行を分離するフレームワークを導入し、固定パイプラインやプランニング・実行型アプローチとは異なり、クエリ固有のワークフロー、適応的な深さ、およびモジュールの構成を可能にします。
探索からポリシーへの学習: 本論文は、人間が作成したワークフローデータなしで、適応的なオーケストレーションポリシーを訓練するメカニズムを提案しています。これは、探索のためのMCTS、キュレーションのための安定性推定、および安定性重み付きSFTとカリキュラムRLの組み合わせを利用しています。
実証的な性能と汎化性能:
- BIRD-Dev: SQLConductorは、BIRD-Devベンチマークにおいて73.2%の実行精度 (EX) を達成し、同等またはより大規模なText-to-SQLバックボーンを直接訓練した従来の手法を上回りました。
- パラメータ効率: 同モデルは、凍結されたより大きなアクションモデル（例：32B）を調整するために、コンパクトなオーケストレーションポリシー（例：8B）のみを訓練することで、これらの結果を達成しており、優れた「パラメータあたりの精度」の効率性を実証しています。
- 汎化性能: データセット固有の再学習を行うことなく、分布外（OOD）データセット（Spider-Test, KaggleDBQA, ScienceBenchmark）において強力な汎化性能を示しています。
- 効率性: 高い精度を維持しながら、推論時のトークン使用量とAPIコストを大幅に削減しています（CHESSなどのベースラインと比較して約8倍安価）。

4. 意義と主張

本論文は、学習されたオーケストレーションは、モノリシックなText-to-SQLモデルをさらに訓練することよりも、パラメータ効率が高く効果的であると主張しています。

適応性 vs ブリュートフォース: 結果は、性能向上が単にワークフローの長さを増やしたりモデルサイズを大きくしたりすることから来るのではなく、オーケストレーションの努力を適応的に割り当てるポリシーの能力から来るものであることを示しています。訓練されたポリシーは、困難なクエリにはより多くのステップを割り当て、単純なクエリには効率的な手順を維持します。
堅牢性: 安定性重み付きのキュレーションにより、ポリシーは偶発的な成功ではなく、堅牢なパターンを学習します。これにより、複雑でノイズが多く、ドメイン特化型のクエリにも効果的に対処できます。
スケーラビリティ: オーケストレーションポリシーとアクションモジュールを分離することで、システム全体を再学習することなく、より大規模または特化したアクションモデルを統合することが可能になり、複雑なText-to-SQLタスクへのスケーラブルな道を提供します。

要約すると、SQLConductorは、中間的な証拠に適応する動的なステップ単位のオーケストレーションポリシーを学習することで、既存のText-to-SQLシステムの硬直性の問題に対処し、大幅に低い計算コストで最先端の性能を達成しています。