エージェントの検証を再考：独立レビューがもたらす効果

はじめに

ツールを使う大規模言語モデルは、最初の回答だけで複雑な課題を終えるわけではありません。ファイルを調べ、コマンドを実行し、結果を観察し、計画を修正しながら作業を進めます。そのため、成果物を検証する仕組みは、最後に付け足す機能ではなく、エージェントシステムの中核となります。

論文「Rethinking Verification in Agent Harnesses」は、エージェントを動かすプロンプト、ツール、観察結果、制御フローの層をエージェント・ハーネスと捉え、検証をテスト時スケーリングの一つの軸として分析しました。焦点は、いつ介入するか、誰が確認するか、確認結果をどう修正につなげるかという3点です。

4つの検証レイヤー

研究は、エージェントのライフサイクルを次の4段階に分け、17種類の設計を比較しています。

• 初期指示：作業開始時点で、成果を自分で確認するよう求める。
• 実行中のリマインダー：ツール呼び出しの途中で、進捗や誤りを再確認させる。
• 完了ゲート：完了を宣言する前に、テストなどの条件を満たすよう要求する。
• 独立レビュー：別の批評役が成果物を確認し、実行役が指摘を受けて修正する。

評価には7つの先端コーディングモデルを用い、Terminal-BenchとSWE-bench Verifiedで比較しました。さらに、専門家が視覚的・インタラクティブな成果物を判定するVisualBenchも導入しています。コードのテストだけでは捉えにくい、最終的な見た目や操作性も評価対象にした点が特徴です。

独立レビューの費用対効果

初期指示と実行中のリマインダーは、平均的には控えめな改善にとどまり、効果はモデルによって異なりました。平均出力トークンを大幅に増やさない一方、複雑な作業で発生する見落としを安定して防ぐとは限りません。

完了ゲートはより大きな改善をもたらす可能性があります。しかし、テストの再実行や追加の修正を誘発すると、コストも増えやすくなります。

これに対して独立レビューは、精度とコストのバランスで有利でした。Terminal-Benchでは平均精度が5.9〜9.5ポイント向上し、コストはベースラインの約1.13〜1.25倍でした。SWE-bench Verifiedでは3.9〜6.6ポイント向上し、コストは約1.00〜1.04倍です。VisualBenchでも、4種類の独立レビュー設計すべてがベースラインを上回る正のネット選好を示し、その幅は13.2〜23.8ポイントでした。

さらに、レビュー回数や批評役の数を増やすと、1回のレビューに比べてTerminal-Benchの平均精度が最大3.5ポイント追加で向上しました。レビューは有無だけでなく、深さや冗長性を調整できるテスト時スケーリングの手段だと考えられます。

エージェント開発への示唆

この研究が示すのは、検証を単なる追加プロンプトとして扱うべきではないということです。開発者は、介入のタイミング、検証者の独立性、フィードバックを修正へ変換する方法、追加計算の許容範囲を設計する必要があります。

高価値なコーディング作業では、同じエージェントにリマインダーを重ねるより、独立した批評役を導入する方が現実的な改善策になる可能性があります。一方、コストに制約がある場合は、不確実性やリスクの高い出力だけを複数回レビューする設計が考えられます。

今後の評価では、基盤モデルだけでなくハーネスの設計も独立した比較対象にすべきです。モデルが能力の上限を決めるとしても、検証アーキテクチャが、その上限にどれだけ安定して到達できるかを左右するからです。

出典：Hugging Face Daily Papers