論文解説: CHASE-SQL — マルチパス推論×DPO候補選択でBIRDベンチマーク73.0%を達成したText-to-SQL

本記事は CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL の解説記事です。

論文概要（Abstract）

CHASE-SQLは、3つの独立したSQL生成パス（Chain-of-Thought、Divide-and-Conquer、Query Plan Based）で複数のSQL候補を生成し、Direct Preference Optimization（DPO）でファインチューニングされた選択モデルが最良のSQLを選択するフレームワークである。著者らは、BIRDベンチマークテストセットでExecution Accuracy 73.0%を達成し、2024年8月時点でBIRDリーダーボード1位を獲得したと報告している。

この記事は Zenn記事: LangGraph×Claude Sonnet 4.6でSQL統合Agentic RAGを実装するの深掘りです。Zenn記事ではLangGraphでSQL検索とベクトル検索を統合するアーキテクチャを紹介していますが、CHASE-SQLはSQL生成自体の精度を最大化するアプローチであり、SQL検索ノードの内部品質を向上させるための技術として参考になります。

情報源

arXiv ID: 2408.07503
URL: https://arxiv.org/abs/2408.07503
著者: Mohammadreza Pourreza, Haidar Khan, Daniel Niklas Wendt, et al. (Google)
発表年: 2024
分野: cs.CL, cs.AI

背景と動機（Background & Motivation）

Text-to-SQL分野では、単一のプロンプト戦略でLLMにSQL文を生成させるアプローチが主流であるが、クエリの種類（単純なSELECT、複雑なJOIN、ネストしたサブクエリ等）によって最適なプロンプト戦略が異なる。著者らは、単一のプロンプト戦略では一部のクエリタイプで精度が低下する問題を指摘し、以下の2段階アプローチを提案した。

生成段階: 異なるプロンプト戦略で複数のSQL候補を並列生成する（多様性の確保）
選択段階: DPOでファインチューニングされたLLMが最良のSQL候補を選択する（精度の最大化）

主要な貢献（Key Contributions）

貢献1: 3つの独立したSQL生成パス（CoT、Divide-and-Conquer、Query Plan Based）の提案。各パスが異なるクエリタイプに強みを持ち、候補の多様性を確保する
貢献2: Direct Preference Optimization（DPO）を用いた候補選択モデルのファインチューニング。正解SQL（chosen）と不正解SQL（rejected）のペアデータから、LLMの選好を学習させる
貢献3: BIRDテストセットで73.0% EXを達成し、リーダーボード1位（2024年8月時点）

技術的詳細（Technical Details）

マルチパス推論アーキテクチャ

CHASE-SQLは「生成→選択」の2段階パイプラインで構成される。

ユーザークエリ + DBスキーマ
    │
    ├─→ [Path 1] Chain-of-Thought（CoT）
    │     段階的推論でSQL生成
    │     温度: 0.0（deterministic）
    │
    ├─→ [Path 2] Divide-and-Conquer（D&C）
    │     複雑クエリをサブ問題に分解
    │     温度: 0.8（多様な候補）
    │
    └─→ [Path 3] Query Plan Based
          SQLクエリプランを先に設計
          温度: 0.0
    │
    ↓ 複数のSQL候補
    │
[Selection Model]（DPO Fine-Tuned LLM）
    → 候補から最良のSQLを選択
    ↓
最終SQL

Path 1: Chain-of-Thought（CoT）推論

CoTパスでは、「クエリの意図分析 → テーブル選択 → JOIN条件決定 → SQL組み立て」の段階的推論でSQL文を生成する。

Step 1: ユーザーは「営業部の先月の売上合計」を求めている
Step 2: 必要なテーブル: sales, departments
Step 3: JOIN条件: sales.department_id = departments.id
        WHERE: departments.name = '営業部' AND sales.date >= '2025-01-01'
Step 4: SELECT SUM(sales.amount) FROM sales
        JOIN departments ON sales.department_id = departments.id
        WHERE departments.name = '営業部'
        AND sales.date >= '2025-01-01' AND sales.date < '2025-02-01'

著者らは温度0.0で確定的な出力を得ることで、CoTパスの安定性を確保している。

Path 2: Divide-and-Conquer（D&C）

D&Cパスは、複雑なクエリをサブ問題に分解し、各サブ問題のSQL文を個別に生成してから結合する。

\[\text{SQL}_{\text{final}} = \text{Compose}(\text{SQL}_1, \text{SQL}_2, \ldots, \text{SQL}_k)\]

ここで、

$\text{SQL}_i$: サブ問題$i$に対する部分SQL
$\text{Compose}$: 部分SQLをNESTED QUERYやCTE（Common Table Expression）で結合する関数

著者らは温度0.8で複数のD&C候補を生成し、多様なSQL構造の候補を確保している。

Path 3: Query Plan Based

Query Planパスでは、SQL文の実行計画（Query Plan）を先に自然言語で設計し、その計画に基づいてSQLを生成する。

Query Plan:
1. departmentsテーブルからname='営業部'のidを取得
2. salesテーブルでdepartment_id = (1で取得したid)をフィルタ
3. date >= '2025-01-01' AND date < '2025-02-01'でフィルタ
4. SUM(amount)で集計

→ SQL生成

このアプローチは、実行計画の明示化により、LLMが論理的なSQLを生成しやすくなる効果がある。

DPO候補選択モデル

3つのパスから生成された複数のSQL候補の中から最良のものを選択するため、著者らはDirect Preference Optimization（DPO）でファインチューニングされたLLMを使用する。

DPOの損失関数:

\[\mathcal{L}_{\text{DPO}}(\pi_\theta; \pi_{\text{ref}}) = -\mathbb{E}_{(x, y_w, y_l) \sim \mathcal{D}} \left[ \log \sigma \left( \beta \log \frac{\pi_\theta(y_w | x)}{\pi_{\text{ref}}(y_w | x)} - \beta \log \frac{\pi_\theta(y_l | x)}{\pi_{\text{ref}}(y_l | x)} \right) \right]\]

ここで、

$\pi_\theta$: ファインチューニング対象のモデル
$\pi_{\text{ref}}$: 参照モデル（ファインチューニング前）
$x$: 入力（クエリ + スキーマ + SQL候補リスト）
$y_w$: 正解SQL（chosen、実行結果が正しいもの）
$y_l$: 不正解SQL（rejected、実行結果が誤りのもの）
$\beta$: 温度パラメータ（参照モデルからの乖離を制御）
$\sigma$: シグモイド関数
$\mathcal{D}$: 学習データセット（Q&A + chosen/rejected SQLペア）

学習データの構築方法: 著者らはBIRDのtraining setに対して3つのパスでSQL候補を生成し、DB上で実行して正解/不正解を判定することでペアデータを自動構築している。

選択モデルのベース: Gemini 1.5 Flashを使用。著者らの報告では、Flashの軽量さが候補選択タスクに適しており、推論コストを抑えながら高い選択精度を実現しているとされる。

スキーマリンキングとカラム値サンプリング

CHASE-SQLでは、SQL生成の前処理としてスキーマリンキングとカラム値サンプリングを実施する。

カラム値サンプリング: 各カラムからサンプル値を抽出し、「Column-meaning」情報としてプロンプトに含める。これにより、LLMがカラムの意味を正確に理解し、適切なWHERE句を生成できる。

  
# カラム値サンプリングの概念
def extract_column_meaning(db, table, column, sample_n=5):
    """カラムのサンプル値を取得し、意味を推定"""
    query = f"SELECT DISTINCT {column} FROM {table} LIMIT {sample_n}"
    samples = db.execute(query)
    return {
        "table": table,
        "column": column,
        "samples": samples,
        "inferred_type": infer_semantic_type(samples),
    }

実装のポイント（Implementation）

CHASE-SQLを実装する際の注意点を整理する。

3パスの並列実行: 各パスは独立しているため、並列実行でレイテンシを抑えられる。ただし、APIコストは3倍になるため、コスト・レイテンシのトレードオフを考慮する必要がある
DPO学習データの準備: 候補選択モデルのファインチューニングには、正解/不正解SQLのペアデータが必要。社内DBに適用する場合、Q&Aログからペアデータを自動生成するパイプラインの構築が前提となる
モデル選択: 著者らはSQL生成にGemini 1.5 Pro、候補選択にGemini 1.5 Flashを使用している。Claude Sonnet 4.6で代替する場合、with_structured_outputでSQL候補のランキングを型安全に出力させるアプローチが考えられる
温度パラメータの調整: 各パスの温度設定（CoT: 0.0、D&C: 0.8、QP: 0.0）は、BIRD benchmarkでの実験に基づく。対象DBの特性に応じて調整が必要な場合がある

実験結果（Results）

論文Table 1およびTable 2より、主要なベンチマーク結果を示す。

モデル	手法	BIRD dev EX	BIRD test EX
Gemini 1.5 Pro	CHASE-SQL（フル）	73.01%	73.0%
Gemini 1.5 Pro	CoTパスのみ	68.2%	-
Gemini 1.5 Pro	D&Cパスのみ	65.8%	-
Gemini 1.5 Pro	QPパスのみ	67.1%	-
Gemini 1.5 Pro	多数決選択（DPOなし）	70.3%	-
GPT-4o	CHESS	65.0%	-
GPT-4	DIN-SQL	55.9%	60.1%
GPT-4	MAC-SQL	59.59%	-

分析ポイント（論文Section 5より）:

単一パス（CoT/D&C/QP）と比較して、マルチパス+DPO選択で4.8%以上の改善が得られている。著者らはこれを「異なるパスが異なるクエリタイプの強みを持つため、候補の多様性が精度向上に寄与する」と分析している
DPO選択と多数決選択の比較では2.7%の差があり、DPOの学習が単純な多数決を上回ることが示されている
CoTパスが単一パスの中で最高精度（68.2%）であり、段階的推論の有効性が確認されている

実運用への応用（Practical Applications）

Zenn記事のSQL統合Agentic RAGにCHASE-SQLの知見を適用する場合、以下が参考になる。

マルチパス生成の導入: Zenn記事のSQL検索ノードで、異なるプロンプト戦略（CoT、D&C）で複数のSQL候補を生成し、最良のものを選択するパターンを採用できる。LangGraphのSend() APIで並列ノード実行が可能
候補選択のシンプル化: DPOファインチューニングは実装コストが高いため、代替として「生成した全SQL候補をDB上で実行し、結果が得られるものの中からLLMが最適なものを選択する」アプローチが実用的である
カラム値サンプリングの追加: Zenn記事のsample_rows_in_table_info=3設定を拡張し、CHASE-SQLのColumn-meaning抽出を適用することで、LLMのスキーマ理解が向上する可能性がある

制約: CHASE-SQLは3パス生成＋DPO選択モデルという構成のため、レイテンシとAPIコストが通常の3倍以上になる。リアルタイム応答が求められるシステムでは、パス数の削減やキャッシュ戦略の導入が必要である。また、DPO学習データの準備コストが高いことも実用上の障壁となる。

まとめと今後の展望

CHASE-SQLは、3つの独立したSQL生成パスとDPO候補選択モデルの組み合わせにより、BIRDベンチマークで2024年8月時点のSOTA（73.0%）を達成したフレームワークである。著者らの「異なるプロンプト戦略を並列実行し、学習された選好で最良候補を選択する」という設計思想は、LLMベースのシステム設計における一般的なパターンとして参考になる。

Zenn記事のSQL検索ノード内でマルチパス生成を導入することで、特に複雑なSQLクエリの生成精度向上が期待できる。ただし、コスト・レイテンシのトレードオフを考慮し、対象システムの要件に応じたパス数の選択が重要である。

参考文献

arXiv: https://arxiv.org/abs/2408.07503
BIRD Leaderboard: https://bird-bench.github.io/
DPO原論文: Rafailov et al., “Direct Preference Optimization: Your Language Model is Secretly a Reward Model”, NeurIPS 2023
Related Zenn article: https://zenn.dev/0h_n0/articles/58dc3076d2ffba
DIN-SQL: https://arxiv.org/abs/2305.11853
CHESS: https://arxiv.org/abs/2405.16755

📄 論文解説: CHASE-SQL — マルチパス推論×DPO候補選択でBIRDベンチマーク73.0%を達成したText-to-SQL

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

マルチパス推論アーキテクチャ

Path 1: Chain-of-Thought（CoT）推論

Path 2: Divide-and-Conquer（D&C）

Path 3: Query Plan Based

DPO候補選択モデル

スキーマリンキングとカラム値サンプリング

実装のポイント（Implementation）

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: CHASE-SQL — マルチパス推論×DPO候補選択でBIRDベンチマーク73.0%を達成したText-to-SQL

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

マルチパス推論アーキテクチャ

Path 1: Chain-of-Thought（CoT）推論

Path 2: Divide-and-Conquer（D&C）

Path 3: Query Plan Based

DPO候補選択モデル

スキーマリンキングとカラム値サンプリング

実装のポイント（Implementation）

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: DIN-SQL — 分解型In-Context Learningで実現するText-to-SQL自己修正パイプライン

📄 COLING 2025論文解説: MAC-SQL — Selector・Decomposer・Refinerによるマルチエージェント協調Text-to-SQL

📄 論文解説: CHESS — RAGベーススキーマ選択でText-to-SQL精度73%を達成するパイプライン