06.04.2025 AI Engineering5 Minuten Lesezeit

Agenten evaluieren: Trajektorien statt finaler Antworten

Agenten-Evaluation bedeutet 2025, Trajektorien und Tool-Aufrufe zu bewerten — nicht nur finale Antworten. Wir erklären Metriken auf Schrittebene, aufgabenspezifische Erfolgsprädikate und Zuverlässigkeitsmessung mit pass^k, gestützt auf τ-bench, WebArena, BFCL V3 und SWE-bench Verified. Ebenso klar benennen wir, was Trajektorien-Evaluation nicht leistet und warum sie anspruchsvoller ist als RAG-Evaluation.

Die finale Antwort ist die falsche Messgröße

Nach Anthropics Definition vom Dezember 2024 ist ein Agent ein System, in dem ein Sprachmodell seinen eigenen Ablauf und seine Tool-Nutzung dynamisch steuert. In der Praxis entsteht eine Schleife: Tool auswählen, Argumente füllen, Ergebnis beobachten, neu entscheiden. Ein Produktionslauf umfasst fünf bis dreißig solcher Schritte. Wer nur die letzte Nachricht bewertet, ignoriert daher den größten Teil des Verhaltens — und damit auch den größten Teil der Fehlerfläche.

Die Lücke zwischen Antwortqualität und Aufgabenerfolg ist messbar. WebArena (Juli 2023) setzte Agenten in 812 realistische Web-Aufgaben und prüfte funktionale Ergebnisse statt Transkripte: Der beste GPT-4-basierte Agent schloss 14,41 % der Aufgaben Ende-zu-Ende ab, Menschen 78,24 %. Ein Agent kann gleichzeitig eine flüssige Abschlussnachricht und einen falschen Umgebungszustand produzieren. Nur einer von beiden zählt.

Eine Änderung landet — Prompt, Modell oder Retrieval. 1/4

Warum Agenten-Evals schwerer sind als RAG-Evals

Eine RAG-Pipeline hat eine feste Form: Anfrage, Retrieval, Generierung, ein Durchlauf. Ihre Standardmetriken — Context Precision, Context Recall, Faithfulness, Answer Relevance — sind aus vier statischen Artefakten berechenbar: Frage, gefundene Textstellen, Antwort, Referenz. Nichts in der Pipeline verändert einen Zustand. Jeder Lauf mit derselben Eingabe ist strukturell identisch.

Agenten brechen jede dieser Annahmen. Die Schrittzahl variiert, und für dieselbe Aufgabe können mehrere Trajektorien korrekt sein. Tool-Aufrufe haben Seiteneffekte; ein falscher Schreibzugriff ist nicht bloß ein falscher Satz — er kann irreversibel sein. Sampling macht Läufe zusätzlich schwer reproduzierbar. Eine Agenten-Evaluation muss deshalb Sequenzen und Endzustände bewerten, Pfadvarianz zulassen und die Streuung zwischen Läufen quantifizieren. Eine RAG-Scorecard leistet nichts davon.

Trajektorien als primäres Evaluationsobjekt

Eine Trajektorie ist die vollständige geordnete Aufzeichnung eines Laufs: jeder Modell-Turn, jeder Tool-Aufruf mit Argumenten, jedes Tool-Ergebnis und der finale Umgebungszustand. Sie muss vollständig persistiert werden. Im März 2025 setzt das Tooling das bereits voraus: OpenAIs Agents SDK (veröffentlicht am 11. März 2025) traced Läufe standardmäßig, LangSmith speichert sie als Bäume, und das Model Context Protocol (November 2024) gibt Tool-Aufrufen eine einheitliche protokollierbare Form.

Eine Trajektorie zu bewerten heißt, sie mit gewählter Strenge gegen Erwartungen zu vergleichen: exakter Abgleich mit einer Referenzsequenz, Abgleich in Reihenfolge mit Toleranz für Zusatzschritte, Abgleich ohne Reihenfolge oder Precision und Recall über die Menge der Tool-Aufrufe. Die Strenge ist eine Designentscheidung mit bekannten Trade-offs. Exakter Abgleich bestraft legitime Umwege. Mengenbasierter Abgleich übersieht Reihenfolgefehler — ein Schreibzugriff vor der Validierung besteht den Mengen-Check und scheitert in Produktion.

Metriken auf Schrittebene für Tool-Aufrufe

Unter der Trajektorie liegt der einzelne Schritt, und die nützlichen Schrittmetriken sind zählbar statt gerichtet: richtiges Tool gewählt, Argumente valide, Aufruf erfolgreich, Aufruf redundant, Fehler behoben. Diese Zählungen lokalisieren Fehler. Die Fehleranalyse von τ-bench ist hier ein Vorbild: GPT-4o machte 0,46 Tool-Aufrufe mit nicht existierenden IDs pro Retail-Aufgabe, GPT-3.5-Turbo 2,08. Diese eine Zahl trennt ein Grounding-Problem bei Argumenten von einem Policy-Problem.

BFCL V3 (19. September 2024) zeigt, dass Schritt- und Ergebnisprüfungen auch in Multi-Turn-Szenarien mechanisch bleiben können. Am Ende jedes Turns laufen zwei Checks: ein zustandsbasierter Vergleich des Backends nach der Ausführung und ein Subset-Abgleich der Antworten für lesende Aufrufe, die keine Zustandsspur hinterlassen. Kein Judge-Modell ist beteiligt. Deterministische Checks zuerst, LLM-Judges nur dort, wo kein Prädikat existiert — diese Reihenfolge hält Evals günstig und debugbar.

Ebene	Frage	Beispielprüfung
Finale Antwort	Ist die Antwort korrekt?	String-Vergleich oder LLM-Judge
Endzustand	Hat die Umgebung das Ziel erreicht?	Datenbank-Diff (τ-bench), Unit-Tests (SWE-bench Verified)
Trajektorie	War der Pfad valide und effizient?	Tool-Aufruf-Abgleich in Reihenfolge, Schrittzahl
Einzelschritt	War dieser Tool-Aufruf richtig?	Tool-Auswahl, Argumentvalidierung, Fehlerbehandlung

Erfolgskriterien gehören zur Aufgabe

Generische Scores übertragen sich nicht zwischen Aufgaben; Erfolg muss pro Aufgabe definiert werden, als ausführbares Prädikat. τ-bench annotiert jede Aufgabe mit einem Ziel-Datenbankzustand und vergleicht Endzustände — das bleibt robust, wenn der simulierte Nutzer die Anfrage umformuliert. SWE-bench Verified (13. August 2024) hängt an jede der 500 Issues human-validierte Unit-Tests. Beide reduzieren die Frage nach dem Erfolg auf eine mechanische Prüfung.

Dieselbe Regel gilt in unseren eigenen Agentenprojekten: Wir schreiben das Erfolgsprädikat vor dem Agenten, verankern es in der Aufgabendefinition und führen es ohne Judge-Modell aus. Verbotene Aktionen — destruktive Schreibzugriffe, Policy-Verstöße — stehen separat daneben und gelten unabhängig vom Endzustand als harte Fehlschläge. Lässt sich Erfolg nicht als Prädikat formulieren, ist die Aufgabe noch nicht reif für einen Agenten.

Zuverlässigkeit messen mit pass^k

pass@k fragt, ob mindestens einer von k Versuchen gelingt; das belohnt Glückstreffer. τ-bench (Juni 2024) schlug pass^k vor: die Wahrscheinlichkeit, dass alle k unabhängigen Versuche gelingen. Die Differenz zwischen beiden ist die Zuverlässigkeitslücke. GPT-4o mit Function Calling erreicht pass^1 von 61,2 % auf τ-retail und 35,2 % auf τ-airline; auf τ-retail fällt pass^8 unter 25 %.

Ein kundennaher Agent begegnet derselben Anfrage viele Male; pass^k ist deshalb die ehrliche Produktionsmetrik. Sie bestimmt zugleich das Eval-Budget: Jede Aufgabe muss mehrfach laufen. Die τ-bench-Autoren berichten rund 200 US-Dollar API-Kosten für einen einzelnen Durchlauf über die Retail-Domäne. Zuverlässigkeitsmessung ist ein Budgetposten, kein Nebenprodukt.

Was Trajektorien-Evaluation nicht leistet

Trajektorien-Evaluation stichprobt Verhalten; sie begrenzt es nicht. Eine bestandene Suite ist Evidenz, kein Sicherheitszertifikat. Sie beseitigt das Judge-Problem nicht: Wo ein LLM Trajektorien benotet, müssen seine Urteile gegen menschliche Labels kalibriert und Abweichungsraten berichtet werden. Sie löst auch keinen Distribution Shift: Offline-Aufgabensätze altern, und Produktionsverkehr driftet von ihnen weg.

Günstig ist sie ebenfalls nicht. Mehrfache Versuche mal lange Trajektorien multiplizieren die Token-Kosten, und zustandsbasierte Prüfungen verlangen eine zurücksetzbare Umgebung — geseedete Datenbanken, Mock-APIs, Fixtures — deren Engineering-Aufwand mit dem Agenten selbst vergleichbar ist. Teams sollten das explizit budgetieren, statt es mitten im Projekt zu entdecken.

Ausblick vom März 2025

Drei Entwicklungen halten wir von hier aus für wahrscheinlich. Erstens konvergieren Trace-Formate: MCP verbreitet sich — OpenAI hat Ende März 2025 Unterstützung in sein Agents SDK aufgenommen — und die Generative-AI-Konventionen von OpenTelemetry reifen. Standardisierte Traces machen Trajektorien-Evals über Frameworks hinweg portabel.

Zweitens wandern Schrittprüfungen in die CI. Sobald Trajektorien als strukturierte Daten vorliegen, wird eine Assertion darauf zum Unit-Test. Agenten-Regressionen sollten dann in Pipelines auffallen, nicht bei Nutzern. Drittens erreichen Zuverlässigkeitsmetriken die Verträge: Wer behauptet, ein Agent funktioniere, wird nach pass^k bei genanntem k gefragt werden — nicht nach einer Demo. Das dauerhafte Engineering-Artefakt dieser Phase wird der Eval-Harness sein, nicht der Prompt.