MAC-SQL：マルチエージェント協調型 Text-to-SQL
MAC-SQL は、2023年12月に Text-to-SQL 問題に対する最も明示的なエージェント中心の回答として登場しました。1つのプロンプトで1つのクエリを生成するのではなく、3つの特化型エージェントが協調して、関連するサブスキーマを選択し、質問を分解し、実行後に SQL を修正します。私がこの論文を読んでいる理由は、これまでの2つの記事で BIRD (MAC-SQL が提出時にトップだったベンチマーク) と DIN-SQL (MAC-SQL が拡張した分解ベースライン) を扱ったため、マルチエージェントのラッパーがそれらの基盤の上で具体的な成果をもたらすのかという当然の疑問が生じたからです。
論文の概要
"MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL" (Wang et al., COLING 2025) は、BIRD が初期のシングルプロンプト手法で露呈させた失敗モードをターゲットにしています。ノイズの多いスキーマを持つ大規模なデータベースや、複雑なマルチステップの質問は、すべてを一度に推論しようとするモデルを圧倒してしまいます。
アーキテクチャには3つのエージェントがあります。Selector は、SQL 生成が始まる前に関連性のないテーブルや列をフィルタリングすることで、大規模なデータベースを関連するサブスキーマに絞り込みます。Decomposer はコアエンジンであり、複雑な自然言語の質問をサブ問題に分解し、フューショットの Chain-of-Thought (思考の連鎖) 推論を用いて SQL を段階的に生成します。Refiner は、候補となる SQL を実際のデータベースに対して実行し、エラーメッセージをそのまま読み取って、最大再試行回数まで繰り返しクエリを修正します。3つのエージェントすべてがすべてのクエリでアクティブになるわけではありません。単純なタスクでは、複雑さのシグナルに基づいて Selector や Refiner をスキップします。
著者らはまた、このフレームワークによって生成された出力で SQL-Llama (Code Llama 7B) をファインチューニングし、より小規模なオープンソース版を提供しています。
主要なアイデア
- 生成前のスキーマ削減: Selector は、Decomposer が SQL を記述する前に、データベースを関連するサブスキーマにフィルタリングします。アブレーション解析により、BIRD dev セットで +2.11 パー センテージポイントの向上が確認されました。実質的ではありますが、控えめな結果です。
- 実行ガイド付きの洗練: Refiner は実際のデータベースのエラーメッセージを読み取り、SQL を修正します。これはアブレーションにおいて最大の貢献要素であり、これを除去すると BIRD dev の精度は 4.63 ポイント低下します。これは Selector (−2.11) や Decomposer (−3.85) を除去するよりも大きな影響です。
- 条件付きエージェントディスパッチ: 単純なクエリを Selector や Refiner に通さないようにルーティングすることで、簡単なケースでの精度を損なうことなくトークンを節約します。
- オープンソース蒸留のギャップ: SQL-Llama (7B) は BIRD dev で 43.94% に達しましたが、GPT-4 のベースライン 46.35% には及びませんでした。パラメータ数の差を考えればその差は劇的ではありませんが、ファインチューニングされた 7B モデルは、GPT-4+MAC-SQL のフルセットによるテストスコア 59.59% には依然として 15 ポイント以上の差をつけられています。
- BIRD テスト結果: 59.59% の実行精度を達成。提出時点でリーダーボードのトップに立ち、DAIL-SQL+GPT-4 (57.41%) を 2.18 ポイント上回りました。
評価できる点とそうでない点
Refiner はここでの最良のアイデアであり、アブレーションがそれを証明しています。実際のデータベースのエラーメッセージを読み取り、自身の SQL を修正するエージェントは、真空中で自己反省する LLM よりも、純粋に原理に基づいた動作をしています。これは CRITIC の「ツール対話型批判 (tool-interactive critiquing)」の原則を SQL 実行フィードバックに直接かつ具体的に適用したものです。
Selector の貢献はプラスですが、わずかなものです。数百のテーブルを持つデータベースではより重要かもしれませんが、BIRD の典型的なスキーマでは限界があり、論文では Selector がどの程度の頻度で起動したかや、関連する列を保持する精度については報告されていません。これは単一の集計数値のみのブラックボックスです。
Decomposer は DIN-SQL からの漸進的な進化です。DIN-SQL はすでに自己修正機能を備えたサブ問題へのクエリ分解を行っていました。MAC-SQL はこれをマルチエージェント間の会話として再構成したものです。3つの名前付きエージェントへのアーキテクチャ分割は、新しい推論アルゴリズムというよりは、ソフトウェア設計上の選択に近いです。総トークン数を制御した上で、3つのエージェントによるプロンプト構造が、単一エージェントによる長いプロンプトを上回るかどうかはテストされていません。認められている限界（プロンプトが「広範にエンジニアリングされていない」、ファインチューニングが 7B に制限されている）は現実的なものですが、より本質的な欠落は、プロンプトの長さ対アーキテクチャのアブレーションが完全に行われていないことです。
時間的な文脈は評価において重要です。BIRD テストでの MAC-SQL の 59.59% は 2023年12月時点では最先端でした。2025年半ばまでに、BIRD のリーダーボードには 81% を超えるシステムが登場しています。サブスキーマのフィルタリング、質問の分解、実行の再試行といった具体的なアイデアは、推論優先のトレーニング、RLVR、より豊かな CoT を使用した後続の研究によって吸収され、拡張されてきました。成果物としての MAC-SQL は古く見えますが、アーキテクチャパターンとしての MAC-SQL は依然として今日的です。
金融 AI にとっての重要性
Beancount は、元帳データに対する主要なプログラムインターフェースとして、SQL に近いクエリ言語である beanquery を使用しています。実際の数年間にわたる beancount ファイルには、階層構造で整理された数十のアカウント、複数の通貨、メタデータタグ、計算された残高列を含むスキーマが存在します。これはまさに Selector がターゲットとする、大規模でノイズの多いスキーマの問題です。
Decomposer は、ユーザーが実際に尋ねるような種類のクエリに直接適用できます。「2024年第3四半期のユーロでの外食費の合計はいくらか？ただし、払い戻された取引は除外し、月ごとに集計すること」という質問は、分解の問題です。アカウントプレフィックスによるフィルタリング、日付範囲によるフィルタリング、フラグ付き取引の除外、月ごとの集計などです。Refiner も自然に翻訳できます。生成された beancount エントリを確定する前に、エージェントが beancount パーサーでドライランを実行し、構文エラーや残高エラーを受け取って修正することが可能です。MAC-SQL が示す実行フィードバックループは、書き戻しセーフティレイヤーが必要とするループと同じです。
オープンソースの蒸留結果は警告でもあります。GPT-4 ベースのパイプラインを近似するために 7B モデルをファインチューニングしても、依然として大きく後れを取るモデルしか得られません。Bean Labs が元帳クエリ生成のためにローカルモデルを構築する場合、MAC-SQL からのギャップは、小規模モデルには汎用的なファインチューニングをはるかに超えるドメイン固有のトレーニングデータが必要であることを示唆しています。
次に読むべきもの
- DAIL-SQL (Gao et al., 2023, arXiv:2308.15363) — MAC-SQL が BIRD で直接改善を加えた、体系的なプロンプトエンジニアリングのベンチマーク評価。スキーマ表現とフューショット例の選択に関する制御されたアブレーションについて読む価値があります。
- SQLFixAgent (arXiv:2406.13408) — 実行ガイド付き SQL 修正を整合性チェック付きのマルチエージェントシステムに拡張した、MAC-SQL の Refiner のアイデアの直接的な後継です。
- BIRD-Critic / SWE-SQL (2025) — 実行エラーの理解を必要とする新しい BIRD 推論トラック。MAC-SQL の Refiner が行っていたことの自然な進化系です。
