Welche vergangenen Fälle in ein Agenten-Testset gehören und welche nicht ins Tuning dürfen

Welche vergangenen Fälle sich eignen

Ein vergangener Fall ist nur nützlich, wenn Sie das richtige Ergebnis kennen und den Agenten daran messen können. Verwenden Sie Fälle, die alle diese Bedingungen erfüllen:

• Der Fall ist abgeschlossen und sein Endergebnis ist dokumentiert, etwa eine Rechnung, die freigegeben, angehalten oder mit Begründung abgelehnt wurde
• Zwei Personen, die den Prozess kennen, kämen anhand derselben Dokumente zum selben Urteil; mit diesem Kriterium beschreibt Anthropic eine eindeutige Eval-Aufgabe
• Die Entscheidung lässt sich mit Informationen treffen, die beim Eingang vorlagen. Hat ein Sachbearbeiter den Fall nach einem Telefonat ohne Notiz gelöst, kann der Agent dieses Ergebnis nicht treffen
• Sie können die Eingaben rekonstruieren: die Dokumente, die relevanten Datensätze im damaligen Zustand und die damals geltende Richtlinie

Dokumentierte Ergebnisse sind nicht automatisch richtig. Bevor ein Fall in das Set kommt, bestätigt oder korrigiert eine Fachperson das Ergebnis und notiert die Begründung. Scheitern leistungsfähige Agentenversionen über viele Läufe an einem Fall, prüfen Sie zuerst den Fall und seine Bewertungslogik, bevor Sie den Agenten verantwortlich machen. Der Leitfaden von Anthropic sieht eine Erfolgsquote nahe null als häufiges Zeichen für eine fehlerhafte Aufgabe, der Fall kann aber auch tatsächlich schwierig sein.

Eine Mischung, die der tatsächlichen Arbeit entspricht

Ziehen Sie den Großteil des Sets im Verhältnis zum realen Volumen je Fallart. Ergänzen Sie dann gezielt Fälle, denn teure Fehler sind selten und gehen bei einer Zufallsstichprobe unter.

• Routinefälle je Fallart, ungefähr in den Anteilen der letzten Monate
• Bekannte Ausnahmen wie Teillieferungen, abweichende Währungen, doppelt eingereichte Belege und Dokumente in einer anderen Sprache
• Fälle, in denen die richtige Aktion ist, anzuhalten und den Fall an eine Person zu übergeben
• Fälle, in denen ein Tool oder eine Datenquelle nichts, einen Fehler oder veraltete Daten liefert
• Später jeder bestätigte Fehler aus der Produktion, reduziert auf das, was zur Reproduktion nötig ist

Anthropic empfiehlt ausgewogene Sets, die prüfen, wann ein Verhalten eintreten soll und wann nicht, damit ein Set, das nur Abschlüsse belohnt, das Team nicht zu einem Agenten drängt, der nie eskaliert.

Ein hypothetisches Beispiel: Für einen Agenten zum Rechnungsabgleich könnte ein erstes Set mit 80 Fällen 44 Standardabgleiche enthalten, 12 Abweichungen innerhalb der Toleranz, 8 Abweichungen außerhalb der Toleranz, die angehalten werden müssen, 8 Rechnungen ohne Bestellung, die eskaliert werden müssen, 4 Dubletten und 4 Fälle, in denen die ERP-Abfrage fehlschlägt. Ihre Anteile ergeben sich aus Ihrer eigenen Fallhistorie.

Da die gezielt ergänzten Fälle überrepräsentiert sind, entspricht die Gesamtquote dieses Sets nicht der Quote, die Sie in Produktion erwarten können. Weisen Sie jede Kategorie getrennt aus oder gewichten Sie die Kategorien nach ihrer tatsächlichen Häufigkeit, bevor Sie sie zusammenfassen.

Der Teil, an dem niemand optimiert

Teilen Sie die Fälle auf, bevor der erste Prompt entsteht. Das Entwicklungsset dient dazu, Transkripte zu lesen, Prompts anzupassen, Beispiele auszuwählen und Tools zu korrigieren. Das zurückgehaltene Set wird nur bewertet und nach Kategorien zusammengefasst; niemand ändert den Agenten mit Blick auf seine Fälle.

Machine-Learning-Teams wenden dieselbe Disziplin auf Testdaten an. Der Machine Learning Crash Course von Google weist darauf hin, dass sich Testsets durch wiederholte Nutzung abnutzen und Dubletten zwischen Trainings- und Testdaten die Ergebnisse schönen.

Wie Sie aufteilen, hängt davon ab, was das zurückgehaltene Set messen soll. Muss der Agent Lieferanten oder Dokumentvorlagen bewältigen, die er nie gesehen hat, halten Sie alle Fälle eines Lieferanten oder einer Vorlage auf einer Seite, damit Vertrautheit die Bewertung nicht schönt. Bringt die Produktion überwiegend bekannte Lieferanten, sind Fälle desselben Lieferanten auf beiden Seiten ein fairer Test; entfernen Sie aber exakte oder nahezu exakte Kopien desselben Dokuments. Diese Handlungen gelten als Tuning am zurückgehaltenen Set:

• Einen zurückgehaltenen Fall oder eine enge Umschreibung davon als Beispiel in den Prompt übernehmen
• Eine Regel in den Prompt schreiben, nachdem man gelesen hat, warum ein bestimmter zurückgehaltener Fall gescheitert ist
• Zwei Agentenversionen iterativ verbessern, indem man immer wieder prüft, welche mehr zurückgehaltene Fälle besteht

Sobald ein zurückgehaltener Fall den Agenten beeinflusst hat, verschieben Sie ihn ins Entwicklungsset und ersetzen ihn durch einen neuen Fall aus der aktuellen Arbeit.

Was jeder Falldatensatz enthält

Speichern Sie jeden Fall als Datensatz, den das Evaluations-Harness ohne Rückfragen ausführen kann. Diese Skizze für den hypothetischen Rechnungsagenten ist kein Schema eines Anbieters.

case_id: inv-0147
split: held_out             # development | held_out
category: price_deviation_outside_tolerance
group_key: supplier-2291    # used when the split is by supplier
source_ref: ERP document 5100231 (pseudonymised copy)
inputs:
  documents: [invoice.pdf, purchase_order.json, goods_receipt.json]
  system_snapshot: snapshots/inv-0147/erp-2026-06-03.json
  policy_version: ap-tolerance-policy v4
expected_outcome:
  action: hold
  reason_code: PRICE_ABOVE_TOLERANCE
must_not:
  - post_invoice
  - change_vendor_master_data
graders:
  - deterministic: action and reason_code match
  - rubric: hold note names the line and the price difference
reviewed_by: AP team lead, 2026-09-18

Am wichtigsten sind das erwartete Ergebnis als prüfbarer Zustand, die verbotenen Aktionen und der Systemstand beim Eingang. Ohne diesen Snapshot kann ein Fall scheitern, nur weil die Bestellung inzwischen geschlossen wurde.

Personenbezogene Daten in vergangenen Fällen

Vergangene Fälle enthalten oft Namen, Bankverbindungen oder Gesundheitsdaten. Behalten Sie nur, was die Entscheidung reproduziert, pseudonymisieren Sie Kennungen, die das Ergebnis nicht beeinflussen, und halten Sie die Herkunft jedes Falls fest, damit er auf Anfrage entfernt werden kann. Ob echte Fälle überhaupt zum Testen genutzt werden dürfen, entscheidet Ihr Datenschutzbeauftragter.

Wann das Testset Sie in die Irre führt

• Es wurde aus den Fällen gebaut, die leicht zu bewerten waren, und beschreibt deshalb nur die einfache Hälfte der Arbeit
• Der Prozess oder die Richtlinie hat sich geändert und alte erwartete Ergebnisse sind nun falsch. Prüfen Sie Fälle erneut, sobald sich die Version der Richtlinie ändert

Geben Sie dem Set eine verantwortliche Person und versionieren Sie es zusammen mit dem Agenten. Ein praktischer erster Schritt: Ziehen Sie die abgeschlossenen Fälle der letzten drei Monate für einen Prozess, lassen Sie die verantwortliche Person die Fälle markieren, denen sie als Referenz vertrauen würde, und sehen Sie, wie viele übrig bleiben.

KI-Agenten und Prozessautomatisierung