Trajectory Evaluation für AI-Agenten: den Weg statt nur das Ergebnis prüfen

Trajectory Evaluation prüft die Folge von Beobachtungen, Entscheidungen, Tool Calls, Antworten der Umgebung, Freigaben und State Transitions zwischen Anfrage und Endergebnis. Ein Outcome Grader beantwortet, ob die Aufgabe erledigt wurde; ein Trajectory Grader prüft, ob der Agent erlaubte Quellen und Tools verwendet, Policies eingehalten, Side Effects nicht doppelt ausgeführt und auf Fehler korrekt reagiert hat. Für eine read-only Frage genügt manchmal ein Outcome Check. Bei Zahlung, Kundennachricht, Repository-Änderung oder PII-Verarbeitung ist die Sicherheit des Pfads eine eigene Release-Bedingung.

Verlangen Sie keine einzige kanonische Schrittfolge: Gute Agenten können dieselbe Aufgabe auf unterschiedlichen legitimen Wegen lösen. Definieren Sie stattdessen Invarianten, erlaubte Action Classes, verbotene Ereignisse und den autoritativen Terminal State. Ein guter Grader akzeptiert mehrere sichere Trajektorien, lässt aber Secret Leakage, unautorisierten Write, versteckten Fehler, Duplicate Action oder eine finale Antwort ohne Evidence unabhängig von der Überzeugungskraft des Outputs durchfallen.

Ein minimaler Trace enthält Task ID, Tenant-/User-Kontext, Model- und Agent-Revision, Policy-Version, Fingerprint des Initial State, Observation, Decision Event, Tool Name und Version, Argumente oder deren sicheren Hash, Authorization Verdict, Tool-Result-Status, Retry-/Idempotency-Key, Approval Event, Side-Effect-Receipt, finale Antwort und Terminal State. Timestamps und Parent-Child-IDs ermöglichen die Rekonstruktion der kausalen Reihenfolge paralleler Schritte. Sensitive Payloads sollten nicht unkontrolliert kopiert werden: Redacted Evidence speichern und ein separat geschütztes Raw Artifact nur dann vorhalten, wenn es begründet ist.

Der Trace muss aus Orchestration und Tool Boundary stammen, nicht aus dem Self-Report des Modells. Die Aussage „Ich habe das CRM geprüft“ beweist keinen CRM-Aufruf; ein schön formuliertes Chain-of-Thought ist kein Audit Log und wird für die Prüfung externer Aktionen nicht benötigt. Loggen Sie beobachtbare Ereignisse, Versionen und Postconditions. Fehlt bei einem folgenreichen Run Telemetrie, lautet das Verdict INCONCLUSIVE statt PASS.

Teilen Sie das Verdict in Planning Relevance, Tool Correctness, Authority, State Integrity und Recovery. Planning Relevance erkennt zwecklose Loops und fehlende notwendige Prüfungen. Tool Correctness prüft Tool-Auswahl, schema-valide Argumente und Response Handling. Authority ordnet jede Aktion Identity, Scope, Approval und aktuellem State zu. State Integrity vergleicht das behauptete Ergebnis mit dem System of Record. Recovery prüft Timeout, Partial Commit, Rate Limit, stale Approval und Dependency Failure.

Efficiency wird erst nach Correctness und Safety bewertet. Weniger Schritte sind nicht besser, wenn der Agent einen Identity Check übersprungen hat; mehr Schritte sind nicht schlechter, wenn sie eine notwendige Bestätigung liefern. Nützliche Measures sind Task Success, Critical-Invariant-Failures, Rate ungültiger oder unautorisierter Calls, Duplicate Side Effects, unnötige Calls, Recovery Success, Evidence Coverage, Latenz und Kosten pro sicher abgeschlossener Aufgabe. Ein kritischer Fehler und Token-Einsparungen gehören nicht in einen gemeinsamen Durchschnittsscore.

• Outcome → autoritativer Terminal State erfüllt den Task Contract.
• Trajectory → jeder Schritt ist erlaubt, relevant und durch Evidence belegt.
• Policy → kein Hard Invariant wird verletzt.
• Recovery → unsicherer State wird vor einem Retry reconciled.
• Efficiency → nur unter sicheren erfolgreichen Runs bewerten.

Deterministische Grader sollten zuerst Schema, Allowlists, Identity und Scope, Aktualität des Approvals, Idempotency, verbotene Ereignisse und autoritative Postconditions prüfen. Ein Model Grader eignet sich für semantische Plan-Relevanz, ausreichende Evidence oder Qualität einer Escalation, sollte aber einen strukturierten Trace und eine Rubric statt eines unkontrollierten Transcripts erhalten. Human Review bleibt für hochriskante mehrdeutige Fälle und die Kalibrierung des Graders.

Validieren Sie den Grader auf einem gelabelten Set aus positiven, negativen und Boundary Cases. Messen Sie Disagreement je Risk Slice statt nur eine globale Agreement Rate. Versionieren Sie Prompt, Rubric, Grader Model und Threshold gemeinsam mit dem Agent Bundle. Ein Model Grader darf einen deterministischen Security Failure nicht überstimmen; eine selbstbewusste Erklärung macht einen unautorisierten Write nicht zulässig.

Das Eval Set sollte Tool Timeout vor einem Write und nach Partial Commit, malformed Result, 429, stale Data, Schema Drift, entzogene Berechtigung, abgelaufenes Approval, Cross-Tenant-Objekt, Prompt Injection im Tool Output, Duplicate Event, widersprüchliche Quellen, nicht verfügbaren Oracle und eine Aufgabe enthalten, bei der Abstention korrekt ist. Definieren Sie für jede Fixture Initial State, injected Fault, erlaubte Transitions, verbotene Ereignisse und Terminal Oracle.

Besonders wichtig ist „reconcile before retry“: Nach einem unsicheren Write liest der Agent das System of Record über den Operation Key und entscheidet erst dann, ob die Aktion wiederholt oder der Run beendet wird. Testen Sie auch Compensation. Wenn der Workflow einen Draft erstellt, ihn aber nicht mit dem Case verknüpfen konnte, bleibt ein Orphan zurück oder wird ein Owner Task geöffnet? Gerade Partial Success unterscheidet Production Trajectory Eval von einer Tool-Calling-Demo.

Führen Sie Frozen Regression Set, Held-out Cases und einen Fault-Injection-Slice auf gepinntem Model, Prompt, Tools, Policy und Environment aus. Promotion verlangt akzeptable Outcomes in jedem kritischen Slice, null definierte Hard-Invariant-Failures, einen kompatiblen Grader und getesteten Rollback. Starten Sie Canary mit read-only oder draft-only Authority; Write Scope wird in einer separaten Entscheidung erweitert und nicht als Belohnung für einen besseren Durchschnittsscore.

Nach einer Änderung von Model, Tool Schema, Permission Policy, Retry Logic oder Grader wird das vorherige Verdict zu historischer Evidence. Rollback stellt das komplette kompatible Bundle wieder her, stoppt neue Runs und reconciled nicht abgeschlossene Side Effects. Reduzieren Sie einen Production Incident auf einen privacy-safe Regression Case. So wird Evaluation zu einem laufenden Release Control statt zu einer einmaligen Tabelle, die nach dem Pilot feierlich vergessen wird.