VAKRAが8,000超のローカルAPIを再実行、エージェントの精度はマルチホップとポリシー制約で急落

IBMの研究チームは[VAKRA](https://arxiv.org/abs/2608.12282)を公開した。これは、エージェント評価においてツール呼び出し、RAG、マルチホップ推論、ポリシー遵守が別々にテストされがちだという課題を埋めることを目指すベンチマークだ。BIRD-SQLなどのデータを、62分野にまたがる8,000超の実行可能なAPIへ変換し、分野別ドキュメントも組み合わせている。タスクでは、エージェントが2〜5ホップの推論を行い、前段階で取得したエンティティやフィールドを後続APIのパラメータへ変換する必要がある。一部のワークフローでは、自然言語で記述されたツール利用制限も同時に遵守しなければならない。

評価では最終回答だけを確認するわけではない。システムは、エージェントが提出したツール実行軌跡をローカルサービス上で再実行し、まず使用したツールと返却データが正解を導くのに十分かを確認する。次にポリシー遵守を検査し、最後にモデルベースの評価器が、回答がツールの結果によって裏付けられているかを判定する。この設計では複数の有効な経路を許容するとともに、「誤ったツールの選択」「不正確なパラメータ値」「データ取得後の誤った結論生成」を区別できる。公開実装はDockerまたはPodmanを使い、SQLite、FastAPI、ChromaDB、MCPの各サービスを起動する。完全なデータセットには約35GBのストレージが必要で、一部のテストではコンテナに少なくとも8GBのメモリを割り当てる必要がある。

ReActラッパーを固定して評価したところ、GPT-5.5は単一エンドポイント型のDashboard APIタスクで70.4%を記録したが、操作の組み合わせが必要な2種類のBI APIインターフェースでは約50%〜51%にとどまった。多くのモデルでは、推論ホップ数が増えるにつれて精度が半分以下に低下した。ポリシーによって質問への回答が不可能になる場合、Claude Opus 4.7とGemini 3 Flash Previewの関連タスクにおける成功率は最低2.4%まで落ち込んだ。軌跡分析によると、主なボトルネックは関数呼び出し構文の生成ではなく、エンティティの曖昧性解消、複数ソース間の対応付け、フィールドの意味理解にあった。

エンジニアリングチームは、この環境を使ってエージェントが異種の企業システムを実際に横断できるかを検証できる。ただし、結果をそのまま本番環境での信頼性とみなすことはできない。データとポリシーの多くは既存の研究コーパスや生成パイプラインから構築されており、Groundednessの評価段階では依然としてLLMベースの評価器に依存している。Claude Opus 4.7もコスト上の理由からデータセットの一部でしか評価されていない。さらに、公開ライセンスは非商用の研究用途に限定される。今後は、異なるプランナー、構造化ポリシーエンジン、失敗後のリトライ戦略によって、基盤モデルを変更せずにマルチホップ推論の性能差を縮められるかが注目される。