2つのAI審査員がエージェントの回答に0.85のスコアを付けたが、ファイルは一度も開かれていなかった

大規模言語モデル（LLM）を審査員として用いるLLM-as-Judgeが、エージェント評価のデフォルト手法となっている今、重要な問題が見過ごされています。審査員は最終回答だけを見て、エージェントがどのようにその回答に至ったかは見ていません。本記事は、具体的なケーススタディを通じて、この手法の根本的な欠陥を明らかにします。

あるケーススタディでは、特定のConfluenceページの内容に依存する質問がエージェントに与えられました。エージェントは、そのページが存在しないと主張し、それに基づいて回答しました。2つの最先端の審査員モデルが質問と回答を読み、どちらも0.85のスコアを付けました。しかし、実際の軌跡記録によると、エージェントはそのページを一度も取得しておらず、検索もしていませんでした。必要な検索を行わずに存在しないと断言し、その未検証の主張から推論を進めていました。実際の軌跡とアクセスポリシーに基づいて評価すると、回答のスコアは0.000でした。

このギャップは偶然ではありません。LLM-as-Judgeのプロンプトは、最終回答が正解と一致するかどうかだけをチェックするよう明示的に指示しており、背景や推論プロセスは無視します。単純な文字列一致には合理的ですが、現実世界で行動するエージェントにはまったく不十分です。エージェントは幸運な推測や虚偽の断言で正しい回答を得る可能性があり、審査員はそれを区別できません。

記事はさらに、3つの典型的な障害モードを分析しています。1つ目は「機械的に完璧だが状態無効」で、エージェントは正しくツールを呼び出しても、不可視の文書や過去の成果物を使用する可能性があります。2つ目は「欠落問題」で、エージェントは十分な検索なしに存在しないと主張します。3つ目は「因果関係の逆転」で、エージェントは実際の出来事を引用しながら因果関係を誤る可能性があります。これらの障害モードは、LLM-as-Judgeでもツール呼び出しチェックでも発見できません。

なぜこの問題が見えなかったのでしょうか？審査員モデルは質問と回答だけでは成果物がエージェントの可視範囲外かどうかを検証できません。アクセスポリシー、イベントログ、成果物タイムスタンプが必要ですが、ほとんどの評価設定はこれらを提供していません。これらの構造が提供されると、正しさのシグナルは審査員の妥当性評価ではなく、状態契約そのものになります。最終回答の正しさは不十分であり、正しさは証拠経路に基づいて評価されるべきです。

記事はまた「攻撃論法」を提唱しています。デプロイ後に構築される防御のほとんどは、事前に見つけられるべきテストギャップを補うものです。デプロイ前に具体的なアクセスポリシーに対して状態有効性テストを実行すれば、エージェントが境界を守れるかどうかが事前にわかります。

最終的に、記事はデプロイ前の状態有効性テストが、未知の弱点を多層防御でカバーするのではなく、既知の弱点を明確にして防御することを可能にすると強調します。契約を先に書き、承認は後で書くこと、これがエージェント評価の未来です。