Zum Inhalt

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Bewertung von AI Agents in Produktion: Von Traces zu Test-Suites

Eine Chatbot-Antwort ist eine Zeile. Ein Agent-Run ist ein Baum.

Dieser Unterschied durchbricht viele etablierte Evaluationsgewohnheiten. Die finale Antwort kann gut aussehen, obwohl der Agent ein erforderliches Tool übersprungen, denselben Call 17-mal wiederholt, ein Tool-Ergebnis falsch gelesen oder einen Pfad genommen hat, der in Produktion unzulässig wäre. Wenn du nur die Antwort bewertest, verpasst du den Teil, in dem das System tatsächlich versagt hat.

Kurzfassung: Agent-Evals brauchen drei Ebenen: Outcome-Metriken, Trajektorienmetriken und Komponentenmetriken. Baue um diesen Loop herum: trace -> label -> cluster -> dedupe -> versioned dataset -> CI gate -> online monitoring. Nutze deterministische Checks für Tool-Reihenfolge, Argumente, Loops und Invarianten. Nutze LLM-Judges nur dort, wo der Check von Interpretation abhängt, forme diese Judges mit Schema-Guided Reasoning (SGR) und kalibriere sie gegen menschliche Labels, bevor du ihnen vertraust.

Warum Agent-Evals anders sind

Traditionelle LLM-Evals bewerten meist ein einzelnes Input-Output-Paar: Relevanz, Faithfulness, Korrektheit, Sicherheit, vielleicht Stil. Agents fügen Planung, Tool-Calls, Retries und Termination-Checks hinzu, und jeder Schritt ist eine neue Fehlerstelle.

Nimm einen Refund-Agenten. Das Transkript kann gut enden, obwohl der Trace falsch ist:

lookup_order -> issue_refund -> final_answer

Die Output-Eval besteht. Eine Trajectory-Eval sollte fehlschlagen, weil verify_identity nie vor issue_refund ausgeführt wurde. Für toolnutzende Agents sind reine Answer-Evals nur Smoke-Tests: Sie finden Totalversagen und übersehen alles andere.

Es gibt ein zweites Problem: Fehler kumulieren. Wenn ein 20-Schritte-Workflow in jedem Schritt 95 % zuverlässig ist, landet seine End-to-End-Erfolgsrate trotzdem nur bei etwa 36 %:

\[ 0.95^{20} \\approx 0.36 \]

Der Agent kann also in isolierten Checks solide aussehen und trotzdem in den meisten vollständigen Runs scheitern. Der Bruch liegt meist irgendwo in der Mitte, und um ihn zu finden, braucht man Sichtbarkeit auf Komponentenebene, nicht noch einen Blick auf die Antwort.

Eine Zeile versus ein Baum: Wo Agent-Fehler verborgen sind

Zwei Forschungsteams haben das quantifiziert.

tau-bench ist ein Benchmark, in dem ein Agent Airline- und Retail-Customer-Service-Aufgaben bearbeitet: Er spricht mit einem simulierten User, ruft APIs auf und muss dabei die Domänenrichtlinien einhalten. Die Bewertung ignoriert das Transkript. Nachdem die Konversation beendet ist, prüft der Benchmark, ob die Datenbank den annotierten Zielzustand erreicht hat. Ein höflicher, plausibel klingender Run, der die falschen Zeilen hinterlässt, fällt also trotzdem durch. Unter diesem Bewertungsverfahren war selbst GPT-4o bei weniger als der Hälfte der Aufgaben erfolgreich. Das Paper führte außerdem pass^k ein: Führe dieselbe Aufgabe k-mal aus und zähle nur dann als bestanden, wenn der Agent in allen k Runs erfolgreich ist. Retail-Scores, die für einen einzelnen Versuch noch akzeptabel aussahen, fielen bei k = 8 unter 25 %. Gleicher Agent, gleiche Aufgabe, acht Runs, meist unterschiedliche Outcomes. Diese Inkonsistenz bleibt unsichtbar, wenn deine Eval jeden Fall nur einmal ausführt.

MAST stellt eine andere Frage: nicht wie oft Agents scheitern, sondern warum. Die Autor:innen annotierten mehr als 1.600 Execution-Traces aus 7 populären Multi-Agent-Frameworks und sortierten die Fehler in 14 wiederkehrende Modi. Fast keiner davon ist „das Modell hat eine falsche Antwort gegeben“. Es sind Dinge wie vage Rollendefinitionen (Systemdesign), ein Agent ignoriert, was ein anderer ihm gesagt hat (Inter-Agent-Misalignment), oder Erfolg wird erklärt, ohne das Ergebnis zu prüfen (keine Verifikation). Die meisten Fehler stecken im Harness: in den Prompts, der Orchestrierungslogik, den fehlenden Checks. Ein stärkeres Basismodell verkleinert diese Zahlen, aber es kann keinen Verifikationsschritt reparieren, der nie gebaut wurde. Deshalb musst du den Harness evaluieren, nicht nur das Modell darin.

Die Adoptionslücke

Die meisten Teams haben das Rohmaterial für bessere Evals bereits. Sie haben Traces. Sie haben daraus nur noch keine Tests gemacht.

Die Umfrage State of Agent Engineering von LangChain ist die klarste öffentliche Momentaufnahme dieser Lücke. Sie berichtet, dass 57,3 % der Befragten bereits Agents in Produktion haben, 89 % irgendeine Form von Observability besitzen, 52,4 % Offline-Evals ausführen und 37,3 % Online-Evals ausführen. Und auf die Frage, was die Produktion blockiert, nannten 32 % der Befragten Qualität, vor Latenz mit 20 %. Das, was Evals messen, ist genau das, woran Teams hängen bleiben.

Damit bleiben Teams in einem unbequemen Zwischenzustand: Sie können einen schlechten Run im Nachhinein inspizieren und denselben Fehler trotzdem zweimal ausliefern.

Eine Regel behebt das: Jeder diagnostizierte Produktionsfehler sollte einen Trace, ein Label, eine Dataset-Zeile und einen Scorer hinterlassen. Wenn er wieder passieren kann, gehört er in die Regressions-Suite.

Metriken nach Fehlermodus wählen

Die richtige Metrik hängt vom Fehlermodus ab, nicht vom Framework. Die nützliche Aufteilung hat drei Bereiche:

  1. Outcome-Evals beantworten, ob die Aufgabe erfolgreich war.
  2. Trajectory-Evals beantworten, ob der Pfad valide, effizient und policy-konform war.
  3. Component-Evals beantworten, welches Tool, welcher Retriever, welcher Sub-Agent oder welcher Entscheidungsschritt versagt hat.

Drei Ebenen der Agent-Evaluation mit ihren Metriken

Jeder Bereich kann offline laufen (feste, reproduzierbare Fälle vor dem Release) oder online (gesampelte Produktions-Traces nach der Antwort); der Abschnitt zu Guardrails unten behandelt diese Trennung im Detail. Die Kurzfassung: Offline-Evals können Goldens voraussetzen, während Online-Evals Invarianten, Verteilungen und asynchrone Checks bevorzugen sollten, die nicht im Request-Pfad liegen.

Frage Metrikfamilie Offline-/Online-Vertrag Deterministisch oder Judge? Worauf achten?
Hat der Agent die richtigen Tools aufgerufen? Tool-Korrektheit: Exact-, In-Order- oder Any-Order-Match Exakte Goldens offline; Required-Tool-Invarianten und Anomalien online Deterministisch Exact Match bestraft valide alternative Pfade
Hat er sie mit den richtigen Inputs aufgerufen? Argument-Korrektheit, Schema-Validierung, Parameter-Match Erwartete Argumente offline; Schema-, Bereichs- und Policy-Checks online Beides Richtiges Tool plus falsche Argumente bleibt defekt
Hat er Schritte verschwendet? Schritt-Effizienz, Retry-Anzahl, Loop-Erkennung, Kosten und Latenz Step- und Loop-Budgets offline; Kosten- und Latenz-Drift online Meist deterministisch Hohe Task-Completion kann teures Umherirren verdecken
War die Aufgabe tatsächlich erfolgreich? Task Completion, Outcome-Grading, Final-State-Diff Simulator oder Golden State offline; Final State, User-Signal oder Async-Judge online Judge oder State-Check Wenn möglich den Umweltzustand bewerten
Hat er Kontext über Turns hinweg bewahrt? Multi-Turn-Fidelity, Rollenadhärenz, Gesprächsvollständigkeit Geskriptete Long-Horizon-Fälle offline; gesampelte lange Sessions online Judge Single-Turn-Tests sagen nichts über Turn 14
Hat er zum richtigen Zeitpunkt gestoppt? Termination-Korrektheit, verfrühter Erfolg, endlose Arbeit Szenariotests offline; Loop-, Timeout- und False-Success-Monitore online Beides „Done“ kann ein halluzinierter Zustand sein
Hat er Tool-Ergebnisse korrekt interpretiert? Tool-Result-Verständnis, Downstream-State-Checks Adversariale Tool-Outputs offline; Downstream-State-Checks und gesampelte Reviews online Beides Das Tool kann korrekt sein, obwohl der Agent es falsch liest

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

Tool-Call-Korrektheit

Tool-Korrektheit vergleicht die aufgerufenen Tools mit den erwarteten Tools. Wähle den Strengegrad bewusst:

  • Exact Match: Die Sequenz muss exakt übereinstimmen. Nutze das, wenn Reihenfolge Policy ist, zum Beispiel lookup_order -> verify_identity -> issue_refund.
  • In-Order Match: Erforderliche Tools müssen in der richtigen relativen Reihenfolge erscheinen, aber zusätzliche harmlose Calls sind erlaubt.
  • Any-Order Match: Erforderliche Tools müssen erscheinen, die Reihenfolge kann aber variieren.

Ein kleiner lokaler Scorer reicht für den Einstieg:

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":
        return len(set(expected) & set(called)) / len(set(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

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

Argument-Korrektheit

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 validiere JSON-Schema und exakte Werte. Für semantische Fälle speichere erwartete Argumente und bewerte 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 Tool-Name-Metrik kann 2026-06-17 nicht erkennen, wenn die Policy 2026-06-19 verlangt. Das Dataset muss also auch Argumente speichern.

Effizienz, Loops und Sackgassen

Der Pfad zählt auch dann, wenn das Ziel erreicht wird. Ein Agent, der die Aufgabe erst nach fünf redundanten Tool-Calls abschließt, signalisiert trotzdem ein Planungsproblem und verursacht höhere Laufzeitkosten.

Günstige Signale, mit denen du beginnen solltest:

  • 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, Latenz oder Kosten.
  • Path Convergence: wie nah der Run am kürzesten bekannten validen Pfad für die Aufgabe liegt.
  • Termination-Korrektheit: ob der Agent zu früh gestoppt hat, nach Erfolg weitergearbeitet hat oder Erfolg ohne erforderliche Zustandsänderung erklärt hat.

Führe diese Checks wann immer möglich vor einem Judge aus. Ein Loop-Detektor sind ein paar Zeilen über dem Trace. Dafür braucht es kein Modell.

Task Completion und Outcome-Grading

End-to-End lautet die Frage: „Hat der User bekommen, worum er gebeten hat?“

Zwei Muster funktionieren am besten:

  • Referenzloses Task-Completion-Judging: Extrahiere das Ziel aus dem Input und bewerte, ob Trace plus finale Antwort es erreicht haben. Das funktioniert online, weil produktiver Traffic selten Golden Outputs hat.
  • Environment-State-Grading: Vergleiche die finalen Datenbankzeilen, Dateien, Tickets, Buchungen oder Records mit einem annotierten Zielzustand. Das ist robuster als Transcript-Matching, weil Agents valide Pfade finden können, die du nicht explizit aufgeschrieben hast.

Die zweite Option ist besser, wenn du sie bauen kannst. Der finale Zustand ist der Vertrag. Das Transkript ist nur Evidenz.

Das Trace-to-Eval-Flywheel

Brainstorme dein Eval-Set nicht zuerst. Gewinne es aus Produktionsfehlern.

Das Trace-to-Eval-Flywheel

Der Loop:

  1. Den vollständigen Trace erfassen.
  2. Labeln, was fehlgeschlagen ist.
  3. Ähnliche Fehler gruppieren.
  4. Einen repräsentativen Golden pro Cluster behalten.
  5. Das Dataset versionieren.
  6. Es in CI ausführen.
  7. Gesampelte Produktions-Traces weiterhin online scoren.

Fehler mit Error Analysis abbauen

Hamel Husain und Shreya Shankar vermitteln einen Error-Analysis-Workflow genau für diesen Schritt; Hamels Field Guide führt hindurch. Die ersten beiden Schritte übernehmen ihre Namen aus der qualitativen Forschung, aber die Methode ist einfach: Lies Traces, mache Notizen, benenne Muster.

  1. Open Coding: Lies 30 bis 50 echte Traces und schreibe freie Notizen dazu, was schiefgelaufen ist.
  2. Axial Coding: Cluster diese Notizen in 5 oder 6 benannte Fehlerkategorien.
  3. Alles labeln gegen die Taxonomie.
  4. Metriken bauen für die größten Buckets.

Starte nicht mit Labels wie reasoning_issue oder tool_problem. Die sind zu vage, um sie zu testen. Nutze Labels wie missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 oder stopped_before_database_update. Ein so spezifisches Label sagt dir genau, was der Regressionstest behaupten sollte.

Vor dem Promoten deduplizieren

Der Trace-Mining-Loop hat eine Falle: jeden schlechten Trace für immer hinzuzufügen. Das erzeugt ein Dataset, das groß, teuer und eng ist. Es besteht aus Beinahe-Duplikaten aus dem März und verpasst die neue Form desselben Bugs im Juni.

Zuerst gruppieren. Pro Cluster einen repräsentativen Golden promoten. Die zugehörigen Trace-IDs in den Metadaten speichern, damit ein Reviewer die Produktionsevidenz später inspizieren kann.

Wenn ein Fehlercluster nach einem Fix wiederkehrt, hat der Regression Case nicht generalisiert. Re-clustere und erweitere den Golden, statt 15 punktuelle Beispiele hinzuzufügen.

Das Dataset versionieren

Versioniere Datasets genauso wie Prompts und Code. Immer wenn sich etwas Bedeutendes ändert (Modell, Prompt, Tool-Schema, Judge-Prompt oder App-Verhalten), willst du dieselbe Dataset-Version vorher und nachher laufen lassen.

Das CI-Gate sollte festhalten:

  • Dataset-Version
  • App-Version
  • Prompt-Version
  • Judge-Modell
  • Judge-Prompt
  • Evaluator-Code-Version

Wenn sich eines davon bewegt, wird dein Vorher-Nachher-Vergleich unscharf. Eine goldens-v3.json-Datei in git reicht in kleinem Maßstab. Tool-native Snapshots in Langfuse, Phoenix, Braintrust oder LangSmith helfen, sobald das Dataset kollaborativ wird.

CI gaten

Eine fehlschlagende Metrik muss zu einem fehlschlagenden Build werden, 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 einfach den alten fehlgeschlagenen Trace abspielen:

@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 umzusetzen. Die Aufgabe des Datasets ist es, zu erkennen, wenn die nächste Version des Agenten einen alten Fehler wiederholt, nicht den Fehler selbst zu archivieren.

Den Judge kalibrieren, bevor man ihm vertraut

LLM-as-a-Judge hilft. Man kann sich damit aber auch leicht etwas vormachen.

Die Idee hat eine belastbare Vorgeschichte. G-Eval zeigte, dass ein Judge, der eine explizite Rubrik Schritt für Schritt durchgeht, menschliche Bewertungen besser abbildet als die älteren automatischen Metriken, die er ersetzte. MT-Bench zeigte, dass GPT-4 mit menschlichen Präferenzen ungefähr so oft übereinstimmt, wie Menschen untereinander übereinstimmen, was LLM-Judging in den Mainstream brachte. Dann kamen die Einschränkungen: Judges bevorzugen in einem Pairwise-Prompt die Antwort, die zuerst erscheint, bewerten längere Antworten höher, bevorzugen Outputs aus ihrer eigenen Modelfamilie und verschieben sich, wenn sich Prompt oder Modellversion ändern. JudgeBench testete Judges auf Antwortpaaren, bei denen eine Antwort objektiv falsch ist, und fand, dass selbst starke Judges bei den harten Fällen nahe der Münzwurf-Genauigkeit liegen.

Behandle den Judge als Messinstrument.

Wenn ein Judge nötig ist, mache das Urteil strukturiert. Schema-Guided Reasoning (SGR) ist hier das Standardmuster: Definiere den Reasoning-Pfad des Judges als Pydantic-Schema, führe ihn über Structured Outputs oder constrained decoding aus und zwinge das Modell, Felder wie evidence, passed_criteria, failed_criteria, failure_mode und score auszugeben.

Das macht den Judge nicht magisch korrekt. Es macht die Messung aber reproduzierbarer. Der Judge muss bei jedem Run und über jedes kompatible Modell hinweg dieselben vordefinierten Rubrikschritte in derselben Feldreihenfolge durchlaufen. Ein Reviewer kann benannte Felder prüfen, statt einen Absatz zu parsen. CI kann ein stabiles JSON-Objekt diffen. Kalibrierung wird einfacher, weil die Rubrik nicht mehr in frei formulierter Prosa versteckt ist.

Es verändert auch die Kostenkurve. Wenn die Reasoning-Topologie explizit ist und der Output constrained ist, reichen günstigere Modelle oft für routinemäßiges Judging aus. Hebe den größeren Judge für Uneinigkeit, High-Risk-Fälle oder Kalibrierungsläufe auf, statt bei jedem Trace dafür zu bezahlen.

Judge-Kalibrierungsloop

Bias Was passiert Gegenmaßnahme
Position Pairwise-Prompts bevorzugen einen Slot Reihenfolge tauschen und beide Permutationen mitteln
Verbosity Längere Antworten werden höher bewertet, obwohl die Qualität unverändert ist Nicht belegte Verbosity in der Rubrik bestrafen
Self-preference Ein Judge bevorzugt seine eigene Modelfamilie Eine andere Modelfamilie oder eine Jury verwenden
Sycophancy Der Judge gibt unbelegten Behauptungen Kredit Evidenz aus dem Trace im Urteil verlangen
Calibration drift Ein Modell- oder Prompt-Update verschiebt Scores Judge-Modell und Prompt pinnen; bei Änderungen rekalibrieren

Standard-Checkliste für Judge-Hygiene:

  1. Wenn möglich binäres Pass/Fail bevorzugen. Fünf-Punkte-Skalen erzeugen Scheingenauigkeit.
  2. 30 bis 50 Trajektorien von Hand labeln, bevor die finale Rubrik geschrieben wird.
  3. Judge-Mensch-Übereinstimmung mit Cohen's kappa oder einfachem TPR/TNR messen.
  4. Grobe Kriterien zerlegen. „Hat der Agent vor dem Refund-Tool-Call die Identität verifiziert?“ ist besser als „War die Trajektorie gut?“
  5. Das Urteil über ein SGR-Schema mit Evidenz, fehlgeschlagenen Kriterien, Fehlermodus und Score ausgeben.
  6. Wenn möglich einen Judge aus einer anderen Modelfamilie als den Generator verwenden.
  7. Pairwise-Reihenfolge randomisieren und beide Richtungen mitteln.
  8. Judge-Modell, Prompt, Dataset, Schema und App-Version pinnen.
  9. Nach Änderungen an Modell, Prompt, Tool, Policy oder Schema rekalibrieren.

Für Scores mit hohen Anforderungen nutze eine kleine Jury statt eines großen Judges. PoLL testete genau dieses Setup: ein Panel kleinerer Judges aus disjunkten Modelfamilien, deren Urteile zu einem Score zusammengeführt werden. Über sechs Datasets hinweg bildete das Panel menschliche Urteile besser ab als ein einzelner GPT-4-Judge, vermied den Self-Preference-Bias, den ein einzelner Judge für die Outputs seiner eigenen Familie mitbringt, und kostete mehr als siebenmal weniger. Behalte Human Review für Entscheidungen, die Geld, Zugriff, Sicherheit oder Compliance betreffen.

Wenn ein Judge auf deiner Aufgabe nur eine Kappa von 0,55 mit Menschen erreicht, nutze ihn nicht, um Deploys zu blockieren. Nutze ihn, um Review-Queues zu sortieren. Liegt er eher bei 0,75 und die Fehlerkosten sind moderat, lässt sich ein CI-Gate viel leichter rechtfertigen.

Online-Evals sind keine Guardrails

Menschen werfen das oft zusammen, weil beides Scores produziert. Sie sitzen aber an unterschiedlichen Stellen.

Guardrails versus Online-Evals

Guardrails laufen inline. Sie sind schnell, deterministisch und user-sichtbar. Eine Guardrail kann einen Tool-Call blockieren, PII redigieren, Prompt Injection ablehnen oder einen Retry erzwingen, bevor die Antwort dein System verlässt. Ein False Positive ist ein Produktionsbug.

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

Online-Evals laufen nach der Antwort, meist auf gesampeltem Traffic. Sie können langsamere LLM-Judges nutzen, weil sie nicht im Latenzpfad liegen. Ihre Aufgabe ist es, Drift zu erkennen, neue Fehlercluster zu finden und das nächste Offline-Dataset zu speisen.

Wenn du die Platzierung falsch machst, tut es in beide Richtungen weh:

  • Ein Judge im Request-Pfad erzeugt Latenz und eine neue Flaky-Quelle.
  • Eine Guardrail, die auf async Scoring degradiert wird, lässt Policy-Verstöße bis zu den Usern durch.

Für Systeme mit hohem Volumen solltest du ein kleines Sample mit einem stärkeren Judge scoren und ein breiteres Sample mit günstigeren Klassifikatoren. Alerting sollte auf Clustern und Konfidenzgrenzen beruhen, nicht auf einem einzelnen verrauschten Punktschätzer.

Tooling-Entscheidungen

Kein einzelnes Tool besitzt den gesamten Loop. Die meisten ernsthaften Stacks verwenden zwei Bausteine: einen Trace Store und einen CI-/Eval-Runner.

Tool Beste Passung CI-Story Self-Hosting-Story Trade-off
DeepEval Pytest-native Agent- und LLM-Evals Stark: deepeval test run passt in CI Core Library ist lokal/Open Source Judge-Calls und Cloud-Features können Kosten erzeugen
Inspect AI Safety-, Frontier- und sandboxed Evaluations CLI und Python API Vollständig lokal/Open Source Keine Plattform für Produktions-Traces
Phoenix OTel/OpenInference-Tracing plus Evals Custom Scripts Starke Self-Host-Option Managed Alerting liegt in der kommerziellen Schicht
Langfuse Trace Store, Datasets, Prompt-Versionen Experimente und Custom Gates Starke Self-Host-Option Eval-Metriken sind weniger batteries-included als bei DeepEval
LangSmith LangChain-/LangGraph-Tracing und Evals pytest, Vitest, GitHub-Workflows Enterprise Self-Host Closed Source; Preise pro Seat und Trace-Volumen beachten
Braintrust Eval-getriebener Produktloop und PR-Review Sehr starker gemanagter PR-Regression-Flow Enterprise/Hybrid Span-Volumen, verarbeitete Daten und Score-Anzahl können sich summieren
Promptfoo Prompt-Tests und Red-Team-Suites GitHub, GitLab, Jenkins, CircleCI Lokaler/Open-Source-Core Starker Pre-Release-Runner, aber kein Trace-Hub

Die Trade-off-Notizen beschreiben, wo Kosten entstehen, nicht wie hoch sie sind. Preislisten ändern sich, und Anbieter zählen unterschiedliche Dinge: Traces, Observations, Spans, Scores, User, Retention oder verarbeitete Daten. Prüfe vor einer Festlegung die aktuelle Preisgestaltung.

Entscheidungskürzel:

  • Brauchst du selbst gehostetes Tracing mit OTel-Portabilität: Starte mit Phoenix oder Langfuse.
  • Brauchst du ein code-first CI-Gate: Starte mit DeepEval.
  • Bist du bereits auf LangGraph festgelegt: LangSmith ist bequem.
  • Willst du gemanagte PR-Regression-Reviews: Braintrust ist schwer zu schlagen.
  • Security- und Red-Team-Fälle dominieren: Promptfoo ist das fokussierte Tool.
  • Safety Research oder kontrollierte Benchmark-Arbeit: Inspect AI passt besser.

Die Tool-Wahl ist zweitrangig. Wenn Produktionsfehler nicht zu Testfällen werden, bezahlst du größtenteils nur für Trace Storage.

Eine praktische Rollout-Checkliste

Bevor die Implementierung clever wird, baue die Evidenz-Pipeline. Die erste Frage lautet nicht „welche Metrik sollten wir optimieren?“, sondern „woher kommen die Beispiele?“

  1. Zuerst historische Runs sammeln. Wenn der Agent bereits existiert, ziehe Traces, Support-Tickets, Bug-Reports, Thumbs-down-Sessions, manuelle QA-Transkripte und Dogfooding-Notizen, bevor du die Implementierung änderst. Wenn der Agent noch nicht existiert, logge vom ersten Tag an jeden Prototypen- und manuellen Test-Run.

  2. Die Trace-Shape instrumentieren. Erfasse Nachrichten, Tool-Calls, Argumente, Tool-Outputs, Fehler, Token-Anzahlen, Latenz, Kosten, User-Feedback, App-Version, Prompt-Version, Modellversion, Tool-Schema-Version und finalen Environment State. Nutze OpenTelemetry GenAI conventions oder OpenInference-artige Spans, wenn du Portabilität willst. Nutze Langfuse, LangSmith, Phoenix oder Braintrust, wenn du sofort eine Trace-UI und einen Dataset-Workflow willst.

  3. Echte Fehler in Seed-Cases überführen. Lies die Traces, bevor du sie mit einem Modell zusammenfasst. Speichere für jeden nützlichen Fehler Input, Source-Trace-ID, Expected State, Expected Tool Invariants, Failure Mode, Severity und Reviewer-Notiz. Langfuse kann Dataset-Items mit Produktions-Traces verknüpfen; LangSmith kann Datasets aus getraceten Runs erzeugen. Behalte den Source-Link, damit der Fall auditierbar bleibt.

  4. Wenn es keine Historie gibt, Cold-Start-Cases erzeugen. Bitte ein LLM, Aufgaben aus Produktanforderungen, Policies, Tool-Schemas, State Machines und Support-Makros zu entwerfen. Erzeuge sowohl Happy Paths als auch „should not happen“-Fälle: falsche Berechtigungen, fehlende Identitätsprüfungen, veraltete Tool-Ergebnisse, mehrdeutige Datumsangaben, Retries nach Rate Limits und Tool-Outputs, die der User-Anfrage widersprechen.

  5. Synthetischen Fällen nicht vertrauen, bevor ein Mensch sie geprüft hat. Synthetische Beispiele sind nützlich für Coverage, nicht für Wahrheit. Kennzeichne sie mit source: synthetic, verlange, dass ein Reviewer das erwartete Outcome freigibt, führe nach Möglichkeit einen Known-Good-Referenzpfad aus und vermeide es, dieselbe Modelfamilie zu verwenden, um den Fall zu erzeugen und das Ergebnis zu bewerten.

  6. Ein kleines, ausgewogenes Dataset bauen. Schließe Erfolge, Fehler, Refusals, Boundary Cases, Long-Turn-Cases, policy-sensitive Fälle und valide alternative Pfade ein. Mache den Golden nicht zum „exakten alten Transkript“. Der Golden sollte das erforderliche Outcome, erlaubte Invarianten und den Fehlermodus kodieren.

  7. Zuerst deterministische Checks hinzufügen. Erforderliche Tool-Reihenfolge, wenn Reihenfolge Policy ist, erforderliche Argumente, Schema-Validierung, Final-State-Diffs, Loop-Limits sowie taskspezifische Invarianten sollten vor jedem Judge laufen.

  8. Einen SGR-geformten Judge hinzufügen. Nutze ihn nur für den Teil, der Interpretation braucht. Kalibriere ihn gegen menschliche Labels. Wenn er gute und schlechte Beispiele im Kalibrierungsset nicht trennen kann, repariere die Rubrik, bevor du ihn an CI anschließt.

  9. Den Loop verdrahten. Führe die kleine Offline-Suite in CI aus, die größere Suite vor dem Release, scorne gesampelten Produktionstraffic online und promote wiederkehrende Online-Fehlercluster zurück in das Offline-Dataset.

Deine erste Eval-Suite wird auf langweilige Weise falsch sein. Shippe sie trotzdem. Eine Suite, die du jeden Tag laufen lässt, ist leichter zu reparieren als ein perfektes Designdokument, das nie einen schlechten PR blockiert.

Wichtigste Takeaways

  1. Agent-Evals sind Trace-Evals. Die finale Antwort ist nur ein Knoten im Run.
  2. Tool-Auswahl, Argument-Korrektheit, Loop-Erkennung, Task Completion und Multi-Turn-Fidelity gehören in getrennte Metriken.
  3. Das Produktions-Flywheel lautet trace -> label -> cluster -> dedupe -> dataset -> CI gate -> online score.
  4. Starte deterministisch. Tool-Checks, Argument-Checks, State-Checks und Loop-Detektoren sind günstiger und stabiler als Judges.
  5. LLM-Judges brauchen Struktur und Kalibrierung. Nutze SGR für reproduzierbare, inspizierbare Urteile und pinne dann Judge-Modell, Prompt, Schema, Dataset-Version, App-Version und Human-Label-Sample.
  6. Offline-Evals gaten bekannte Fälle vor dem Release. Online-Evals gewinnen gesampelte Produktions-Traces nach der Antwort. Guardrails blockieren unsicheres Verhalten inline.
  7. Die meisten Teams brauchen einen Trace Store und einen CI-Runner. Wähle langweilige Tools, mit denen Produktionsfehler schnell zu Regressionstests werden.

Referenzen