Die Bewertung von KI-Agenten prüft, ob ein Agent das richtige Ergebnis erreicht hat und ob die Tool-Aufrufe und Abrufe, die dazu geführt haben, angemessen waren. Ein Team, das nur das Endergebnis bewertet, prüft möglicherweise nie, wie der Agent zu diesem Ergebnis gelangt ist – denn ein Agent kann über eine fehlerhafte Abfolge von Tool-Aufrufen ein scheinbar korrektes Ergebnis liefern.
Dieser Leitfaden zeigt, was auf jeder Ebene eines Agentenlaufs zu messen ist und worin sich fünf Bewertungsmethoden darin unterscheiden, was sie erkennen und was ihnen entgeht.
Für die Produktions-Tracing-Seite desselben Problems erfahren Sie mehr über Observability für KI-Agenten, die die Frage beantwortet, was während eines laufenden Durchlaufs geschieht.
Was ist die Bewertung von KI-Agenten?
Die Bewertung von KI-Agenten bewertet einen Agenten anhand Ihrer eigenen Aufgaben, mit Ihren eigenen Tools und Ihren eigenen Daten. Sie prüft, ob der Agent das richtige Ergebnis erzielt hat, indem er die von Ihnen definierten Schritte befolgt hat. Die Bewertung von KI-Agenten misst das System, das Sie bereitgestellt haben, und nicht ein abstraktes Modell.
Daneben gibt es das Modell-Benchmarking, das ein Modell anhand eines festen, öffentlichen Aufgabensatzes bewertet – für alle derselbe Satz. Die Agentenbewertung bewertet Ihren Agenten anhand Ihrer eigenen Workflows: ein Anruf im Forderungsmanagement, der Ihr CRM aktualisiert, oder eine Umbuchung, die Ihre Tarifregeln einhält.
Ein öffentlicher Benchmark kann die Fehler, die in Ihren eigenen Workflows zählen, nicht erkennen, weil er Ihre internen Tools und Ihre Compliance-Regeln nie testet. Die Agentenbewertung erkennt den Agenten, der das falsche interne Tool aufruft, und den Agenten, der eine von Ihrem Compliance-Team festgelegte Offenlegungsregel verletzt.
Warum die Ergebnisgenauigkeit die falsche Kennzahl ist
Die Ergebnisgenauigkeit ist die falsche primäre Kennzahl für einen KI-Agenten, denn zwei völlig unterschiedliche Fehler gelten bei einer reinen Antwortprüfung beide als korrekt. Ein Agent kann über einen fehlerhaften Prozess zur richtigen Antwort gelangen – oder jeden Schritt korrekt ausführen und die Aufgabe dennoch nicht abschließen.
Der Agent befolgt die vordefinierten Schritte nicht
Der Agent erledigt die Aufgabe auf dem falschen Weg, weil die Prüfung nur die endgültige Antwort betrachtet und nicht den Weg dorthin. Überspringt der Agent einen erforderlichen Schritt, liest er den falschen Datensatz aus oder ruft er das falsche Tool auf, kann er in diesem Durchlauf dennoch ein korrekt wirkendes Ergebnis liefern.
Ein Support-Agent kann beispielsweise nach dem Girokontostand einer Kundin fragen und stattdessen das Sparkonto auslesen. Beide Salden können an diesem Tag übereinstimmen, doch die falsche Abfrage liefert eine nur scheinbar richtige Zahl.
Häufige Ursachen dafür:
- Falsche Datenquelle: Die Abfrage ruft den falschen Datensatz, das falsche Konto oder das falsche Feld ab – nicht das, was die Aufgabe vorgegeben hat.
- Falscher Tool-Aufruf: Der Agent ruft ein Tool auf, das nicht zum aktuellen Schritt passt, oder übergibt ihm das falsche Argument.
- Übersprungener Schritt: Der Workflow geht zum nächsten Schritt über, bevor eine erforderliche Prüfung – etwa eine Identitäts- oder Richtlinienverifizierung – abgeschlossen ist.
- Verlorener Kontext: Ein früherer Wert aus dem Gespräch wird weitergeführt statt des Werts, der in einem späteren Gesprächsschritt korrigiert wurde.
Der Agent befolgt jeden Schritt, liefert aber nie ein Ergebnis
Dies ist ein anderes Szenario: Ein Agent kann jede Prüfung auf Schrittebene bestehen und die Aufgabe dennoch nicht abschließen. Ein Erstattungsagent wählt das richtige Tool, übergibt gültige Argumente und erhält bei jedem Schritt eine gültige Antwort – und stoppt dennoch vor dem finalen Schreibvorgang im Zahlungssystem.
Jede Bewertung auf Schrittebene gilt als korrekt. Die Erstattung wird nie gebucht, und der Zahlungsdatensatz der Kundschaft wird nie aktualisiert.
Das sind die Gründe dafür:
- Unbemerkt fehlgeschlagener Schreibvorgang: Der Aktualisierungsaufruf kehrt zurück, ohne den erfolgreichen Schreibvorgang zu bestätigen, und der Agent prüft dies nie nach.
- Bestätigung als Abschluss missverstanden: Der Agent wertet eine gültige Antwort aus einem Zwischenschritt als Ende der Aufgabe.
- Fehlender letzter Schritt: Der Workflow endet einen Schritt vor der Aktion, die die Änderung festschreibt – etwa dem Schreibvorgang im Zahlungs- oder CRM-System.
- Turn- oder Kostenlimit erreicht: Der Agent erreicht seine Turn- oder Kostenobergrenze, bevor der letzte Schritt ausgeführt wird, und gibt zurück, was er hat.
Was sollte man tatsächlich messen?
Die Agentenbewertung erfolgt auf drei Ebenen, und jede Ebene bewertet einen anderen Teil des Durchlaufs. Die Schrittebene bewertet eine einzelne Aktion, die Trace-Ebene bewertet, ob der Durchlauf sein Ziel erreicht hat, und die Ergebnisebene bewertet das geschäftliche Resultat des Durchlaufs.
Ein Team, das nur eine dieser Ebenen misst, kann nicht erkennen, was auf den beiden anderen passiert ist. Das sollten Sie auf den einzelnen Ebenen messen.
Die Schrittebene bewertet jede einzelne Aktion
Die Bewertung auf Schrittebene bewertet jede Aktion innerhalb eines Laufs, noch bevor der Lauf abgeschlossen ist. Eine falsche Aktion kann dennoch ein richtig aussehendes Ergebnis liefern – ein Unternehmen, das nur die endgültige Antwort prüft, bemerkt also nie den Schritt, der beinahe fehlgeschlagen wäre.
Die folgenden Schritte werden durchgeführt, um die Korrektheit dieses Schritts zu überprüfen.
- Tool-Auswahl: Prüft, ob der Agent das ausdrücklich angeforderte, für diesen Schritt vorgesehene Tool aufruft und nicht ein ähnliches, das ein falsches Ergebnis liefert.
- Tool-Argumente: Überprüft, ob der Agent die richtige Konto-, Auftrags- oder Datensatz-ID an das aufgerufene Tool übergibt.
- Qualität des Abrufs: Bestätigt, ob das Dokument, die Richtlinie oder der Datensatz, den der Agent abgerufen hat, tatsächlich zu der beantworteten Frage passt.
- Kohärenz der Argumentation: Führt eine Prüfung durch, um sicherzustellen, dass jeder Schritt logisch auf den vorherigen folgt, ohne einer früheren Entscheidung im selben Lauf zu widersprechen.
Die Trace-Ebene bewertet den gesamten Lauf
Die Bewertung auf Trace-Ebene bewertet den gesamten Lauf eines Agenten gemessen am vorgegebenen Ziel – und nicht nur jede Aktion für sich.
Ein Unternehmen braucht diese Ebene, weil ein Lauf jeden Schritt bestehen und die Aufgabe trotzdem verfehlen kann: Ein Rückerstattungs-Agent kann alle richtigen Tools aufrufen und dennoch stoppen, bevor der Zahlungsdatensatz aktualisiert wird. Die Bewertung auf Trace-Ebene erkennt diese Lücke zwischen korrekten Schritten und einer abgeschlossenen Aufgabe. Es ist außerdem die Ebene, die ein Compliance-Team für Berichte heranzieht.
Dafür müssen diese Faktoren in einem Test aufeinander abgestimmt werden:
- Aufgabenabschluss: Prüft, ob der Lauf den von der Aufgabe geforderten Zustand erreicht hat, etwa eine gebuchte Rückerstattung oder eine bestätigte Buchung.
- Richtlinientreue: Überprüft, ob die Regeln eingehalten werden, für die sie entwickelt wurden, etwa erforderliche Hinweise oder Auslöser für eine Eskalation.
- Kontexterhalt: Ermittelt, ob ein Agent einen Wert oder eine Anweisung über mehrere Gesprächsschritte hinweg beibehalten hat, statt sie zwischendurch zu verlieren.
- Schritte und Kosten: Wie viele Gesprächsschritte hat der Lauf benötigt und was hat er gekostet – verglichen mit derselben Aufgabe auf kürzerem Weg?
Die Outcome-Ebene bewertet das Geschäftsergebnis
Die Bewertung auf Outcome-Ebene misst das Geschäftsergebnis, das der Lauf erzielen sollte – in der Regel als Zahl, die das Management auf einem Dashboard ablesen kann. Sie prüft, ob die Arbeit des Agenten eine Kennzahl bewegt hat, die das Unternehmen verfolgt, und nicht, ob ein einzelner Schritt oder der zugrunde liegende Trace korrekt war.
Hier finden die folgenden Prüfungen statt:
- Lösungsquote: Welcher Anteil der Läufe die Aufgabe ohne menschliches Eingreifen abgeschlossen hat.
- Eskalationsquote: Welcher Anteil der Läufe an eine Person übergeben wurde – und warum.
- Korrekturquote durch Menschen: Wie oft eine Person das Ergebnis des Agenten nachträglich korrigieren musste.
- Nachgelagerte Geschäftskennzahl: Steht für die Zahl, die der Workflow bewegen soll, etwa eingezogene Forderungen, abgeschlossene Buchungen oder geschlossene Tickets.
Die meisten Teams hören bei der Outcome-Ebene auf, weil das die Zahlen sind, die ein Dashboard dem Unternehmen ohnehin zeigt. Die Umfrage State of Agent Engineering von LangChain unter 1.340 Teams, die Agenten im Produktivbetrieb entwickeln, ergab, dass 89 % ihren Agenten eine gewisse Observability hinzugefügt haben. Dennoch können nur 62 % einen einzelnen Schritt oder Tool-Aufruf nachverfolgen, und lediglich 37,3 % führen Bewertungen anhand von Live-Traffic aus dem Produktivbetrieb durch.
Bewertungsmethoden im Vergleich
Ein fehlkalibriertes LLM-as-a-Judge würde selbstbewusste, aber falsche Bewertungen liefern – das ist in der Praxis der häufigste Fehler bei der Bewertung. Bevor ein Team einem Judge-Modell vertraut, muss es dessen Bewertungen an einer Stichprobe mit menschlichen Labels abgleichen und diese Prüfung bei jedem Wechsel des Judge-Modells wiederholen.
| Method | What it catches | What it misses | Cost | When to use it |
|---|---|---|---|---|
| Human review | Nuance and judgment on open-ended output | Scale, since a person reviews only a few runs | High | Calibration and hard edge cases |
| Rule-based assertions | Known hard constraints, like a forbidden action or a bad format | Anything the rules don't encode | Low | Policy and safety gates |
| LLM-as-judge | Open-ended quality at scale | Whatever an unaligned judge scores as wrong | Medium | High volume, once the judge is checked against human labels |
| Regression suites from production failures | A repeat of a failure that already happened | A failure mode nobody has seen yet | Low to maintain | Stopping a known bug from returning |
| Simulation | Behavior across many generated cases before launch | The real distribution of live traffic | Medium | Pre-deployment coverage |
Offline-Bewertung versus kontinuierliche Bewertung
Ein Bewertungsset vor der Bereitstellung wird getestet, bevor ein Agent live geht, um die Fehlerarten zu erkennen, die ein Team bereits kennt. Die kontinuierliche Bewertung soll nach dem Start auf Live-Traffic im Produktivbetrieb laufen und jene Fehlerarten aufdecken, an deren Prüfung niemand gedacht hat.
Hier ist der vollständige Unterschied zwischen der Evaluierung und der kontinuierlichen Evaluierung.
| Process Aspect | Offline evaluation | Continuous evaluation |
|---|---|---|
| When it runs | Before the agent goes live | After launch, on live production traffic |
| What it catches | Failure modes a team already knows about | Failure modes nobody thought to test for |
| Test cases come from | A curated eval set built ahead of time | Real runs the agent that is currently handling |
| Role in the loop | Blocks a known failure from reaching production again | Adds the next production failure to the eval set |
| Risk if left unmaintained | Reports passing scores against tasks the agent no longer runs | Has no risk of going stale, since it always tests current traffic |
Was beide Evaluierungen verbindet, ist ein einziger Kreislauf aus einem Produktionsfehler. Beispielsweise wird ein falsch gelesenes Konto aus einem Live-Lauf zu einem neuen Evaluierungsfall, und dieser Fall wird zu einem Regressionstest, der dasselbe Fehlverhalten künftig verhindert. Dieser Kreislauf hält auch eine Test-Suite vor der Bereitstellung nach dem Launch nützlich, statt sie an dem Tag veralten zu lassen, an dem der Agent ausgeliefert wird.
Ein Evaluierungsset veraltet, sobald ein Team die Workflows, Tools und Richtlinien des Agenten ändert. Eine Suite, die das Team nicht mehr aktualisiert, ist schlechter als gar keine Suite, weil sie bestandene Ergebnisse für Aufgaben meldet, die der Agent gar nicht mehr ausführt. Eine solche Suite erzeugt falsches Vertrauen statt echter Abdeckung. Ein Team, das kontinuierliche Evaluierung und A/B-Tests im Live-Traffic durchführt, hält die Suite mit den aktuellen Workflows des Agenten im Einklang.
Die Wahl der Evaluierungstools
Für ein Großunternehmen bedeutet die Wahl der Evaluierungstools, zu entscheiden, wo Agenten-Traces und Daten liegen – und nicht, Funktionen zu vergleichen. Eine Bank oder eine Fluggesellschaft muss wissen, wer ein Gesprächstranskript einsehen kann, bevor sie einen Anbieter auswählt.
Kategorien
Der Markt teilt sich in vier Kategorien auf – je nachdem, wo die Suite liegt und wer sie betreibt.
Evaluierungsorientierte Plattformenbehandeln die Eval-Suite selbst als Kernprodukt und ergänzen sie um Tracing.
- Braintrust
- Galileo
- Maxim
- Comet
Open-Source-Bibliothekenlaufen in Ihrem eigenen Code und Ihrer CI, sodass kein Anbieter Ihre Traces speichert.
- DeepEval
- MLflow-Evaluierungstools
Tracing-Plattformenmit einer Evaluierungsebene erfassen zuerst den Trace und bewerten dann anhand davon.
- Langfuse
- Arize Phoenix
In eine Agentenplattform integriertbedeutet, dass die Plattform, die die Agenten betreibt, diese selbst bewertet – so muss der Käufer keinen separaten Stack zusammenstellen.
Datenlokalisierung, die Frage, ob Traces Ihre Umgebung verlassen dürfen, und wer die Suite pflegt, entscheiden über die Wahl – nicht die Anzahl der Funktionen.
HappyRobot fällt in diese vierte Kategorie: Die Governance-Ebene kann jeden Agenten auf der Plattform bewerten, sodass ein Großunternehmen die Evaluierung einkauft, statt sie selbst zu bauen.
