Anthropic Engineering: Praktischer Leitfaden und Methodik für die Bewertung (Evals) von AI Agents

Zusammenfassung:

• Mit bestehenden LLM-Benchmarks allein lässt sich die Leistung von „AI Agents“, die Tools nutzen und mehrstufiges Schlussfolgern ausführen, nur schwer präzise messen.
• Die Bewertung von Agents sollte ähnlich wie Softwaretests Unit Tests und Integration Tests kombinieren.
• Es ist effektiv, deterministische codebasierte Bewertung (Code-based) und modellbasierte Bewertung (Model-based) mit LLMs zu kombinieren.
• Entlang des Entwicklungslebenszyklus von Agents ist ein Wechsel von „Capability Evals“ zu „Regression Evals“ erforderlich.

Ausführliche Zusammenfassung:

1. Warum die Bewertung von AI Agents schwierig ist
   Im Gegensatz zu einfachen Chatbots (Single-turn) nutzen Agents Tools, verändern den Zustand ihrer Umgebung und führen Aufgaben über mehrere Schritte (Multi-turn) hinweg aus. Daher reicht es nicht aus, nur die endgültige Antwort zu prüfen; stattdessen muss ganzheitlich bewertet werden, ob der Agent die richtigen Tools verwendet hat, ob der Ablauf effizient war usw.

2. Struktur einer Agentenbewertung (Eval)
   Ein effektives Bewertungssystem besteht aus den folgenden Kernelementen.

• Task: Ein einzelner Testfall mit definiertem Input und Erfolgskriterien.
• Grader: Die Logik, die das Ausführungsergebnis des Agents bewertet.
• Transcript: Das vollständige Ausführungsprotokoll des Agents, einschließlich Denkprozess, Tool-Aufrufen und Zwischenergebnissen.
• Outcome: Der finale Zustand der nach der Agentenausführung veränderten Umgebung (z. B. ob tatsächlich eine Reservierung in der DB erstellt wurde).

3. Vergleich der Grader-Typen
   Anthropic empfiehlt, drei Arten von Gradern in Kombination zu verwenden.

Typ	Beschreibung	Vorteile	Nachteile
Code-based	String-Matching, reguläre Ausdrücke, statische Analyse, Ausführung von Unit Tests usw.	Schnell, günstig, objektiv, reproduzierbar	Kann komplexe Nuancen übersehen, geringe Flexibilität
Model-based	Einsatz eines LLM als Judge für rubric-basierte Bewertung	Flexibel, kann Nuancen erfassen, geeignet für offene Fragen	Kann nicht deterministisch sein, kostet Geld, benötigt menschliche Kalibrierung
Human	Experten-Review, Crowdsourcing	Goldstandard der Qualität	Sehr langsam und teuer

4. Beispiel für die Bewertung eines Coding Agents (YAML-Konfiguration)
   Bei der Bewertung eines Coding Agents wird nicht nur betrachtet, ob der Code läuft (deterministische Tests), sondern auch, ob es Probleme beim Coding-Stil oder Sicherheitsverstöße gibt (statische Analyse/LLM-Bewertung). Im Folgenden ein hypothetisches Beispiel für eine Bewertungskonfiguration für die Task „Sicherheitslücke beheben“.

task:  
  id: "fix-auth-bypass_1"  
  desc: "Fix der Authentifizierungs-Bypass-Sicherheitslücke, die auftritt, wenn das Passwortfeld leer ist"  
  graders:  
    # 1. Deterministischer Test: Prüfen, ob der echte Testcode besteht  
    - type: deterministic_tests  
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]  
    
    # 2. LLM-Rubric-Bewertung: Bewertung von Codequalität und Stil  
    - type: llm_rubric  
      rubric: prompts/code_quality.md  
    
    # 3. Statische Analyse: Linter und Sicherheitstools ausführen  
    - type: static_analysis  
      commands: [ruff, mypy, bandit]  
    
    # 4. Zustandsprüfung: Prüfen, ob Sicherheitslogs korrekt hinterlassen wurden  
    - type: state_check  
      expect:  
        security_logs: {event_type: "auth_blocked"}  
    
    # 5. Prüfung der Tool-Nutzung: Wurde die erforderliche Datei gelesen und bearbeitet?  
    - type: tool_calls  
      required:  
        - {tool: read_file, params: {path: "src/auth/*"}}  
        - {tool: edit_file}  
        - {tool: run_tests}  
  
  # Zu verfolgende Metriken  
  tracked_metrics:  
    - type: transcript  
      metrics:  
        - n_turns # Anzahl der Turns  
        - n_toolcalls # Anzahl der Tool-Aufrufe  
        - n_total_tokens # Token-Nutzung  
    - type: latency  
      metrics:  
        - time_to_first_token  

5. Bewertungsmetriken (Metrics)
   Um mit den nicht deterministischen Eigenschaften von Agents umzugehen, werden neben einfacher Genauigkeit folgende Metriken verwendet.

• pass@k: Wahrscheinlichkeit, bei k Versuchen mindestens einmal erfolgreich zu sein (misst Explorationsfähigkeit).
• pass^k: Wahrscheinlichkeit, dass bei k Versuchen alle Versuche erfolgreich sind (misst Konsistenz/Zuverlässigkeit).

6. Tools und Frameworks
   Für den Aufbau eines Bewertungssystems wird vorgeschlagen, Tools wie Harbor (Ausführung in Container-Umgebungen), Promptfoo (YAML-basierte Testkonfiguration), Braintrust, LangSmith usw. zu nutzen oder ein eigenes Framework passend zum Workflow des Teams aufzubauen. Entscheidend ist nicht das Framework selbst, sondern die Verfügbarkeit hochwertiger Testfälle.