VAKRA ベンチマーク分析: エージェントの推論、ツール使用、および失敗モード

TL;DR

Hugging Faceは、62のドメインにわたる8,000以上のローカルホストAPIを含む実行可能なスイートであるVAKRAベンチマークをリリースしました。これは、構成的推論、ツール選択、マルチホップ・ワークフロー、およびポリシー遵守に関するAIエージェントをテストするものです。現在の最先端モデルはパフォーマンスが低く、実世界へのデプロイメントにおける重大なギャップを露呈しています。

VAKRAとは？

VAKRAは、AIエージェントがエンタープライズのような環境でどれだけ適切に推論し、行動できるかを評価するために設計された、ツールに基づいた実行可能なベンチマークです。従来の孤立したスキルテストとは異なり、VAKRAはエージェントに完全なマルチステップのワークフローの実行を要求し、検証のために実行トレースを提供することで、APIとドキュメントにわたる構成的推論を測定します。

主な統計:

実際のデータベースに裏付けられた8,000以上のローカルホストAPI。
ビジネスインテリジェンス、ダッシュボード、ドキュメント検索をカバーする62のドメイン。
タスクには、構造化されたAPI呼び出しと非構造化ドキュメント検索を組み合わせた3〜7ステップの推論チェーンが含まれます。
4つの能力グループが、異なるスキルセット（APIチェイニング、ツール選択、マルチホップ推論、およびポリシー制約を伴うマルチソース推論）をテストします。

ベンチマーク、データセット、リーダーボード、およびコードは、Hugging FaceとGitHubで公開されています。

能力 1 – ビジネスインテリジェンスAPIによるAPIチェイニング

インスタンス: 54ドメインにわたる2,077個。
ツールコレクション: SLOT-BIRD (7つの汎用ツール) および SEL-BIRD (拡張されたドメイン固有のゲッター)。
ワークフロー: get_data(tool_universe_id) で軽量なプレビューをロードしてサーバーを構成することから始まり、続いてデータをフィルタリングおよび選択するために1〜12のチェインされたツール呼び出しが行われます。

JSONリクエストの例 (簡略化):

{
  "query": "Which football team has a build-up play speed of 31 …?",
  "tool_calls": [
    {"name": "get_data", "arguments": {"tool_universe_id": "..."}, "label": "retrieved_data_1"},
    {"name": "select_data_equal_to", "arguments": {"data_label": "retrieved_data_1", "key_name": "play_speed", "value": 31}, "label": "FILTERED_DF_0"},
    ..
  ],
  "answer": "FC Barcelona"
}

課題: 大規模で動的なセットから正しいツールを選択し、多くのオプションパラメータを提供すること。

能力 2 – ダッシュボードAPIによるツール選択

インスタンス: 17ドメインにわたる1,597個。
ツールコレクション: FastAPIを介して提供され、MCPサーバーによってラップされたREST-BIRD。
ドメインサイズ: ドメインあたり6〜328個のツール (平均116個)。
制約: OpenAIの128個というツールリストの制限により、エージェントにはショートリスト作成メカニズムの実装が強制されます。ベースラインは単純なヒューリスティック・ショートリスターを使用しています。
目標: クエリに対して単一の正しいエンドポイント形式のAPIを特定すること。

能力 3 – ダッシュボードAPIによるマルチホップ推論

インスタンス: 38ドメインにわたる869個。
要件: 1〜5回の論理的なホップ。各ホップは正しいAPIを呼び出し、適切な引数を渡す必要があります。
観察: ホップの深さが増すにつれて精度が急激に低下しており、複数のAPI呼び出しをチェインすることが現在のモデルにとって大きな困難であることを裏付けています。

能力 4 – マルチホップ・マルチソース推論およびポリシー遵守

インスタンス: 41ドメインにわたる644個。
特徴:
- マルチソース: クエリには API → ドキュメント検索 (RAG) → API のようなシーケンスが必要な場合があります。ソースのデコンタミネーション（汚染防止）により、各ホップの回答は単一のソースからのみ利用可能であることが保証されます。
- マルチターン: 対話コンテキストが提供されます。エージェントは現在のターンのみに回答する必要があります。
- ツール使用ポリシー: プレーンテキストの制約により、どの知識ソースを使用できるかが規定されます（例：「テクノロジーに関するクエリにはドキュメント検索器のみを使用すること」）。
ポリシーの強制: ベースラインエージェントはプロンプトの前に制約文を付加します。開発者はより高度なチェックを実装することも可能です。

評価フレームワーク

VAKRAは、ツールの実行の正確性と最終的な回答の品質の両方でエージェントを検証する、実行中心のウォーターフォール型パイプラインを使用しています。

ポリシー遵守 (能力4のみ) – プログラム的に検証。
ツール呼び出しシーケンスの検証 – 予測された呼び出しが実行され、レスポンスがグランドトゥルース（正解）のレスポンスと比較されます。
- 完全一致に失敗した場合、LLMベースの評価器 (CRAGから適応) が、予測された軌跡がすべての必要な情報を取得しているかを確認し、代替の有効なツールシーケンスを許可します。
最終回答の評価 – LLMジャッジが、回答が実行されたツールの出力に基づいていること、および事実としてリファレンスと一致していることを確認します。

スコアリング

4つの能力すべてが等しい重み付けを受けます:

$$\text{Leaderboard Score}=\frac{1}{4}\sum_{i=1}^{4}\text{Capability}_i$$

能力 1-3: 単純な精度 (正しいクエリ数 / 総クエリ数)。
能力 4: マルチソースクエリは、難易度の高さを反映して2倍の重みが付けられます。

エラー分析 – エージェントが崩壊する箇所

分析では、失敗を最初の崩壊点によって分類しています:

誤ったツール選択。
引数の欠落またはハルシネーション。
不正確な引数の値。
不正確または根拠のない最終回答。

APIチェイニング (能力 1)

最良のモデル: GPT-OSS-120B。主にツールスキーマの優れた理解と、オプションパラメータの堅牢な処理によるものです。
エラーパターン: SLOT-BIRDコレクションを使用しているモデルは引数の命名に苦戦し、SEL-BIRDを使用しているモデルはツールセットが大きいためにツール選択のミスが多くなりました。

ダッシュボードツール選択 (能力 2)

最良のモデル: Gemini-3-flash-preview。すべてのエラーカテゴリにおいて他を圧倒しています。
支配的なエラー: ツール選択の失敗と不正確なパラメータ値。ツール呼び出しが成功した場合でも、最終回答の合成が課題として残りました。

マルチホップ推論 (能力 3)

傾向: ホップの深さとともに精度が低下します (1ホップ > 2ホップ > 3+ホップ)。すべてのモデルが同じパターンを示しており、複数のAPI呼び出しのチェイニングがエラーの伝播を増幅させることを裏付けています。

マルチホップ・マルチソースおよびポリシー (能力 4)

ハイブリッドホップ: API呼び出しとドキュメント検索の両方を必要とするインスタンスが最も困難です。純粋なAPIまたは純粋なRAGのホップと比較して、パフォーマンスが急激に低下します。
ポリシーの影響: モデルは一般的にポリシーを十分に遵守できていません。最も関連性の高いソースがポリシーによって制限されると、ほとんどのモデルで顕著な精度の低下が見られます。Granite-4.0-h-Small-32Bは例外で、低下が少ないことを示しています。
具体的な観察: GPT-OSS-120Bは、単一ホップのRAG呼び出しをスキップして、内部知識から回答してしまうことがよくあります。Gemini-3-flash-previewは、ダッシュボードAPIにおける強みを活かしていると思われる、2ホップのAPI-RAGコンボで優れた性能を発揮します。

エージェント開発への示唆

ツールの能力 ≠ 信頼性: 正しいAPIを選択することは問題の一部に過ぎません。エージェントは引数を管理し、マルチステップのワークフローを実行し、外部の制約を尊重する必要があります。
実行中心のメトリクスが重要: 従来の回答のみのスコアは中間ステップでの失敗を隠してしまいます。VAKRAの軌跡ベースの評価は、これらのギャップを浮き彫りにします。
ポリシー処理は弱点: 実世界へのデプロイメントでは、コンプライアンスやセキュリティポリシーが課されることがよくあります。現在のモデルは、そのような制約を推論に組み込むことに苦労しています。
開発ターゲットとしてのベンチマーク: エージェントがどこで失敗するかを明らかにすることで、VAKRAはツール使用モジュール、ショートリスト作成メカニズム、およびポリシーを意識したプロンプティングを改善するための具体的なロードマップを提供します。

VAKRAを試す方法

データセット: https://huggingface.co/datasets/ibm-research/VAKRA
リーダーボード & 提出: https://github.com/IBM/vakra?tab=readme-ov-file#submitting-to-the-live-leaderboard
コード & 評価器: https://github.com/IBM/vakra

エージェントをベンチマークで実行し、ツール選択、マルチホップ推論、またはポリシー遵守のどこで失敗するかを確認し、VAKRAが提供する詳細なエラー内訳に基づいて反復改善を行ってください。