AgentJudgeBench、ツール呼び出しエージェントを評価するLLMの信頼性を検証

導入

エージェントの評価は、最終回答が自然に見えるかどうかだけでは決まらない。正しいツールを選べたか、引数を正しく渡したか、前段の結果に応じて依存関係を守ったか、途中で問題が起きた際に適切に処理したかまで確認する必要がある。現在は別の大規模言語モデルを評価者として使う方法が広がっているが、複雑な実行フローに対する信頼性は十分に検証されていなかった。

AgentJudgeBenchは、この問題を対象にしたベンチマークである。一般的な文章の好みや自由回答の評価とは区別し、有向非巡回グラフ（DAG）で表現される依存関係付きのツール呼び出しワークフローに焦点を当てている。

主なポイント

• 複数の軸で構成された評価。 3,808件のインスタンスを、6種類のDAGトポロジーと3段階の難度で構成している。実験では複数規模の5つの生成モデルと、異なる能力帯の6つの評価モデルを比較した。
• 難度が上がるほど一致率が低下。 プログラムによる基準結果との一致は、タスクが難しくなるにつれて単調に低下した。正解情報がない条件では、その低下が正解情報ありの場合のおよそ1.5倍速かった。
• モデル規模だけでは越えられない上限。 正解情報なしの難しいクエリでは、6種類の評価者が77〜82%の狭い範囲に集まった。評価モデルを大きくしても、この範囲を突破できない構造的な制約が示唆される。
• 正解情報が逆効果になる場合もある。 GPT-5.4では一致率が1.5ポイント、Gemini-2.5-Proでは3.9ポイント低下した。基準情報に過度に引きずられる「アンカリング」が一因として考えられている。
• 改善策の効果は限定的で不均一。 思考連鎖推論や評価者の温度設定はほとんど影響しなかった。一方、構造化された評価ルーブリックは最大6.5ポイント改善したが、すべての生成モデルと評価モデルの組み合わせに一般化したわけではない。

意義と影響

この結果は、「大きなモデルほど優れた評価者になる」という単純な前提に疑問を投げかける。ツール呼び出しエージェントの評価対象は最終出力だけではなく、ツール、引数、実行順序、依存関係、途中状態を含む軌跡全体だからだ。途中の小さな誤りが後続処理に波及する一方、最終回答だけを見た評価者は失敗箇所を特定できない可能性がある。

実運用では、ツール名や引数形式、依存関係の充足、各ステップの結果、最終状態を分けて採点し、プログラムによる検証とLLM評価を組み合わせる設計が有効だろう。正解情報も絶対的な答えではなく、独立した確認を補助する材料として扱う必要がある。

AgentJudgeBenchの重要性は、単一の最強評価モデルを決めたことではない。評価器そのものにも失敗条件があることを明確にした点にある。エージェントの性能を報告する際には、タスク難度、ワークフロー構造、正解情報の有無によって評価結果がどの程度安定するかも示す必要がある。

出典：Hugging Face Daily Papers