Einen Evaluationsrahmen für Agenten-Aufgaben aufbauen

Ziel

Entscheiden, ob eine Änderung an Prompt, Toolset oder Modell einen Agenten bei den Aufgaben, für die er tatsächlich eingesetzt wird, besser oder schlechter macht, mit einer über Läufe hinweg vergleichbaren Zahl statt eines Eindrucks aus wenigen Transkripten.

Voraussetzungen

Eine Aufgabenliste mit einem prüfbaren Endzustand je Aufgabe (eine Datenbankzeile, eine Datei, ein Rückgabewert); eine Umgebung, die zwischen Läufen zurückgesetzt werden kann (Container, Fixture-Datenbank, aufgezeichnete HTTP-Antworten); ein Budget für wiederholte Läufe. τ-bench ist ein dokumentiertes Beispiel für diese Form: Der Agent arbeitet mit domänenspezifischen Tools und Richtlinienregeln gegen einen simulierten Nutzer, und die Publikation wertet aus, indem der Datenbankzustand am Ende der Konversation mit einem annotierten Zielzustand verglichen wird. Frameworks wie Inspect (UK AI Security Institute) beschreiben eine Evaluation als zusammensetzbare Bausteine (Datensätze, Agenten, Tools und Scorer) und bieten Sandboxing für nicht vertrauenswürdigen Modellcode sowie Tool-Freigabe.

Schritte

1. Aufgaben aus dem realen Einsatz sammeln: gescheiterte Sitzungen, Support-Tickets, Grenzfälle, nicht nur einfache Erfolge. Jede als Eingabe plus Oracle (erwarteter Endzustand oder eine deterministische Prüfung) formulieren, nie als erwartetes Transkript.
2. Die Umgebung einfrieren: Tool-Versionen, Seed-Daten und aufgezeichnete externe Antworten fixieren, damit ein fehlgeschlagener Lauf mit identischen Eingaben wiederholt werden kann.
3. Den Endzustand im Code bewerten. Eine modellbewertete Rubrik nur dort einsetzen, wo keine deterministische Prüfung existiert, und sie anhand einer Stichprobe menschlicher Labels kalibrieren.
4. Jede Aufgabe k-mal ausführen. Die τ-bench-Publikation schlägt pass^k vor, die Wahrscheinlichkeit, dass alle k Versuche gelingen, neben dem üblichen pass@k; beide berichten, da die Lücke zwischen ihnen die Inkonsistenz des Agenten ausdrückt.
5. Kosten, Schritte und Tokens je Lauf zusammen mit dem Score erfassen, damit eine Verbesserung, die die Kosten verdoppelt, sichtbar wird.
6. Eine zurückgehaltene Menge führen, die beim Anpassen der Prompts nie verwendet wird; Ergebnisse aus Tuning und aus der zurückgehaltenen Menge getrennt berichten.
7. Die Konfiguration (Modell, Prompt-Version, Toolset, Seed) zu jedem Ergebnis speichern und den Rahmen bei jeder Prompt- oder Modelländerung ausführen.

Erwartetes Ergebnis

Ein Score je Aufgabe und je Lauf mit Konfidenzband, eine Liste von Aufgaben, die zwischen Versuchen zwischen Erfolg und Fehlschlag wechseln, sowie Kosten je abgeschlossener Aufgabe, alles reproduzierbar aus der gespeicherten Konfiguration.

Grenzen und Prüfbasis

Die zitierte Publikation berichtet, dass zum damaligen Zeitpunkt hochmoderne Function-Calling-Agenten bei unter 50 Prozent ihrer Aufgaben erfolgreich und inkonsistent waren (pass^8 unter 25 Prozent in ihrer Retail-Domäne); für andere Agenten oder Aufgaben werden hier keine Zahlen behauptet. Modellbewertete Bewertung übernimmt die Verzerrungen des Bewerters, kleine Aufgabenmengen ergeben breite Konfidenzbänder, und der Rahmen misst nur, was seine Aufgaben abdecken.