DIN-SQL: Text-to-SQLのための分解されたインコンテキスト学習

先週、私はBIRDについて取り上げました。これは、text-to-SQLが整理されたトイ・データベースから、乱雑な命名、ドメイン知識、効率性の制約を伴う実世界のスキーマに移行した際に、LLMがいかに大きく躓くかを明らかにしたベンチマークです。DIN-SQLは、本来最初に読んでおくべき論文でした。これは、慎重に分解されたLLMプロンプティング・パイプラインがSpiderやBIRDで実際に何を達成できるかを定義したものであり、GPT-4が広く利用可能になったちょうどその頃に、Mohammadreza Pourreza氏とDavood Rafiei氏によってNeurIPS 2023で発表されました。BIRDによって限界が露呈した今、これを読むことで、その強みと限界がより鮮明に見えてきます。

論文について

DIN-SQL (arXiv:2304.11015) は、顕著なパフォーマンスのギャップに対処しています。2023年初頭、最高のファインチューニング済みモデル（RESDSQL-3B+NatSQL）はSpiderテストセットで79.9%の実行精度に達していましたが、素のフューショット・プロンプティングを用いたGPT-4は開発セットで67.4%に留まっていました。Pourreza氏とRafiei氏の仮説は、このギャップは主にインターフェースの問題であるというものです。LLMには十分な能力がありますが、1回のパスでSQLを生成させることは、スキーマリンキング、複雑度分類、クエリ合成をすべて同時に解決させることになります。これらを連続したサブタスクに分解し、各解決策をコンテキストとして次に渡せば、話は変わってきます。

彼らのパイプラインには4つのステージがあります：(1) 思考の連鎖（CoT）プロンプティングを使用して自然言語の質問をスキーマ内の特定の列や値にマッピングするスキーマリンキング・モジュール。(2) クエリを「簡単（単一テーブル、結合なし）」、「非入れ子複雑（結合あり、サブクエリなし）」、「入れ子複雑（結合、サブクエリ、集合演算あり）」に分類し、入れ子クエリの場合は問題をサブクエリに分解する分類・分解モジュール。(3) プロンプティング戦略を複雑度クラスに合わせるSQL生成モジュール（簡単な場合は単純なフューショット、非入れ子の場合はNatSQL中間表現、入れ子の場合は多段階CoT）。(4) DISTINCTの欠落やDESCの配置ミスといった軽微なエラーがないか、モデル自身に出力をレビューさせる自己修正モジュールです。

主要なアイデア

• GPT-4 + DIN-SQLは、タスク固有のトレーニングデータなしで、Spiderのホールドアウト・テストセットで85.3%の実行精度に達し、当時のSOTAであったファインチューニング済みのRESDSQL-3B+NatSQL（79.9%）を5.4ポイント上回りました。
• Spider開発セットにおいて、分解パイプラインによりGPT-4は67.4%（フューショットのベースライン）から74.2%へと6.8ポイント向上しました。CodeX Davinciは61.5%から69.9%へと向上しました。
• アブレーション研究により、すべてのステージが貢献していることが確認されました。スキーマリンキングを除去するだけでCodeXは69.9%から65.9%に低下し、分類を除去するとさらに63.1%まで低下しました。
• 精度向上は「簡単」および「中程度」のクエリに集中しています。「超難問（extra hard）」のクエリでは、完全なDIN-SQL + GPT-4パイプラインでもSpider開発セットで43.4%にしか達しません。分解は複雑さを根本的に解決するのではなく、解法が明らかなクエリにおける回避可能なエラーを減らすだけです。
• 自己修正はモデルに依存します。GPT-4は潜在的な改善を促す「穏やかな」プロンプトに反応しますが、CodeXはSQLが間違っていることを前提とした「一般的な」プロンプトにより良く反応します。これは、このモジュールが真の意味論的検証ではなく、スタイルのクリーンアップを行っていることを示唆しています。
• BIRD開発セットでは、DIN-SQL + GPT-4のスコアは50.72%で、素のGPT-4ベースラインの46.35%と比較して4.4ポイントの向上でした。これはSpiderでの向上幅よりも大幅に小さくなっており、これについては後述します。

評価できる点とそうでない点

核心となる結果は本物です。text-to-SQLを明示的なサブタスクに分解することでパフォーマンスが向上し、アブレーション研究も個々のモジュールの貢献を信じるに足るほど明確です。難易度の高いクエリにおいてスキーマリンキングが最も重要であるというのは理にかなっています。質問がどのテーブルや列を指しているかを正しく特定できなければ、モデルは正しいJOINを生成できません。

しかし、いくつか気になる点もあります。開発セット（74.2%）とテストセット（85.3%）の乖離は不自然です。通常、モデルは開発セットに対して暗黙的にチューニングされるため、開発セットの方が難しいか、少なくとも同等であるのが普通です。開発からテストで11ポイントも跳ね上がるのは異例です。著者はこれについて説明しておらず、テストセットの難易度分布が異なるのか、あるいは公式のSpiderリーダーボードサーバー経由の評価方法に何か違いがあるのか疑問が残ります。この点に触れずに85.3%という数字を引用することには慎重であるべきです。

BIRDにおける差（50.72%）がSpiderの向上幅より顕著に小さいことも注目に値します。BIRDのデータベースは、省略された列名、ドメイン固有の用語、曖昧な値を持つ、乱雑な実世界のスキーマを持っています。DIN-SQLのスキーマリンキング・モジュールは、Spiderの比較的綺麗なスキーマを念頭に設計されました。スキーマが汚くなると、リンキング精度が低下し、パイプラインの残りの部分もそれに引きずられて劣化します。これはまさにBIRDの論文が測定したことであり、DIN-SQLはそれを解決していません。

コストとレイテンシの数字は、商用システムにとっては問題です。GPT-4を使用した場合、質問1回につき約0.50ドル、時間は60秒かかります。1日に10個のクエリを実行するデータアナリストであれば問題ありませんが、インタラクティブな用途には全く不向きです。論文ではこれを既知の制限事項として提示していますが、削減のための道筋は提案されていません。数ヶ月後に発表されたDAIL-SQL (arXiv:2308.15363) は、明示的な分解ではなく、より優れた例文選択によって、Spiderで86.6%に到達し、DIN-SQLを大幅に低いコストで上回ることを示しました。

自己修正モジュールは最も脆弱な部分です。著者も「軽微な」エラーをキャッチすることを認めています。できないのは、意味論的なエラーの検出です。生成されたSQLが構文的に正しく実行も可能であっても、質問に対する答えとして間違っている場合です。これは、実際のユーザーにとってより深刻な失敗モードです。

金融AIにとっての重要性

Beanquery (BQL) は、Beancountの帳簿データに対するSQLライクなクエリ言語です。これには、一般的なデータベーススキーマとは全く異なる、勘定科目の階層、タグ、メタデータフィールドを備えた独自のテーブル構造（transactions, postings, balance, prices）があります。BQLへの自然言語インターフェースは非常に有用であり（実際にこれをMCP経由で実装した実験的な beanquery-mcp サーバーが存在します）、DIN-SQLの分解戦略は出発点として適切です。

BQLにおけるスキーマリンキングはリレーショナルテーブルの場合と似ていますが、2つの大きな違いがあります。勘定科目が Assets:US:Checking:Bank のような階層パスであること、そして関連するスキーマがユーザーの質問の種類（損益計算書、貸借対照表、キャッシュフロー）に依存することです。DIN-SQLの分類モジュールは、直接的な適用の可能性を示唆しています。まずクエリの意図（残高 vs フロー vs 価格検索）を分類し、それから異なるプロンプトテンプレートにルーティングするのです。

実世界の乱雑さがLLMのtext-to-SQLを阻害するというBIRDベンチマークの知見は、直接的に関連しています。Beancountの帳簿もまた、ユーザー定義の勘定科目名、一貫性のないコモディティ記号、カスタムメタデータキーなど、非常に「乱雑」です。BIRDでの向上が4.4ポイントであったのに対しSpiderでは6.8ポイントであったことは、構造化された綺麗なスキーマ環境での評価は、実際のBQLクエリにおいて分解がどれほど役立つかを過大評価していることを示唆しています。実際には、より限定的な向上を期待すべきでしょう。

コストの制約は存在しますが、ここではそれほど致命的ではありません。個人財務ユーザーが1日に10〜20件のクエリを実行する場合、インターフェースが真に有用であれば、APIコストとして1日5〜10ドルを許容できるかもしれません。それよりも60秒というレイテンシがインタラクティブな使用において問題となります。分析クエリをバッチ処理することで、この問題を回避できるかもしれません。

次に読むべき文献

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — プロンプトエンジニアリング戦略の系統的な研究。アーキテクチャの分解ではなく例文の選択に焦点を当てることで、Spiderで86.6%を達成。DIN-SQLに対する有用な対比となります。
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — DIN-SQLが上回ったファインチューニング済みのベースライン。ファインチューニングのアプローチが得意とする内容を理解することで、プロンプティングが依然として及ばない点が明確になります。
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — 多段階の分解のアイデアを、Selector、Decomposer、Refinerを備えた明示的なマルチエージェント・パイプラインへと拡張。GPT-4を使用してBIRDで59.59%に達しており、この分野で最もエージェント中心のアプローチです。