Executive Summary

Die Evaluierung ist die Harness-Komponente, die aus einem ’es scheint zu funktionieren‘ eine messbare, vertretbare Aussage macht. Da Agenten nicht-deterministisch sind und offene Aufgaben bearbeiten, können Sie sich Vertrauen nicht einfach durch Zusicherungen (Assertions) verschaffen – Sie müssen Verhaltensverteilungen mit bekannten, guten Referenzen abgleichen und sich gegen Regressionen absichern. Dieses Kapitel behandelt Offline- und Online-Evaluierung, Golden Sets, LLM-as-Judge, Regressions-Suites sowie Metriken zur Aufgabenerfüllung und argumentiert, dass die Evaluierung die Trennlinie zwischen Agenten-Handwerk und Agenten-Engineering darstellt.

Kernkonzepte

Offline-Evaluierung: Bewertung eines Agenten anhand eines festen Datensatzes vor dem Deployment.
Online-Evaluierung: Bewertung des Live-Produktionsdatenverkehrs (mit Nutzersignalen oder Shadow-Judges).
Golden Set: Ein kuratierter Datensatz von Eingaben mit bekannten, guten erwarteten Ausgaben oder Akzeptanzkriterien.
LLM-as-Judge: Verwendung eines Modells zur Bewertung von Ausgaben anhand einer Rubrik, wenn ein exakter Abgleich (Exact-Match) unmöglich ist.
Regressions-Suite: Eine Reihe von Testfällen, die bei jeder Änderung ausgeführt werden, um Qualitätsverluste abzufangen.
Aufgabenerfüllungsrate (Task-Completion Rate): Der Anteil der Versuche, die das Ziel End-to-End erreichen.
Trajektorien-Evaluierung: Bewertung des Pfads, den ein Agent genommen hat, und nicht nur seiner endgültigen Antwort.

Definition

Die Evaluierung eines agentischen Systems ist das Harness-Subsystem, das die Qualität, Sicherheit und Zuverlässigkeit des Agentenverhaltens anhand definierter Kriterien misst – sowohl über kuratierte Datensätze (offline) als auch im Live-Betrieb (online) – und Änderungen basierend auf den Ergebnissen freigibt oder blockiert. Sie beantwortet zwei Fragen: ’Ist es gut genug für den Release?‘ und ’Hat diese Änderung das System verbessert oder verschlechtert?‘

Architekturdiagramm

flowchart TB
  subgraph OFFLINE["Offline-Evaluierung (Pre-Deploy)"]
    GOLD[(Golden Set)] --> RUNO[Agent ausf&uuml;hren]
    RUNO --> SCORE1[Scorer]
    SCORE1 --> GATE{Regressions-Gate}
    GATE -->|pass| SHIP[Deployen]
    GATE -->|fail| BLOCK[Blockieren / Untersuchen]
  end
  subgraph ONLINE["Online-Evaluierung (Live)"]
    PROD[Produktions-Traffic] --> TRACE[Traces HRN-006]
    TRACE --> JUDGE[LLM-as-Judge / Regeln]
    PROD --> USERSIG[Nutzersignale]
    JUDGE --> MON[Monitore &amp; Dashboards]
    USERSIG --> MON
  end
  subgraph SCORERS["Scorer-Typen"]
    EXACT[Exakt / Regelbasiert]
    LLMJ[LLM-as-Judge]
    HUMAN[Menschliche &Uuml;berpr&uuml;fung]
  end
  SCORE1 --- SCORERS
  JUDGE --- SCORERS
  MON -.liefert neue F&auml;lle.-> GOLD

Detaillierte Erklärung

Warum die Evaluierung von Agenten schwierig ist

Drei Eigenschaften machen dies schwieriger als traditionelles Softwaretesting. Erstens: Nicht-Determinismus: Dieselbe Eingabe kann zu unterschiedlichen Ausgaben und sogar unterschiedlichen Pfaden führen, weshalb eine einzelne Pass/Fail-Zusicherung (Assertion) bedeutungslos ist – Sie müssen Raten über mehrere Durchläufe hinweg messen. Zweitens: Offenheit (Open-Endedness): Es gibt viele korrekte Antworten, weshalb ein Exact-Match-Scoring fehlschlägt und Sie eine rubrikbasierte oder semantische Bewertung benötigen. Drittens: Mehrstufige Trajektorien: Ein Agent kann eine richtige Antwort über einen falschen (unsicheren, teuren) Pfad erreichen, weshalb die Evaluierung nur der endgültigen Ausgabe unzureichend ist. Das Evaluierungsdesign ist die Kunst, diese Eigenschaften in messbare Signale zu verwandeln.

Offline-Evaluierung und Golden Sets

Die Offline-Evaluierung führt den Agenten vor jedem Release über ein festes Golden Set aus – kuratierte Eingaben gepaart mit erwarteten Ausgaben oder Akzeptanzkriterien. Das Golden Set ist das wertvollste Asset, das die Evaluierung hervorbringt; es codiert, was ’gut‘ für Ihre Domäne bedeutet, und wächst im Laufe der Zeit an. Bauen Sie es aus echten (anonymisierten) Produktionsfällen, bekannten Fehlerfällen und Grenzfällen (Edge Cases) auf und erweitern Sie es bei jedem Vorfall: Wenn der Agent in der Produktion fehlschlägt, besteht der Fix nicht nur aus einer Codeänderung, sondern aus einem neuen Golden Case, damit der Fehler nie wieder unbemerkt auftreten kann. Dies ist die Regressionsdisziplin (Wissensvalidierung der Klasse PAT-015), die das System verbesserungsfähig macht.

Scorer-Typen – die Methode an die Aufgabe anpassen

Exakte / regelbasierte Scorer für Aufgaben mit überprüfbaren Ausgaben (ein korrektes SQL-Ergebnis, ein gültiges JSON-Schema, ein erfolgreicher Unit-Test). Günstig, deterministisch, vertrauenswürdig – setzen Sie sie ein, wo immer es möglich ist.
LLM-as-Judge für offene Ausgaben, bei denen ein Exact-Match fehlschlägt (Zusammenfassungen, Erklärungen, Pläne). Ein Modell bewertet anhand einer Rubrik. Leistungsstark, aber fehlbar: Judges weisen Biases auf (Position, Detailreichtum, Eigenpräferenz). Kalibrieren Sie sie daher anhand menschlicher Labels, verwenden Sie klare Rubriken und bevorzugen Sie paarweise Vergleiche gegenüber absoluten Bewertungen, wo dies machbar ist. Behandeln Sie den Judge als ein Instrument, das selbst evaluiert werden muss.
Menschliche Überprüfung (Human Review) für Fälle mit höchstem Risiko oder größter Mehrdeutigkeit sowie zur Kalibrierung der automatisierten Scorer. Teuer, reservieren Sie sie daher für die Fälle, die sie wirklich benötigen, und um die günstigeren Scorer ehrlich zu halten.

Metriken für Aufgabenerfüllung und Trajektorien

Die wichtigste Kennzahl für einen Agenten ist in der Regel die Aufgabenerfüllungsrate (Task-Completion Rate): Hat er das Ziel End-to-End erreicht? Darunter angesiedelt sind Metriken auf Schrittebene und Trajektorien-Metriken – hat er geeignete Tools ausgewählt, unnötige Schritte vermieden, das Budget eingehalten und unsichere Aktionen auf dem Weg vermieden? Die Trajektorien-Evaluierung deckt Agenten auf, die ’aus den falschen Gründen richtig‘ liegen – genau die Art von Fragilität, die bei einem Distribution Shift (Verschiebung der Datenverteilung) zusammenbricht. Kombinieren Sie die Erfüllungsrate mit den Kosten pro Aufgabe (Cost-per-Task) und der Rate an Sicherheitsverletzungen (Safety-Violation Rate), um zu vermeiden, dass eine Metrik auf Kosten der anderen optimiert wird.

Online-Evaluierung

Offline gibt Ihnen Aufschluss über Ihren Datensatz; erst die Online-Evaluierung zeigt Ihnen die Realität. Die Online-Evaluierung bewertet den Live-Traffic anhand impliziter Nutzersignale (Akzeptanz, Bearbeitungen, Eskalationen, erneute Versuche), Shadow-LLM-Judges, die auf Produktions-Traces (HRN-006) laufen, und regelmäßiger menschlicher Audits von stichprobenartigen Durchläufen. Über die Online-Evaluierung werden auch neue Golden Cases entdeckt – die Produktion ist die reichhaltigste Quelle für die Grenzfälle, die Ihrem Offline-Set fehlen. Der Kreislauf lautet: Beobachten (HRN-006) → Online bewerten → Fehler in das Golden Set überführen → mit Offline-Regression absichern.

Regressions-Gating – Evaluierung als CI-Gate

Die Disziplin wird zum Engineering, wenn die Evaluierung Änderungen steuert (gates). Jede Prompt-Anpassung, jeder Modellwechsel oder jede Tool-Änderung wird gegen die Regressions-Suite ausgeführt, und ein Qualitätsabfall blockiert den Merge – genau wie ein fehlschlagender Unit-Test den Code blockiert. Dies ist die operative Form des Evidence-First-Prinzips (HRN-004): Keine Änderung wird basierend auf bloßem Bauchgefühl (’Vibes‘) veröffentlicht. Da die Evaluierung von Agenten ratenbasiert ist und teilweise von LLMs beurteilt wird, nutzen Gates Schwellenwerte und statistische Vergleiche anstelle eines einfachen Booleans, aber das Prinzip ist identisch.

Praxisbelege

Evidenzgrad: theoretisch 'b7 Vertrauen: mittel 'b7 Quelle: industry_observation

Illustratives, repräsentatives Szenario – kein verifiziertes einzelnes Deployment.

Kontext: Teams, die einen Produktionsagenten durch häufige Prompt-Änderungen und Modellwechsel iterativ verbessern.
Szenario: Ohne ein Evaluierungs-Gate führte eine Prompt-Änderung, die einen Fall verbesserte, unbemerkt zu einer Verschlechterung (Regression) bei mehreren anderen Fällen, was zu einem insgesamt schlechteren Agenten im Release führte. Die Einführung einer Golden-Set-Regressions-Suite mit LLM-as-Judge und regelbasierten Scorern fing die Regression vor dem Deployment ab.
Technologie: Golden-Set-Harness, regelbasierte und LLM-as-Judge-Scorer, CI-Gate, Online-Judge über Produktions-Traces.
Last: Häufige Änderungen an einem Golden Set, das von Dutzenden bis zu Tausenden von Fällen reicht.
Ergebnisse: Die repräsentative Erfahrung zeigt, dass die Qualität nicht mehr abdriftet, sobald Änderungen über Gates gesteuert werden, und dass das Golden Set – das kontinuierlich durch Produktionsfehler erweitert wird – zum wertvollsten Asset des Teams wird.

Beobachtete Fehlermuster

Bauchgefühl-basiertes Releasen (’Vibes-based Shipping‘): Änderungen werden nur durch Stichproben einiger weniger Prompts evaluiert, sodass Regressionen unbemerkt veröffentlicht werden.
Overfitting auf das Golden Set: Optimierung, bis das feste Set bestanden wird, während die Qualität in der realen Welt stagniert – entschärft durch die Erweiterung des Sets um neue Produktionsfälle.
Naiver LLM-as-Judge: Vertrauen in einen unkalibrierten Judge mit bekannten Biases; Behandlung seiner Bewertungen als Ground Truth ohne Validierung durch Menschen.
Ausschließliche Bewertung der endgültigen Antwort: Übersehen von Agenten, die richtige Antworten über unsichere oder teure Pfade erreichen.
Keine Online-Evaluierung: Starke Offline-Zahlen, die dem Kontakt mit echtem, sich veränderndem Traffic nicht standhalten.

KPIs

Metrik	Ziel	Anmerkungen
Aufgabenerfüllungsrate	Domänenabhängig, im Trend	Primäre Hauptqualitätsmetrik
Erfolgsquote der Regressions-Suite	100 % vor dem Deploy	Gate bei jeder Änderung
Übereinstimmung zwischen Judge und Mensch	Hoch, kalibriert	Validiert das LLM-as-Judge-Instrument
Rate an Sicherheitsverletzungen	Nahe Null	Auf Trajektorien-Ebene, nicht nur endgültige Antwort
Kosten pro erfolgreicher Aufgabe	Minimiert	Gekoppelt mit der Erfüllungsrate, um Überoptimierung zu verhindern

Kostenmetriken

Die Evaluierung verursacht an drei Stellen Kosten: Ausführung des Agenten über das Golden Set (Inferenz), LLM-as-Judge-Scoring (weitere Inferenz) und menschliche Überprüfung (Arbeitszeit). Diese werden durch Tiering gesteuert – günstige regelbasierte Scorer zuerst, LLM-Judge für die offene Teilmenge, Menschen für die Kalibrierung und risikoreiche Fälle. Die Kosten amortisieren sich durch die Vermeidung von Regressionen, die nach dem Release weitaus teurer sind. Die Wiederverwendung von Observability-Traces (HRN-006) für das Offline-Replay vermeidet, wo möglich, eine erneute Ausführung des Modells.

Skalierungseigenschaften

Die Evaluierungskosten skalieren mit der Größe des Golden Sets 'd7 Scorer-Kosten 'd7 Änderungsfrequenz. Wenn das Set wächst, halten Stichprobenverfahren und gestaffeltes Scoring (Tiered Scoring) die Regressionsläufe bezahlbar; die aussagekräftigsten Fälle können gewichtet oder häufiger ausgeführt werden. Die Online-Evaluierung skaliert mit dem stichprobenartig erfassten Traffic statt mit dem gesamten Traffic. Das Golden Set selbst gewinnt mit zunehmender Größe an Wert – das Gegenteil der meisten Kostenkurven –, da jeder hinzugefügte Fall ein dauerhaft abgesichertes Fehlermuster darstellt.

Zugehörige Inhalte

HRN-006 — Observability für agentische Systeme
PAT-009 — (Evaluierungs- / Judging-Pattern)
PAT-015 — Wissensvalidierung

Referenzen

Fachliteratur zu LLM-Evaluierung, LLM-as-Judge-Kalibrierung und Golden Datasets.
Branchenbeobachtungen zum Regressions-Gating für agentische Systeme, 2023–2026.
Santa María, S. — Arbeitsnotizen zur Disziplin der Agenten-Evaluierung.

FAQs

F: Kann ich einem LLM-as-Judge einfach vertrauen? A: Nutzen Sie es, aber behandeln Sie es als ein Instrument, das selbst evaluiert werden muss. Kalibrieren Sie es anhand menschlicher Labels, geben Sie ihm explizite Rubriken, bevorzugen Sie paarweise Vergleiche und achten Sie auf bekannte Biases (Position, Detailreichtum, Eigenpräferenz).

F: Woher kommen Golden Cases? A: Aus echtem (anonymisiertem) Produktions-Traffic, bekannten Fehlerfällen und Grenzfällen (Edge Cases) – und ganz entscheidend: Jeder Produktionsvorfall sollte einen neuen Golden Case hinzufügen, damit der Fehler nicht unbemerkt wiederkehren kann.

F: Offline- oder Online-Evaluierung – was brauche ich? A: Beides. Offline steuert Änderungen vor dem Deployment gegen ein bekanntes Set; online zeigt Ihnen, was tatsächlich in der Realität passiert, und führt neue Fälle in das Offline-Set zurück. Zusammen mit Observability bilden sie einen Kreislauf.

Evaluation agentischer Systeme