AIエージェントの評価というと、つい「質問に答えられるか」「コードを書けるか」みたいな単発タスクを思い浮かべがちです。
でも現実の仕事って、そんなに単純じゃないですよね。
たとえば、
……みたいな、地味だけど面倒な工程の連続です。
VAKRAは、まさにそこを測ろうとするベンチマークです。
IBM Research が Hugging Face 上で公開したこの記事では、VAKRA を tool-grounded, executable benchmark と説明しています。ざっくり言えば、「ツールを本当に使って動く環境で、エージェントの推論力と実行力を測る」ということです。
ここが面白いのは、単なる知識テストではなく、複数のAPIや文書をまたいで、ちゃんと手を動かせるかを見ている点です。
正直、これこそエージェントの本番だよな、と思います。知っているだけでは仕事にならないので。
VAKRAは、主に次のような特徴を持っています。
つまり、モデルは「質問に答える」のではなく、ツールを呼び出しながら答えを作る必要があります。
しかも記事によると、モデルはこのベンチマークでかなり苦戦しているとのこと。
これは納得感があります。現実の業務っぽいタスクは、モデルの“知ってる風”を簡単には許してくれません。曖昧な推測ではなく、正しい手順で正しい情報に到達する力が問われるからです。
VAKRAは、4つの能力領域に分かれています。
順番に見ていくと、だんだん「これは難しいぞ」という感じが強くなります。
これは、複数のAPIをつないで答えを出す力を測るタスクです。
記事によると、2,077件のテストインスタンスがあり、54ドメインにまたがっています。
SLOT-BIRD や SEL-BIRD というツール群を使い、1回から12回ものツール呼び出しが必要になることもあります。
ここでのポイントは、1つのAPIを呼んで終わりではないことです。
たとえば記事中の例では、あるサッカーチームを見つけるために、データを取得してから、速度・ドリブル・パスという複数条件で順番に絞り込んでいます。
こういう“段階的な絞り込み”は、まさに人間がBIツールを使うときの感覚に近いです。
個人的には、このタイプが一番「業務っぽい」と感じます。
派手さはないけど、実務ではこういう作業が一番多いんですよね。
こちらは、たくさんあるツールの中から正しいものを選ぶ力を測ります。
17ドメイン、1,597件のインスタンスがあり、各ドメインには6〜328個、平均116個ものツールがあるそうです。
いやこれは多い。普通に考えて、エージェントが迷うのも当然です。
しかも OpenAI API Specification には、ツール一覧の長さに最大128個という制限があります。
つまり、単に全部見せればいいわけではなく、候補を絞り込む仕組みも必要になります。
ここで大事なのは、AIエージェントには「賢く答える力」だけでなく、使える道具をうまく選ぶ力が必要だということです。
人間でも、工具箱が巨大すぎると逆に困るので、これはかなり自然な課題設定だと思います。
これは、1回で答えられない質問に対して、複数の情報をつなげて考える力です。
869件のインスタンス、38ドメイン。
1〜5段階の論理的な「hop」が必要になります。
ここでいう hop は、簡単に言えば推論の段階です。
たとえば、
という流れです。
これは「検索すれば終わり」ではなく、情報を組み立てる力が試されます。
最近のAIは検索もできますが、複数の情報を正しくつないで結論を出すのは、まだ簡単ではないと感じます。ここがVAKRAの本丸のひとつでしょう。
これがいちばん複雑です。
記事では、644件のインスタンス、41ドメインとされています。
何が難しいのかというと、次の要素が全部乗っています。
APIだけでなく、文書インデックスも使う必要があります。
つまり、データベースを見るだけでは足りず、文章資料から探す場面もあるということです。
さらに、各 hop ごとに、使うべき情報源が決まっている場合があります。
たとえば、
のように、ソースが切り替わる。
これはかなり実務に近いです。人間の仕事でも、数字はDB、背景は資料、最終確認は別システム、みたいなことはよくあります。
会話が複数ターンにまたがる設定もあります。
つまり、単発の質問応答ではなく、会話の流れを踏まえて答える必要があります。
さらに厄介なのが、どのツールを使ってよいかというルールまであることです。
たとえば「Technology & Software に関する質問は、document retriever だけを使って答えなさい」といった制約が入ります。
これ、かなり重要だと思います。
現実の企業環境では、「便利だから全部使っていい」わけではなく、使っていい情報源が限定されることが多いからです。
セキュリティや監査、部門ルールの都合で、勝手に別のツールを叩けない場面は普通にあります。
だからVAKRAは、単なる知能テストというより、**“ルールのある現場で働けるか”の試験**に近いです。
VAKRAの面白いところは、評価がかなり丁寧なことです。
単に最終回答が正しければOK、ではありません。
まず、モデルが出したtool-call trajectory、つまり「どんな順番でどんなツールを呼んだか」を見ます。
しかも、そのツール呼び出しは実際に同じ環境で実行されます。
これは地味ですが、とても大事です。
なぜなら、エージェントは答えだけ合っても、中身の手順がぐちゃぐちゃでは仕事にならないからです。
予測されたツール列が、正解のツール列と同じかを見るわけですが、ここでも柔軟性があります。
VAKRAでは、別のAPI呼び出し方でも正しいなら認める設計になっています。
これも良い判断だと思います。
現実には「同じ答えにたどり着く道」は複数あるので、固定の手順だけを正解にしてしまうと評価が狭くなりすぎます。
中間結果の比較が難しい場合には、LLM-based evaluation を使います。
これは、構造が違っていても、必要な情報がちゃんと取れているかを判断するためです。
最後に、最終回答が
を見ます。
つまりVAKRAは、
「答えが合っているか」だけでなく、「正しい情報に、正しい道筋で、ちゃんと到達したか」
を見ようとしているわけです。
ここはかなり重要です。
AIエージェントの評価は、これからますますこういう方向に行くはずだと思います。なぜなら、単純な正解率だけでは、現場での信頼性を測れないからです。
VAKRAの記事を読んで感じるのは、AIエージェントの評価が、かなり**“現実の仕事への接近戦”**になってきたということです。
昔のベンチマークは、ある意味で「試験問題」でした。
でもVAKRAは違います。
ツールをどう使うか、途中でどこを参照するか、ルールを守れるかまで含めて見ています。
これはエージェント開発者にとっては厳しい話です。
でも、かなり健全でもあると思います。
なぜなら、現実に使えるAIは、派手なデモではなく、面倒な制約の中でもきちんと動くAIだからです。
個人的には、VAKRAのようなベンチマークが増えるほど、AIの評価は「会話のうまさ」から「業務遂行能力」へと重心が移っていくのではないかと思います。
そしてそれは、エージェント時代には自然な流れです。
VAKRAは、AIエージェントの
を総合的に測る、かなり本格的なベンチマークです。
しかも評価は、最終回答だけでなく、実際の実行トレースまで見る。
この点がとても重要で、私はかなり「本物感」のある設計だと感じました。
AIが本当に仕事をする時代には、こういうベンチマークが必要になるはずです。
VAKRAは、その方向性をかなりはっきり示している記事だと言えるでしょう。
参考: Inside VAKRA: Reasoning, Tool Use, and Failure Modes of Agents
