Ein fehlerfreier Lauf ist noch kein richtig bearbeiteter Fall

Ein sauberer Lauf mit falschem Ergebnis

Nehmen Sie einen hypothetischen Agenten für die Schadenaufnahme. Der Trace zeigt drei erfolgreiche Tool-Aufrufe: Er hat die Police gesucht, den Schadenfall angelegt und dem Kunden eine Bestätigung geschickt. Keine Fehler, normale Latenz, normaler Tokenverbrauch. Der Kunde hat jedoch zwei Policen, die Suche hat den ersten Treffer geliefert, und der Schadenfall hängt nun an der Hausratpolice statt an der Kfz-Police.

Jedes technische Signal ist grün, und die Zusammenfassung des Agenten meldet, dass der Schadenfall erfasst wurde. Der Leitfaden von Arize zur Agentenbewertung sagt es direkt: Ergebnisprüfungen sollen den tatsächlichen Systemzustand lesen, nicht die Bestätigungsnachricht des Agenten. Die Bestätigung stammt vom Agenten selbst und kann deshalb nicht der Beleg dafür sein, dass er richtig lag.

Drei Fragen mit unterschiedlichen Belegen

Der Leitfaden von Anthropic zu Agenten-Evals trennt das Transkript, also die Aufzeichnung von Ausgaben, Tool-Aufrufen und Überlegungen, vom Ergebnis, also dem Endzustand der Umgebung, etwa ob eine Reservierung in der Datenbank existiert. Für einen Prozessagenten ergeben sich daraus drei getrennte Fragen:

• Zustand des Laufs: Ist der Lauf beendet, welche Aufrufe sind fehlgeschlagen, wie lange hat er gedauert und was hat er gekostet? Belege sind Spans und Metriken
• Weg: Hat der Agent die erlaubten Schritte eingehalten, wo nötig eine Freigabe eingeholt und Schleifen vermieden? Beleg ist der Trace
• Ergebnis: Ist der resultierende Zustand der Geschäftsdaten für diesen Fall richtig? Beleg ist eine Abfrage im führenden System nach dem Lauf

Ein Monitoring, das sich auf Laufzustand, Fehler und Latenz beschränkt, beantwortet die erste Frage gut und die dritte gar nicht. Ergebnisprüfungen können in dieselbe Telemetrie und dieselben Alarme einfließen; die Lücke liegt in dem, was instrumentiert ist. Prozessverantwortliche interessiert vor allem die dritte Frage.

Eine Ergebnisprüfung für einen Fall schreiben

1. 1

   Den erwarteten Endzustand festlegen

   Beschreiben Sie ihn über Datensätze, nicht über Aktionen: Es gibt genau einen Schadenfall, verknüpft mit Police P-2, Schadenart Sturm, Status wartet auf Begutachtung.

2. 2

   Das führende System lesen

   Fragen Sie nach dem Lauf das System für die Schadenbearbeitung direkt ab, mit Zugangsdaten, die der Agent nicht nutzt. Verwenden Sie nicht die Tool-Ausgabe, die der Agent gesehen hat.

3. 3

   Prüfen, was sich nicht ändern durfte

   Kein zweiter Schadenfall, keine Änderung der Kundenadresse, keine Nachricht an andere Personen als den Versicherungsnehmer.

4. 4

   Teile getrennt bewerten

   Richtige Police, richtige Schadenart und richtiger Status sind getrennte Prüfungen. Anthropic empfiehlt Teilpunkte für mehrteilige Aufgaben, was auch zeigt, welcher Teil am häufigsten scheitert.

Wofür der Trace weiterhin nützlich ist

Die Bewertung des Ergebnisses macht Traces nicht weniger wichtig. Scheitert eine Ergebnisprüfung, zeigt der Trace, wo der Fall entgleist ist: ein mehrdeutiges Suchergebnis, ein vom Modell erfundenes Tool-Argument oder ein Dokument, das nie gelesen wurde. Die OpenTelemetry-Semantik-Konventionen für generative KI beschreiben Spans wie invoke_agent und execute_tool mit Attributen wie gen_ai.tool.name und error.type. Sie haben noch den Status Development, geben aber unterschiedlichen Frameworks eine gemeinsame Form für diese Daten.

Manche Regeln zum Weg sind zudem harte Anforderungen. Wenn eine Richtlinie verlangt, dass eine Auszahlung vorher freigegeben wird, ist eine korrekte Auszahlung ohne Freigabe trotzdem ein Fehler. Anthropic rät davon ab, eine feste Schrittfolge zu bewerten, weil das gültige Alternativen bestraft; Arize schlägt vor, die Anforderungen zu prüfen, die alle gültigen Wege teilen. Schreiben Sie in der Praxis Wegprüfungen nur für Regeln, die wirklich verbindlich sind, und überlassen Sie den Rest dem Ergebnis.

Ergebnis und Trace gemeinsam lesen

• Richtiges Ergebnis, regelkonformer Weg: Der Fall ist bestanden
• Richtiges Ergebnis, Regel unterwegs verletzt: ein Fehler, auch wenn der Datensatz gut aussieht
• Falsches Ergebnis, sauberer Lauf: die gefährlichste Kombination, weil Fehler- und Latenzalarme stumm bleiben. Prüfen Sie Tool-Daten, mehrdeutige Eingaben und die Überlegungen des Modells
• Falsches Ergebnis mit Fehlern im Lauf: meist ein Problem der Fehlerbehandlung, bei dem der Agent nach einem fehlgeschlagenen oder unvollständigen Tool-Ergebnis weitergemacht hat

Weisen Sie die dritte Gruppe als eigene Kennzahl aus. Sie ist der Anteil der Fälle, den Dashboards mit reinen Fehler- und Latenzdaten nicht sehen können und den Ergebnisprüfungen auffangen sollen.

Wenn sich das Ergebnis schwer prüfen lässt

Nicht jedes Ergebnis ist ein Feld in einer Datenbank. Eine Antwort an einen Kunden, eine Zusammenfassung für einen Gutachter oder eine Zahlung, die erst Tage später verbucht wird, braucht einen anderen Ansatz. Verzögerte Ergebnisse brauchen eine zweite Prüfung zu dem Zeitpunkt, an dem die Wirkung eingetreten sein sollte. Texte brauchen ein Bewertungsraster, das ein kalibrierter Modell-Judge oder Menschen anwenden. Anthropic empfiehlt, Modell-Judges ausdrücklich die Antwort unbekannt zu erlauben und sie mit menschlichen Fachleuten abzugleichen.

Eine nützliche erste Übung: Nehmen Sie zwanzig aktuelle Läufe ohne Fehler, prüfen Sie jedes Ergebnis von Hand im führenden System und zählen Sie, wie viele falsch waren. Diese Zahl zeigt, ob Ergebnisprüfungen Priorität haben.