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

Viacheslav Dubrov

2026-06-10 · Aktualisiert 2026-08-16 · 22 Min. · KI-Agenten

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

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 änderte. Grading ausschließlich anhand der Antwort verbirgt diese Fehler.

Für Engineers, die Tool-Using Agents in Production betreiben, besteht die Lösung darin, wiederholbare Traces in begrenzte Regression Cases zu überführen: 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 noch vor dem nächsten Release erkennt.

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

Warum sich Agent Evals unterscheiden

Herkömmliche LLM Evals bewerten meist ein einzelnes Input-Output-Paar: Relevanz, Faithfulness, Korrektheit, Safety und eventuell Stil. Agents bringen Planning, Tool Calls, Retries und Termination Checks hinzu, wobei jeder Schritt eine neue Fehlerquelle darstellt.

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

lookup_order -> issue_refund -> final_answer

Die Output-Evaluation ist erfolgreich. Eine Trajectory-Evaluation sollte fehlschlagen, weil verify_identity vor issue_refund nie ausgeführt wurde. Für Tool-Using Agents sind Evals, die nur die Antwort bewerten, Smoke Tests: Sie erkennen einen vollständigen Ausfall und übersehen fast alles andere.

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

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

Zwei Research-Teams haben dies quantifiziert.

tau-bench stellt einem Agenten Customer-Service-Aufgaben aus den Bereichen Fluggesellschaften und Einzelhandel. Der Agent kommuniziert mit einem simulierten User, ruft APIs auf und muss die jeweilige Domain-Policy einhalten. Nach dem Gespräch prüft der Grader, ob die Datenbank den annotierten Goal State erreicht hat. Ein plausibles Transcript mit den falschen Datensätzen 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: Dieselbe Aufgabe wird k-mal ausgeführt, und ein Pass wird nur gezählt, wenn der Agent in allen k Runs erfolgreich ist.

Retail, der einfachere Split, fiel bei k = 8 unter 25 %. Bei mehr als drei Vierteln dieser Aufgaben scheiterte derselbe Agent bei mindestens einem von acht Runs, obwohl er jedes Mal dieselbe Aufgabe bearbeitete. Eine Eval mit nur einem Run kann diese Inkonsistenz nicht aufdecken.

MAST untersucht, warum Agents scheitern. Die Autoren entwickelten aus 150 manuell annotierten Traces eine Taxonomie mit 14 Fehlermodi und wendeten sie anschließend auf mehr als 1.600 Traces aus 7 populären Multi-Agent Frameworks an. Die Taxonomie umfasst vage Rollendefinitionen (System Design), einen Agent, der ignoriert, was ein anderer Agent berichtet hat (Inter-Agent Misalignment), sowie Erfolgsmeldungen ohne Prüfung des Ergebnisses (No Verification). Diese Fehler weisen auf Prompts, Orchestration Logic und fehlende Checks im Harness hin. Ein stärkeres Base Model kann keinen Verification Step ausführen, der nie implementiert wurde. Deshalb muss das Evaluationsziel auch den 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 über das Rohmaterial für bessere Evals verfügen. Demnach hatten 89 % irgendeine Form von Observability, 52,4 % führten Offline Evals aus und 37,3 % Online Evals.

Laut der Umfrage haben außerdem bereits 57,3 % der Befragten Agents in Production. Auf die Frage, was Production blockiert, nannten 32 % Quality und 20 % Latency. Dies ist eine Vendor-Umfrage unter den eigenen Befragten und keine Vollerhebung aller Agent-Teams. Sie zeigt jedoch eine nützliche Lücke zwischen Trace-Erfassung und systematischer Evaluation.

Damit befinden sich Teams in einem ungünstigen Zwischenzustand: Sie können einen fehlerhaften Run im Nachhinein untersuchen und denselben Fehler anschließend trotzdem zweimal ausliefern.

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

Metriken nach Fehlermodus auswählen

Die richtige Metrik hängt vom Fehlermodus ab, nicht vom Framework. Die sinnvolle Aufteilung umfasst drei Ebenen:

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

Jede Ebene kann offline auf festen, wiederholbaren 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 benötigen: gespeicherte Cases, die ein Input mit dem Outcome, Tool-Invarianten und den Argumenten verbinden, die ein korrekter Run erzeugen muss. Online Evals sollten Invarianten, Verteilungen und asynchrone Checks bevorzugen, die nicht im Request Path liegen.

Beginnen Sie mit deterministischen Metriken. Sie sind günstig, schnell und driften nicht.

Tool-Call-Correctness

Tool Correctness vergleicht die aufgerufenen Tools mit den erwarteten Tools. Wählen Sie den gewünschten Striktheitsgrad bewusst:

• Exact Match: Die Sequenz muss exakt übereinstimmen. Verwenden Sie dies, wenn die Reihenfolge durch die Policy vorgegeben ist, zum Beispiel lookup_order -> verify_identity -> issue_refund.
• In-Order Match: Erforderliche Tools müssen in der korrekten relativen Reihenfolge erscheinen, zusätzliche harmlose Calls sind jedoch zulässig.
• Any-Order Match: Erforderliche Tools müssen vorkommen, die Reihenfolge darf jedoch variieren.

Für den Anfang reicht ein kleiner lokaler Scorer:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    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

Der Score in_order ist der Recall der Longest Common Subsequence: Welcher Anteil der erforderlichen Sequenz in der richtigen Reihenfolge erhalten geblieben ist. Beachten Sie, was dabei ignoriert wird. Junk Calls senken den Score nicht. Ein Agent kann hier also 1,0 erreichen und dennoch doppelt so viele Calls ausführen wie nötig. Wenn zusätzliche Calls Geld kosten oder den State verändern, erfassen Sie zusätzlich die Precision (gematchte erforderliche Calls geteilt durch alle Calls) und betrachten Sie beide Werte gemeinsam. Recall erkennt den fehlenden Schritt, Precision das Wandern.

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

Argument Correctness

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

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

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

Eine Metrik für den Tool-Namen kann 2026-06-17 nicht erkennen, obwohl die Policy 2026-06-19 verlangt. Das Dataset muss daher auch Argumente speichern.

Die zu diesem Dataset passende Kennzahl ist Parameter Match: der Anteil der erwarteten (tool, key, value)-Triples, die der Agent korrekt geliefert hat.

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 called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

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

Efficiency, Loops und Dead Ends

Ein Agent, der die Aufgabe nach fünf redundanten Tool Calls abschließt, weist weiterhin auf ein Planning-Problem hin 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 Anstiege bei Tiefe, Tool-Call-Anzahl, Token-Anzahl, Latency oder Cost.
• Path Convergence: Wie nah der Run am kürzesten bekannten gültigen Pfad für die Aufgabe liegt.
• Termination Correctness: Ob der Agent zu früh angehalten, 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 Plan gefolgt ist. Ein guter Plan, der ignoriert wird, und ein schlechter Plan, der perfekt befolgt wird, sind aus entgegengesetzten Gründen beide fehlerhaft. 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 benötigt nur wenige Zeilen über dem Trace. Dafür ist kein Model erforderlich.

Task Completion und Outcome Grading

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

Zwei Patterns funktionieren am besten:

• Referenceless Task-Completion Judging: Ziel aus dem Input extrahieren und bewerten, ob Trace plus finale Antwort dieses Ziel erreicht haben. Das funktioniert online, weil Production Traffic nur selten Golden Outputs besitzt.
• Environment-State-Grading: Finale Datenbankzeilen, Dateien, Tickets, Buchungen oder Records mit einem annotierten Goal State vergleichen. Das ist robuster als Transcript Matching, weil Agents gültige Pfade finden können, die Sie nicht vorab festgelegt haben.

Die zweite Option ist besser, wenn Sie sie umsetzen können. Der Final State ist der Vertrag. Das Transcript ist lediglich ein Beleg.

Zwei Einschränkungen sorgen für eine realistische Bewertung. Ein Audit von Agentic Benchmarks aus dem Jahr 2025 stellte fest, dass tau-bench manche Aufgaben ausschließlich anhand des Database State bewertet. Bei einigen Aufgaben erfordert das annotierte Outcome weder eine State-Änderung noch einen bestimmten Text. Ein Agent, der nichts tut, kann dann einen Pass erreichen: 38 % im Airline-Split und 6,0 % im Retail-Split – bei jedem k. Anthropic berichtete von einem Opus-4.5-Run, der eine Booking-Aufgabe in tau2-bench, dem Nachfolge-Benchmark, „nicht bestand“. Der Agent hatte eine Policy-Lücke gefunden, die tatsächlich das bessere Outcome für den User darstellte. State Grading ist robuster als Transcript Matching, aber der Goal State ist weiterhin eine Annotation, und Annotationen können Fehler enthalten. Prüfen Sie Cases, die zu leicht erfolgreich sind, nicht nur die fehlgeschlagenen.

Component Evals

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

Drei Checks decken den größten Teil ab:

• Per-Span-Scoring: Führen Sie die zum Span-Typ passende Metrik aus. Retrieval-Spans erhalten Recall und Precision gegenüber dem annotierten Chunk, Sub-Agent-Spans Schema Validation plus einen eigenen Tool-Correctness-Score, Tool-Spans Error Rate und Latency.
• Tool-Result-Interpretation: Geben Sie dem Agenten einen korrekten, aber ungewöhnlichen 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 das Ergebnis falsch liest. Dieser Fehler wird erst zwei Schritte später sichtbar.
• Failure Attribution: Der sichtbare Fehler liegt meistens downstream vom eigentlichen Fehler. Attribuieren Sie ihn dem frühesten Span, dessen Output bereits falsch war – nicht dem Schritt, der den Fehler ausgelöst hat.

Auch hier zahlt sich die eingangs dargestellte Compounding Math aus. Wenn 20 Schritte isoliert betrachtet jeweils gut 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-Fehler, bevor Sie zusätzliche Eval Cases brainstormen.

Der Loop:

1. Den vollständigen Trace erfassen.
2. Kennzeichnen, was fehlgeschlagen ist.
3. Ähnliche Fehler gruppieren.
4. Pro Cluster ein repräsentatives Golden behalten.
5. Das Dataset versionieren.
6. Es in CI ausführen.
7. Gesampelte Production Traces weiterhin online scoren.

Das begleitende 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 zu einem versionierten 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 nachstellen. 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.

Fehler mit Error Analysis finden

Hamel Husain und Shreya Shankar vermitteln für genau diesen Schritt einen Error-Analysis-Workflow; Hamels Field Guide führt durch den Prozess. Die ersten beiden Schritte übernehmen ihre Bezeichnungen aus der qualitativen Forschung, die Methode ist jedoch unkompliziert: Traces lesen, Notizen machen, Patterns benennen.

1. Open Coding: 30 bis 50 reale Traces lesen und frei formulierte Notizen darüber anlegen, was schiefgelaufen ist.
2. Axial Coding: Diese Notizen in 5 oder 6 benannte Fehlerkategorien clustern.
3. Alles anhand der Taxonomie labeln.
4. Für die größten Buckets Metriken erstellen.

Beginnen Sie nicht mit Labels wie reasoning_issue oder tool_problem. Sie sind zu vage, um testbar zu sein. 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 muss.

Vor der Aufnahme deduplizieren

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

Gruppieren Sie zuerst. Nehmen Sie pro Cluster ein repräsentatives Golden auf. Speichern Sie die zugehörigen Trace IDs in den Metadaten, damit ein Reviewer die Production-Evidenz später untersuchen kann.

Wenn ein Failure Cluster nach einem Fix erneut auftritt, hat der Regression Case nicht generalisiert. Clustern Sie neu und erweitern Sie das Golden, statt 15 punktuelle Beispiele hinzuzufügen.

Das Dataset versionieren

Versionieren Sie Datasets genauso wie Prompts und Code. Sobald sich etwas Wesentliches ändert (Model, Prompt, Tool Schema, Judge Prompt oder App-Verhalten), möchten Sie dieselbe Dataset-Version vor und nach der Änderung ausführen.

Das CI-Gate sollte folgende Angaben pinnen:

• Dataset-Version
• App-Version
• Prompt-Version
• Judge Model
• Judge Prompt
• Version des Evaluator-Codes

Wenn sich einer dieser Werte ändert, wird Ihr Vorher-Nachher-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 genutzt wird.

CI gaten

Eine fehlschlagende Metrik muss zu einem fehlschlagenden Build führen, sonst ist die Eval Suite nur ein Dashboard, das niemand liest.

Der Test sollte den aktuellen Agenten gegen den Golden Input erneut ausführen. Er sollte nicht lediglich den alten fehlgeschlagenen Trace wiedergeben (Skizze; die ausführbare Version befindet sich im begleitenden 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, zu erkennen, dass die nächste Version des Agents einen alten Fehler wiederholt – nicht darin, den Fehler selbst zu archivieren.

Den Judge kalibrieren, bevor Sie ihm vertrauen

LLM-as-Judge ist hilfreich. Gleichzeitig kann man sich damit leicht selbst täuschen.

G-Eval evaluiert drei Meta-Evaluation-Benchmarks. Dabei handelt es sich um SummEval, das auf News Summarization mit CNN/DailyMail basiert, Topical-Chat, einen Knowledge-Grounded-Dialogue-Benchmark, und QAGS, das die faktische Konsistenz von CNN/DailyMail- und XSum-Summaries prüft. Mit GPT-4 als Backbone erreichte G-Eval-4 bei 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-maliges Sampling, weil dieses Model sie im Experiment nicht offenlegte. Ein Hosted Model bietet möglicherweise keine nutzbaren Logprobs. Behalten Sie daher das Rubric bei, suggerieren Sie aber nicht, dass Sie die Probability Weighting des Papers reproduziert haben. Diese Ergebnisse vergleichen das Protokoll des Papers mit seinen NLG-Baselines auf diesen Benchmarks. Sie sprechen dafür, einen Judge mit explizitem Rubric zu testen, nicht für einen allgemeinen Ersatz automatischer Metriken oder eines Production-Agent-Trajectory-Benchmarks.

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

JudgeBench stellte Response-Paare zusammen, bei denen eine Antwort in überprüfbarem Wissen, Reasoning, Mathematik und Code objektiv falsch war. Mit einem einfachen Judge Prompt erzielte GPT-4o 50,9 % – kaum mehr als ein Münzwurf. Der stärkere Arena-Hard Prompt des Papers hob dasselbe Model nur auf 56,6 %. Der Austausch des Models unter diesem stärkeren Prompt war 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. Selbstbewusst vorgetragene, aber falsche Antworten bleiben für einen Judge schwierig, der vor dem Grading nicht reasoned.

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 ändern.

Wenn ein Judge erforderlich ist, sollte das Verdict strukturiert sein. 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.

Platzieren Sie Evidence Fields vor dem Score, wenn sich der Record dadurch leichter prüfen lässt. Die Feldreihenfolge ist Präsentation, keine Garantie für Reasoning. Ein Schema-valides Verdict kann weiterhin nicht unterstützte Evidenz oder einen unzuverlässigen Score enthalten. Testen Sie die Zuverlässigkeit des Judges durch Kalibrierung anhand menschlicher Labels, deterministische Validatoren und Transcript Review. CI kann ein stabiles JSON-Objekt diffen, prüft damit aber Inspectability und Shape, nicht die tatsächliche Einhaltung der Rubric-Schritte.

Ein strukturiertes Verdict kann außerdem die Kostenkurve verändern. Betrachten Sie ein günstigeres Model als Kandidaten, 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. Verwenden Sie es nur für Routinefälle, wenn es die von Ihrer Anwendung gesetzten Schwellenwerte erreicht. 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ünfstufige Skalen laden zu Scheingenauigkeit ein.
2. Labeln Sie 30 bis 50 Trajectories von Hand, bevor Sie das finale Rubric schreiben.
3. Messen Sie die Judge-Human-Übereinstimmung mit Cohens Kappa, einer Confusion Matrix sowie Positiv- und Negativ-Recall. Ein Judge, der immer „Pass“ sagt, verfügt über keine nützliche Trennschärfe. Kappa kann null oder undefiniert sein, wenn der Nenner der erwarteten Übereinstimmung null ist. Legen Sie eine explizite Policy für undefiniertes Kappa fest, bevor Sie die Metrik als Deployment-Gate verwenden.
4. Zerlegen Sie grobe Kriterien. „Hat der Agent vor dem Refund Tool Call die Identität verifiziert?“ ist besser als „War die Trajectory gut?“
5. Geben Sie das Verdict über ein SGR Schema mit Evidenz, fehlgeschlagenen Kriterien, Fehlermodus und Score aus.
6. Verwenden Sie nach Möglichkeit einen Judge aus einer anderen Model-Familie als der Generator.
7. Randomisieren Sie die Reihenfolge bei Pairwise-Vergleichen und mitteln Sie beide Richtungen.
8. Bestrafen Sie nicht unterstützte Länge im Rubric. 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 neu.

Für Scores mit hoher Tragweite sollten Sie statt eines einzelnen großen Judges eine kleine Jury verwenden. PoLL testete ein Panel kleinerer Judges aus disjunkten Model-Familien und aggregierte deren Verdicts. Über sechs Datasets hinweg entsprach das Panel den menschlichen Bewertungen besser als ein einzelner GPT-4 Judge. Außerdem vermied es den Self-Preference-Bias des einzelnen Judges und kostete mehr als siebenmal weniger. Behalten Sie Human Review für Entscheidungen bei, die Geld, Zugriff, Safety oder Compliance betreffen.

Wenn ein Judge bei Ihrer Aufgabe nur ein Kappa von 0,55 mit Menschen erreicht, verwenden Sie ihn nicht, um Deployments zu blockieren. Nutzen Sie ihn zum Sortieren von Review Queues. Liegt er bei ungefähr 0,75 und sind die Fehlerkosten moderat, lässt sich ein CI-Gate deutlich leichter verteidigen.

Guardrails blockieren inline, Online Evals beobachten danach

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

Guardrails laufen inline. Sie sind schnell und für den 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-Erkennung sind Classifier; betrachten Sie Misses daher als erwartbar und lassen Sie zusätzlich eine asynchrone Eval überwachen, was diese durchlassen.

Offline Evals laufen vor dem Release. Sie sind reproduzierbar. Sie gaten Prompts, Models, Tools, Retrievers und Policies gegen ein fixes Dataset.

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

Eine falsche Platzierung schadet in beiden Fällen:

• Ein Judge im Request Path fügt Latency und eine neue Flakiness-Quelle hinzu.
• Ein Guardrail, das auf asynchrones Scoring verschoben wird, lässt Policy-Verstöße bis zum User gelangen.

Für High-Volume-Systeme sollten Sie eine kleine Stichprobe mit einem stärkeren Judge und eine größere Stichprobe mit günstigeren Classifiers bewerten. Alarmieren Sie bei Clustern und Confidence Bounds, nicht bei einem einzelnen verrauschten Point Estimate.

Tool-Auswahl

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

Dies ist ein Author Snapshot, geprüft am 2026-08-16. Jeder Link verweist auf die aktuelle Dokumentation, die ich für die jeweilige Capability-Aussage verwendet habe. Plans, Lizenzen, API Keys, Provider-Zugriff und Infrastructure Requirements gelten weiterhin.

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

Empfehlungen nach Constraints:

• Wählen Sie Phoenix, wenn Self-Hosting, Privacy und OTel-kompatibles Tracing zwingend erforderlich sind und Ihr Team das Deployment betreiben kann.
• Wählen Sie Langfuse, wenn Sie zusätzlich Dataset-Versionierung und Experimente benötigen und den Storage Stack selbst betreiben oder die erforderlichen Add-ons kaufen können.
• Wählen Sie DeepEval, wenn Python-/pytest-CI-Pass-Fail das primäre Vertragsmodell ist.
• Wählen Sie Inspect AI, wenn die Hauptarbeit in Safety- oder Frontier-Agent-Evaluation in konfigurierbaren Sandboxes besteht.
• Wählen Sie LangSmith, wenn die LangChain-/LangGraph-Integration die Enterprise-Anforderung für Hybrid- oder Self-Hosted-Deployment überwiegt.
• Wählen Sie Braintrust, wenn Managed Pull-Request Feedback und Experiment-Vergleiche 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 nachrangig. Wenn Production-Fehler nicht zu Test Cases werden, bezahlen Sie größtenteils für Trace Storage.

Praktische Rollout-Checkliste

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

1. Zuerst historische Runs sammeln. Wenn der Agent bereits existiert, erfassen Sie Traces, Support Tickets, Bug Reports, Thumbs-Down-Sessions, manuelle QA-Transcripts und Dogfooding-Notizen, 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, Argumente, Tool Outputs, Errors, Token Counts, Latency, Cost, User Feedback, App Version, Prompt Version, Model Version, Tool-Schema-Version und den finalen Environment State. Verwenden Sie OpenTelemetry GenAI Conventions oder OpenInference-Style-Spans, wenn Sie Portabilität wünschen. Verwenden Sie Langfuse, LangSmith, Phoenix oder Braintrust, wenn Sie sofort eine Trace-UI und einen Dataset-Workflow benötigen.

3. Reale Fehler in Seed Cases überführen. Lesen Sie die Traces, bevor Sie sie von einem Model zusammenfassen lassen. 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 Fehlerfälle ab, etwa falsche Berechtigungen, fehlende Identity Checks, veraltete Tool Results, mehrdeutige Datumswerte, Retries nach Rate Limits und widersprüchliche Tool Outputs.

5. Synthetischen Cases erst nach Human Review vertrauen. Synthetische Beispiele eignen sich für Coverage, nicht für Truth. Kennzeichnen Sie sie mit source: synthetic und verlangen Sie, dass ein Reviewer das Expected Outcome freigibt. Führen Sie nach Möglichkeit einen Known-Good-Reference-Pfad aus und verwenden Sie unterschiedliche Model-Familien zum Generieren des Cases und zum Bewerten des Ergebnisses.

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

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

8. Einen SGR-geprägten Judge hinzufügen. Verwenden Sie ihn nur für den Teil, der Interpretation erfordert. Kalibrieren Sie ihn anhand menschlicher Labels. Wenn er im Calibration Set gute und schlechte Beispiele nicht trennen kann, korrigieren Sie das Rubric, bevor Sie ihn in CI integrieren.

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

Ihre erste Eval Suite wird auf banale Weise fehlerhaft sein. Shippen Sie sie trotzdem. Eine Suite, die Sie täglich ausführen, lässt sich leichter verbessern als ein perfektes Design-Dokument, das niemals einen fehlerhaften PR blockiert.

Referenzen

• Begleitendes Demo-Repository trace2evals
• LangChain – State of Agent Engineering
• Anthropic – Demystifying Evals for AI Agents
• Hamel Husain – A Field Guide to Rapidly Improving AI Products
• OpenTelemetry Semantic Conventions für generative AI-Systeme
• 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 – Datasets programmgesteuert erstellen und verwalten
• Braintrust – Experimente erstellen
• Phoenix LLM Evals
• Promptfoo GitHub Action Integration
• tau-bench: Ein Benchmark für Tool-Agent-User-Interaktion in realen Domänen
• 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