Hauptbereich
Agency
KI-Konzepte Evaluation Agenten

Agent-Evaluation — Task-Success-Rate, Eval-Harness, Benchmarks

Martin Rau ·

Warum Agent-Evaluation ein eigenes Fach ist

Ein Agent tut mehr als Text erzeugen — er ruft Tools auf, hält über mehrere Schritte einen Zustand, reagiert auf Fehler und trifft unterwegs Entscheidungen, die niemand vorab festgelegt hat. Damit reicht die klassische Modell-Frage „Ist die Antwort gut?” nicht mehr. Die Frage lautet jetzt: Hat das System die Aufgabe am Ende erledigt, und zwar auf einem Weg, dem man vertrauen kann? Agent-Evaluation ist die Antwort darauf — eine eigene Methodik, die nicht das Sprachmodell isoliert testet, sondern das gesamte Zusammenspiel aus Modell, Tools, Prompt und Fehlerbehandlung.

Der Eval-Harness — die Testinfrastruktur dahinter

Ein Eval-Harness ist die Infrastruktur, die Agent-Bewertungen von Anfang bis Ende durchführt — kein einfacher Unit-Test, sondern ein System für nicht-deterministische Ausgaben. Zwei Bausteine machen ihn aus:

  1. Datensatz — eine Sammlung von Testfällen („Goldens”) mit Aufgabe, Kontext und erwartetem Ergebnis oder erwarteter Eigenschaft.
  2. Metrik-Suite — deterministische Checks (Regex, Tool-Aufruf-Zähler, Schema-Validierung) plus LLM-basierte Bewertungen für alles, was sich nicht hart prüfen lässt.

Der Ablauf: Der Harness schleust jeden Fall durch den Agenten, sammelt Antwort und Ausführungs-Trace (welche Tools wann mit welchen Argumenten liefen), wendet die Metrik-Suite darauf an und persistiert die Scores. Der entscheidende Unterschied zu Software-Tests: Ein Unit-Test prüft grün/rot bei deterministischem Code. Ein Eval-Harness beantwortet Fragen wie „War der Tool-Aufruf gerechtfertigt?” oder „Hat der Agent an der richtigen Stelle nachgefragt?” — Fragen, die weder Linter noch Hooks abdecken.

Task-Success-Rate und Trajectory-Accuracy

Die naheliegendste Metrik ist die Task-Success-Rate: Anteil der Aufgaben, die der Agent zu einem korrekten Endergebnis gebracht hat. Sie allein trügt aber leicht — τ-bench (Sierra, 2024) zeigte, dass selbst GPT-4-gestützte Agenten in weniger als der Hälfte aller Fälle erfolgreich waren, und bei achtfacher Wiederholung derselben Aufgabe nur rund ein Viertel konsistent zum gleichen Ergebnis kamen. Daraus stammt die Unterscheidung zwischen pass¹ (Erfolg in einem einzelnen Lauf) und pass^k (Erfolg in allen von k unabhängigen Wiederholungen) — Letzteres misst Verlässlichkeit, nicht nur Können.

Zusätzlich zählt die Trajectory-Accuracy: War der Weg zum Ergebnis nachvollziehbar und angemessen, oder hat der Agent per Zufall über einen riskanten, ineffizienten oder unsicheren Umweg das richtige Ergebnis erreicht? Ein Agent, der eine Rückerstattung ohne Berechtigungsprüfung auslöst und zufällig den richtigen Betrag trifft, hat eine korrekte Task-Success-Rate — und ein handfestes Sicherheitsproblem. Deshalb bewerten reife Harnesse den kompletten Trace, nicht nur die letzte Nachricht.

Die wichtigsten Agent-Benchmarks

| Benchmark | Misst | Domäne | |---|---|---| | GAIA | 466 Aufgaben mit mehrstufigem Web-Browsing, Datei-Analyse und Tool-Nutzung, von Menschen gegen Referenzantworten geprüft | Allgemeiner Assistent | | τ-bench | Multi-Turn-Interaktion zwischen Agent, simuliertem Nutzer und Tools/Datenbank, inkl. pass^k-Konsistenz | Airline- und Retail-Kundenservice | | SWE-bench Verified | Ob ein Agent aus einem echten GitHub-Issue einen Diff erzeugt, der die Tests grün macht | Coding-Agent | | HAL (Holistic Agent Leaderboard) | Vereinheitlichter, kostenbewusster Dritt-Leaderboard über neun bis elf Einzelbenchmarks (u. a. SWE-bench Verified, GAIA, τ-bench Airline, AgentHarm), inkl. Pareto-Sicht auf Genauigkeit vs. Kosten | Übergreifend |

HAL, ein Princeton-Projekt, ist deshalb bemerkenswert, weil es genau das Eval-Harness-Prinzip auf Leaderboard-Ebene hebt: ein einheitlicher, reproduzierbarer Harness statt Dutzender inkompatibler Einzel-Setups mit unterschiedlichen Kostenannahmen.

LLM-as-a-Judge bei Agenten

Bei Agenten reicht ein Judge, der nur die Endantwort liest, nicht aus — er muss den Trace verstehen. Praxis unterscheidet zwei Judge-Typen: einen Outcome-Judge, der nur bewertet, ob das Endergebnis stimmt, und einen Trajectory-Judge, der den ganzen Ablauf liest und unnötige, riskante oder falsch-sequenzierte Tool-Aufrufe erkennt. Die bekannten Bias-Klassen aus der reinen LLM-Bewertung — Position-, Verbosity- und Self-Preference-Bias (Details dazu in LLM-Qualität messen) — gelten hier unvermindert, kommen bei langen Traces aber zusätzlich mit Kontext-Länge und „Quiet Drift” ins Spiel, wenn sich das Judge-Modell selbst über die Zeit ändert.

Offline- vs. Online-Evaluation

Offline-Evaluation läuft gegen einen festen Datensatz, meist als CI-Job vor dem Deployment — reproduzierbar, günstig wiederholbar, aber blind für das, was echte Nutzer tatsächlich verlangen. Online-Evaluation bewertet Agenten an echten oder nahezu echten Live-Interaktionen, oft per Agent-as-a-Judge zur Laufzeit. Eine 2026er Studie zu interaktiven Agenten fand für Online-Judging eine durchschnittliche Kriterien-Abdeckung von 0,92 gegenüber 0,56 bei klassischem Offline-Judging — Online-Verfahren erfassen mehr von dem, was in der Praxis zählt, kosten aber mehr und wirken erst, nachdem die Interaktion bereits stattgefunden hat. In der Praxis ergänzen sich beide: Offline-Evals als Regressions-Gate im CI, Online-Evals als Monitoring für Drift, den kein fixer Datensatz vorhersehen konnte.

Abgrenzung zur reinen Modell-Qualität

LLM-Qualität messen bewertet das Sprachmodell isoliert — Faktentreue, Reasoning, Stil, gemessen über Evals und Public Benchmarks. Agent-Evaluation bewertet das gesamte System: Tool-Auswahl, Fehlerbehandlung bei API-Timeouts, Zustandsführung über viele Turns, Kosten pro erledigter Aufgabe und Sicherheits-Constraints. Beides korreliert nur locker. Ein Agent mit einem Spitzenmodell scheitert trotzdem an schlechtem Tool-Design, fehlendem Retry-Verhalten oder einem zu knappen Tool-Set — und umgekehrt liefert ein günstigeres Modell mit sauberem Harness und engen Tool-Grenzen oft eine solidere Task-Success-Rate als ein teureres Modell ohne Agenten-Feinschliff. Modell-Benchmark-Werte wie MMLU oder Arena-Elo sagen deshalb wenig über Agent-Performance aus — genau deshalb existieren GAIA, τ-bench und HAL als eigene Messlatte.

FAQ

FAQ

Reicht ein gutes Modell-Benchmark-Ergebnis, um einen Agenten zu bewerten?
Nein. Modell-Benchmarks wie MMLU messen das isolierte Sprachmodell. Ob der Agent daraus eine funktionierende Toolkette baut, misst nur ein eigener Agent-Eval mit echten Tool-Aufrufen.
Was bedeutet Trajectory-Accuracy genau?
Ob der Weg zum Ergebnis nachvollziehbar und angemessen war — richtige Tool-Reihenfolge, keine unnötigen oder riskanten Zwischenschritte — statt nur zu prüfen, ob die Endantwort stimmt.
Warum reicht Offline-Evaluation allein nicht?
Ein fester Datensatz kann nicht jede reale Nutzeranfrage vorwegnehmen. Online-Evaluation deckt laut Studien deutlich mehr der tatsächlich relevanten Kriterien ab, ist aber teurer und wirkt erst nach der Interaktion.
Mit welchem Benchmark fängt man am besten an?
Für den eigenen Anwendungsfall zunächst ein kleiner eigener Task-Datensatz mit echten Fällen. GAIA, τ-bench oder HAL eignen sich danach für die Einordnung gegenüber anderen Agenten.
Was kostet Agent-Evaluation zusätzlich gegenüber reinem LLM-Eval?
Echte Tool-Aufrufe, Sandbox-Umgebungen und oft mehrere Wiederholungen pro Aufgabe für pass^k-Messungen — das treibt die Kosten spürbar über reine Text-Evals hinaus, weshalb HAL Kosten explizit mitausweist.

Fazit

Agent-Evaluation ist kein Zusatzkapitel zur LLM-Evaluation, sondern ein eigenes Fach: Ein Eval-Harness führt Aufgaben gegen den kompletten Agenten aus und bewertet Trace und Ergebnis gemeinsam, Task-Success-Rate und Trajectory-Accuracy ergänzen sich, Benchmarks wie GAIA, τ-bench und HAL liefern Vergleichsmaßstäbe, und Offline- wie Online-Judging decken unterschiedliche Risiken ab. Wer nur das zugrunde liegende Modell testet, testet das System, das beim Nutzer ankommt, nicht.

Themenuebersicht

KI-KonzepteEvaluationAgenten