EarlyEval、途中経過からエージェント評価を早期終了

導入

LLMエージェントの評価は、最終回答だけを採点する作業ではない。コード修正、ターミナル操作、複数ツールの利用を行うエージェントでは、推論、行動、観察、修正という長いループを最後まで実行して初めて結果が確定することが多い。そのため、フロンティアモデルでエージェント用ベンチマークを一度実行するだけでも、数百ドルから数千ドルに達する場合がある。開発サイクルごとに同じ評価を繰り返せば、負担はさらに大きくなる。

これまでのコスト削減策は、ベンチマーク蒸留などによってタスク数を減らすことが中心だった。EarlyEvalは別の場所に注目する。1つのタスクについて、結果がほぼ見えているにもかかわらず、残りのステップを実行し続ける必要があるのか、という発想である。

手法の概要

EarlyEvalの前提は、最終結果に関する手がかりが実行途中の軌跡に現れるというものだ。たとえば、ツール呼び出しの不整合、参照解からの明確な逸脱、実装後の検証に進む一貫した流れなどは、成功または失敗の兆候になり得る。

システムは各ステップで、エージェントの行動、生成テキスト、参照解に関係する特徴を収集する。そして、成功を予測する分類器と失敗を予測する分類器という、2つの軽量なLightGBMモデルを学習する。信頼度を校正したうえで、どちらか一方の予測が設定した閾値を超えると、そのタスクの実行を停止する。分類器の追加負荷を小さく抑え、不要なモデル呼び出しを省く設計だ。

実験結果と注意点

評価対象はSWE-bench Verified、TerminalBench、Toolathlonの3つである。EarlyEvalはエージェントの実行ステップを13%—26%削減し、条件によっては入力トークンを最大44.1%、出力トークンを最大29.4%削減した。予測精度は89%—97%で、エージェントごとのresolve rateの変化は平均で約1—2ポイントにとどまった。

ただし、早期停止には誤判定のリスクがある。成功するはずのタスクを失敗と判断すれば、結果を過小評価する可能性がある。反対に、失敗を成功と予測して早く止めれば、実際の挙動を十分に観察できない。閾値の設定や、別のモデル・タスク・ツール構成への適応性も重要になる。

意義

EarlyEvalは、評価タスクそのものを削除する方法を補完する。結果が明確になったタスクだけを短縮し、不確実なタスクには完全な実行予算を残すことで、評価資源を動的に配分できる。特に、エージェントを頻繁に改良し、回帰テストを繰り返す開発現場では、タスクごとの小さな節約が累積する。

この研究の意義は、エージェント評価を固定長の実行ではなく、軌跡に応じて計算量を調整する問題として捉えた点にある。もっとも、EarlyEvalは完全実行の代替ではなく、予測器の校正と結果への影響監視が前提となる。軽量な評価高速化手法として、今後の実運用で検証される余地がある。

出典：Hugging Face Daily Papers