エージェントシステムの評価手法
エージェントシステムは、動的な意思決定を行い、実行間で非決定的であり、単一の正解を欠くことが多いため、従来のソフトウェアとは異なる方法で評価します。これらの特性を考慮し、実用的なフィードバックを提供し、回帰を見つけ、コンテキストエンジニアリングの選択が意図した効果を達成していることを検証する評価フレームワークを構築します。
アクティベートすべきタイミング
以下の場合にこのスキルをアクティベートします：
- エージェントのパフォーマンスを体系的にテストする場合
- コンテキストエンジニアリングの選択を検証する場合
- 経時的な改善を測定する場合
- デプロイ前に回帰を検出する場合
- エージェントパイプラインの品質ゲートを構築する場合
- 異なるエージェント設定を比較する場合
- 本番システムを継続的に評価する場合
隣接する作業は他のスキルが担当するため、このスキルはアクティベートしないでください：
- LLMジャッジ自体の設計、ペアワイズ比較、ジャッジのキャリブレーション、バイアス軽減：
advanced-evaluation。 - 自律制御サーフェス、新規性ゲート、ロールバック、PR承認境界の設計：
harness-engineering。 - 測定前の特定のコンテキスト障害モードのデバッグ：
context-degradation。
コアコンセプト
エージェントは目標への有効な代替ルートを見つける可能性があるため、実行パスではなくアウトカムに焦点を当てて評価します。エージェントが特定の一連のステップに従ったかどうかではなく、適切なプロセスを通じて正しいアウトカムを達成したかどうかを判断します。
単一のスコアでは特定の次元における重大な障害が隠れてしまうため、単一スコアではなく多次元ルーブリックを使用します。事実の正確性、完全性、引用の正確性、ソースの品質、ツール効率を個別の次元として捉え、ユースケースに応じて重み付けします。
モデルによる評価は、決定論的チェックとルーブリックが安定した後にのみ使用します。作業の中心がジャッジプロンプト、ペアワイズ比較、キャリブレーション、バイアス軽減にある場合は、高度な評価に切り替えます。
成果物に機械でチェック可能な構造がある場合は、LLMによる判断の前に決定論的バリデーションを実行します。スキーマの妥当性、重複キー、ルーブリックの計算、マニフェストの同期、検索ステータス、必要なエビデンスパスは、評価者がトークンを消費したり主観的なスコアを返したりする前に、迅速に失敗する必要があります。
パフォーマンスドライバー
評価予算を設計する際には、ブラウジングエージェントの研究を適用します。トークン使用量、ツール呼び出し、モデルの選択が測定されるパフォーマンスのばらつきを支配する可能性があります（claim-evaluation-browsecomp-variance）。
| 要因 | 説明される分散 | 含意 |
|---|---|---|
| トークン使用量 | 主要なドライバー | コストまたはコンテキスト品質が崩壊するまで、より多くの探索がパフォーマンスを向上させる可能性がある |
| ツール呼び出し数 | 二次的なドライバー | ツールの使用が有効なエビデンスを取得する場合にのみ役立つ |
| モデルの選択 | 二次的だが乗算的 | 優れたモデルは、多くの場合トークンとツールをより効率的に使用する |
評価を設計する際には、これらの含意に基づいて行動します：
- 現実的なトークン予算を設定する：無制限のリソースではなく、本番環境に即したトークン制限でエージェントを評価します。
- モデルアップグレードとトークン増加を比較する：優れたモデルは、より大きな予算を持つ弱いモデルよりもトークンを効率的に使用する可能性があります。
- マルチエージェントアーキテクチャを検証する：追加のエージェントはトークンとツール呼び出しを追加します。シングルエージェントのベースラインと比較して評価します。
詳細トピック
評価の課題
非決定性と複数の有効パスへの対処
エージェントは目標に到達するためにまったく異なる有効なパスを取る可能性があるため、パスのばらつきを許容する評価を設計します。あるエージェントは3つのソースを検索する一方で、別のエージェントは10個を検索するかもしれません。どちらも正しい答えを生成する可能性があります。特定のステップをチェックすることは避けます。代わりに、アウトカム基準（正確性、完全性、品質）を定義し、それらに対してスコアを付け、実行パスは評価的ではなく情報として扱います。
コンテキスト依存の障害をテストする
エージェントの障害は、微妙な方法でコンテキストに依存することが多いため、複雑さのレベルと対話の長さにわたって評価します。エージェントは単純なクエリでは成功しても複雑なクエリでは失敗したり、あるツールセットではうまく機能しても別のツールセットでは機能しなかったり、コンテキストが蓄積されるにつれて拡張された対話の後にパフォーマンスが低下したりする可能性があります。これらのパターンを明らかにするために、単純、中程度、複雑、非常に複雑なテストケースを含めます。
複合品質次元を個別にスコアリングする
エージェントの品質を個別の次元（事実の正確性、完全性、首尾一貫性、ツール効率、プロセス品質）に分解し、各次元を独立してスコアリングします。なぜなら、エージェントは正確性では高スコアでも効率性では低スコアになる可能性があるからです。次に、ユースケースの優先順位に合わせて調整された加重平均を計算します。このアプローチにより、信号を平均化して見えなくするのではなく、どの次元を改善する必要があるかが明らかになります。
評価ルーブリックの設計
多次元ルーブリックの構築
主要な次元をカバーし、優れているから失敗までの記述レベルのルーブリックを定義します。以下のコア次元を含め、ユースケースごとに重みを調整します：
- 事実の正確性：クレームがグラウンドトゥルースと一致する（知識タスクでは重く重み付け）
- 完全性：出力が要求された側面をカバーする（研究タスクでは重く重み付け）
- 引用の正確性：引用が主張されたソースと一致する（信頼が重要なコンテキストでは重み付け）
- ソースの品質：適切な一次ソースを使用する（権威ある出力には重み付け）
- ツール効率：適切なツールを妥当な回数使用する（コスト重視のシステムでは重み付け）
ルーブリックを数値スコアに変換する
次元の評価を数値スコア（0.0～1.0）にマッピングし、次元ごとの重みを適用し、加重全体スコアを計算します。ユースケースの要件に基づいて合格しきい値を設定します（通常は一般用途で0.7、ハイステークスアプリケーションで0.9）。個々の次元スコアを集約スコアとともに保存します。内訳がターゲットを絞った改善を促進するためです。
評価方法論
LLM-as-Judgeを大規模に使用する
LLMベースの評価プロンプトを構築します。これには以下を含めます：明確なタスクの説明、テスト対象のエージェント出力、利用可能な場合はグラウンドトゥルース、明示的なレベル説明を含む評価尺度、および推論を含む構造化された判断の要求。LLMジャッジは、大規模なテストセットに対して一貫性のあるスケーラブルな評価を提供します。自己強化バイアスを回避するために、評価対象のエージェントとは異なるモデルファミリーを使用します。
人間による評価で補完する
エッジケース、異常なクエリ、および本番トラフィックのランダムサンプルを人間のレビューアにルーティングします。人間は、自動評価が見逃す幻覚的な回答、システム障害、微妙なバイアスに気付くためです。人間のレビュー全体のパターンを追跡して体系的な問題を特定し、そのフィードバックを自動評価基準にフィードバックします。
ステートフルエージェントのための最終状態評価を適用する
永続的な状態（ファイル、データベース、設定）を変更するエージェントの場合、エージェントがどのようにそこに到達したかではなく、最終状態が期待と一致するかどうかを評価します。期待される最終状態アサーションを定義し、各テスト実行後にプログラムで検証します。
テストセットの設計
代表的なサンプルを選択する
初期開発時は、変更が劇的な影響を及ぼし、すぐに改善できる点が多いため、小さなサンプル（20～30ケース）から始めます。システムが成熟するにつれて、信頼性の高い信号を得るために50ケース以上に拡大します。実際の使用パターンからサンプリングし、既知のエッジケースを追加し、複雑さのレベル全体にわたるカバレッジを確保します。
複雑さで層別化する
簡単な例がスコアを不当に引き上げないように、複雑さのレベル全体にテストセットを構成します：
- 単純：単一のツール呼び出し、事実の検索
- 中程度：複数のツール呼び出し、比較ロジック
- 複雑：多数のツール呼び出し、かなりのあいまいさ
- 非常に複雑：拡張された対話、深い推論、合成
全体的なスコアとともに層ごとのスコアを報告し、エージェントが実際にどこで苦戦しているかを明らかにします。
コンテキストエンジニアリングの評価
コンテキスト戦略を体系的に検証する
同じテストセット上で異なるコンテキスト戦略を持つエージェントを実行し、品質スコア、トークン使用量、効率メトリクスを比較します。これにより、コンテキストエンジニアリングの影響を他の変数から分離し、逸話に基づく決定を防ぎます。
劣化テストを実行する
異なるコンテキストサイズでエージェントを実行することにより、コンテキストの劣化がパフォーマンスにどのように影響するかをテストします。コンテキストが問題になるパフォーマンスの崖を特定し、安全な動作限界を確立します。これらの限界をコンテキスト管理戦略にフィードバックします。
継続的評価
自動評価パイプラインを構築する
エージェントの変更時に評価が自動的に実行されるように、評価を開発ワークフローに統合します。結果を経時的に追跡し、バージョンを比較し、主要なメトリクスで後退するデプロイメントをブロックします。
本番品質を監視する
本番インタラクションをサンプリングし、継続的に評価します。品質が警告（合格率0.85）およびクリティカル（合格率0.70）のしきい値を下回った場合にアラートを設定します。時間枠にわたるトレンド分析を示すダッシュボードを維持し、緩やかな劣化を検出します。
実践的なガイダンス
評価フレームワークの構築
以下の順序に従って評価フレームワークを構築します。初期のステップをスキップすると、実際の品質を反映しない測定値になります。
- 評価コードを書く前に、ユースケースに関連する品質次元を定義します。後で選択される次元は、重要なものではなく、測定しやすいものを反映する傾向があるためです。
- 評価者（人間またはLLM）が一貫したスコアを生成できるように、明確で説明的なレベル定義を持つルーブリックを作成します。
- 実際の使用パターンとエッジケースからテストセットを構築し、複雑さで層別化し、信頼性の高い信号を得るために少なくとも50ケースを含めます。
- すべての重要な変更時に実行される自動評価パイプラインを実装します。
- 変更を行う前にベースラインメトリクスを確立し、既知のリファレンスに対して改善を測定できるようにします。
- すべての重要な変更に対して評価を実行し、ベースラインと比較します。
- 経時的なメトリクスをトレンド分析のために追跡します。緩やかな劣化は急激な低下よりも気付きにくいためです。
- 自動評価を定期的な人間によるレビューで補完します。
- 決定論的バリデーションの失敗と品質判断を分離し、無効な成果物が有利なLLMスコアによって不正に通過できないようにします。
評価の落とし穴を回避する
評価の信頼性を損なう一般的な失敗から保護します：
- 特定のパスへのオーバーフィッティング：特定のステップではなくアウトカムを評価します。エージェントは新しい有効なパスを見つけるためです。
- エッジケースの無視：複雑さの全スペクトラムをカバーする多様なテストシナリオを含めます。
- 単一メトリクスへの固執：単一のスコアは次元固有の障害を隠すため、多次元ルーブリックを使用します。
- コンテキスト効果の軽視：クリーンルーム条件ではなく、現実的なコンテキストサイズと履歴でテストします。
- 人間による評価のスキップ：自動評価は、人間が確実にキャッチする微妙な問題を見逃します。
例
例1：単純な評価
def evaluate_agent_response(response, expected):
rubric = load_rubric()
scores = {}
for dimension, config in rubric.items():
scores[dimension] = assess_dimension(response, expected, dimension)
overall = weighted_average(scores, config["weights"])
return {"passed": overall >= 0.7, "scores": scores}
例2：テストセットの構造
包括的な評価を確実にするために、テストセットは複数の複雑さレベルにまたがる必要があります：
test_set = [
{
"name": "simple_lookup",
"input": "What is the capital of France?",
"expected": {"type": "fact", "answer": "Paris"},
"complexity": "simple",
"description": "Single tool call, factual lookup"
},
{
"name": "medium_query",
"input": "Compare the revenue of Apple and Microsoft last quarter",
"complexity": "medium",
"description": "Multiple tool calls, comparison logic"
},
{
"name": "multi_step_reasoning",
"input": "Analyze sales data from Q1-Q4 and create a summary report with trends",
"complexity": "complex",
"description": "Many tool calls, aggregation, analysis"
},
{
"name": "research_synthesis",
"input": "Research emerging AI technologies, evaluate their potential impact, and recommend adoption strategy",
"complexity": "very_complex",
"description": "Extended interaction, deep reasoning, synthesis"
}
]
例3：モデル判断前の決定論的ゲート
def evaluate_pr_candidate(candidate):
structure = run_validate_repo(candidate)
if not structure.ok:
return {"passed": False, "reason": "deterministic validation failed", "details": structure.errors}
quality = run_rubric_eval(candidate)
return {"passed": quality.overall >= 0.8, "scores": quality.dimensions}
例4：品質ゲートの次元
gate:
deterministic:
- schema_valid
- required_files_present
- no_duplicate_ids
quality:
factual_accuracy: min 0.85
completeness: min 0.80
source_traceability: min 0.90
ガイドライン
- 単一メトリクスではなく、多次元ルーブリックを使用する
- 特定の実行パスではなく、アウトカムを評価する
- 単純から複雑までの複雑さレベルをカバーする
- 現実的なコンテキストサイズと履歴でテストする
- リリース前だけでなく、継続的に評価を実行する
- LLM評価を人間によるレビューで補完する
- トレンド検出のために経時的にメトリクスを追跡する
- ユースケースに基づいて明確な合格/不合格のしきい値を設定する
注意点
- 特定のコードパスへの評価のオーバーフィッティング：テストは合格するが、エージェントはわずかな入力のバリエーションで失敗します。表面上のパターンではなく、アウトカムとセマンティクスに対して評価基準を記述し、定期的にテスト入力をローテーションします。
- LLMジャッジの自己強化バイアス：モデルは独立したジャッジよりも自身の出力を高く評価します。評価対象のモデルとは異なるモデルファミリーを評価ジャッジとして使用します。
- テストセットの汚染：評価例がトレーニングデータやプロンプトテンプレートに漏れ込み、スコアを水増しします。評価セットをバージョン管理し、プロンプトやファインチューニングで使用されるデータから分離して保持します。
- メトリクスのゲーミング：測定されているメトリクスの最適化は、実際の品質を向上させずに行われる可能性があります。これに対抗するために、評価基準の定期的な監査とローテーションを実施します。
[truncated for translation]