Anthropicエンジニアリング: AIエージェント評価（Evals）の実践ガイドと方法論

要約:

• 既存のLLMベンチマークだけでは、ツール使用や多段階推論を行う「AIエージェント」の性能を正確に測定するのが難しい。
• エージェント評価はソフトウェアテストと同様に、単体テスト（Unit Tests）と統合テスト（Integration Tests）を組み合わせる必要がある。
• 決定論的なコード採点（Code-based）と、LLMを用いたモデルベース採点（Model-based）を混在させて使うのが効果的。
• エージェント開発ライフサイクルに合わせて、「能力評価（Capability Evals）」から「回帰テスト（Regression Evals）」へ移行する必要がある。

詳細要約:

1. AIエージェント評価が難しい理由
   単純なチャットボット（Single-turn）とは異なり、エージェントはツールを使い、環境の状態を変更し、複数段階（Multi-turn）にわたって作業を実行します。そのため、単に最終回答だけを確認するのでは不十分で、エージェントが正しいツールを使ったか、プロセスが効率的だったかなども含めて総合的に評価する必要があります。

2. エージェント評価（Eval）の構造
   効果的な評価システムは、次の中核要素で構成されます。

• タスク（Task）: 定義された入力と成功基準を持つ単一のテストケース。
• 採点者（Grader）: エージェントの実行結果をスコア化するロジック。
• トランスクリプト（Transcript）: エージェントの思考過程、ツール呼び出し、中間結果などを含む全実行記録。
• 結果（Outcome）: エージェント実行後に変更された環境の最終状態（例: 実際のDBに予約が作成されたか）。

3. 採点者（Grader）の種類比較
   Anthropicは、3種類の採点者を組み合わせて使うことを推奨しています。

種類	説明	長所	短所
コードベース（Code-based）	文字列一致、正規表現、静的解析、単体テスト実行など	高速、低コスト、客観的、再現可能	複雑なニュアンスを見落とす可能性がある、柔軟性に欠ける
モデルベース（Model-based）	LLMを審査員（Judge）として活用し、ルーブリックベースで採点	柔軟、ニュアンスを把握可能、自由形式の質問処理に適する	非決定論的になり得る、コストがかかる、人手による補正が必要
人間（Human）	専門家レビュー、クラウドソーシング	品質の「ゴールドスタンダード」	非常に遅く、高コスト

4. コーディングエージェント評価の例（YAML構成）
   コーディングエージェントを評価する際は、単にコードが実行できるか（決定論的テスト）だけでなく、コーディングスタイルやセキュリティ違反の有無（静的解析/LLM採点）も併せて確認します。以下は、「セキュリティ脆弱性の修正」タスクに対する仮想的な評価設定例です。

task:  
  id: "fix-auth-bypass_1"  
  desc: "비밀번호 필드가 비어있을 때 발생하는 인증 우회 취약점 수정"  
  graders:  
    # 1. 결정론적 테스트: 실제 테스트 코드가 통과하는지 확인  
    - type: deterministic_tests  
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]  
    
    # 2. LLM 루브릭 채점: 코드 품질 및 스타일 평가  
    - type: llm_rubric  
      rubric: prompts/code_quality.md  
    
    # 3. 정적 분석: 린터(Linter) 및 보안 도구 실행  
    - type: static_analysis  
      commands: [ruff, mypy, bandit]  
    
    # 4. 상태 확인: 보안 로그가 제대로 남았는지 확인  
    - type: state_check  
      expect:  
        security_logs: {event_type: "auth_blocked"}  
    
    # 5. 도구 사용 확인: 필요한 파일을 읽고 수정했는지  
    - type: tool_calls  
      required:  
        - {tool: read_file, params: {path: "src/auth/*"}}  
        - {tool: edit_file}  
        - {tool: run_tests}  
  
  # 추적할 메트릭  
  tracked_metrics:  
    - type: transcript  
      metrics:  
        - n_turns # 턴 수  
        - n_toolcalls # 도구 호출 횟수  
        - n_total_tokens # 토큰 사용량  
    - type: latency  
      metrics:  
        - time_to_first_token  

5. 評価指標（Metrics）
   エージェントの非決定論的な特性に対応するため、単純な正答率に加えて次のような指標を使います。

• pass@k: k回試行したとき、少なくとも1回以上成功する確率（探索能力の測定）。
• pass^k: k回試行したとき、すべての試行が成功する確率（一貫性/信頼性の測定）。

6. ツールとフレームワーク
   評価システム構築のために、Harbor（コンテナ環境実行）、Promptfoo（YAMLベースのテスト構成）、Braintrust、LangSmith などのツールを活用するか、チームのワークフローに合った独自フレームワークを構築することが提案されています。重要なのはフレームワーク自体ではなく、高品質なテストケースを確保することです。

[darjeeling]

内容が良かったので、韓国語訳を追加します。

https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents