Anthropic Engineering: Praktischer Leitfaden und Methodik für die Bewertung (Evals) von AI Agents
(anthropic.com)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:
-
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. -
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).
- 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 |
- 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
- 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).
- 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.
1 Kommentare
Der Inhalt ist gut, daher füge ich eine koreanische Übersetzung hinzu.
https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents