Ingénierie chez Anthropic : guide pratique et méthodologie pour l’évaluation (evals) des agents IA

Résumé :

• Les benchmarks LLM existants ne suffisent pas, à eux seuls, à mesurer précisément les performances des « agents IA » capables d’utiliser des outils et d’effectuer un raisonnement en plusieurs étapes.
• L’évaluation des agents doit combiner des tests unitaires (Unit Tests) et des tests d’intégration (Integration Tests), à l’image des tests logiciels.
• Il est efficace d’utiliser un mélange de notation déterministe par code (code-based) et de notation fondée sur le modèle (model-based) via un LLM.
• Il faut passer des « Capability Evals » aux « Regression Evals » en fonction du cycle de vie du développement de l’agent.

Résumé détaillé :

1. Pourquoi l’évaluation des agents IA est difficile
   Contrairement à un simple chatbot (single-turn), un agent utilise des outils, modifie l’état de l’environnement et accomplit une tâche sur plusieurs étapes (multi-turn). Il ne suffit donc pas de vérifier uniquement la réponse finale ; il faut aussi évaluer globalement si l’agent a utilisé les bons outils, si le processus a été efficace, etc.

2. Structure d’une évaluation d’agent (Eval)
   Un système d’évaluation efficace se compose des éléments clés suivants.

• Tâche (Task) : un cas de test unique avec des entrées définies et des critères de réussite.
• Correcteur (Grader) : la logique qui attribue un score au résultat de l’exécution de l’agent.
• Transcript (Transcript) : l’historique complet de l’exécution, incluant le raisonnement de l’agent, les appels d’outils et les résultats intermédiaires.
• Résultat (Outcome) : l’état final modifié de l’environnement après l’exécution de l’agent (par ex. : une réservation a-t-elle réellement été créée dans la base de données ?).

3. Comparaison des types de correcteurs (Graders)
   Anthropic recommande de combiner trois types de correcteurs.

Type	Description	Avantages	Inconvénients
Basé sur le code (Code-based)	Correspondance de chaînes, expressions régulières, analyse statique, exécution de tests unitaires, etc.	Rapide, peu coûteux, objectif, reproductible	Peut manquer des nuances complexes, manque de flexibilité
Basé sur le modèle (Model-based)	Utilise un LLM comme juge pour une notation fondée sur une grille d’évaluation	Flexible, capable de saisir les nuances, adapté aux questions ouvertes	Peut être non déterministe, coûteux, nécessite un calibrage humain
Humain (Human)	Revue par des experts, crowdsourcing	« Gold standard » de la qualité	Très lent et très coûteux

4. Exemple d’évaluation d’un agent de codage (configuration YAML)
   Lorsqu’on évalue un agent de codage, il ne faut pas seulement vérifier si le code s’exécute (tests déterministes), mais aussi examiner le style de code ou d’éventuelles violations de sécurité (analyse statique / notation LLM). Voici un exemple fictif de configuration d’évaluation pour une tâche de « correction d’une vulnérabilité de sécurité ».

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 # nombre de tours  
        - n_toolcalls # nombre d’appels d’outils  
        - n_total_tokens # volume de tokens utilisé  
    - type: latency  
      metrics:  
        - time_to_first_token  

5. Indicateurs d’évaluation (Metrics)
   Pour tenir compte du caractère non déterministe des agents, on utilise, en plus de la simple précision, les indicateurs suivants.

• pass@k : probabilité de réussir au moins une fois en k tentatives (mesure de la capacité d’exploration).
• pass^k : probabilité que toutes les tentatives réussissent en k essais (mesure de la cohérence / fiabilité).

6. Outils et frameworks
   Pour construire un système d’évaluation, il est proposé d’utiliser des outils comme Harbor (exécution en environnement conteneurisé), Promptfoo (configuration de tests basée sur YAML), Braintrust, LangSmith, ou de créer un framework interne adapté au workflow de l’équipe. L’important n’est pas le framework en lui-même, mais la disponibilité de cas de test de haute qualité.