Ein KI-Agent muss ein konkretes Nutzerziel über den gesamten Ablauf erreichen – nicht nur eine plausible Schlussantwort liefern. Google empfiehlt, dafür kritische Nutzerreisen in überprüfbare Szenarien zu übersetzen, Ausführungsspuren auszuwerten und beobachtete Fehler in wiederholbare Tests zu überführen (Googles Leitfaden zur Bewertung von KI-Agenten).
Der Ablauf: vom Nutzerziel bis zum Regressionstest
Beginne mit einem klaren Erfolgskriterium. Erst dann kannst du Szenarien und spätere Änderungen sinnvoll bewerten.
1. Erfolg als Nutzerreise definieren
Beschreibe, wer den Agenten wofür einsetzt, welche Bedingungen gelten und woran sich eine erfolgreiche Erledigung erkennen lässt. Google nennt diese Beschreibung eine Critical User Journey (CUJ): Jeder ihrer Bestandteile kann zu einem eigenen Prüfpunkt werden. Ein Beispiel aus Googles Leitfaden: Ein Agent soll eine strittige Transaktion identifizieren, die Angaben mit einem internen Buchungssystem abgleichen und eine Antwort entwerfen. Daraus werden mehrere konkrete Prüffragen statt eines einzigen Urteils über den fertigen Text.
2. Szenarien durchspielen und Ausführungsspuren prüfen
Lege für jede Nutzerreise einen normalen Ablauf und schwierige Varianten an. Simulierte Nutzer können etwa unvollständige Angaben machen, sich vertippen oder im Gespräch die Richtung wechseln. So lässt sich ein erster Testbestand aufbauen, bevor reale Nutzungsfälle vorliegen. Wenn echte Ausführungsspuren verfügbar sind, können sie die Szenarien schrittweise ergänzen.
Prüfe zunächst manuell, was im Ablauf geschieht: Eingaben und Zwischenschritte, Werkzeugargumente und Ausgaben. Eine überzeugende Schlussantwort kann verdecken, dass der Agent zuvor ein Werkzeug falsch eingesetzt oder eine Bedingung übersehen hat. Wiederkehrende Fehlermuster werden anschließend zu konkreten, wiederholbaren Kontrollen.
3. Wiederholungen und Abhängigkeiten kontrollieren
Ein einzelner erfolgreicher Lauf sagt wenig darüber aus, ob ein Agent bei leicht veränderten Abläufen zuverlässig bleibt. Braintrust empfiehlt deshalb mehrere Durchläufe je Aufgabe. Mit Stubs – Ersatzdiensten, die feste Antworten liefern – oder eingefrorenen Datensätzen lässt sich außerdem verhindern, dass Änderungen externer Dienste oder Datenbanken den Vergleich verzerren (Braintrusts Leitfaden zu Agentenbewertungen).
Für die Fehlersuche lassen sich Testumgebungen zusätzlich isolieren und gezielt mit Problemen wie Zeitüberschreitungen, fehlerhaften Antworten oder fehlenden Feldern konfrontieren. Dann wird sichtbar, wie der Agent mit diesen Fällen umgeht, statt dass ein wechselnder externer Dienst die Ursache eines abweichenden Ergebnisses verschleiert.
4. Prüfungen kombinieren und LLM-Richter kalibrieren
Google empfiehlt vier sich ergänzende Prüftypen: Unit-Tests für einzelne Komponenten, deterministische Kennzahlen, Bewertungsrubriken für ein LLM als Richter und Integrationstests für das Zusammenspiel. Wo es passt, sind klare Ja-Nein-Kriterien leichter auszuwerten als eine unscharfe Skala von eins bis fünf. Automatisierte Urteile sollten mit manuell geprüften Ausführungsspuren abgeglichen werden.
Ein LLM-Richter bewertet Antworten anhand einer Rubrik oder vergleicht mehrere Antworten miteinander. IBM Technology beschreibt drei mögliche Verzerrungen: Positionsverzerrung zugunsten einer Antwort, weil sie an erster Stelle steht; Längenverzerrung zugunsten ausführlicherer Antworten; und Selbstbevorzugung, wenn das Modell die eigene Ausgabe besser bewertet. Um gezielt die Positionsverzerrung zu prüfen, vertauschst du die Reihenfolge der Antwortkandidaten und kontrollierst, ob sich das Urteil ändert. Dieser Test betrifft die Reihenfolge der Antworten.
Wenn menschliche Prüfer und ein automatischer Richter wiederholt uneinig sind, schlagen Kommentierende in einer Diskussion auf Reddit vor, die Entscheidung samt Begründung und Regelversion festzuhalten und geklärte Fälle als Regressionstests aufzunehmen. So bleibt nachvollziehbar, welche Regel für einen späteren Vergleich galt (Diskussion über strittige Bewertungen).
5. Eine stabile Basis für Änderungen und CI/CD schaffen
Halte den Referenzdatensatz während eines Vergleichs konstant und ändere jeweils nur eine Variable. Sonst bleibt unklar, ob ein anderes Ergebnis auf eine Änderung am Agenten oder auf veränderte Tests zurückgeht. Als Freigabeschranke für CI/CD schlägt Google eine globale Bestehensschwelle zusammen mit dem Ausschluss von Rückschritten bei zuvor bestandenen Kernprüfungen vor.
Miss neben der Antwortqualität auch das Betriebsverhalten: etwa Latenz, Tokenverbrauch, API-Kosten und Werkzeugaufrufe. Google beschreibt für sein Toolkit außerdem die Standardisierung von OpenTelemetry-Traces nach OpenInference-Konventionen und nennt Google ADK, LangGraph sowie eigene Laufzeitumgebungen als unterstützte Kontexte.
6. Beobachtungen aus der Produktion zurückführen
Online-Evaluierung kann reale Interaktionen und Ergebnisse beobachten. Microsoft beschreibt, wie Erkenntnisse aus der Produktion anschließend in Offline-Testdaten einfließen können (Microsofts Leitfaden zu KI-Agenten in der Produktion). Auch Google empfiehlt, übersehene Grenzfälle aus dem laufenden Betrieb in den Referenzdatensatz aufzunehmen. So wächst die Testsuite mit den Fällen, die im tatsächlichen Einsatz auftreten.
