AI-Agent-Evaluation in Production: Von Traces zu Testsuites

Viacheslav Dubrov

2026-06-10 · Aktualisiert 2026-09-06 · 25 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Artikel-Update

Ursprünglich am 10. Juni 2026 veröffentlicht. Am 6. September 2026 überprüft und aktualisiert. Das Update behandelt neuere Agent-Benchmarks, Überarbeitungen der Grader und Erkenntnisse dazu, wie sich die Infrastruktur auf Scores auswirkt.

Eine finale Antwort kann behaupten, dass eine Rückerstattung abgeschlossen ist, während der Trace zeigt, dass verify_identity nie ausgeführt wurde, issue_refund 17-mal wiederholt wurde oder der Agent Erfolg meldete, bevor sich die Datenbank geändert hatte. Answer-only-Grading verbirgt diese Fehler.

Für Engineers, die Tool-using Agents in Production betreiben, besteht die Lösung darin, wiederholbare Traces in klar abgegrenzte Regression Cases umzuwandeln: Deterministische Checks erzwingen Tool-Reihenfolge, Argumente, Loops und Invarianten; kalibrierte Judges übernehmen Entscheidungen, die Interpretation erfordern. Das Ergebnis ist eine versionierte Suite, die denselben Fehler vor dem nächsten Release erkennt.

Den kurzen Tool-Vergleich finden Sie unter Best AI Agent Evaluation Tools.

Warum sich Agent Evals unterscheiden

Traditionelle LLM Evals bewerten meist ein einzelnes Input-Output-Paar: Relevanz, Faithfulness, Korrektheit, Sicherheit, möglicherweise Stil. Agents fügen Planning, Tool Calls, Retries und Termination Checks hinzu, wobei jeder Schritt eine neue Fehlerquelle darstellt.

Nehmen wir einen Refund Agent. Das Transkript kann gut enden, während der Trace fehlerhaft ist:

lookup_order -> issue_refund -> final_answer

Der Output Eval ist erfolgreich. Ein Trajectory Eval sollte fehlschlagen, weil verify_identity nie vor issue_refund ausgeführt wurde. Bei Tool-using Agents können Answer-only Evals Fehler bei der Inhaltsqualität erkennen, aber nicht nachweisen, dass der Agent eine gültige Trajectory genommen oder die erforderlichen Side Effects erzeugt hat.

Es gibt ein zweites Problem: Fehler kumulieren. Wenn ein Workflow 20 erforderliche Schritte umfasst, jeder Schritt unabhängig erfolgreich ist und jeder Schritt dieselbe Zuverlässigkeit von 95 % hat, liegt die End-to-End-Erfolgsrate bei ungefähr 36 %:

Der Agent kann in isolierten Checks also solide wirken und trotzdem die meisten vollständigen Runs nicht erfolgreich abschließen. Der Bruch liegt meist irgendwo in der Mitte. Ihn zu finden erfordert Visibility auf Component-Ebene, nicht einen weiteren Blick auf die Antwort.

Zwei Research-Teams haben dies quantifiziert.

tau-bench gibt einem Agent Airline- und Retail-Kundenserviceaufgaben. Der Agent kommuniziert mit einem simulierten User, ruft APIs auf und muss die Domain-Policy einhalten. Nach dem Gespräch prüft der Grader, ob die Datenbank den annotierten Zielzustand erreicht hat. Ein plausibles Transkript mit den falschen Rows schlägt trotzdem fehl.

Unter diesem Grading löste GPT-4o nur 35,2 % der Airline-Aufgaben und etwas mehr als 60 % der Retail-Aufgaben. Das Paper führte außerdem pass^k ein: die Wahrscheinlichkeit, dass alle k unabhängigen Trials bestehen, gemittelt über die Tasks.

Retail, der einfachere Split, hatte pass^8 unter 25 %. Für einen zufällig ausgewählten Retail-Task und acht unabhängige Trials lag die Wahrscheinlichkeit, dass alle acht Runs bestanden, unter 25 %. Ein Eval mit nur einem Run kann diese Konsistenz nicht messen.

MAST untersucht, warum Agents scheitern. Die Autoren entwickelten aus 150 von Hand annotierten Traces eine Taxonomie mit 14 Modi und wandten sie anschließend auf mehr als 1.600 Traces aus sieben populären Multi-Agent Frameworks an. Die Taxonomie umfasst vage Rollendefinitionen (System Design), einen Agent, der ignoriert, was ein anderer Agent gemeldet hat (Inter-Agent Misalignment), sowie das Melden von Erfolg ohne Überprüfung des Ergebnisses (No Verification). Diese Fehler betreffen Prompts, Orchestration Logic und fehlende Checks im Harness. Ein stärkeres Base Model kann keinen Verification Step ausführen, der nie implementiert wurde. Das Evaluationsziel muss daher auch das Harness rund um das Model umfassen.

Die Adoptionslücke

Die Umfrage State of Agent Engineering von LangChain (1.340 Befragte, durchgeführt Ende 2025) deutet darauf hin, dass viele Teams bereits das Rohmaterial für bessere Evals besitzen. Demnach verfügten 89 % über eine Form von Observability, 52,4 % führten Offline Evals aus und 37,3 % Online Evals.

Die Umfrage berichtet außerdem, dass 57,3 % der Befragten bereits Agents in Production haben. Auf die Frage, was Production blockiert, nannten 32 % die Qualität und 20 % die Latency. Dies ist eine Vendor-Umfrage unter dessen Befragten, keine Vollerhebung aller Agent-Teams. Sie zeigt jedoch eine nützliche Lücke zwischen Trace-Sammlung und systematischer Evaluation.

Damit befinden sich Teams in einem schwierigen Zwischenzustand: Sie können einen fehlerhaften Run nachträglich untersuchen und denselben Fehler anschließend trotzdem zweimal ausliefern.

Jeder diagnostizierte Production-Fehler sollte einen Trace, ein Label, eine Dataset-Row und einen Scorer hinterlassen. Ein wiederholbarer Fehler gehört in die Regression Suite.

Metriken nach Failure Mode auswählen

Die richtige Metrik hängt vom Failure Mode ab, nicht vom Framework. Die nützliche Aufteilung umfasst drei Ebenen:

1. Outcome Evals beantworten, ob der Task erfolgreich war.
2. Trajectory Evals beantworten, ob der Pfad gültig, effizient und Policy-konform war.
3. Component Evals beantworten, welches Tool, welcher Retriever, Sub-Agent oder Decision Step fehlerhaft war.

Jede Ebene kann offline auf festen, replaybaren Cases vor dem Release oder online auf gesampelten Production Traces nach der Response ausgeführt werden. Der Abschnitt zu Guardrails behandelt diese Aufteilung ausführlich. Offline Evals können Goldens erfordern: gespeicherte Cases, die ein Input mit dem Outcome, Tool-Invarianten und den Argumenten eines korrekten Runs verbinden. Online Evals sollten Invarianten, Verteilungen und asynchrone Checks bevorzugen, die nicht im Request Path liegen.

Beginnen Sie mit deterministischen Metriken. Sie sind bei festen Inputs und Code reproduzierbar und kostengünstig auszuführen. Ihre Regeln können trotzdem veralten, wenn sich Tools oder Policies ändern. Versionieren Sie den Scorer daher gemeinsam mit der von ihm geprüften Spezifikation.

Tool-Call-Correctness

Tool Correctness vergleicht die aufgerufenen Tools mit den erwarteten Tools. Legen Sie die Strenge bewusst fest:

• Exact Match: Die Sequenz muss exakt übereinstimmen. Verwenden Sie dies, wenn die Reihenfolge Policy ist, etwa bei lookup_order -> verify_identity -> issue_refund.
• In-Order Match: Erforderliche Tools müssen in der richtigen relativen Reihenfolge erscheinen, zusätzliche harmlose Calls sind jedoch erlaubt.
• Any-Order Match: Erforderliche Tools müssen erscheinen, die Reihenfolge darf aber variieren.

Ein kleiner lokaler Scorer reicht für den Anfang:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if mode not in {"exact", "in_order", "any_order"}:
        raise ValueError(f"unknown matching mode: {mode}")
    if mode == "exact":
        return float(called == expected)
    if not expected:
        return 1.0
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)

called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667
assert tool_correctness(["issue_refund"], [], "exact") == 0.0
assert tool_correctness([], [], "exact") == 1.0
assert tool_correctness(["a", "b"], ["a", "a", "b"], "any_order") == 2 / 3
try:
    tool_correctness([], [], "typo")
except ValueError:
    pass
else:
    raise AssertionError("unknown modes must fail")

Der Score in_order ist der Recall der Longest Common Subsequence: welcher Anteil der erforderlichen Sequenz in der richtigen Reihenfolge erhalten blieb. Beachten Sie, was er ignoriert. Junk Calls senken den Score nicht. Ein Agent kann hier also 1,0 erreichen und trotzdem doppelt so viele Calls ausführen wie nötig. Wenn zusätzliche Calls Geld kosten oder den State mutieren, erfassen Sie zusätzlich die Precision (gematchte erforderliche Calls geteilt durch alle Calls) und interpretieren Sie beide Werte gemeinsam. Recall erkennt den fehlenden Schritt, Precision das Wandern. Weder ein Recall-Score von 1,0 noch eine hohe Precision autorisieren zusätzliche Mutationen. Prüfen Sie jeden State-Changing Call gegen seine Berechtigungen, Ressource, Argumente und die erforderliche vorherige Verifikation. Bei einer leeren erwarteten Liste bedeutet nur der Exact Mode „keine Calls erlaubt“; die anderen Modi haben keine positiven Anforderungen.

DeepEvals Tool-Correctness-Metrik stellt dieselben Stellschrauben über should_consider_ordering und should_exact_match bereit.

Argument Correctness

Das richtige Tool mit falschen Argumenten aufzurufen ist oft schlimmer, als das falsche Tool aufzurufen, weil der Trace normal aussieht.

Für einfache Cases validieren Sie JSON Schema und exakte Werte. Für semantische Cases speichern Sie erwartete Argumente und bewerten die Deltas:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for June 19, 2026.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Eine Tool-Name-Metrik kann 2026-06-17 nicht erkennen, wenn die Policy 2026-06-19 verlangt. Das Dataset muss auch Argumente speichern.

Für diese Illustration mit einem Call pro Tool ist Parameter Match der Anteil der erwarteten (tool, key, value)-Tripel, die der Agent korrekt geliefert hat. Die Dictionaries unten sind nur gültig, wenn jedes relevante Tool höchstens einmal aufgerufen wird. Erzeugen Sie sie nicht, indem Sie frühere Calls mit demselben Namen überschreiben: Das würde einen falschen Refund gefolgt von einem korrekten verbergen. Behalten Sie bei wiederholten Calls Call IDs und Reihenfolge bei, matchen Sie die beabsichtigte Invocation und validieren Sie jede Mutation separat.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if key in called_args.get(tool, {}) and called_args[tool][key] == want:
                matched += 1
    return matched / total if total else 1.0

assert argument_correctness({}, {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {}},
                            {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {"date": None}},
                            {"reschedule_delivery": {"date": None}}) == 1.0

Exakte Gleichheit ist für IDs, Enums und bereits in ein einheitliches Format normalisierte Daten richtig. Für freien Text, Floats und Datumswerte in beliebigen vom Model erzeugten Formen ist sie falsch, weil == eine korrekte Antwort als falsch markiert. Bewerten Sie solche Felder nach ihren jeweiligen Regeln: normalisierter String-Match, Datums-Parsing oder numerische Toleranz. Die Metrik bleibt gleich; der Comparator pro Feld ändert sich.

Efficiency, Loops und Dead Ends

Ein Agent, der den Task nach fünf redundanten Tool Calls abschließt, signalisiert weiterhin ein Planning-Problem und verursacht höhere Betriebskosten.

Mit diesen günstigen Signalen sollten Sie beginnen:

• Redundant-Call-Rate: identische Tool Calls mit identischen Argumenten, die mehr als zweimal wiederholt werden.
• Trace-Shape-Anomalien: plötzliche Spitzen bei Tiefe, Tool-Call-Anzahl, Token-Anzahl, Latency oder Cost.
• Path Convergence: wie nahe der Run am kürzesten bekannten gültigen Pfad für den Task liegt.
• Termination Correctness: ob der Agent zu früh gestoppt, nach dem Erfolg weitergearbeitet oder Erfolg ohne die erforderliche State-Änderung gemeldet hat.
• Plan Adherence: Wenn der Agent vor dem Handeln einen Plan schreibt, prüfen Sie, ob der Trace diesem gefolgt ist. Ein guter ignorierter Plan und ein perfekt befolgter schlechter Plan schlagen beide fehl, allerdings aus entgegengesetzten Gründen. Die Differenz zwischen Plan und Trace zeigt, welcher Fall vorliegt.

Führen Sie diese Checks nach Möglichkeit vor einem Judge aus. Ein Loop Detector umfasst nur wenige Zeilen über dem Trace. Er benötigt kein Model.

Task Completion und Outcome Grading

Beim Outcome Grading lautet die Frage: „Hat der User bekommen, was er verlangt hat?“

Zwei Patterns funktionieren am besten:

• Referenceless Task-Completion Judging: Extrahieren Sie das Ziel aus dem Input und bewerten Sie, ob Trace plus finale Antwort dieses erreicht haben. Das funktioniert online, weil Production Traffic selten Golden Outputs besitzt.
• Environment-State Grading: Vergleichen Sie finale Datenbank-Rows, Files, Tickets, Buchungen oder Records mit einem annotierten Zielzustand. Das ist robuster als Transcript Matching, weil Agents gültige Pfade finden können, die Sie nicht vorab aufgeschrieben haben.

Die zweite Option ist besser, wenn Sie sie umsetzen können. Der Final State ist der Vertrag. Das Transkript ist nur die Evidenz.

Zwei Einschränkungen sind wichtig. Ein 2025 Audit von Agentic Benchmarks stellte fest, dass tau-bench einige Tasks ausschließlich anhand des Database State bewertet. Bei manchen Tasks erfordert das annotierte Outcome weder eine State-Änderung noch spezifischen Text. Ein Agent, der nichts tut, kann dann bestehen: 38 % im Airline-Split und 6,0 % im Retail-Split, bei beliebigem k. Anthropic berichtete von einem Opus-4.5-Run, der einen Booking Task in tau2-bench, dem Nachfolge-Benchmark, „nicht bestand“. Der Agent hatte eine Policy-Lücke gefunden, die für den User tatsächlich das bessere Outcome darstellte. State Grading ist robuster als Transcript Matching, aber der Zielzustand ist weiterhin eine Annotation, und Annotationen können Fehler enthalten. Prüfen Sie Cases, die zu leicht bestehen, nicht nur diejenigen, die fehlschlagen.

Benchmark-Versionen und Environments verändern das Ergebnis

Die oben genannten ursprünglichen tau-bench-Zahlen beschreiben die Zuverlässigkeit wiederholter Trials; sie sind kein aktuelles Model-Leaderboard. Das gepflegte tau-bench-Repository präsentiert inzwischen tau3-bench, das Knowledge Retrieval und Full-Duplex-Voice ergänzt. Der Grading-Fix in Version 1.0.1 vom Juli 2026 verändert die banking_knowledge-Scores: Ergebnisse früherer Versionen sind für diese Domain nicht vergleichbar. Pinnen Sie neben dem Model auch Task- und Grader-Revisionen und bewerten Sie gespeicherte Trajectories neu, wenn eine Annotation korrigiert wird.

Wählen Sie einen Benchmark, der das deployte Interface ausübt. Text-only Customer-Service-Tests können Interruption Handling in einem Voice Agent nicht nachweisen. Knowledge-Retrieval-Tasks benötigen außerdem das Corpus, die Search Configuration und die bei jedem Turn verfügbaren Evidenzen. Übernehmen Sie diese Task Shapes für lokale Regression Cases, statt einen öffentlichen Leaderboard-Rang als Release-Kriterium zu importieren.

Auch die Sandbox ist Teil des Tests. Anthropic’s Infrastructure Study vom Februar 2026 fand bei identischem Model, Harness und identischen Tasks einen Unterschied von sechs Prozentpunkten in Terminal-Bench 2.0 zwischen strikten und unbeschränkten Resource Setups. Zusätzlicher Spielraum reduzierte sowohl Infrastructure Failures als auch die Möglichkeit anderer Lösungsstrategien. Erfassen Sie CPU- und RAM-Garantien und -Limits, Timeouts, Concurrency, Network Access und den Umgang mit Infrastructure Errors. Melden Sie diese Fehler separat, ohne sie stillschweigend aus dem Nenner der erwarteten Tasks zu entfernen.

Component Evals

Outcome- und Trajectory-Metriken zeigen, dass ein Run fehlgeschlagen ist und ungefähr wo. Component Evals bewerten einen einzelnen Span: War der Retrieved Chunk relevant? Hat der Sub-Agent das von seinem Caller erwartete Schema zurückgegeben? Konnte die eigene Response des Tools geparst werden? Hängen Sie den Score an den Span statt an den Run, damit „Welches Tool hat sich diese Woche verschlechtert?“ eine Query und kein erneuter Run ist.

Drei Checks decken den Großteil ab:

• Per-Span-Scoring: Führen Sie die zum Span-Typ passende Metrik aus. Retrieval-Spans erhalten Recall und Precision gegen den annotierten Chunk, Sub-Agent-Spans Schema Validation plus ihren eigenen Tool-Correctness-Score, Tool-Spans Error Rate und Latency.
• Tool-Result-Interpretation: Geben Sie dem Agent einen korrekten, aber unhandlichen Tool Output (eine leere Liste, einen Partial Match oder einen veralteten Timestamp) und prüfen Sie, was er als Nächstes tut. Ein Tool kann korrekt sein, während der Agent es falsch liest. Dieser Fehler wird zwei Schritte später sichtbar.
• Failure Attribution: Der sichtbare Fehler liegt meist hinter dem eigentlichen Fehler. Ordnen Sie ihn dem frühesten Span zu, dessen Output bereits falsch war, nicht dem Schritt, der den Error ausgelöst hat.

Auch hier gilt die Compounding Math aus dem Einstieg. Wenn 20 Schritte isoliert betrachtet korrekt aussehen, kann der Run trotzdem meistens fehlschlagen. Per-Span-Pass-Rates zeigen, welcher Schritt mit 95 % und welcher mit 70 % läuft.

Das Trace-to-Eval-Flywheel

Analysieren Sie Production Failures, bevor Sie zusätzliche Eval Cases brainstormen.

Der Loop:

1. Erfassen Sie genügend Trace Evidence, um den Fehler zu rekonstruieren, und kontrollieren Sie dabei sensible Inhalte.
2. Labeln Sie, was fehlgeschlagen ist.
3. Gruppieren Sie ähnliche Fehler.
4. Behalten Sie repräsentative Goldens einschließlich Varianten, die unterschiedliche Outcomes benötigen.
5. Versionieren Sie das Dataset.
6. Führen Sie es in CI aus.
7. Scoren Sie weiterhin gesampelte Production Traces online.

Das Companion Repository trace2evals implementiert den vollständigen Loop für einen fehlerhaften Support Agent. Es erfasst OpenTelemetry-GenAI-Spans, erkennt Fehler mit deterministischen Regeln, dedupliziert Cases in ein versioniertes Golden Dataset und führt jedes Golden in CI erneut aus. Das Default Backend ersetzt das Model durch deterministische Regeln, die die Entscheidungen des fehlerhaften Agents nachbilden. Dadurch reproduziert make demo den gesamten Loop offline ohne API Key. Führen Sie uv sync --extra live aus und setzen Sie einen API Key. Dann steuern dieselben Commands stattdessen ein echtes Model.

Dies ist eine Teaching Pipeline. Die am 6. September 2026 geprüfte Revision enthält weiterhin Edge Cases im Scorer, namensbasierte Authorization Checks und einen gemeinsam genutzten Trial State. Ihr Trace Adapter erwartet eigene Span Attributes und Message Shapes. Die korrigierten Beispiele hier aktualisieren dieses Repository nicht und etablieren keine Production Authorization. Validieren Sie jede Mutation auf erfolgreiche, an die Ressource gebundene Autorisierung und isolieren Sie Trials, bevor Sie sich auf dessen CI Verdicts verlassen.

Fehler mit Error Analysis analysieren

Hamel’s Field Guide zeigt den Workflow: reale Conversations untersuchen, offene Notizen anlegen, Fehler kategorisieren und spezifische Tests erstellen.

1. Traces untersuchen und offene Notizen dazu verfassen, was schiefgelaufen ist.
2. Wiederkehrende Fehler gruppieren und in benannte Kategorien einteilen.
3. Traces labeln anhand dieser Taxonomie.
4. Spezifische Tests erstellen für die größten umsetzbaren Cluster.

Beginnen Sie nicht mit Labels wie reasoning_issue oder tool_problem. Sie sind zu vage, um sie zu testen. Verwenden Sie Labels wie missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 oder stopped_before_database_update. Ein derart spezifisches Label sagt Ihnen genau, was der Regression Test prüfen sollte.

Vor dem Promote deduplizieren

Der Trace-Mining-Loop hat eine Falle: jeden fehlerhaften Trace dauerhaft hinzuzufügen. So entsteht ein großes, teures und enges Dataset. Es besteht auf Near-Duplicates aus dem März, verfehlt aber im Juni die neue Form desselben Bugs.

Gruppieren Sie zuerst. Beginnen Sie mit einem repräsentativen Golden pro Cluster und behalten Sie anschließend Varianten mit unterschiedlichen Permissions, Argumenten, Recovery States oder erwarteten Outcomes. Ähnliche Formulierungen machen zwei Policy Cases nicht gleichwertig. Speichern Sie verwandte Trace IDs in Access-Controlled Metadata, damit ein Reviewer die Evidenz später untersuchen kann.

Wenn ein Failure Cluster nach einem Fix erneut auftritt, hat der Regression Case nicht generalisiert. Überarbeiten Sie den Cluster und ergänzen Sie die fehlenden Behavioral Variants, statt nahezu identische Transkripte zu sammeln.

Das Dataset versionieren

Versionieren Sie Datasets so, wie Sie Prompts und Code versionieren. Immer wenn sich etwas Wesentliches ändert (Model, Prompt, Tool Schema, Judge Prompt oder App-Verhalten), sollten Sie vor und nach der Änderung dieselbe Dataset-Version ausführen.

Der CI Check sollte pinnen:

• Dataset-Version
• App-Version
• Prompt-Version
• Judge Model
• Judge Prompt
• Evaluator-Code-Version
• Tool Schemas, Policy, Harness und Context-Management-Konfiguration
• Model-Revision, Reasoning- und Sampling-Einstellungen
• Initial Environment Fixture und erlaubte externe Effekte

Wenn sich einer dieser Punkte ändert, wird Ihr Before/After-Vergleich unscharf. Eine goldens-v3.json-Datei in Git reicht für kleine Umgebungen aus. Tool-Native Snapshots in Langfuse, Phoenix, Braintrust oder LangSmith helfen, sobald das Dataset kollaborativ gepflegt wird.

Halten Sie Development Regressions, Judge-Calibration-Examples, Held-out Validation und Monitoring Samples getrennt. Gruppieren Sie verwandte Sessions, User und Tasks vor dem Split, damit Near-Duplicates nicht zwischen Sets leaken können. Sobald ein Case einen Prompt oder eine Rubric beeinflusst, behandeln Sie ihn als Development Evidence. Eine geminte Failure Suite testet bekannte Regressions; ihr Durchschnitt schätzt nicht die Production Success Rate.

Setzen Sie den Mutable State für jeden Trial zurück: Files, Database Rows, Caches und Tool Fixtures. Isolieren Sie Credentials und externe Effekte und halten Sie Candidate- und Baseline-Budgets gleich. Berichten Sie die Anzahl der Tasks separat von den Trials sowie alle gestarteten Attempts, Timeouts, Crashes und nicht scorbaren Outcomes. Vergleichen Sie gepaarte Ergebnisse auf denselben Tasks. Diese Entscheidungen folgen dem Clean-Trial- und Outcome-Grading-Ansatz aus Anthropic’s Evaluation Guide.

Evals in CI ausführen

Ein Release Check muss den Build fehlschlagen lassen, wenn eine Metrik ihr vereinbartes Limit überschreitet. Andernfalls ist die Eval Suite nur ein Dashboard.

Nach der Wiederherstellung der Case Fixture in einem isolierten Trial sollte der Test den aktuellen Agent gegen den Golden Input erneut ausführen. Er sollte nicht lediglich den alten fehlgeschlagenen Trace abspielen (Skizze; die ausführbare Version befindet sich im Companion Repository):

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Diese Unterscheidung wird leicht übersehen. Die Aufgabe des Datasets besteht darin, die nächste Version des Agents dabei zu erwischen, denselben alten Fehler zu wiederholen, nicht darin, den Fehler selbst zu archivieren.

Den Judge kalibrieren, bevor Sie ihm vertrauen

LLM-as-Judge ist hilfreich. Man kann sich damit aber auch leicht selbst täuschen.

G-Eval evaluiert drei Meta-Evaluation-Benchmarks. Dies sind SummEval, ein auf CNN/DailyMail-News-Summarization basierender Benchmark; Topical-Chat, ein Knowledge-Grounded-Dialogue-Benchmark; und QAGS, das faktische Konsistenz in CNN/DailyMail- und XSum-Summaries testet. Mit GPT-4 als Backbone erreichte G-Eval-4 auf SummEval eine Spearman-Korrelation von 0,514 mit menschlichen Bewertungen. Seine Scoring Function gewichtet Rating Levels anhand der Token Probability ($\text{score} = \sum_i p(s_i)\,s_i$).

Das Paper schätzte GPT-4s Token Probabilities durch 20 Sampling-Durchläufe, weil das Model sie im Experiment nicht exponierte. Ein Hosted Model stellt möglicherweise keine nutzbaren Logprobs bereit. Behalten Sie daher die Rubric bei, behaupten Sie aber nicht, die Probability Weighting des Papers reproduziert zu haben. Diese Ergebnisse vergleichen das Protokoll des Papers mit seinen NLG-Baselines auf diesen Benchmarks. Sie unterstützen das Testen eines Judges mit expliziter Rubric, nicht den generellen Ersatz automatischer Metriken oder eines Production-Agent-Trajectory-Benchmarks.

MT-Bench zeigte, dass GPT-4 ungefähr so häufig mit menschlichen Präferenzen übereinstimmte, wie Menschen untereinander übereinstimmen. Dieses Ergebnis trug dazu bei, LLM Judging zum Mainstream zu machen. Spätere Arbeiten zeigten Biases durch Position, Länge und Self-Preference. Judge Scores können sich außerdem ändern, wenn sich Prompt oder Model-Version ändern.

JudgeBench erstellte Response Pairs, bei denen eine Antwort in verifizierbarem Wissen, Reasoning, Mathematik und Code objektiv falsch war. Mit einem einfachen Judge Prompt erreichte GPT-4o 50,9 %, kaum mehr als einen Münzwurf. Der stärkere Arena-Hard Prompt des Papers hob dasselbe Model nur auf 56,6 %. Ein Model-Wechsel unter diesem stärkeren Prompt ist relevanter: Claude 3.5 Sonnet, der beste getestete General-Purpose-Judge, erreichte 64,3 %, während o3-mini mit hohem Reasoning-Aufwand 80,9 % erreichte. Selbstbewusste, aber falsche Antworten bleiben für einen Judge schwierig, der vor dem Grading nicht Reasoning betreibt.

Behandeln Sie den Judge wie ein Messinstrument: Kalibrieren Sie ihn anhand menschlicher Labels, bevor er irgendetwas bewertet, und prüfen Sie ihn erneut, sobald sich Judge Model oder Prompt ändert.

Wenn ein Judge erforderlich ist, strukturieren Sie das Verdict. Schema-Guided Reasoning (SGR) gibt dem Verdict ein Schema für Output Shape und Inspectability. Structured Outputs oder Constrained Decoding können Object Shape, Required Fields und Value Constraints für Felder wie evidence, passed_criteria, failed_criteria, failure_mode und score erzwingen.

Setzen Sie Evidence Fields vor den Score, wenn das Record dadurch leichter zu inspizieren ist. Die Field Order ist Präsentation, keine Garantie für den Reasoning-Prozess. Ein Schema-valides Verdict kann weiterhin nicht belegte Evidenz oder einen unzuverlässigen Score enthalten. Verwenden Sie Calibration gegen Human Labels, deterministische Validatoren und Transcript Review, um die Reliability des Judges zu testen. CI kann ein stabiles JSON-Objekt diffen, prüft damit aber Inspectability und Shape, nicht den Nachweis, dass Rubric Stages befolgt wurden.

Ein Structured Verdict kann außerdem die Cost Curve verändern. Betrachten Sie ein günstigeres Model als Candidate, nicht als automatischen Ersatz. Führen Sie es über dasselbe Human-Labeled-Calibration-Set aus. Vergleichen Sie Agreement, False-Pass-Rate und False-Fail-Rate mit dem größeren Judge. Setzen Sie es für Routinefälle nur ein, wenn es die Schwellenwerte Ihrer Anwendung erfüllt. Behalten Sie den größeren Judge für Disagreements, High-Risk-Cases oder Calibration Runs.

Checkliste für die Judge-Hygiene:

1. Bevorzugen Sie, wo möglich, binäres Pass/Fail. Fünf-Punkte-Skalen laden zu falscher Präzision ein.
2. Labeln Sie Trajectories, die die tatsächlichen Failure Modes abdecken, bevor Sie die Rubric finalisieren. Wählen Sie die Sample Size anhand der Coverage und der Unsicherheit, die die Entscheidung tolerieren kann, und reservieren Sie separate Cases für Validation.
3. Messen Sie die Judge-Human-Übereinstimmung mit Cohens Kappa, einer Confusion Matrix sowie Positive und Negative Recall. Kappa misst Agreement unter Berücksichtigung des zufällig erwarteten Agreements; höher ist besser. Ein Judge, der immer „Pass“ sagt, hat keine nützliche Discrimination, daher kann Kappa null oder undefiniert sein. Legen Sie fest, was bei einem undefinierten Wert geschieht, bevor Sie die Metrik für eine Release-Freigabe verwenden.
4. Zerlegen Sie grobe Kriterien. „Hat der Agent die Identität vor dem Refund Tool Call verifiziert?“ ist besser als „War die Trajectory gut?“
5. Geben Sie das Verdict über ein SGR Schema mit Evidenz, fehlgeschlagenen Kriterien, Failure Mode und Score aus.
6. Vergleichen Sie Judges derselben und anderer Model-Familien anhand zurückgehaltener Human Labels. Die Trennung der Families allein belegt keine Reliability.
7. Messen Sie die Sensitivität gegenüber der Reihenfolge von Pairs. Behalten Sie Randomization oder Swapped-Order-Aggregation nur bei, wenn sie Held-out Decisions verbessert; eine kontrollierte Studie von 2026 stellte fest, dass Swapping bei adversarial Cases schaden kann.
8. Geben Sie zusätzlichem Text keinen Credit, sofern er nicht korrekten, relevanten und belegten Content ergänzt. Eine längere Antwort ist nicht automatisch besser.
9. Pinnen Sie Judge Model, Prompt, Dataset, Schema und App-Version.
10. Kalibrieren Sie nach Änderungen an Model, Prompt, Tool, Policy oder Schema erneut.

Ein Panel ist eine weitere Option, die getestet werden sollte. PoLL berichtete über bessere Übereinstimmung mit menschlichen Bewertungen, weniger Intra-Model-Bias und geringere Kosten als die Single-GPT-4-Baseline über sechs Datasets hinweg. Diese Ergebnisse gelten für die dort verwendeten Models, Tasks und historischen Preise. Sie belegen nicht, dass ein Panel bei Ihrem Task sicherer ist. Vergleichen Sie False Passes, False Failures, Kosten und Disagreement Workload mit einem kalibrierten Judge anhand zurückgehaltener Labels.

Es gibt keinen universellen Kappa-Schwellenwert, der einen Judge für CI geeignet macht. Berichten Sie Confusion Matrix, Label Counts, False-Pass-Rate unter den menschlich als fehlerhaft bewerteten Cases und False-Fail-Rate unter den menschlich als erfolgreich bewerteten Cases, jeweils mit Unsicherheit. Wählen Sie Release Limits anhand der Konsequenzen dieser Fehler. Verwenden Sie Review Queues, wenn die Evidenz für eine automatische Akzeptanz zu schwach ist, und behalten Sie bei folgenreichen Aktionen die Human Authorization bei, wenn der Workflow dies erfordert.

Guardrails laufen inline, Online Evals beobachten danach

Diese Konzepte werden verwechselt, weil beide Scores erzeugen. Der Unterschied liegt in der Platzierung: inline im Request Path, vor dem Release oder nach der Response.

Guardrails laufen inline. Sie sind schnell und für User sichtbar. Ein Guardrail kann einen Tool Call blockieren, PII redigieren, Prompt Injection ablehnen oder vor dem Verlassen Ihres Systems einen Retry erzwingen. Ein False Positive ist ein Production Bug. Ein False Negative ist leiser und schlimmer, weil im Request Path nichts darüber berichtet. Schema-, Range- und Policy-Checks sind deterministisch. Injection- und PII Detection sind Classifier. Betrachten Sie Misses daher als erwartbar und lassen Sie ein Async Eval überwachen, was sie durchlassen.

Offline Evals laufen vor dem Release. Sie sind reproduzierbar und prüfen Prompts, Models, Tools, Retrievers und Policies gegen ein festes Dataset.

Online Evals laufen nach der Response, normalerweise auf gesampeltem Traffic. Sie können langsamere LLM Judges verwenden, weil sie nicht auf dem Latency Path liegen. Ihre Aufgabe ist, Drift zu erkennen, neue Failure Clusters zu finden und das nächste Offline Dataset zu speisen.

Wenn die Platzierung falsch ist, schadet es in beide Richtungen:

• Ein Judge im Request Path erhöht die Latency und fügt eine neue Flakiness-Quelle hinzu.
• Ein Guardrail, das auf Async Scoring reduziert wird, lässt Policy Violations bis zu den Usern gelangen.

Unterscheiden Sie bei Security Tests zwischen Attack Detection, also dem Versuch einer verbotenen Aktion, und dem tatsächlich erfolgreichen Harmful Effect. Berichten Sie erfolgreiche schädliche Effekte pro Attack Trial zusammen mit Threat Model und Attempt Budget sowie Legitimate Task Success und False Blocks pro Benign Trial. Ein Detector Score allein kann weder belegen, dass Daten privat blieben, noch dass ein Write verhindert wurde. Verwenden Sie isolierte Targets; Anthropic’s Cybersecurity Evaluation Incident Report dokumentiert, warum Evaluation Effects Containment benötigen.

Bei High-Volume-Systemen sollten Sie ein kleines Sample mit einem stärkeren Judge und ein größeres Sample mit günstigeren Classifiers scoren. Alarmieren Sie bei Clustern und Confidence Bounds, nicht bei einem einzelnen verrauschten Point Estimate.

Tooling-Auswahl

Kein einzelnes Tool besitzt den gesamten Loop. Vergleichen Sie einen Trace-/Dataset Store und einen CI-/Eval Runner separat. Ein Produkt kann beides abdecken, aber Sie müssen nicht beides bei einem Vendor kaufen.

Dies ist ein Author Snapshot vom 6. September 2026. Jeder Link verweist auf die aktuelle Dokumentation, die ich für die jeweilige Capability-Aussage verwendet habe. Pläne, Lizenzen, API Keys, Provider Access und Infrastruktur-Anforderungen gelten weiterhin.

Die Trade-off-Hinweise beschreiben, wo Kosten entstehen, nicht deren Höhe. Pricing Pages ändern sich, und Vendors zählen unterschiedliche Dinge: Traces, Observations, Spans, Scores, User, Retention oder verarbeitete Daten. Prüfen Sie die aktuellen Preise erneut, bevor Sie sich festlegen.

Empfehlungen nach Constraint:

• Wählen Sie Phoenix, wenn Self-Hosting, Privacy und OTel-kompatibles Tracing harte Anforderungen sind und Ihr Team das Deployment betreiben kann.
• Wählen Sie Langfuse, wenn Sie zusätzlich Dataset-Versionierung und Experimente benötigen und dessen Storage Stack betreiben oder die erforderlichen Add-ons kaufen können.
• Wählen Sie DeepEval, wenn Python/pytest-CI-Pass/Fail der primäre Vertrag ist.
• Wählen Sie Inspect AI, wenn die Hauptaufgabe Safety- oder Frontier-Agent-Evaluation in konfigurierbaren Sandboxes ist.
• Wählen Sie LangSmith, wenn LangChain/LangGraph-Integration zu Ihrem Workflow passt. Nutzen Sie Cloud oder berücksichtigen Sie die Enterprise-Anforderung für BYOC oder Self-Hosted Platform Hosting.
• Wählen Sie Braintrust, wenn Managed Pull-Request Feedback und Experiment Comparison einen API-Key-basierten Service rechtfertigen.
• Wählen Sie Promptfoo, wenn Prompt- oder Red-Team-Checks die wichtigste Regression Surface sind und ein Trace Store außerhalb des Scopes liegt.

Die Tool-Auswahl ist zweitrangig. Wenn Production Failures nicht zu Test Cases werden, bezahlen Sie im Wesentlichen für Trace Storage.

Praktische Rollout-Checkliste

Bauen Sie die Evidence Pipeline auf, bevor Sie den Metrik-Stack erweitern. Entscheiden Sie zunächst, woher die Beispiele stammen sollen.

1. Historische Runs zuerst sammeln. Wenn der Agent bereits existiert, ziehen Sie Traces, Support Tickets, Bug Reports, Thumbs-Down-Sessions, manuelle QA-Transkripte und Dogfooding-Notizen heran, bevor Sie die Implementierung ändern. Wenn der Agent noch nicht existiert, loggen Sie ab Tag eins jeden Prototype- und manuellen Test-Run.

2. Die Trace Shape instrumentieren. Erfassen Sie Messages, Tool Calls, Arguments, Tool Outputs, Errors, Token Counts, Latency, Cost, User Feedback, App Version, Prompt Version, Model Version, Tool-Schema-Version und finalen Environment State. Verwenden Sie OpenTelemetry GenAI Conventions oder OpenInference-Style-Spans, wenn Sie Portabilität wünschen, und pinnen Sie Convention-Version und Adapter. Erfassen Sie Content selektiv: Redigieren Sie Secrets und personenbezogene Daten, beschränken Sie den Zugriff und legen Sie Retention fest, bevor Sie Traces in Datasets übernehmen. Nutzen Sie Langfuse, LangSmith, Phoenix oder Braintrust, wenn Sie sofort eine Trace UI und einen Dataset Workflow möchten.

3. Reale Fehler in Seed Cases umwandeln. Lesen Sie die Traces, bevor Sie sie mit einem Model zusammenfassen. Speichern Sie für jeden nützlichen Fehler Input, Source Trace ID, Expected State, Expected Tool Invariants, Failure Mode, Severity und Reviewer Note. Langfuse kann Dataset Items mit Production Traces verknüpfen; LangSmith kann Datasets aus getraceten Runs erstellen. Bewahren Sie den Source Link auf, damit der Case auditierbar bleibt.

4. Wenn keine Historie vorhanden ist, Cold-Start Cases generieren. Bitten Sie ein LLM, Tasks aus Product Requirements, Policies, Tool Schemas, State Machines und Support Macros zu entwerfen. Decken Sie Happy Paths und Fehler ab, etwa falsche Permissions, fehlende Identity Checks, veraltete Tool Results, mehrdeutige Datumsangaben, Retries nach Rate Limits und widersprüchliche Tool Outputs.

5. Synthetischen Cases erst nach Human Review vertrauen. Synthetische Beispiele sind nützlich für Coverage, nicht für Truth. Markieren Sie sie mit source: synthetic und verlangen Sie die Freigabe des erwarteten Outcomes durch einen Reviewer. Führen Sie nach Möglichkeit einen Known-Good Reference Path aus und validieren Sie generierte Erwartungen unabhängig. Die Verwendung einer anderen Model-Familie ersetzt diesen Check nicht.

6. Ein kleines, ausgewogenes Dataset erstellen. Nehmen Sie Successes, Failures, Refusals, Boundary Cases, Long-Turn Cases, Policy-Sensitive Cases und gültige Alternate Paths auf. Machen Sie das Golden nicht zum „exakten alten Transkript“. Speichern Sie zusätzlich zu den oben beschriebenen Golden-Inhalten den Failure Mode, aufgrund dessen der Case in die Suite aufgenommen wurde.

7. Zuerst deterministische Checks hinzufügen. Required Tool Order, wenn die Reihenfolge Policy ist, Required Arguments, Schema Validation, Final-State Diffs, Loop Limits sowie Token- und Latency-Ceilings und Task-Specific Invariants sollten vor jedem Judge laufen.

8. Einen SGR-geformten Judge hinzufügen. Verwenden Sie ihn nur für den Teil, der Interpretation benötigt. Kalibrieren Sie ihn anhand menschlicher Labels und testen Sie die gewählte Rubric auf unveränderten Validation Cases. Wenn er gute und schlechte Beispiele im Calibration Set nicht trennen kann, korrigieren Sie die Rubric, bevor Sie sie in CI integrieren.

9. Den Loop verdrahten. Führen Sie die kleine Offline Suite in CI aus, die größere Suite vor dem Release, scoren Sie gesampelten Production Traffic online und übernehmen Sie wiederkehrende Online Failure Clusters zurück in das Offline Dataset.

Ihre erste Eval Suite wird Cases übersehen. Führen Sie sie trotzdem aus und ergänzen Sie wiederkehrende Fehler als Cases. Eine täglich laufende Suite liefert Evidenz, mit der Sie sie verbessern können.

Referenzen

• trace2evals Companion Demo Repository
• LangChain – State of Agent Engineering
• Anthropic – Demystifying Evals for AI Agents
• Hamel Husain – A Field Guide to Rapidly Improving AI Products
• OpenTelemetry Semantic Conventions for Generative AI Systems
• DeepEval Tool Correctness
• DeepEval Task Completion
• DeepEval Unit Testing in CI/CD
• Inspect Running Evals
• OpenAI Structured Model Outputs
• Schema-Guided Reasoning: vLLM, xgrammar und Pydantic
• Phoenix Self-Hosting
• Langfuse Datasets und Versionierung
• Langfuse Experiments in CI/CD
• LangSmith Platform Setup
• LangSmith – Create and Manage Datasets Programmatically
• Braintrust – Create Experiments
• Phoenix LLM Evals
• Promptfoo GitHub Action Integration
• tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Why Do Multi-Agent LLM Systems Fail?
• Establishing Best Practices for Building Rigorous Agentic Benchmarks
• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models
• JudgeBench: A Benchmark for Evaluating LLM-based Judges
• Self-Preference Bias in LLM-as-a-Judge