Anthropic: AIエージェント用評価の仕組みを解明する

TL;DR

Anthropicは、反復的なデバッグループを防ぎ、開発を加速するための厳密なAIエージェント評価（"evals"）の構築ガイドを公開しました。核心的な教訓は、効果的なエージェント評価には決定論的、モデルベース、人間によるグレーディングの組み合わせが必要であり、能力評価とリグレッション評価の区別、そしてグレーディングが実際のパフォーマンスを測っているかを確認するためにトランザクションを読むことへのコミットメントが不可欠であるということです。

エージェント評価のアーキテクチャ

AIエージェントの評価は、単一のLLM応答の評価よりもはるかに複雑です。エージェントは複数のターンにわたって動作し、環境状態を変更し、静的なグレーディングロジックを回避する創造的な解決策を見つける可能性があるからです。

キー評価定義

一貫した評価システムを構築するため、Anthropicは以下のコンポーネントを定義しています。

  • タスク（問題／テストケース）： 入力と成功基準が明確に定義された単一のテスト。
  • トライアル： タスクに対する単一の試行。モデルの非決定論性を考慮するために複数回実行されます。
  • グレーダー： アサーションやチェックを通じてパフォーマンスをスコアリングするロジック。
  • トランザクション（トレース／トラジェクトリ）： ツール呼び出し、推論、API相互作用を含むトライアルの完全な記録。
  • アウトカム： 環境の最終状態（たとえば、データベースレコードが実際に作成されたかどうか）。
  • 評価ハarness： タスクを並列で実行し、ステップを記録し、結果を集約するインフラストラクチャ。
  • エージェントハarness（スキャフォールド）： モデルがエージェントとして動作できるようにするシステム（例：Claude Code）。
  • 評価スイート： 特定の能力や行動を測定するタスクの集合。

エージェントタイプ別の評価戦略

異なるエージェントアーキテクチャには、正確性と有用性を確保するためのカスタマイズされたグレーディング手法が必要です。

コーディングエージェント

コーディングエージェントは、決定論的グレーダーで最も適切に評価されます。ソフトウェアは二値の結果（動くか動かないか）を持つため、生成されたコードを安定した環境でユニットテストに実行するというのがゴールドスタンダードです。

  • ベンチマーク： SWE-bench Verified と Terminal-Bench が主な例として挙げられ、成功は既存のテストを壊さずに失敗テストを修正することとして定義されます。
  • ハイブリッドアプローチ： 結果は決定論的ですが、トランザクションはLLMルーブリックを使ってコード品質やツール使用効率を評価できます。

コンバーシェンスエージェント

コンバーシェンスエージェントには、対話の質とタスク完了の両方が重要であるため、多次元アプローチが必要です。

  • シミュレーション： これらの評価では、エージェントをストレステストするため、第二のLLMを使ってユーザーの役割をシミュレートすることが多いです。
  • グレーディング： 成功は、状態チェック（例：「チケットは解決されたか？」）、トランザクション制約（例：「10ターン以内に終了したか？」）、およびトーンや共感のためのLLMルーブリックを組み合わせて測定されます。

リサーチエージェント

リサーチエージェントは、開かれた出力を持つため、「正しさ」は文脈に依存します。

  • 検証： 評価は、根拠の有効性（出典に基づく主張）、カバレッジ（重要な事実の包含）、出典の質に焦点を当てます。
  • キャリブレーション： リサーチの質は主観的であるため、LLMベースのルーブリックは専門家の人間判断と頻繁にキャリブレーションする必要があります。

コンピュータ使用エージェント

これらのエージェントはAPIではなく、スクリーンショットとクリックを通じてGUIと対話します。

  • 環境： 評価には、OSやブラウザの最終状態を検査できるサンドボックス環境（例：WebArena や OSWorld）が必要です。
  • 効率性： 評価は、エージェントが適切なツール（例：DOM抽出 vs. スクリーンショット）を選択する能力を追跡し、遅延とトークンコストのバランスを取るべきです。

効果的なグレーダーの設計

Anthropicは、速度、コスト、ニュアンスのバランスを取るために、段階的なグレーディングアプローチを推奨しています。

グレーダータイプ 強み 弱み
コードベース 速い、客観的、再現可能、安価。 有効な変化に脆い；ニュアンスが欠ける。
モデルベース 非常に柔軟でスケーラブル。ニュアンスや開かれたタスクに対応可能。 非決定論的；人間によるキャリブレーションが必要。
人間 ゴールドスタンダード。専門家の判断と一致。 高コスト、遅い、スケーラブルではない。

能力評価 vs. リグレッション評価

  • 能力（品質）評価： エージェントの能力の限界を調べるためのもの。低い合格率から始め、"登るべき山"を提供する。
  • リグレッション評価： 既存の機能が壊れていないことを保証するためのもの。ほぼ100％の合格率を維持すべき。
  • ライフサイクル： 能力評価が高合格率に達すると、リグレッションスイートに「卒業」する。

非決定論性の扱い

エージェントの振る舞いは実行ごとに異なるため、単一の合格／不合格では不十分です。Anthropicは以下の2つの主要な指標を提案しています。

  1. pass@k： k 回の試行の中で少なくとも1回正解を出す確率。ツールのいずれかの成功が勝利となる場合に有用。
  2. pass^k： k 回すべての試行が成功する確率。顧客向けエージェントでは信頼性と一貫性が極めて重要であるため、これが不可欠です。

実装のロードマップ

フェーズ1：データセット収集

  • 小さなスタート： 実際の失敗から得られる20〜50のタスクから始めます。
  • 曖昧さの回避： 2人の専門家が同じ判断に達するようにします。エージェントが多数の試行で100％失敗（pass@100が0％）する場合、それはモデルの失敗ではなく、タスク仕様が壊れている可能性が高いです。
  • バランスの取れたセット： エージェントが行動すべきでない「ネガティブ」ケースを含め、過剰なトリガーを防ぎます。

フェーズ2：ハarnessとグレーダー設計

  • 隔離： 各トライアルがクリーンな環境から開始されるようにし、共有状態がスコアを不自然に高めるのを防ぎます。
  • 経路ではなくアウトカム： エージェントが取ったツール呼び出しの特定の順序ではなく、エージェントが生成した結果を評価することで、創造的だが正当な解決策を罰しないようにします。
  • 部分点： 複数の要素を持つタスクには、成功の連続性を反映するためのスコアリングを実装します。

フェーズ3：長期的なメンテナンス

  • トランザクションのレビュー： 定期的にトランザクションを読み、本物のエージェントのミスとグレーディングのバグを区別します。
  • 飽和のモニタリング： 評価が100％に達すると、改善を示す意味がなくなります。チームは進歩を測り続けるために、より難しい新しい評価を開発する必要があります。
  • 評価駆動開発： 機能を構築する前に、計画された能力のための評価タスクを定義し、エージェントが合格するまで反復します。

総合的なパフォーマンス理解

自動化された評価は第一の防衛線ですが、広範な戦略の一部でなければなりません：

  • プロダクションモニタリング： 実世界の分布のずれや予期しない障害を検出します。
  • A/Bテスト： 大規模に実際のユーザーの成果（リテンション、完了率）を検証します。
  • ユーザーからのフィードバック： 予期しない問題を明らかにし、現実世界の例を提供します。
  • マニュアルレビュー： 故障モードに対する直感を構築し、LLMグレーダーのキャリブレーションを行います。
  • 人間による研究： 主観的なタスクのゴールドスタンダードとなる参照を提供します。

Sources

関連