Testen von KI-Agenten anhand des Ergebnisses: Überprüfung des Zustands statt Vertrauen auf Antworten

Wenn ein KI-Agent mit „Erledigt“ antwortet, handelt es sich dabei um eine Behauptung und nicht um einen Nachweis. Eine Bewertung, die nur die endgültige Nachricht liest, wird einen fälschlich als erfolgreich eingestuften Erfolg gerne als Bestehen werten. Dieser Leitfaden zeigt, wie man Agenten, die Tools nutzen, anhand dessen testen kann, was tatsächlich in der Welt geändert wurde: wie man die Erledigung definieren, welche Beweise überprüfen, wie mit Zeitüberschreitungen und Fällen umgehen, in denen der Agent nichts tun sollte, sowie wie man Zuverlässigkeit statt eines glücklichen Demonstrationsbeispiels messen kann.

Eine selbstsichere Antwort ist kein Beweis

Nehmen wir eine einfache Anfrage an einen Terminplanungs-Assistenten: Ein Meeting auf Donnerstagnachmittag verschieben. Der Assistent antwortet höflich und ohne Zögern, dass das Meeting nun um 15 Uhr stattfindet. Wenn man dann den Kalender öffnet, befindet sich die Veranstaltung genau dort, wo sie zuvor war.

Auch andere Varianten sind möglich: Die Veranstaltung wurde in einer anderen Zeitzone auf 15 Uhr verschoben, oder es erschien eine völlig neue Veranstaltung, während die ursprüngliche unverändert blieb und dem Benutzer somit zwei Optionen zur Verfügung standen. Das Beispiel ist erfunden, doch das Testproblem ist sehr real: Wenn man nur den von dem Agenten erzeugten Text bewertet, sehen alle drei Fehlschläge genauso aus wie ein Erfolg.

Der nützliche Denkansatz ist folgender: Für einen Agenten ist die Antwort ein Bericht über die geleistete Arbeit, und ein Bericht kann falsch sein. Das umgebende System des Modells, seine Infrastruktur, bestimmt, ob es überhaupt zuverlässig agieren kann (diese Ebene behandeln wir in dort, wo zuverlässiges Agentenverhalten tatsächlich entsteht). Die Bewertung ist der Schritt, der bestätigt, ob dieses System tatsächlich das Erwartete geliefert hat.

Schreiben Sie zunächst den Vertragsentwurf

„Mein Meeting verschieben“ klingt trivial, bis man versucht, Akzeptanzkriterien dafür zu formulieren.

In dem hier genannten Beispiel geht man davon aus, dass der Benutzer ein einzelnes Ereignis ausgewählt hat, ein Datum sowie eine Zeitzone angegeben hat und eine Aktualisierung autorisiert hat. Das gewünschte Ergebnis ist nicht einfach nur, dass um 15 Uhr ein Meeting existiert. Vielmehr soll das gleiche Ereignis nun zu der angeforderten Zeit beginnen, seine ursprüngliche Dauer sowie die Liste der Teilnehmer beibehalten und dabei kein anderes Ereignis verändert werden. Falls die Anfrage unklar ist oder der Assistent keine Berechtigung hat, ist das richtige Vorgehen, nachzufragen und nicht zu raten.

Diese Regeln gelten für dieses hypothetische Produkt. Ein anderes Produkt könnte Benachrichtigungen senden, eine ausdrückliche Genehmigung erfordern oder die Teilnehmer anders behandeln. Entscheidend ist, dass der Vertrag schriftlich festgehalten wird. Ohne ihn lobt ein Bewertender einen Assistenten für seine Initiative, während ein anderer denselben Ablauf als unbefugte Änderung kennzeichnet – dadurch werden Ihre Bewertungen unzuverlässig.

Jeder Bewertungsfall sollte daher Folgendes spezifizieren:

• den Ausgangszustand der Umgebung;
• die Anfrage des Benutzers;
• die Aktionen, die der Agent ausführen darf;
• die Bedingungen, die danach erfüllt sein müssen; sowie
• die Elemente, die unverändert bleiben müssen.

Diesen letzten Punkt vergisst man leicht. Ein guter Test definiert sowohl das Ziel als auch die darum liegenden Grenzen.

Drei Sichtweisen auf einen einzigen Ablauf

Jeder ausgeführte Agent kann aus drei Perspektiven untersucht werden, wobei jede Perspektive unterschiedliche Fehler aufdeckt.

• Ausgabe: die Nachricht, die der Benutzer gesehen hat. Ist sie genau und hilfreich, oder verschweigt sie unvollendete Arbeiten anstatt sie zu offenbaren?
• Verlauf: die beobachtbare Abfolge der Tool-Aufrufe, -Ergebnisse, Genehmigungen, Wiederholversuche und Überprüfungen. Hat der Agent das richtige Ereignis ausgewählt, sich innerhalb seiner Befugnisse bewegt und angemessen reagiert, als ein Tool fehlschlug?
• Ergebnis: der tatsächliche Zustand des Kalenders nach Abschluss des Versuchs.

Anthropics Leitfaden zur Bewertung von Agenten macht ebenfalls eine Trennung zwischen der Transkription und dem Endzustand der Umgebung und warnt davor, jede gültige Lösung anhand einer festen Abfolge von Schritten zu bewerten. Dieses Gleichgewicht lohnt es, es anzunehmen. Beobachten Sie, wie sich der Agent verhalten hat, aber bestehen Sie nicht auf Ihrem bevorzugten Weg, es sei denn, die Reihenfolge der Operationen ist tatsächlich Teil der Vereinbarung.

Konkret könnten zwei Agenten den Kalender durch unterschiedliche Vorgehensweisen durchgehen und dennoch zum gleichen korrekten Ergebnis gelangen; beide sollten bestehen. Das Überspringen einer obligatorischen Freigabe hingegen ist ein Misserfolg, selbst wenn der Kalender letztendlich korrekt aussieht. Das Ergebnis entscheidet darüber, ob die Aufgabe erfolgreich war, die Grenzen bestimmen, ob sie zulässig war, und der Ablauf erklärt die Lücke zwischen den beiden.

Überprüfen Sie die Welt über einen unabhängigen Kanal

Zum Überprüfen des Kalender-Tests soll das gespeicherte Ereignis über eine autorisierte Schnittstelle gelesen werden, die nichts mit der eigenen Antwort des Agents zu tun hat. Dem Agent ist es nicht gestattet, seine eigene Hausaufgabe zu bewerten.

Vergleichen Sie die Felder, die tatsächlich die Richtigkeit definieren, mit dem erwarteten Zustand:

• der stabile Ereignisidentifikator;
• Start- und Endzeit sowie die Zeitzone;
• die Liste der Teilnehmer;
• nahegelegene Ereignisse, die unverändert bleiben sollten.

Vermeiden Sie einen Abgleich anhand des Ereignisnamens. Zwei Treffen können denselben Namen haben, und ein Namensabgleich kann fälschlicherweise das falsche Ereignis bestätigen.

Diese Idee geht den heutigen Agentenframeworks voraus. τ-bench bewertet gespräche mit Werkzeugnutzung, indem es den endgültigen Datenbankzustand mit einem annotierten Zielzustand vergleicht, und WebArena misst, ob Aufgaben in realistischen Webumgebungen funktional abgeschlossen werden. Beide sind Forschungsbeispiele dafür, das Geschehene statt des Gesagten zu bewerten.

Erkennen Sie, was ein Erfolgsignal wirklich verspricht

Eine erfolgreiche API-Antwort ist ein nützliches Indiz – doch nur, wenn man weiß, was sie garantiert. „Akzeptiert“ kann bedeuten, dass die Anfrage in der Warteschlange steht und noch nicht verarbeitet wurde. Ein Erfolgsbanner im Browser kann bereits erscheinen, bevor der zugrunde liegende Datensatz gespeichert wird.

Für asynchrone Systeme sollte im Voraus entschieden werden, wie lange der Überprüfer wartet und welcher Zustand als abgeschlossen gilt. Wenn der Zustand überhaupt nicht beobachtet werden kann, sollte das Ergebnis als unüberprüft vermerkt werden. Zählen Sie es nicht stillschweigend als erfolgreich, und gehen Sie auch nicht vom Gegenteil aus. Diese dritte Kategorie wird unverzichtbar, sobald Anfragen anfangen, abzutreten.

Der schwierigste Moment: direkt nach einem Timeout

Ein Timeout sagt nichts darüber aus, ob die Aktualisierung angekommen ist. Die Anfrage könnte bereits vor Erreichen des Kalenderdienstes abgebrochen worden sein, oder sie könnte erfolgreich gewesen sein und nur die Antwort auf dem Rückweg verloren gegangen sein.

Ein Agent, der darauf reagiert, ein neues Ersatztreffen erstellt, kann dem Benutzer zwei Ereignisse hinterlassen. Dadurch wird das Wiederherbeleitungsverhalten zu einem wichtigen Testfall. Eine solide Wiederherstellungssequenz sieht wie folgt aus:

1. Das Zielereignis erneut lesen.

Überprüfen Sie, ob die angeforderte Änderung bereits umgesetzt wurde.

Wiederholen Sie den Vorgang nur dann, wenn die vorliegenden Belege sowie die Spezifikationen des Tools eine Wiederholung zulassen.

Falls der Dienst dies unterstützt, verwenden Sie einen Idempotenzmechanismus, damit wiederholte Anfragen als dieselbe Operation und nicht als neue erkannt werden.

Falls das Ergebnis auch danach noch unklar ist, kann es sinnvoll sein, innezuhalten und dem Benutzer die Unsicherheit zu erklären. Eine klare Kommunikation ist besser als ein künstlich erzeugter Erfolg. Dasselbe Prinzip gilt auch im herkömmlichen Backend-Design; zu den Aspekten auf der Serverseite siehe Idempotenzschlüssel für Node.js POST-Endpunkte.

Bewerte sowohl den Inhalt als auch die Formulierung. „Ich konnte die Aktualisierung nicht bestätigen“ ist wahr, selbst wenn der Dienst den Änderung sofort umsetzt. „Es wurde nichts geändert“ ist in genau derselben Situation eine unbegründete Behauptung. Unsicherheit ist ein legitimes Ergebnis, das der Ansprechpartner bewältigen muss – nicht eine Lücke, die er mit Selbstsicherheit füllen sollte.

Passen Sie den Bewertungstool zum Fragestil an

Andere Fragen erfordern andere Bewertungskräfte.

• Deterministischer Code für genaue Fakten: Identifikatoren, Zeitstempel, die Liste der zulässigen Änderungen sowie die Anzahl der duplizierten Ereignisse.
• Ein modellbasiertes Bewertungstool mit klarer Bewertungsrichtlinie für die Kommunikationsqualität: Hat der Assistent fertige Arbeiten von unvollendeten Versuchen unterschieden und die nächsten Schritte beschrieben, ohne eigene Details hinzuzufügen?

Menschliche Überprüfung für unklare Fälle sowie zur regelmäßigen Überprüfung, ob die automatischen Bewertungen weiterhin mit den Erwartungen des Produktteams übereinstimmen.

In der LangSmith-Bewertungsdokumentation werden Code-Regeln, menschliche Überprüfung und modellbasierte Beurteilung als separate Optionen behandelt. Sie benötigen diese Plattform nicht, um von der Trennung dieser Elemente zu profitieren.

Ein Anti-Muster verdient besondere Erwähnung: Dem zweiten Modell wird die zuverlässige Antwort des Agenten übergeben, um zu prüfen, ob die Aufgabe erfolgreich erscheint. Der Beurteiler wird von derselben Zuverlässigkeit überzeugt, die Sie getäuscht hat. Geben Sie dem Beurteiler stattdessen die Beweise, die die Frage tatsächlich erfordert, und ermöglichen Sie ihm, „unzureichende Beweise“ anzugeben.

Halten Sie kritische Fehler von den Qualitätsbewertungen getrennt. Eine nicht autorisierte Änderung des Kalenders darf nicht durch einen angenehmen Ton oder präzise Formulierungen ausgeglichen werden. Eine kompakte Bewertungstabelle eignet sich gut: korrektes Ergebnis, Einhaltung der Grenzen, wahrheitsgetreuer Bericht, angemessene Wiederherstellung. Geben Sie die Verzögerung und Kosten daneben an, anstatt alles in einer unklaren Zahl zusammenzufassen.

Enthalten Sie Fälle, in denen die richtige Antwort darin besteht, nichts zu tun

Eine vernünftige Ausgangsgrundlage für den Kalenderassistenten umfasst:

• eine normale Umplanung;
• Zwei Ereignisse mit demselben Titel;
• eine Anfrage ohne Zeitzone;
• eine abgelehnte Genehmigung;
• einen Zeitüberschreitungsfall seitens des Kalenderservices;
• eine Aktualisierung, die bereits vor dem Ausführen des Assistenten angewendet wurde;
• eine Anfrage, einen vorgeschlagenen Änderungsvorschlag zu erstellen, ohne ihn umzusetzen.

Der letzte Fall schützt Sie vor einem subtilen Verzerrungseffekt. Wenn jeder Test die Durchführung einer äußeren Änderung belohnt, wählen Sie letztendlich einen Agenten aus, der zu eifrig handelt.

Führen Sie Tests durch, bei denen der Zustand in isolierten Testkonten oder kontrollierten Umgebungen verändert wird, und setzen Sie die Fixtures zwischen unabhängigen Versuchen zurück. Eine durch einen vorherigen Lauf hinterlassene Konfiguration darf niemals dazu führen, dass der nächste Lauf als erfolgreich erscheint.

Diese Liste dient nur als Ausgangspunkt und stellt kein statistisch ausreichendes Sample dar. Erweitern Sie sie anhand dessen, was Ihre Nutzer tatsächlich verlangen, wo die wirklichen Risiken liegen und welche Fehler in der Praxis auftreten. Entfernen Sie personenbezogene Daten aus Fixtures, die Sie wiederverwenden möchten, und beschränken Sie den Zugriff auf Spuren, die private Daten enthalten.

Messen Sie die Konsistenz – nicht die beste Demo

Führen Sie jeden Fall mehrmals aus und dokumentieren Sie jeden Versuch, einschließlich Zeitüberschreitungen sowie Laufe, bei denen die Überprüfung fehlschlug.

τ-bench führte eine Metrik für wiederholte Versuche ein, nämlich pass^k, die prüft, ob ein Agent bei allen k Versuchen erfolgreich ist und nicht nur bei mindestens einem. Die veröffentlichten Modellwerte sind historisch und sollten nicht als Rangliste der aktuellen Agenten interpretiert werden, doch die Lehre bleibt: „Erfolgreich sein“ und „zuverlässig erfolgreich sein“ sind unterschiedliche Eigenschaften, und ein einziger erfolgreicher Versuch gibt nur Auskunft über das Erstere.

Ein erster Produkt-Dashboard könnte Folgendes erfassen:

• die gültige Abschlussrate;
• die Anzahl der nicht autorisierten Aktionen;
• die unbegründeten Erfolgsansprüche;
• die angemessenen Eskalationen;
• die Latenzzeit;
• den Kosten pro gültigem Abschluss.

Sprechen Sie klar über den Nenner. Zählen Sie Benutzeranfragen, unabhängige Versuche oder einzelne Wiederholungsversuche? Dasselbe Datenmaterial kann je nach Wahl sehr unterschiedliche Raten ergeben.

Lesen Sie die Zahlen gemeinsam durch. Eine Veränderung, die die Erfolgsrate erhöht, aber gleichzeitig auch unautorisierte Aktionen begünstigt, stellt keinen echten Gewinn dar. Ebenso wenig ist ein Agent geeignet, der alle Risiken vermeidet, indem er jede nützliche Aufgabe ablehnt. Vergleichen Sie Versionen derselben Fälle mit denselben Budgets und geben Sie an, wie viele Fälle Sie durchgeführt haben sowie inwieweit sich die Ergebnisse zwischen den Durchläufen unterschieden haben. Ein paar Versuche reichen bei weitem nicht aus, um eine genaue Angabe zur Zuverlässigkeit in der Produktion zu rechtfertigen.

Jedes Versagen in einen Regressionstest umwandeln

Wenn ein Fall fehlschlägt, sollten Sie zunächst herausfinden, was tatsächlich schiefgelaufen ist: der Agent, das Tool, die Umgebung oder der Bewertungsalgorithmus. Ein fehlerhafter Test ist kein Beweis für ein fehlerhaftes Modell.

Dann soll ein minimaler, reproduzierbarer Fall erfasst werden, und alles, was ihn beeinflussen kann, muss versioniert werden: die Aufgabe, der erwartete Zustand, der Bewertungstool, die Modellkonfiguration, die Anweisungen sowie die Verträge der Tools. Wenn sich etwas davon ändert, müssen die betroffenen Fälle erneut ausgeführt werden. Das Festlegen des erwarteten Zustands ist genauso wichtig wie das Festlegen des Modells; unser Artikel zu Version-Pinning in LLM-Evaluierungs-Suiten geht darauf ausführlicher ein.

Offline-Tests und Echtzeit-Überwachung beantworten unterschiedliche Fragen. Sorgfältig ausgewählte Prä-Release-Bewertungen zeigen an, ob ein Update sicher veröffentlicht werden kann; die Bewertung echter Interaktionen zeigt auf, was im Einsatz schiefgeht. Die LangSmith-Dokumentation beschreibt beides und empfiehlt, Produktionsfehler wieder in den Testdatensatz aufzunehmen.

Für den Kalenderassistenten könnte ein solcher Zyklus mit Meldungen der Benutzer über doppelte Ereignisse beginnen, einen Fall fehlender Rückmeldung zur Suite hinzufügen und sicherstellen, dass ein Wiederherstellungsfix vor einer breiteren Einführung funktioniert.

Kernpunkte

• Betrachten Sie „Erledigt“ als etwas, das überprüft werden muss, niemals als Beweis.
• Schreiben Sie den Vertrag für jeden Fall individuell aus: Ausgangszustand, Anfrage, zulässige Aktionen, erforderlicher Endzustand sowie das, was unverändert bleiben muss.
• Bewerten Sie das Ergebnis, setzen Sie Grenzen durch und nutzen Sie die Spur, um den Unterschied zu erklären.
• Überprüfen Sie über einen unabhängigen, autorisierten Leseweg und behalten Sie „nicht überprüft“ als ehrliches Ergebnis bei.
• Testen Sie explizit Zeitüberschreitungen, Duplikate sowie Fälle ohne Aktion – genau hier versagen zuverlässige Agenten.
• Ausklammern Sie kritische Fehler aus den durchschnittlichen Qualitätsbewertungen und messen Sie die Zuverlässigkeit bei wiederholten Versuchen.

Bevor man einer Erfolgsmeldung Glauben schenkt, sollte man fragen, was sich geändert hat, welche Einschränkungen weiterhin galten und welche Beweise die Meldung stützen.