技術要約: Spider 2.0-AIFunc

問題提起

主要なクラウドデータプラットフォーム（Snowflake、BigQuery、Databricksなど）は、大規模言語モデル（LLM）の機能をネイティブなSQL関数として公開し始めています。これらの「AIネイティブ」関数により、アナリストは標準的なSQLクエリ内で、分類、感情分析、類似性検索、情報抽出といったセマンティックな操作を直接実行できるようになりました。しかし、既存のText-to-SQLベンチマーク（Spider 1.0、Spider 2.0、BIRDなど）は、構造化データに対する従来のSQLのみを評価しています。これらは、標準的なクエリ構築だけでなく、AI関数の正しい選択、パラメータ設定、および統合能力を必要とするAIネイティブSQLを生成するモデルの能力については、何らシグナルを提供しません。

メソドロジー

著者らは、AIネイティブなワークフローの文脈におけるText-to-SQL能力を評価するために設計されたベンチマーク、Spider 2.0-AIFuncを導入します。構築および評価のメソドロジーは、以下の3つのコアコンポーネントで構成されています。

1. エージェント・パイプラインによるベンチマーク構築

このベンチマークは、Spider 2.0のエンタープライズレベルのサブセットであるSnowflake上のSpider2-Snowデータセットの513インスタンスから派生しています。著者らは、再利用可能なエージェントベースのパイプライン（Claude Opus 4.5を使用）を用いて、これらの伝統的なタスクをAIネイティブ版へと変換します。

• 変換: エージェントは、Snowflake Cortex AI関数を組み込むようにターゲットSQLを書き換えると同時に、意図されたAIの使用を明示的にするために自然言語の指示を洗練させます。
• 曖昧さの排除: 複数の有効なゴールドSQLが存在するタスクに対しては、単一の正解を保証するために、指示を洗練させて正確なAI関数とパラメータ（例：分類のための完全なクラスラベルセット）を指定します。
• 2段階プロセス:
  • メインラウンド: エージェントがAI関数を自由に選択し、その結果、AI_CLASSIFY、AI_FILTER、AI_SIMILARITYが支配的な分布となります。
  • 多様性ラウンド: エージェントは、6種類のサポートされているAI関数タイプの広範なカバレッジを確保するために、過小評価されている関数（AI_SENTIMENT、AI_EXTRACT、AI_AGG）を優先するよう指示されます。

2. 決定論的検証

AI関数のベンチメントにおける重要な課題は、LLMの出力がゼロ温度設定であっても微細な不一致を示す可能性があるため、**実行の決定論（execution determinism）**です。これに対処するため：

• マルチパス検証: 各候補インスタンスは、4回の実行パス（合計35回以上の実行）を経ます。検証エージェントは、SQL、指示、または評価構成を調整することで、不一致な結果を生むインスタンスを修復します。
• 時間的安定性: 生き残ったインスタンスは、時間的に分離された3つの時間枠における30回の実行を含む最終的な安定性チェックを受けます。これらの時間枠間で不一致な結果を生じるインスタンスは破棄されます。
• 最終データセット: このプロセスにより、125の実世界のデータベースにわたる465の検証済みインスタンスが得られました。

3. 評価プロトコル

• 指標: 実行精度（Execution Accuracy: EX）。ゴールドの結果が事前に計算され静的である従来のベンチマークとは異なり、Spider 2.0-AIFuncでは、ゴールドSQL（$S_n$）と予測SQL（$\hat{S}_n$）の両方を同じ時間枠内で実行し、両者が同じ基礎となるモデルの状態に対して評価されることを保証する必要があります。
• 比較ロジック: 結果はカラム部分集合マッチング（ゴールドのカラムが予測結果に含まれていなければならない。予測カラムには余分なものが含まれていてもよい）を使用して比較されます。
• フレームワーク: モデルは、最小限のツールセット（スキーマ探索、SQL実行、タスク終了のためのbash）を備えたSpider-Agentフレームワークを使用して評価されます。セットアップには、Snowflake Cortex AI関数のリファレンスドキュメントが含まれます。

主な貢献

1. Spider 2.0-AIFunc ベンチマーク: AIネイティブなText-to-SQLに特化した初のベンチマークであり、465の検証済みインスタンス、125のデータベース、および6種類のAI関数（分類、フィルタリング、感情、類似性、抽出、集計）をカバーしています。
2. エージェントベースの構築パイプライン: 既存のエンタープライズText-to-SQLタスクを、指示の洗練と実行の決定論の検証を同時に行いながら、AIネイティブ版へと自動的に変換する新しいパイプラインです。
3. AIネイティブSQLの経験的分析: 10の最先端モデル（プロプライエタリ5種、オープンソース5種）と3つのエージェントフレームワークの包括的な評価を行い、特定の失敗モードと、この新しい環境における従来のText-to-SQL戦略の限界を明らかにしました。

結果

Spider 2.0-AIFuncにおける10のモデルの評価から、以下の知見が得られました。

• プロプライエタリ vs オープンソースの格差: プロプライエタリなモデルは、オープンソースのモデルを大幅に上回っています。
  • トップ・プロプライエタリ: Claude Opus 4.6 (70.3%)、Claude Sonnet 4.6 (69.0%)、Gemini 3.1 Pro (67.1%)。
  • トップ・オープンソース: Kimi K2.5 (58.1%)。
  • この格差は、主に述語の指定（predicate specification）、スキーマのグラウンディング（schema grounding）、およびAI関数のパラメータ設定におけるエラーによって引き起こされています。
• 実行成功率: ほとんどのモデルは高い「Exec.（実行）」率（90–99%）を達成しており、これはエラーなしで動作する構文的に正しいAIネイティブSQLを生成できることを示しています。性能の差は、意味的な正しさ（semantic correctness）にあります。
• エージェントフレームワークの転移性: 従来のText-to-SQLの課題（スキーマの取得、テーブル選択など）のために設計されたエージェントフレームワークは、AIネイティブSQLには効果的に転移しません。
  • 複雑なフレームワーク（AutoLink、ReFoRCE、DSR-SQL）は、同じバックボーンモデル（Claude Sonnet 4.6）を使用した場合、最小限のSpider-Agentセットアップと同等の性能は見せましたが、それを超えることはありませんでした。
  • これは、従来のSQLのスキャフォールディング（足場作り）のための戦略よりも、AI関数の使用に関する正確なセマンティックな決定（例：正しいパラメータ設定、フィルタリングの順序）を行う能力の方が重要であることを示唆しています。
• インタラクション挙動: オープンソースのモデルは、プロプライエタリなモデル（10–12回）と比較して、有意に多くのインタラクションラウンド（19–30回）と、より多くのSQL実行試行を必要とし、しばしば正しく終了することに失敗します。

重要性と主張

本論文は、Spider 2.0-AIFuncが、純粋な構造化データの操作から、セマンティックな操作をSQLに直接統合するAIネイティブなワークフローへと、Text-to-SQL評価を進化させるために必要であると主張しています。

著者らは以下を強調しています：

1. 現在のベンチマークは不十分である: 既存のベンチマークは、エンタープライズのデータパイプラインへのLLM機能の統合という複雑さを捉えきれていません。
2. 決定論は極めて重要である: 検証プロトコルは、制御された環境であってもLLMの出力に固有の非決定性があるため、AI関数のベンチマークには厳格な安定性チェックが必要であることを浮き彫りにしています。
3. 戦略のシフト: 複雑なエージェントフレームワークが最小限のセットアップを上回ることができない事実は、AIネイティブSQLの主なボトルネックは、スキーマの取得や分解ではなく、AI関数の正確な指定とパラメータ設定にあることを示唆しています。モデルが向上するにつれ、従来のSQLコンポーネントのための精巧なスキャフォールディングの価値は、正確なセマンティック関数の呼び出しの必要性に比べて減少していきます。

この研究は、企業向けデータプラットフォームによってますます求められている能力である、「AIネイティブ」なデータ分析ワークフローを構築できるモデルを評価し、改善するための基礎的なステップとして機能します。