技術概要：BEAVER：テキストから SQL へのエンタープライズベンチマーク

問題定義

既存のテキストから SQL へのベンチマーク（Spider、BIRD など）は、構造化されたスキーマ、明示的な結合関係、比較的単純なクエリを持つ公開データベースから構築されています。大規模言語モデル（LLM）はこれらのベンチマークで高い精度を達成していますが、その有効性は非公開のエンタープライズ環境において未証明のままです。エンタープライズデータウェアハウスは以下のような固有の課題を提示します：

• スキーマの複雑性： スキーマは大規模で異質であり、継続的に進化しており、暗号化されたようなカラム名と限られたドキュメントを含む数百のテーブルを有することが多い。
• 暗黙的な関係： 結合関係は、外部キーを通じて宣言されるのではなく、頻繁に暗黙的である。
• ドメイン知識： 自然言語クエリの解決には、スキーマに明示的にエンコードされていないドメイン固有の知識の抽出（例、「Stata building」を内部 ID にマッピングする）がしばしば必要となる。
• クエリの洗練度： エンタープライズクエリは高度に分析的であり、深いネスト、共通テーブル式（CTE）、高度なウィンドウ関数、および複数の結合を伴う。
• 評価の限界： 標準的な「実行精度」（全か無か）指標は、複数の複合的な課題が同時に存在する場合、特定の失敗モードを診断するのに失敗する。

手法

1. データセット構築（BEAVER）

著者は、非公開のエンタープライズデータウェアハウスから導出された最初のテキストから SQL へのベンチマークであるBEAVERを導入する。

• ソースデータ： データセットは、19 の多様なドメイン（例：教育、施設、ネットワーク）を網羅する 3 つの匿名化されたエンタープライズウェアハウス（DW、NW、SP）から構築されている。これには、実際のユーザークエリログと本番環境レポートから収集された 812 のテーブルと 9,128 の質問 - SQL ペアが含まれる。
• データ合成（構造的テンプレート再構成）： プライバシー制約によりアクセス可能なエンタープライズログが不足しているという課題を克服するため、著者は体系的なパイプラインを提案する：
  1. テンプレート抽出： 実際のログから反復的な分析パターン（ベースの SELECT-FROM-JOIN-WHERE-集約、ネスト、CTE、およびドメイン知識述語）を抽出する。
  2. 反復的構成： これらのテンプレートを具体的な値（テーブル、カラム、インスタンス）でインスタンス化し、LLM を使用して反復的に構成する。
  3. 課題の分離： このパイプラインは、特定の課題を分離するクエリを生成する：ドメイン知識なしの高度な複雑さ、ドメイン知識ありの低複雑さ、および両者の組み合わせ。
  4. 検証： 合成されたすべてのクエリは、実行可能性と正しさを専門家が検証する。

2. 評価フレームワーク

BEAVER は、人間の注釈と特定の指標を備えた5 つの重要なサブタスクを導入することで、二値的な実行精度を超えて進化する：

1. マルチテーブル検索： 正しいテーブルのサブセットを特定する（F1 スコア）。
2. 結合キー検出： テーブル間の暗黙的な結合条件を推論する（F1 スコア）。
3. カラムマッピング： 自然言語の概念を不明瞭なカラム名にマッピングする（F1 スコア）。
4. ドメイン知識抽出： 最終的な SQL に含まれないインスタンス値とドメイン事実を特定する（F1 スコア）。
5. クエリ分解： 複雑な質問をサブ問題（CTE/サブクエリ）に分解する（スコア 0-100）。

主要な貢献

1. BEAVER ベンチマーク： 非公開エンタープライズ環境の「無秩序さ」を反映する大規模データセット（9,128 クエリ）。データベースあたりの平均 101.5 のテーブルと 869.4 のカラムを特徴とし、Spider 2.0 や BIRD などの既存ベンチマークよりも著しく大規模である。
2. 構造的テンプレート再構成： 現実世界のワークロードへの高い忠実性を維持しつつ、厳格なプライバシー制約下でエンタープライズデータセットを拡張するための原理的な手法。
3. 微細な評価： 5 つのサブタスクに対する人間の注釈を提供するフレームワークにより、粗い実行精度を超えたモデル失敗の診断分析を可能にする。
4. 包括的なエラー分類： 残存エラーの詳細な分析。失敗を分析的・構造的エラー、スキーマリンキングエラー、述語エラーに分類する。

実験結果

著者は、BEAVER 上で 7 つの最近の LLM（GPT-5.2、Claude-4.5、Qwen3 などを含む）と 4 つのテキストから SQL への手法（ReFoRCE、DIN-SQL、DAIL-SQL、Few-shot）を評価した。

• 性能ギャップ： 既存のベンチマークと比較して、性能に大幅な低下が見られる。GPT-5.2 を使用した最先端のエージェントフレームワーク（ReFoRCE）は、BIRD/Spider で約 80% であるのに対し、BEAVER での実行精度はわずか**10.8%**であった。
• サブタスク分析：
  • モデルは結合キー検出、ドメイン知識、およびクエリ分解で最も性能が低かった。
  • 明示的な外部キーの欠如と暗号化された命名により、結合キー検出は特に困難である。
• オラクルヒント： 5 つのサブタスクすべての注釈を「オラクルヒント」として提供した場合、実行精度は**30.1%**に向上した。これは、これらのサブタスクを正しく解決することが主要なボトルネックであることを確認するが、依然として大きな残存エラーが存在する。
• クエリカテゴリ： モデルは、高い構造的複雑さとドメイン知識を組み合わせたクエリで最も苦労した。ドメイン知識を含まない純粋に複雑なクエリはわずかに容易であり、低複雑さのドメイン固有クエリが最も管理しやすかった。

エラー分析

サブタスクに対するオラクルヒントがあっても、残存エラーは残存し、以下のように分類される：

• 分析的・構造的エラー（46.8%）： グループ化、順序付け、高度な関数（ウィンドウ、スカラー、集約）、およびクエリ分解（例：ROLLUP の誤用）における誤り。
• スキーマリンキングエラー（35.2%）： 不透明な命名規則に起因する、テーブル/カラムの選択および結合タイプの誤り。
• 述語エラー（18.0%）： 誤ったリテラル値または省略されたフィルタ。ドメイン固有の規則の適用失敗を反映している。

意義

本論文は、堅牢でエンタープライズ対応可能な SQL エージェントの開発に向けた重要な一歩として BEAVER を位置づける。それは、単純化された公開ベンチマークでは成功している現在のテキストから SQL への手法が、現実世界の非公開エンタープライズ設定で必要とされる複雑なスキーマ、暗黙的なドメイン知識、および洗練された分析的構成を処理する能力をまだ有していないことを示している。BEAVER は、困難なデータセットと微細な診断フレームワークを提供することで、分野を進展させるために解決されなければならない特定のボトルネック（特にサブタスクの解決と高度な SQL 構築）を特定する。