エージェントハーネスをエンジニアリングするチームは、エンドツーエンドのベンチマークを 振る舞い評価 で補完すべきだと論じる Google for Developers の記事である。振る舞い評価とは、エージェントがタスク全体を完了したかどうかではなく、エージェントが取る個々の観察可能なアクションに対するアサーションである。著者らはまず、ハーネスエンジニアリング に新しく取り組む開発者が繰り返し陥るという失敗から話を始める。Terminal-Bench や DeepSWE のようなベンチマークを実行し、総合スコアが数ポイント動くのを眺め、それがなぜ変わったのかまったくわからない、という失敗である。
著者らの立場は、エンドツーエンドのベンチマークが間違っているということではなく、それが反復のための道具としては適切でないということである。記事は振る舞い評価をハーネスの動作に対する統合テストとして説明し、プロジェクトのどの段階で評価を実行する価値が出てくるかを示し、アーキテクチャと具体的なアサーションの例を挙げ、最後に 2 種類の評価は代替ではなく補完的なものだと論じて締めくくる。
要点
- 著者らは、振る舞い評価はエンドツーエンドのベンチマークよりも確信の尺度として優れていることが多いと論じる。振る舞い評価は、期待される振る舞いが実際に起きているかどうか、ある変更が前進なのか退行なのかを示し、変更がなぜ針を動かしたのかについての洞察を与える反復のパートナーとして機能しうる。
- 著者らはこの対比を、成績表と振る舞いの道しるべの対比として捉えている。ほとんどのチームは、試験を受ける学生のようにエージェントを評価しており、スコアが下がったとき、エンドツーエンドのベンチマークは通常、モデルが曖昧なプロンプトに対して自信過剰になったのか、テストスイートの検証を忘れたのか、CLI フラグをハルシネーションしたのかに直接答えてくれない。
- 振る舞い評価は、最終的な文字列の一致ではなく、特定のツール呼び出しやファイルの変更といった中間的な実行ステップに対してアサーションを行う。著者らの具体例は、現在の天気について尋ねられたエージェントが、記憶から答えるのではなく Web 検索ツールを参照したことをアサートするものである。
- タイミングについて、著者らは評価は第 2 段階に属すると論じる。エージェントを立ち上げたばかりのチームは、開発者の直感とドッグフーディングから始めるものであり、エージェントが自身のコードベースをドッグフーディングできるようになるまでは、そもそも評価を実行する意味はないと著者らは述べる。
- 評価スイートの主な目的は、エージェントを 2% 改善したことを祝うことではなく、プロンプトの微調整、ツールスキーマの変更、モデルのアップグレードによってエージェントが全体として悪化していないという確信を与えることだと述べている。
- 推奨されるアーキテクチャは、振る舞いのアサーションを、ローカルで実行される高速で決定論的なユニットテスト風のチェックとして切り分けるものである。著者らの例では、ローカルの振る舞いスイートが 5 秒未満で実行される。
- 充実したスイートは自動化されたプロンプトエンジニアリングを可能にすると著者らは示唆する。LLM が失敗しているテストが通るまで自身のシステムプロンプトを調整し、スイートの残りの部分が、既存の機能を壊さないための CI/CD 的なガードレールとして機能するというものである。
- 著者らが示す 3 ステップの出発点となるループは次のとおりである。まず、エージェントが実際に犯したミスから失敗モードを 1 つ選ぶ。次に、タスクの複雑さに合わせたアサーションを書く。最適解が 1 つしかない単純なタスクには厳密なシングルターンのアサーションを、モデルが予想外だが正しい経路をとりうる複雑なタスクには LLM-as-a-Judge のような、より緩やかな結果ベースのチェックを用いる。そして、ノイズの多い単発の実行でプルリクエストをブロックするのではなく、バッチ評価を自動化し、集計した合格率を時系列で追跡する。
- 締めくくりの主張は、2 種類の評価は補完的だというものである。マクロなベンチマークは最終的な到達点を検証し、ミクロな振る舞い評価は安全で迅速な反復を可能にする。推奨は両方を採用することである。
背景
これは Google のエンジニアリングチームが自らの実践について述べたもので、Google 自身の開発者ブログに掲載されており、具体例は Google 自身の Antigravity SDK を対象に書かれている。振る舞い評価とエンドツーエンドのベンチマークの比較測定は報告されておらず、その主張は研究ではなく、モデルが進化する中でエージェントシステムの信頼性を保ってきたという著者らの経験に基づいている。
記事の枠組みは、エンジニアリングの主な対象はエージェントのモデルではなくその足場であるという、より広い議論の中に位置づけられる（ハーネスエンジニアリング を参照）。ハーネスを、ユニットテストと統合テストを必要とする標準的なソフトウェアとして扱うべきだという推奨は、この記事を 検証ループ や ガードレール に関する議論と結びつけている。