BIRDベンチマーク：LLM Text-to-SQLにおける実データベースとの乖離
BIRDベンチマーク（NeurIPS 2023 Spotlight）は、GPT-4が「プレーンな英語でデータベースをクエリできる」という主張を耳にするたびに、私が読もうと思っていた論文です。この論文は鋭い問いを投げかけています。LLMは、学術的なおもちゃのようなスキーマではなく、実際のデータベースにおいて、本当にデータベースインターフェースとして機能するのでしょうか？その答えは、Beancountの元帳に対する自然言語クエリレイヤーが直面するであろう課題とほぼ直接的に重なる、身の引き締まるような内容でした。
論文について
Jinyang Li氏と、DAMO Academy、香港大学（HKU）、イリノイ大学アーバナ・シャンペーン校（UIUC）などの大規模なチームによる論文「Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs」は、BIRDを紹介しています。これは、37の専門ドメインにわたる合計33.4 GBの95の実データベースを用いた、12,751の「質問とSQL」のペアで構成されています。この規模こそがポイントです。これまでのText-to-SQL研究を支配していたSpiderやWikiSQLという2つのベンチマークは、せいぜい数百行程度の小さくクリーンなデータベースを使用していました。対照的に、BIRDは実際の機関（金融記録、毒性レポート、政府のデータセット）から抽出されたデータベースを使用しています。そこでは値が汚れており、カラムのセマンティクスにはドメイン知識が必要で、クエリの効率が実際に重要になります。また、この論文では2つの指標を導入しています。SQLの結果が正解と一致するかを確認する実行精度（EX）と、正解ではあるが遅いクエリにペナルティを与える有効効率スコア（VES）です。
主なアイデア
- GPT-4は、精査された外部知識のエビデンスが提供された場合でも、テストセットでわずか54.89%の実行精度しか達成できません。そのエビデンスがない場合、精度は34.88%に低下します。この20ポイントの差は、モデルが自身の世界知識よりも、提供されたヒントにいかに依存しているかを明らかにしています。
- 人間のパフォーマンスは開発セットで92.96%であり、GPT-4にドメインのコンテキストが与えられた後でも、38ポイントもの差が残っています。
- 外部知識は、質問ごとの「エビデンス文」として提供されます（例：「account.type = 'OWNER' はアカウント保有者が主な所有者であることを意味する」）。このコンテキストを自力で取得または推論できないモデルは、最初から足枷をはめられているようなものです。
- Beancountに最も関連性の高い金融ドメインは、アノテーションノイズ率が最も高く、その後の監査では金融ドメインのデータポイントの約49%に何らかの誤り（スペルミス、曖昧な質問、または不正確な正解SQLクエリ）が含まれていることが判明しました。
- リーダーボードは出版以来、大幅に変動しています。2026年現在、主要なシステム（AskData + GPT-4o）はテストセットで81.95%に達していますが、人間のパフォーマンス（~92.96%）との差は依然として存在します。この差が縮まったのは、主に精巧なマルチステップ・パイプラインによるものであり、モデル自体の生の能力によるものではありません。
維持されている点、そうでない点
「Spiderスタイルのベンチマークは、整理されたスキーマを使用することでText-to-SQLの難易度を過小評価していた」という核心的な貢献は揺るぎません。BIRDが実際のデータベース値と外部知識を重視したことで、クリーンなデータでは決して現れない失敗モードが明らかになりました。また、知識エビデンスの追加による20ポイントの変動は、再現可能で重要な発見です。
しかし、このベンチマークには、その後の研究でも認められている設計上の欠陥があります。外部知識のエビデンスは、ドメインの専門知識を持つアノテーターによってクエリごとに手書きされています。これは現実的なデプロイシナリオではありません。実際の自然言語対SQL（NL-to-SQL）エージェントは、すべての質問に対して事前に作成されたヒントを受け取るわけではありません。関連するドメインコンテキストを自身で取得または推論する必要があります。2025年のSEED論文は、自動生成されたエビデンスがいくつかの設定で手書きのエビデンスに匹敵するか、それを上回る可能性があることを示しており、知識のボトルネックこそが難所であるというBIRDの暗黙の前提を弱めています。
ノイズの監査結果はより深刻です。データセット内の22の正解SQLクエリは完全に間違っていました。これらを修正すると、モデルのランキングが入れ替わります。ゼロショットのGPT-3.5が、修正前のベンチマークでGPT-3.5を打ち負かすように設計されたDIN-SQLやMAC-SQLを上回る結果となりました。これは危険信号です。クリーンアップによってランキングが逆転するようなベンチマークは、モデルの能力と同じくらい、アノテーションのアーティファクト（人工的な癖）について教えていることになります。特に金融ドメインにおける49%のノイズ率は、ドメイン固有の結論を信頼できないものにしています。
また、VESにはより微妙な問題があります。クエリの効率を評価することは現実的で賢明な目標ですが、ベンチマークが効率性をトレーニングし評価するためには、特定のデータベースエンジンやデータ分布において何が「効率的」であるかというグラウンドトゥルースが必要です。BIRDでVESが機能するのは、実行環境を制御しているからです。この条件は、異種のハードウェア上でユーザーの個人元帳に対してbeanqueryを実行するBeancountエージェントには当てはまりません。
なぜこれが金融AIにとって重要なのか
Beancountのクエリ言語であるBQL（bean-query CLIやbeanqueryライブラリを通じて提供される）は、構文的にSQLに近いです。SELECT、WHERE、GROUP BY、集計関数、および組み込みのPosting（記帳）テーブルとBalance（残高）テーブルにわたる結合をサポートしています。ユーザーの質問をBQLに変換する自然言語インターフェースは、非技術系ユーザーにとって最も自然な入り口であり、BIRDの発見はこの挑戦の枠組みを直接的に示しています。
BIRDにおける外部知識の問題は、Beancountにそのまま当てはまります。ユーザーが「昨年、医療費にいくら使った？」と尋ねた場合、エージェントはユーザーの医療費が、アカウントの整理方法に応じて Expenses:Health:* にあるのか、それとも Expenses:Medical にあるのかを知る必要があります。このマッピングは個人的なものであり、どのトレーニングコーパスにも存在しません。エビデンスなしでGPT-4が20ポイント失うというBIRDの発見は、あらゆるBQL生成エージェントが、ユーザー自身の勘定科目体系（実質的にユーザーごとのナレッジベース）を学習するリトリーバル（検索）ステップを必要とすることを示唆しています。
汚れたデータの課題も直接関係します。インポートされた銀行取引には、一貫性のない加盟店名、OCRのアーティファクト、混在したエンコーディングが含まれていることがよくあります。BIRDは、これがSQLの正しさにどれほどのコストをもたらすかを数値化しており、その数値は前処理を後付けの考慮事項ではなく、最優先事項にするのに十分な大きさです。
BIRDがカバーしていない点として、残高確認（balance assertion）、埋め合わせ（pad）ディレクティブ、複数通貨の記帳など、元帳固有の構成要素は標準的なSQLには同等のものが存在しません。そのため、どのようなBQLエージェントも、BIRDでは測定されない複雑さの層に直面することになります。このベンチマークは有用な「下限」であって、到達すべき「上限」ではありません。
次に読むべきもの
- Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2502.04306, ICLR 2025 Oral) — BIRDをクラウドデータベースやマルチファイルワークフローを含むエンタープライズ環境に拡張。現実世界のデプロイメントのギャップを理解するための自然な次のステップです。
- SEED: Enhancing Text-to-SQL Performance and Practical Usability Through Automatic Evidence Generation (arXiv:2506.07423) — 自動化されたパイプラインにより、BIRDの手書きエビデンスの前提に直接取り組んでいます。
- DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arXiv:2304.11015, NeurIPS 2023) — BIRDのトップベースラインの1つ。複雑なSQLクエリをサブ問題に分解することで精度が向上することを示しており、Beancount元帳に対するマルチステップのBQLクエリに直接応用できる手法です。
