2026-06-10 · Aktualisiert 2026-07-22

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Bewertung von AI Agents in der Produktion: Vom Traces bis zu Test-Suiten

Ein Chatbot liefert Ihnen eine einzige Antwort zur Bewertung. Ein Agent hingegen stellt Ihnen einen gesamten Entscheidungsbaum zur Verfügung: Pläne, Tool Calls, Wiederholungsversuche sowie den Zeitpunkt, an dem er entschied, dass die Aufgabe abgeschlossen ist.

Dieser Unterschied erfordert eine andere Bewertungsmethode. Eine Endlösung kann zwar korrekt erscheinen, selbst wenn der Agent ein erforderliches Werkzeug übersprungen hat, einen Aufruf 17 Mal wiederholt hat, ein Ergebnis falsch interpretiert hat oder einen Pfad verfolgt hat, der von den Produktionsrichtlinien verboten wird. Die rein auf das Ergebnis ausgerichtete Bewertung verschleiert solche Fehler.

TL;DR: Agent Evals erfordern drei Ebenen: Ergebnismetriken, Trajektoriemetriken sowie Komponentenmetriken. Die Implementierung basiert auf folgendem Zyklus: Trace -> Benennung -> Clustering -> Doppelungserkennung -> versionierte Dataset -> CI-Prüfung -> kontinuierliche Überwachung. Für die Reihenfolge der Tools, Argumente, Schleifen sowie Invarianten sollten deterministische Prüfungen verwendet werden. LLM Judges sollen ausschließlich dort eingesetzt werden, wo die Prüfung von Interpretationen abhängt; dabei müssen diese Judges mithilfe von schema-gestütztem Reasoning (SGR)) strukturiert werden, und es ist erforderlich, sie vor dem Vertrauen darauf gegen menschliche Labels zu kalibrieren.

Warum Agent Evals unterschiedlich sind

Herkömmliche LLM Evals bewerten in der Regel nur ein Eingab-Ausgabepaar: Relevanz, Treue, Korrektheit, Sicherheit sowie gegebenenfalls Stil. Agents fügen hingegen Planning, Tool Calls, Wiederholungsversuche sowie Abschlussprüfungen hinzu, wodurch jeder Schritt zu einem potenziellen Versagenspunkt wird.

Erhalten Sie eine Rückerstattung für Agent. Die Transkription kann trotz fehlerhafter Trace-Werte dennoch ein gutes Ergebnis liefern:

lookup_order -> issue_refund -> final_answer

Die Ausgabe Eval ist erfolgreich. Eine Bahn Eval sollte hingegen fehlschlagen, da verify_identity wurde noch nie zuvor ausgeführt. issue_refund. Bei der Nutzung von Werkzeugen durch Agents dienen die reinen Antwort-Evals-Tests lediglich als Smoke Tests: Sie erkennen nur totale Funktionsstörungen, übersehen aber alle anderen Probleme.

Es gibt ein weiteres Problem: Fehler kumulieren sich. Wenn ein Workflow 20 erforderliche Schritte aufweist, von denen jeder unabhängig voneinander erfolgreich sein muss und jeder Schritt eine gleichbleibende Zuverlässigkeit von 95 % hat, liegt die Gesamterfolgsrate vom Anfang bis zum Ende bei etwa 36 %:

Daher kann der Agent bei isolierten Tests zwar solide erscheinen, bei den meisten vollständigen Ausführungen jedoch dennoch fehlschlagen. Der Fehler liegt in der Regel irgendwo dazwischen, und seine Identifizierung erfordert eine Sicht auf die Komponentenebene – nicht nur einen erneuten Blick auf das Ergebnis.

Zwei Forschungsteams haben hierzu Zahlen ermittelt.

tau-Bench Es werden Aufgaben für den Kundenservice in der Luftfahrtbranche sowie im Einzelhandel mit Agent bereitgestellt. Agent kommuniziert mit einem simulierten Benutzer, ruft APIs auf und muss dabei die geltenden Domänenrichtlinien einhalten. Nach dem Gespräch prüft der Bewertungsalgorithmus, ob die Datenbank den annotierten Zielzustand erreicht hat. Selbst eine plausibel klingende Transkriptversion mit fehlerhaften Datensätzen gilt als fehlgeschlagen.

Unter dieser Bewertungskriterie schaffte selbst GPT-4o weniger als die Hälfte der Aufgaben. Der Artikel stellte außerdem vor pass^k: Den gleichen Task ausführen k Zählt eine Durchführung nur dann, wenn der Agent in allen Fällen erfolgreich ist. k läuft.

Die im ersten Versuch noch akzeptablen Einzelhandelswerte fielen auf unter 25 % bei k = 8. Derselbe Agent musste dieselbe Aufgabe insgesamt acht Mal bewältigen und erzielte dabei überwiegend unterschiedliche Ergebnisse. Ein einmaliger Eval kann diese Inkonsistenz nicht aufzeigen.

MAST Die Studie untersucht, warum Agents fehlschlagen. Die Autoren annotierten mehr als 1.600 Ausführungsprotokolle Traces aus 7 gängigen multi-agent Frameworks und ordneten die Fehler in 14 wiederkehrende Muster ein. Zu dieser Klassifikation gehören vage Definitionen von Rollen im Systemdesign, ein Fall, in dem eine Komponente Agent die Ergebnisse einer anderen Komponente Agent ignoriert (inter-Agent-Divergenz), sowie das Erklären eines Erfolgs ohne Überprüfung des tatsächlichen Ergebnisses (fehlende Verifizierung). Solche Fehler betreffen die Prompts-Logik, die Orchestration-Strukturen sowie das Fehlen geeigneter Prüfmechanismen in den Harness. Da eine robustere Basis Model keinen Verifizierungsprozess ausführen kann, der ursprünglich gar nicht implementiert wurde, muss das Bewertungskonzept die entsprechenden Harness-Elemente im Zusammenhang mit den Model berücksichtigen.

Die Adoptionslücke

Laut der Umfrage von LangChain verfügen viele Befragte bereits über die Rohdaten für verbesserte Evals: 89 % gaben an, über einige Observability zu verfügen, während 52,4 % offline Evals ausführten und 37,3 % online Evals.

Dasselbe Status der Agent-Entwicklung Umfragen zeigen, dass 57,3 % der Befragten Agents bereits in der Produktion einsetzen. Bei der Frage, was die Produktion behindert, nannten 32 % die Qualität und 20 % Latency. Es handelt sich dabei um eine Umfrage unter den Kunden des Anbieters und nicht um eine Erhebung aller Agent-Teams, doch sie macht eine relevante Lücke zwischen der Sammlung von Trace-Daten und deren systematischer Bewertung sichtbar.

Dadurch geraten die Teams in einen unangenehmen Zwischenzustand: Sie können zwar nachträglich einen fehlerhaften Ablauf überprüfen, liefern dennoch denselben Fehler zweimal aus.

Jeder diagnostizierte Produktionsfehler muss einen Trace, eine Kennzeichnung, eine Zeile im Dataset sowie einen Bewertungsfaktor hinterlassen. Ein wiederholbarer Fehler gehört in das Regressionstestset.

Metriken nach Versagensmodus auswählen

Die geeignete Metrik hängt vom Ausfallmodus ab und nicht von Framework. Die sinnvolle Aufteilung umfasst drei Bereiche:

1. Ergebnis Evals gibt an, ob die Aufgabe erfolgreich war.
2. Bewegungsablauf Evals zeigt an, ob der Pfad gültig, effizient und regelkonform war.
3. Komponente Evals identifiziert, welche Werkzeug, Informationsabrufmechanismus, Unter-Agent-Komponente oder Entscheidungsschritt fehlerhaft war.

Jeder Scope kann vor der Veröffentlichung offline an festgelegten, wiederaufrufbaren Fallbeispielen ausgeführt werden oder online nach der Erstellung der Antwort an ausgewählten Produktionsszenarien Traces. Der untenstehende Abschnitt Guardrails erläutert diese Aufteilung im Detail. Für den offline-Betrieb Evals können Goldens erforderlich sein. Im online-Betrieb Evals sollten Invarianten, Verteilungen sowie asynchrone Überprüfungen bevorzugt werden, die außerhalb des Request-Pfads liegen.

Beginnen Sie mit deterministischen Metriken. Sie sind kostengünstig, schnell und weisen keinen Drift auf.

Richtigkeit von Tool-Aufrufen

Die Tool-Korrektheit vergleicht die aufgerufenen Tools mit den erwarteten Tools. Wählen Sie die Strenge bewusst aus:

• Exakte Übereinstimmung: Die Sequenz muss exakt übereinstimmen. Verwenden Sie dies, wenn die Reihenfolge entscheidend ist, zum Beispiel lookup_order -> verify_identity -> issue_refund.
• In-Ordnung-Match: Die erforderlichen Tools müssen in der korrekten relativen Reihenfolge auftreten, wobei zusätzliche, unbedenkliche Aufrufe zulässig sind.
• Jeglicher-Ordnung-Match: Die erforderlichen Tools müssen vorhanden sein, doch ihre Reihenfolge darf variieren.

Ein kleiner lokaler Scorer reicht bereits aus, um mit der Arbeit zu beginnen:

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 in_order Der Wert stellt die Recall-Rate der längsten gemeinsamen Teilfolge dar – also den Anteil der erforderlichen Sequenz, der im richtigen Aufbau erhalten blieb. Beachten Sie dabei, was dabei ausgeblendet wird: Unwichtige Aufrufe senken diesen Wert nicht, sodass ein Agent hier einen Wert von 1,0 erreichen kann, obwohl er doppelt so viele Aufrufe vornimmt wie nötig. Wenn zusätzliche Aufrufe Kosten verursachen oder den Zustand verändern, sollten Sie die Genauigkeit (Anzahl der korrekt abgewickelten Aufrufe geteilt durch die Gesamtanzahl der Aufrufe) gleichzeitig betrachten und beide Werte miteinander vergleichen. Die Recall-Rate zeigt die fehlenden Schritte auf, während die Genauigkeit die Abweichungen erkennen lässt.

Der Korrektheitsmetrik für Tools von DeepEval stellt dieselben Einstellmöglichkeiten über should_consider_ordering und should_exact_match.

Richtigkeit der Argumente

Die Verwendung des richtigen Tools mit falschen Argumenten ist oft schlimmer als die Verwendung des falschen Tools, da der Trace dann normal erscheint.

Bei einfachen Fällen wird JSON schema sowie die genauen Werte überprüft. Bei semantischen Fällen werden die erwarteten Argumente gespeichert und die Abweichungen bewertet:

{
    "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"
        }
    }
}

Ein Metrikwert, der nur den Tool-Namen enthält, kann dies nicht erfassen. 2026-06-17 wo die Richtlinie dies erfordert 2026-06-19. Der Dataset muss ebenfalls Argumente speichern.

Der mit Dataset verbundene Wert ist parameter-match: der Anteil an erwarteten (tool, key, value) Dreifacht die Anzahl der korrekten Antworten von Agent.

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

Genaue Gleichheit ist geeignet für IDs, Enums und Datumswerte. Für Freitexte und Fließkommazahlen hingegen ist sie unangemessen, da == Markiert eine richtige Antwort als falsch. Bewerten Sie diese Felder nach ihren eigenen Kriterien: eine normalisierte Zeichenkettenübereinstimmung, eine Datumsanalyse sowie eine numerische Toleranz. Die Metrik bleibt unverändert; nur der Vergleichsmechanismus pro Feld wechselt.

Effizienz, Schleifen und Sackgassen

Ein Agent, der die Aufgabe nach fünf überflüssigen Tool Calls abgeschlossen hat, weist weiterhin ein Planning-Problem auf und ist außerdem aufwändiger in der Ausführung.

Günstige Signale, mit denen Sie beginnen sollten:

• Rate der redundanten Aufrufe: Dasselbe Tool Calls mit denselben Argumenten wird mehr als zweimal wiederholt.
• Anomalien in der Trace-Struktur: plötzliche Anstiege bei der Tiefe, der Anzahl der Werkzeugaufrufe, der Token-Anzahl, den Latency-Werten oder den Kosten.
• Konvergenz des Pfades: Wie nahe liegt die Ausführung dem kürzesten bekannten gültigen Pfad für die Aufgabe.
• Richtigkeit der Beendigung: Ob der Agent vorzeitig gestoppt wurde, nach einem Erfolg weitergearbeitet hat oder ohne die erforderliche Zustandsänderung einen Erfolg gemeldet hat.
• Befolgung des Plans: Wenn der Agent vor dem Handeln einen Plan erstellt, muss überprüft werden, ob der Trace diesem Plan folgt. Ein guter Plan, der ignoriert wird, sowie ein schlechter Plan, dem perfekt gefolgt wird, scheitern jeweils aus entgegengesetzten Gründen; der Unterschied zwischen dem Plan und dem Trace zeigt an, welcher Fall vorliegt.

Führen Sie diese Schritte immer dann aus, wenn möglich, vor einem Judge. Ein Loop-Detektor befindet sich einige Zeilen über dem Trace. Er benötigt keinen Model.

Aufgabenabschluss und Bewertung der Ergebnisse

Von Anfang bis Ende stellt sich die Frage: „Hat der Benutzer genau das erhalten, was er angefordert hat?“

Zwei Muster funktionieren am besten:

• Bewertung der zielorientierten Aufgabenerfüllung ohne Referenzdaten: Das Ziel wird aus der Eingabe extrahiert und Judge ob der Trace plus die endgültige Antwort hat dies erreicht. Dies funktioniert im Online-Betrieb, da der Produktivverkehr selten „goldene“ Ausgaben aufweist.
• Bewertung des Umgebungszustands: Man vergleicht die endgültigen Datenbankzeilen, Dateien, Tickets, Buchungen oder Datensätze mit einem annotierten Zielzustand. Dies ist robuster als das Abgleichen von Transkripten, weil Agents Es ist möglich, gültige Pfade zu finden, die Sie nicht aufgeführt haben.

Die zweite Option ist vorteilhafter, wenn Sie sie selbst implementieren können. Der endgültige Zustand stellt den Vertrag dar. Die Transkription dient lediglich als Beweismittel.

Zwei Bedenken trüben die Objektivität dieser Bewertungsmethode – beide stammen vom Benchmark, der die Einführung von Zustandsbewertungen populär gemacht hat. tau-bench kann einem Agent, der bei bestimmten sogenannten No-Op-Aufgaben keine Ausführung vornimmt, dennoch eine bestandene Bewertung erteilen, da der Ausgangszustand bereits das Ziel erfüllte. Zudem berichtete Anthropic über einen Lauf von Opus 4.5, bei dem eine Aufgabe im tau2-bench aufgrund eines Mechanismusfehlers „fehlschlug“, obwohl dies tatsächlich das bessere Ergebnis für den Benutzer darstellte. Zustandsbewertungen sind zwar überlegen gegenüber Transkriptvergleichen, doch der Zielzustand bleibt weiterhin eine manuelle Annotation – und Annotationen weisen Fehler auf. Prüfen Sie daher insbesondere die Fälle, die zu leicht bestehen, nicht nur diejenigen, die fehlschlagen.

Der Trace-zu-Eval-Flywheel

Beheben Sie Produktionsstörungen im Bergbau, bevor Sie weitere Eval Fälle durchdenken.

Die Schleife:

1. Erfassen Sie den vollständigen Trace.
2. Kennzeichnen Sie, was fehlgeschlagen ist.
3. Gruppieren Sie ähnliche Fehler.
4. Behalten Sie pro Cluster ein repräsentatives „Gold-Exemplar“ bei.
5. Führen Sie eine Versionskontrolle für den Dataset durch.
6. Führen Sie die Überprüfung im CI-Umfeld aus.
7. Halten Sie weiterhin die Bewertung der ausgewählten Produktionsdaten des Traces online.

Das begleitende Repository trace2evals führt den vollständigen Loop für einen fehlerhaften Support Agent aus. Dabei werden OpenTelemetry GenAI Spans erfasst, Fehler mithilfe deterministischer Regeln erkannt, Fälle in ein versioniertes Golden Dataset dedupliziert und jedes dieser Golden-Exemplare im CI erneut ausgeführt. Die standardmäßige Skriptlösung erfordert keinen API-Schlüssel, sodass make demo führt den Prozess offline aus.

Fehleranalyse bei Minenversagen

Hamel Husain und Shreya Shankar erklären eine Fehleranalyse Workflow für genau diesen Schritt; Hamels Leitfaden Er geht die Prozesse Schritt für Schritt durch. Die ersten beiden Schritte leihen ihre Bezeichnungen aus der qualitativen Forschung, doch die Methode selbst ist einfach: Man liest Traces, macht Notizen und benennt die Muster.

1. Offenes Kodieren: Lesen Sie 30 bis 50 echte Traces-Beispiele und fassen Sie frei formulierte Notizen darüber zusammen, was schiefgelaufen ist.
2. Axiales Kodieren: Gruppieren Sie diese Notizen in 5 oder 6 benannte Kategorien für Fehlerrisiken.
3. Markieren Sie alles entsprechend der Taxonomie.
4. Erstellen Sie Metriken für die größten Gruppen.

Beginnen Sie nicht mit Labels wie reasoning_issue oder tool_problem. Sie sind zu vage, um getestet zu werden. Verwenden Sie Labels wie missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429, oder stopped_before_database_update. Ein Label, das Ihnen exakt angibt, was der Regressionstest überprüfen soll.

Duplikate entfernen, bevor Sie in die Produktion bringen

Der Trace-Mining-Loop birgt ein Problem: Er fügt ständig alle fehlerhaften Trace hinzu. Dadurch entsteht ein Dataset, der groß, ressourcenintensiv und eng gefasst ist. Er übernimmt nahezu identische Fälle aus dem März, während er die neue Ausprägung desselben Fehlers im Juni übersieht.

Gruppiere zunächst die Elemente. Wähle pro Cluster einen repräsentativen „Golden“ aus. Speichere die damit verbundenen Trace-IDs in den Metadaten, damit ein Prüfer später die Produktionsbelege überprüfen kann.

Falls ein Fehlercluster nach einer Korrektur erneut auftritt, bedeutet dies, dass der Regressionsfall nicht generalisiert werden konnte. Gruppieren Sie die Fälle erneut und erweitern Sie stattdessen den „Golden Set“, anstatt 15 zusätzliche Beispiele hinzuzufügen.

Versionierung des Dataset

Die Versionierung von Datasets erfolgt auf dieselbe Weise wie bei der Versionierung von Prompts und Code. Immer dann, wenn sich bedeutende Änderungen ergeben (Model, Prompt, Tool Schema, Judge Prompt oder im Verhalten der Anwendung), sollte man die gleiche Dataset Version vor und nach den Änderungen ausführen.

Das CI-Gate sollte folgende Werte festlegen:

• Dataset-Version
• Anwendungsversion
• Prompt-Version
• Judge Model
• Judge Prompt
• Evaluator-Codeversion

Wenn eine dieser Änderungen vorgenommen wird, wird der Vergleich vor und nach unklar. Ein goldens-v3.json Bei kleinen Datenmengen funktioniert eine Datei im Git-System problemlos. Die tool-eigene Snapshots-Funktionalität in Langfuse, Phoenix, Braintrust oder LangSmith ist dann nützlich, wenn die Dataset-Arbeit kooperativ gestaltet wird.

Gate CI

Ein fehlerhafter Metrikwert muss zu einem fehlerhaften Build führen – andernfalls ist das Eval-Suite lediglich ein Dashboard, das niemand liest.

Der Test sollte den aktuellen Agent erneut mit dem Referenzeingang ausführen. Er darf nicht lediglich den alten, fehlgeschlagenen Trace erneut ablaufen lassen:

@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 ist leicht falsch zu verstehen. Die Aufgabe des Dataset besteht darin, zu erkennen, ob die nächste Version von Agent denselben alten Fehler erneut aufweist, und nicht darin, den Fehler selbst zu archivieren.

Kalibrieren Sie den Judge, bevor Sie ihm vertrauen

LLM als Judge ist hilfreich. Gleichzeitig ist es jedoch auch einfach, sich selbst zu täuschen.

G-Eval Es bittet einen Judge darum, vor der Bewertung ausdrückliche Bewertungsschritte festzulegen. Anschließend wird jede Bewertungsebene nach ihrem Token-Wahrscheinlichkeit gewichtet und summiert ($\text{score} = \sum_i p(s_i)\,s_i$). Dieses Verfahren ermöglichte eine genauere Erfassung menschlicher Bewertungen im Vergleich zu den älteren automatischen Metriken, die es ersetzt hat.

Der wahrscheinlichkeitsgewichtete Schritt benötigt die Judge logprobs, die von einigen gehosteten Models-Systemen nicht bereitgestellt werden. Dennoch ermöglicht das übergeordnete Ergebnis weiterhin den Einsatz eines expliziten Bewertungswegs anstelle einer reinen Punktzahl.

MT-Bench Es zeigte sich, dass GPT-4 in etwa genauso oft den Präferenzen von Menschen zustimmte wie Menschen untereinander, was dazu beitrug, LLM als Maßstab für die Bewertung des Mainstreams zu nutzen. Spätere Studien machten Positionierungs-, Längen- sowie Selbstpräferenzverzerrungen sichtbar. Die Judge-Werte können außerdem schwanken, wenn sich die Prompt- oder Model-Version ändert.

JudgeBench Es wurden Antwortpaare erstellt, bei denen eine der Antworten aufgrund überprüfbarer Fakten, Reasoning, mathematischer Berechnungen sowie Codeaussagen objektiv falsch ist. Der GPT-4o erzielte auf dieser Testmenge einen Wert von 50,9 %, während der leistungsstärkste getestete Judge-Modell etwa 64 % erreichte. Zuverlässige, aber dennoch falsche Antworten stellen weiterhin ein schwieriges Szenario für Model-basierte Judges-Systeme dar.

Betrachten Sie den Judge als Messinstrument: Kalibrieren Sie ihn anhand menschlicher Etiketten, bevor er Bewertungen vornimmt, und überprüfen Sie ihn erneut, sobald sich die Judge Model oder Prompt ändern.

Wenn ein Judge erforderlich ist, muss das Ergebnis strukturiert dargestellt werden. Schema-gestütztes Reasoning (SGR) definiert den Reasoning-Pfad des Judge als Pydantic-Schema. Anschließend erfordern Structured Outputs oder Constrained Decoding Felder wie evidence, passed_criteria, failed_criteria, failure_mode, und score.

Platzieren Sie die Beweisfelder vor der Bewertung. Anschließend wendet das Judge bei jeder Ausführung und in allen kompatiblen Model denselben, im Voraus definierten Bewertungsablauf in derselben Feldreihenfolge an. Ein Prüfer kann stattdessen auf die benannten Felder zugreifen, anstatt einen Absatz zu analysieren. CI kann einen stabilen JSON-Objekt vergleichen, während die Calibration-Menge angezeigt wird, in welcher Bewertungsstufe es zu Uneinigkeiten mit der menschlichen Beschriftung kam.

Es kann außerdem die Kostenkurve verändern. Betrachten Sie einen günstigeren Model als Kandidaten und nicht als automatische Alternative. Führen Sie dessen Testung mit derselben von Menschen gelabelten Calibration-Sammlung durch. Vergleichen Sie dabei seine Übereinstimmungsrate, die False-Pass-Rate sowie die False-Fail-Rate mit denen des umfangreicheren Judge. Verwenden Sie es nur für Routinefälle, sofern es die von Ihrer Anwendung festgelegten Schwellenwerte erfüllt. Behalten Sie den umfangreicheren Judge für Fälle mit Unstimmigkeiten, Hochrisikosituationen oder Ausführungen von Calibration bei.

Standard-Checkliste für die Judge-Hygiene:

1. Wählen Sie soweit wie möglich ein binäres Ergebnis „Bestanden“/„Nicht bestanden“. Fünfstufige Skalen führen zu einer künstlichen Präzisionswahrnehmung.
2. Beschriften Sie vor der Erstellung des endgültigen Bewertungsschemas 30 bis 50 Beispieldaten manuell.
3. Messen Sie die Judge-Mensch-Maschine-Übereinstimmung mithilfe von Cohens Kappa (einer auf Zufall korrigierten Übereinstimmungsrate, wodurch ein Judge, der stets „Bestanden“ ausweist, nahe Null liegt) oder einfach über TPR/TNR.
4. Unterteilen Sie die groben Kriterien. Die Frage „Hat der Agent die Identität vor der Rückerstattung Tool Call überprüft?“ ist aussagekräftiger als die allgemeine Frage „Ist die Antwortqualität gut?“.
5. Geben Sie das Urteil über ein SGR-Schema mit Belegen, fehlgeschlagenen Kriterien, Fehlerursachen sowie der erreichten Punktzahl wieder.
6. Verwenden Sie bei Bedarf einen Judge aus einer anderen Model-Familie als der Generator.
7. Randomisieren Sie die Paarreihenfolge und bilden Sie den Durchschnitt aus beiden Richtungen.
8. Bestrafen Sie im Bewertungsschema unzulässig lange Antworten – eine längere Antwort bedeutet nicht automatisch eine bessere.
9. Fixieren Sie die Werte von Judge, Model, Prompt, Dataset sowie das Schema- und Anwendungsverzeichnis.
10. Kalibrieren Sie erneut nach Änderungen an Model, Prompt, Tools, Richtlinien oder Schemata.

Bei besonders kritischen Bewertungen sollte anstelle eines großen Judge ein kleineres Gremium eingesetzt werden. PoLL Es wurde eine Gruppe kleinerer Judges getestet, die aus unabhängigen Model-Familien stammten, und ihre Entscheidungen zusammengeführt. Über einen Zeitraum von sechs Datasets folgte diese Gruppe den menschlichen Beurteilungen genauer als ein einzelner GPT-4 Judge. Zudem vermied sie den Selbstpräferenzbias des einzelnen Judge und war dabei mehr als sieben Mal kostengünstiger. Lassen Sie menschliche Prüfungen bei Entscheidungen vornehmen, die finanzielle Aspekte, Zugriffsmöglichkeiten, Sicherheit oder Compliance betreffen.

Falls ein Judge bei Ihrer Aufgabe eine Kappa-Wert von 0,55 gegenüber Menschen aufweist, sollten Sie ihn nicht zur Blockierung von Deploys einsetzen. Nutzen Sie ihn vielmehr zur Sortierung der Überprüfungsqueues. Liegt der Wert hingegen nahe bei 0,75 und die Kosten im Falle eines Fehlers sind moderat, ist es deutlich einfacher, eine CI-Gate-Prüfung zu rechtfertigen.

Guardrails-Blöcke inline einbinden, online Evals und anschließend überwachen

Menschen verwechseln diese oft, weil beide Arten Werte erzeugen. Der Unterschied liegt in der Platzierung: entweder inline im Anfragenpfad, vor der Freigabe oder nach der Antwort.

Guardrails werden inline ausgeführt. Sie sind schnell, deterministisch und für den Benutzer sichtbar. Ein Guardrail kann einen Tool Call blockieren, personenbezogene Daten maskieren, Prompt Injection abweisen oder eine Wiederholung erzwingen, bevor die Antwort Ihr System verlässt. Ein falsch positives Ergebnis stellt einen Produktionsfehler dar.

Offline Evals-Ausführungen vor der Veröffentlichung. Sie sind reproduzierbar. Sie stellen sicher, dass Prompts, Models, Tools, Retrieval-Systeme sowie Richtlinien gegenüber einer festgelegten Dataset abgesichert sind.

Online Evals-Ausführungen finden nach der Antwort statt, in der Regel anhand von ausgewählten Datenmengen. Da sie sich nicht auf dem Latency-Pfad befinden, können sie langsamere LLM Judges-Prozesse nutzen. Ihre Aufgabe besteht darin, Abweichungen zu erkennen, neue Ausfallcluster zu identifizieren und die Ergebnisse an den nächsten offline laufenden Dataset weiterzuleiten.

Wenn die Platzierung falsch ist, führt das in jedem Fall zu Problemen:

• Ein Judge im Anfragenpfad führt zu zusätzlichem Latency sowie zu einer neuen Quelle für Instabilität.
• Ein auf asynchrone Bewertung verlagertes Guardrail ermöglicht es, Verstöße gegen Richtlinien den Nutzern zugänglich zu machen.

Bei Systemen mit hohem Durchsatz sollte eine kleine Stichprobe mit einem leistungsstärkeren Judge bewertet werden, während für größere Stichproben günstigere Klassifikatoren eingesetzt werden können. Es sollten Alarme bei Clusterbildung sowie bei den Konfidenzintervallen ausgelöst werden, anstatt sich auf eine störende Schätzung einzelner Punkte zu verlassen.

Werkzeugauswahl

Kein einzelnes Tool übernimmt die gesamte Pipeline. Die anspruchsvollsten Technologiestacke setzen zwei Komponenten ein: einen Trace-Speicher sowie einen CI/Eval-Ausführer.

Die Hinweise zu den Kompromissen beschreiben lediglich die Quellen der Kosten, nicht deren genaue Natur. Die Preisseiten können sich ändern, und die Anbieter berücksichtigen unterschiedliche Faktoren wie Traces, Beobachtungen, Spans, Bewertungswerte, Nutzerzahlen, die Retention-Rate oder die verarbeiteten Daten. Überprüfen Sie daher vor einer endgültigen Entscheidung immer die aktuellen Preise.

Entscheidungshilfen:

• Es ist erforderlich, einen selbst gehosteten Tracing mit OTel-Portabilität zu nutzen: Beginnen Sie mit Phoenix oder Langfuse.
• Für ein auf Code ausgerichtetes CI-Gate ist DeepEval die erste Wahl.
• Da bereits auf LangGraph gesetzt wird, ist LangSmith äußerst praktisch.
• Für eine verwaltete Überprüfung von PR-Regressionen ist Braintrust unschlagbar.
• Bei Schwerpunkt auf Sicherheit und Red-Team-Szenarien eignet sich Promptfoo am besten.
• Für Forschung im Bereich Sicherheit oder kontrollierte Benchmark-Arbeiten ist Inspect AI die geeignetere Lösung.

Die Wahl des Tools spielt nur eine untergeordnete Rolle. Wenn Produktionsfehler nicht zu Testfällen werden, zahlt man im Wesentlichen für die Speicherung bei Trace.

Eine praktische Checkliste für die Einführung

Erstellen Sie zunächst die Beweismittel Pipeline, bevor Sie den Metriken-Stack erweitern. Beginnen Sie damit, zu entscheiden, woher die Beispiele stammen sollen.

1. Sammeln Sie zunächst die historischen Ausführungen ein. Falls der Agent bereits vorhanden ist, holen Sie vor einer Änderung der Implementierung Traces, Support-Tickets, Fehlerberichte, negative Bewertungen Sessions, manuelle QA-Transkripte sowie Notizen aus dem internen Einsatz ein. Wenn der Agent noch nicht existiert, protokollieren Sie ab dem ersten Tag jede Prototypen- und manuelle Testausführung.

2. Instrumentieren Sie die Trace-Struktur. Erfassen Sie Nachrichten, Tool Calls, Argumente, Ausgaben von Tools, Fehler, Token-Zählwerte, Latency, Kosten, Nutzerfeedback, die App-Version, Prompt-Version, Model-Version, Tool Schema-Version sowie den endgültigen Zustand der Umgebung. Verwenden Sie dazu OpenTelemetry Konventionen für Generative KI oder im OpenInference-Stil Spans, falls Sie Portabilität wünschen. Verwenden Sie Langfuse, LangSmith, Phoenix oder Braintrust, wenn Sie sofort eine Trace Benutzeroberfläche sowie Dataset Workflow benötigen.

3. Reale Ausfälle in Seed-Cases umwandeln. Lesen Sie zuerst den Traces, bevor Sie diese mit einem Model zusammenfassen. Für jeden nützlichen Ausfall sollten Eingabedaten, die Quell-Trace-ID, der erwartete Zustand, die erwarteten Tool-Invarianten, der Ausfallmodus, die Schweregrad sowie eine Anmerkung des Prüfers gespeichert werden. Langfuse kann Dataset-Elemente wieder auf die Produktionsumgebung Traces verknüpfen; LangSmith hingegen kann aus protokollierten Ausführungen Datasets erstellen. Bewahren Sie die Quellverlinkung auf, damit der Fall weiterhin nachvollziehbar bleibt.

4. Falls keine Historie vorliegt, werden Cold-Start-Fälle erzeugt. Man sollte einen LLM bitten, Aufgaben auf der Grundlage von Produktanforderungen, Richtlinien, Tool Schemas, State Machines sowie unterstützender Makros zu entwerfen. Dabei sollten sowohl erfolgreiche Abläufe als auch Fehlerfälle berücksichtigt werden – beispielsweise fehlerhafte Berechtigungen, fehlende Identitätsprüfungen, veraltete Tool Results-Werte, unklare Datumsangaben, Wiederholungsversuche nach Rate-Limits sowie widersprüchliche Ausgaben von Tools.

5. Vertrauen Sie synthetischen Fallbeispielen nicht, bevor sie von einem Menschen überprüft wurden. Synthetische Beispiele sind nützlich für die Abdeckungsanalyse, aber nicht für die Überprüfung der Richtigkeit. Kennzeichnen Sie sie entsprechend. source: synthetic und erfordern, dass ein Prüfer das erwartete Ergebnis freigibt. Führen Sie bei Möglichkeit einen bekannten Referenzpfad aus und verwenden Sie unterschiedliche Model-Familien, um den Fall sowie Judge das Ergebnis zu erzeugen.

6. Entwickeln Sie einen kleinen, ausgewogenen Dataset. Dieser sollte Erfolgsfälle, Misserfolge, Ablehnungen, Randfälle, Fälle mit langen Dialogabläufen, fällenspezifische Szenarien sowie gültige alternative Handlungswege umfassen. Es darf sich dabei nicht um das „perfekte, ursprüngliche Transkript“ handeln; vielmehr muss das Referenzmodell das erforderliche Ergebnis, zulässige Invarianten sowie mögliche Fehlermuster kodieren.

7. Fügen Sie zunächst deterministische Überprüfungen hinzu. Die erforderliche Reihenfolge der Tools – wobei die Reihenfolge selbst eine Richtlinie darstellt – umfasst die Verarbeitung der erforderlichen Argumente, die Validierung des Schemas, die Vergleich der Endzustände, die Begrenzung von Schleifen, die Einhaltung der Obergrenzen für Token und Latency sowie die berücksichtigung von task-spezifischen Invarianten, bevor jegliche Judge ausgeführt werden.

8. Fügen Sie einen SGR-förmigen Judge hinzu. Verwenden Sie ihn ausschließlich für den Teil, der einer Interpretation bedarf. Kalibrieren Sie ihn anhand menschlicher Labels. Sollte er es nicht schaffen, gute und schlechte Beispiele in der Calibration-Sammlung voneinander zu trennen, müssen Sie die Bewertungskriterien vor der Einbindung in den CI-Prozess korrigieren.

9. Schließen Sie den Loop. Führen Sie das kleine Offline-Testset im CI aus, starten Sie das größere Testset vor der Veröffentlichung, bewerten Sie den ausgewählten Produktivverkehr online und führen Sie wiederkehrende Online-Fehlercluster zurück in den Offline-Betrieb Dataset.

Ihre erste Eval-Suite wird auf langweilige Weise Fehler aufweisen. Schicken Sie sie dennoch raus. Eine Suite, die täglich genutzt wird, lässt sich leichter beheben als ein perfektes Designdokument, das niemals einen fehlerhaften Pull Request blockiert.

Referenzen

• Demonstrationsrepositorium für trace2evals
• LangChain – Der Stand der Agent-Entwicklung
• Anthropic – Aufklärung zu Evals für AI Agents
• Hamel Husain – Ein Praxisleitfaden zur schnellen Verbesserung von AI-Produkten
• OpenTelemetry semantische Konventionen für generative AI-Systeme
• Correctheit der DeepEval-Tool
• DeepEval-Aufgabenabschluss
• Schema-gestütztes Reasoning auf vLLM: Structured Outputs unter Verwendung von xgrammar und Pydantic
• Langfuse Datasets und Versionsverwaltung
• LangSmith – Erstellung und Verwaltung von Datasets auf programmatische Weise
• Braintrust – systematische Bewertung durchführen
• Phoenix LLM Evals
• Integration von Promptfoo in GitHub Actions
• tau-bench: Ein Benchmark für die Interaktion von Tool-Agent-Benutzern in realen Anwendungsbereichen
• Warum versagen Multi-Agent LLM-Systeme?
• G-Eval: Bewertung von NLG-Anwendungen mithilfe von GPT-4 unter Berücksichtigung einer besseren Abstimmung auf menschliche Anforderungen
• Die Bewertung von LLM als Judge mithilfe von MT-Bench und Chatbot Arena
• Die Ersetzung von Judges durch „Juries“: Bewertung von LLM-Generationen mithilfe eines Panels aus vielfältigen Models.
• JudgeBench: Ein Benchmark zur Bewertung von auf LLM basierenden Judges-Systemen
• Der Selbst-Präferenz-Bias bei LLM als Judge