KI-Agenten testen: Wenn ein gutes Ergebnis Fehler verdeckt

Ein KI-Agent kann die richtige Antwort liefern und trotzdem auf dem Weg dorthin eine verbotene Funktion aufrufen, einen Fehler übergehen oder unnötig viele Schritte ausführen. Eine brauchbare Testsuite prüft deshalb bei realen Aufgaben getrennt den erreichten Endzustand, die Nutzerantwort und den aufgezeichneten Ablauf.

Für jeden Testfall brauchen Entwickler und Produktteams einen definierten Anfangszustand, zulässige Aktionen und überprüfbare Erfolgskriterien. Eindeutige Bedingungen prüft Code, offene Qualitätsfragen ein Modellbewerter. Menschliche Stichproben helfen, Fehlurteile der Bewerter zu erkennen. Vor dem Vergleich zweier Versionen steht fest, welche Befunde eine Freigabe sperren.

Testfälle aus realen Aufgaben bauen

Beginnen Sie mit einer Aufgabe, die der Agent tatsächlich erledigen soll. Ein hypothetischer Testfall: Ein Support-Agent soll in einer Testumgebung die Lieferadresse einer noch nicht versandten Bestellung ändern. Er darf den Bestellstatus lesen und bei erfüllten Voraussetzungen eine Änderungsfunktion aufrufen. Erfolg bedeutet, dass anschließend die richtige Bestellung die neue Adresse trägt, andere Bestellungen unverändert sind und die Antwort die ausgeführte Änderung korrekt beschreibt.

Der Datensatz enthält dafür die Nutzeranfrage, den anfänglichen Bestellstatus, die verfügbaren Werkzeuge und den erwarteten Endzustand. Ebenso wichtig sind verbotene Nebenwirkungen: Der Agent darf weder eine andere Bestellung ändern noch eine erfolgreiche Änderung behaupten, wenn der Schreibaufruf scheitert. So erhält jede Bewertung einen konkreten Maßstab statt einer allgemeinen Erwartung wie „hilfreiche Antwort“.

Ergänzen Sie Varianten, die unterschiedliche Entscheidungen verlangen: Die Bestellung ist bereits versandt, die Berechtigung fehlt, die Änderungsfunktion meldet einen Fehler oder die Anfrage bezeichnet keine Bestellung eindeutig. Legen Sie je Fall fest, ob eine Rückfrage, ein Abbruch oder eine Fehlermeldung richtig ist. Diese Varianten prüfen auch, ob der Agent eine Handlung unterlässt, wenn ihre Voraussetzungen fehlen.

Das Ergebnis am veränderten Zustand messen

Der Leitfaden von Anthropic unterscheidet den vollständigen Ablauf vom Endzustand und beschreibt Unit-Tests für Aufgaben, die eine Umgebung verändern. Sein Beispiel macht den Unterschied greifbar: Die Aussage eines Agenten, ein Flug sei gebucht, belegt noch keine Reservierung in der Datenbank. Die Schlussantwort und der tatsächliche Zustand sind getrennte Prüfpunkte.

Im hypothetischen Adressfall liest ein programmierbarer Test nach dem Lauf den Bestelldatensatz aus. Er prüft die neue Adresse, den unveränderten Versandstatus und ausbleibende Änderungen an anderen Bestellungen. Ein weiterer Test kann feststellen, ob die Antwort eine Änderung meldet, die im Datensatz fehlt. Solche klar definierten Bedingungen gehören in Code, weil ein Fehlschlag dann einer bestimmten Anforderung zugeordnet werden kann.

Jeder Lauf sollte mit demselben frischen Anfangszustand beginnen. Bleiben Änderungen aus einem früheren Versuch bestehen, kann ein Agent einen Erfolg zugeschrieben bekommen, den er selbst nicht erzielt hat. Kontrollierte Antworten externer Werkzeuge machen außerdem sichtbar, ob eine Änderung des Agentenverhaltens oder ein wechselnder Dienst das Testergebnis beeinflusst hat.

Den Ablauf auf Toolfehler und Umwege prüfen

Der OpenAI-Leitfaden für Agenten-Workflows beschreibt Traces als Aufzeichnung von Modellaufrufen, Werkzeugaufrufen, Schutzprüfungen und Übergaben; Trace-Grading kann damit unter anderem Werkzeugwahl, erforderliche Übergaben und Regelverstöße beurteilen. Ein bestandener Zustandstest lässt solche Unterschiede zwischen zwei Ausführungen allein nicht erkennen.

Zeichnen Sie für jeden Lauf auf, welches Werkzeug mit welchen Eingaben aufgerufen wurde, was es zurückgab und wie der Agent darauf reagierte. Im Adressfall wäre etwa zu prüfen, ob nach einer Fehlermeldung derselbe Schreibaufruf ohne Korrektur wiederholt wurde oder ob eine Änderung ohne die erforderliche Berechtigungsprüfung erfolgte. Beide Befunde betreffen den Ablauf, selbst wenn eine spätere Aktion noch zum gewünschten Endzustand führt.

Erfassen Sie außerdem Werkzeugaufrufe, Laufzeit und Kosten pro erfolgreich erledigter Aufgabe. Zwei Varianten können denselben Zustand erreichen, während eine erheblich mehr Ressourcen benötigt. Ein auffälliger Wert ist zunächst ein Anlass, den Trace anzusehen: Bei schwierigen Fällen kann zusätzlicher Aufwand begründet sein, bei wiederholten wirkungslosen Aufrufen liegt ein konkreter Verbesserungsbedarf nahe.

Schreiben Sie dem Agenten keine vollständige Musterfolge aller Aufrufe vor. Mehrere Wege können gültig sein; eine starre Reihenfolge würde brauchbare Lösungen ablehnen. Harte Ablaufregeln sollten sich auf Risiken beziehen, die für die Aufgabe tatsächlich zählen: fehlende Berechtigung, verbotene Werkzeuge, übergangene Fehlerrückgaben oder doppelte Schreibaktionen.

Für jede Anforderung den passenden Bewerter wählen

Eine Gesamtnote verdeckt leicht, welcher Teil einer Aufgabe gescheitert ist. Ordnen Sie deshalb jeder Anforderung eine Prüfart zu:

Programmierbare Tests prüfen den Endzustand, gültige Werkzeugparameter, Berechtigungen und klar verbotene Aufrufe.
Modellbewerter beurteilen anhand einer kurzen Bewertungsregel offene Fragen, etwa ob die Nutzerantwort den tatsächlichen Bearbeitungsstand verständlich und ohne unbelegte Zusage erklärt.
Menschliche Stichproben prüfen strittige Urteile, ungewöhnliche Traces sowie bestandene Fälle, bei denen eine wichtige Nebenwirkung übersehen worden sein könnte.

Ein Modellbewerter braucht die Nutzeraufgabe, den relevanten beobachteten Zustand und eine eng gefasste Frage. Im hypothetischen Fall könnte er beurteilen, ob die Antwort nach einem gescheiterten Änderungsaufruf den Fehler korrekt erklärt. Er sollte sein Urteil an beobachtbaren Stellen begründen und bei fehlenden Informationen Unsicherheit angeben können. Ein gutes Sprachurteil darf weder eine fehlende Zustandsänderung noch einen verbotenen Aufruf überstimmen.

Vergleichen Sie eine Auswahl seiner Bewertungen mit menschlichen Urteilen. Häufen sich Abweichungen, präzisieren Sie die Bewertungsregel oder teilen eine zu breite Frage auf. Auch ein programmierbarer Test kann falsch urteilen: Er könnte einen zulässigen alternativen Ablauf ablehnen, weil er eine bestimmte Aufrufreihenfolge erwartet. Stichproben bestandener und gescheiterter Fälle decken beide Arten von Fehlern auf.

Aus den Tests eine Freigabeentscheidung machen

Nach Änderungen an Modell, Prompt, Werkzeugen oder Routing laufen dieselben Fälle erneut gegen einen gespeicherten Ausgangsstand. Die LangChain-Dokumentation zu Evaluierungstypen beschreibt solche Regressionstests auf kuratierten Datensätzen und die ergänzende Beobachtung im laufenden Betrieb. Da Agenten bei gleicher Aufgabe unterschiedlich handeln können, sind bei wichtigen Fällen mehrere Durchläufe sinnvoll; einzelne Fehlschläge sollten neben zusammengefassten Werten sichtbar bleiben.

Die Freigabegrenzen werden vor dem Vergleich festgelegt. Pflichtfälle müssen den erwarteten Endzustand erreichen. Kritische Nebenwirkungen und Regelverstöße sperren die Freigabe unabhängig davon, wie überzeugend die Antwort klingt. Für die übrigen Fälle lassen sich Erfolgsquote, Laufzeit und Kosten mit dem Ausgangsstand vergleichen. Wie viel Mehraufwand für eine Qualitätsverbesserung akzeptabel ist, entscheidet das Team anhand seiner Produktanforderungen.

Neue, nachvollziehbare Fehler werden als eigene Testfälle mit Anfangszustand und erwarteter Reaktion aufgenommen. Nach der Freigabe kann die Überwachung erledigter Aufgaben weitere Varianten aus realen Anfragen sichtbar machen. So wächst der Datensatz aus konkreten Fehlern, während die Freigabe weiterhin auf überprüfbaren Ergebnissen und Abläufen beruht.

Lesen Sie auch: