τ-bench: Messung der Zuverlässigkeit von KI-Agenten in praxisnahen Tool-Nutzungs-Domänen

Nachdem ich Wochen damit verbracht habe, die Entwicklungslinien von Table-Reasoning und Text-to-SQL nachzuvollziehen, wollte ich einen Schritt zurücktreten und eine andere Frage stellen: Wie gut performen aktuelle Agenten tatsächlich, wenn man sie in einen Live-Betriebszyklus mit einem echten Benutzer versetzt? τ-bench liefert die ehrlichste Antwort, die ich bisher gesehen habe, und die Zahlen sind ernüchternd.

Das Paper

Yao, Shinn, Razavi und Narasimhan – alle an der Princeton University und Sierra Research tätig – veröffentlichten τ-bench (arXiv:2406.12045, Juni 2024), um eine Lücke zu schließen, die im Nachhinein offensichtlich ist: Die meisten Agent-Benchmarks geben dem Modell eine Aufgabe und bewerten die finale Antwort isoliert. Reale Einsätze sehen anders aus. Ein Kundendienst-Agent wird unterbrochen, bekommt Rückfragen gestellt, erhält widersprüchliche Informationen und soll während einer offenen Konversation Geschäftsrichtlinien durchsetzen, bevor er eine Datenbankänderung vornimmt.

τ-bench bettet zwei praxisnahe Kundendienstbereiche – Einzelhandel (Retail) und Fluggesellschaften – in eine Simulationsumgebung ein, in der ein Sprachmodell den Benutzer und ein anderes den Agenten spielt. Der Agent erhält Zugriff auf domänenspezifische APIs (Bestellung stornieren, Sitzplatz ändern, Gutschein anwenden) und ein schriftliches Richtliniendokument, das festlegt, welche Aktionen unter welchen Bedingungen zulässig sind. Die Auswertung bewertet keine Zwischenschritte: Sie vergleicht den finalen Datenbankzustand mit einem annotierten Zielzustand. Die Autoren führen zudem pass^k ein, eine Zuverlässigkeitsmetrik, die fragt, in welchem Anteil der Versuche ein Agent bei k unabhängigen Versuchen derselben Aufgabe konsistent erfolgreich ist.

Kernideen

• pass^k als ehrliche Metrik: Ein einzelner pass@1-Score ist zu fehleranfällig (noisy). pass^k zeigt die Wahrscheinlichkeit auf, dass ein Agent bei jedem einzelnen von k Durchläufen derselben Aufgabe erfolgreich ist – ein Proxy dafür, ob man ihm in der Produktion vertrauen würde.
• Die Konsistenzklippe: GPT-4o im Retail-Bereich erreicht bei pass@1 einen Wert von 0,604, fällt aber bis pass@4 auf 0,383 ab. Das bedeutet, dass es bei etwa 60 % der Aufgaben in mindestens einem von vier Versuchen scheitert – kaum ein produktionsreifer Agent.
• Fluggesellschaften sind schwieriger als Einzelhandel: Der pass@1-Wert von GPT-4o fällt von 0,604 (Retail) auf 0,420 (Fluggesellschaft). Claude 3.5 Sonnet (Version Oktober 2024) schneidet besser ab – 0,692 (Retail) / 0,460 (Fluggesellschaft) bei pass@1 – aber sein pass@4 erreicht dennoch nur 0,462 bzw. 0,225.
• Function Calling schlägt ReAct: Die Function-Calling-Variante von GPT-4o (pass@1 = 0,420 bei Fluggesellschaften) übertrifft sowohl Act (0,365) als auch ReAct (0,325) auf derselben Basis, was darauf hindeutet, dass strukturierte Tool-APIs formatbedingte Fehler reduzieren.
• Benutzersimulation als Variable: Die Autoren verwenden ein Sprachmodell zur Simulation des Benutzers, was eine eigene Varianz einbringt. Ein schwächerer Benutzersimulator kann die Agenten-Scores entweder senken oder erhöhen, je nachdem, wie getreu er adversarisches Benutzerverhalten darstellt.
• Datenbankzustand-Evaluierung umgeht Teilpunkte-Spiele: Der Vergleich des Endzustands anstelle von Dialogschritten bedeutet, dass ein Agent, der eine korrekte Aktion ausführt und diese dann versehentlich rückgängig macht, keine Punkte erhält – was für ein Write-Back-System die richtige Entscheidung ist.

Was Bestand hat – und was nicht

Das pass^k-Konzept ist wirklich nützlich und ich erwarte, dass es diesen spezifischen Benchmark überdauern wird. Die Entscheidung, auf Basis des Datenbankzustands statt auf Token-Ebene zu evaluieren, ist richtig – sie misst direkt, ob der Agent die Aufgabe erfüllt hat, und nicht, ob er die richtigen Worte benutzt hat.

Die Domänen sind jedoch konstruktionsbedingt eng gefasst. Retail und Airline sind prozedural sauber: Die Richtliniendokumente sind endlich und für den Benchmark geschrieben, die APIs sind klein und präzise spezifiziert, und der Benutzersimulator ist standardmäßig kooperativ. Reale Richtliniendokumente sind mehrdeutig; echte Benutzer lügen, erinnern sich falsch und widersetzen sich Ablehnungen. Die Autoren des Benchmarks erkennen dies an – die bloße Existenz von τ²-bench (arXiv:2506.07982) als Nachfolger, der sich auf ein duales Dec-POMDP-Modell erstreckt, bei dem auch der Benutzer den Umgebungszustand manipuliert, ist ein Eingeständnis, dass die Single-Control-Evaluierung die Schwierigkeit unterschätzt.

Es stellt sich auch die Frage, was pass^k tatsächlich misst. Wenn die Benutzersimulation selbst stochastisch ist, vermischt die Varianz über k Versuche die Inkonsistenz des Agenten mit der des Simulators. Das Paper merkt dies an, trennt die beiden Varianzquellen jedoch nicht vollständig. Für sicherheitskritische Anwendungen möchte man die Fehler zuordnen können: Ignoriert der Agent Richtlinien, deutet er die Benutzerabsicht falsch oder wählt er lediglich das falsche Tool-Aufrufformat?

Das Leaderboard auf llm-stats.com zeigt nun Modelle wie Step-3.5-Flash mit 0,882, was nach dramatischem Fortschritt aussähe, wenn man nicht bemerken würde, dass sich das Evaluierungs-Setup wahrscheinlich verschoben hat: Neuere Einträge scheinen unter anderen Versionen des Benutzersimulators und möglicherweise anderen Aufgabenverteilungen bewertet worden zu sein. Quervergleiche zwischen Einträgen bei sich entwickelnden Benchmarks sind immer mit Vorsicht zu genießen.

Warum das für Finanz-KI wichtig ist

Der Beancount-Write-Back-Agent, den ich im Sinn habe, ist strukturell identisch mit den Agenten, die τ-bench evaluiert: Er verfügt über domänenspezifische Tools (Transaktion anhängen, Saldo korrigieren, Eintrag neu kategorisieren), Richtlinienbeschränkungen (geschlossene Perioden nicht ändern, keine negativen Salden erzeugen, dem Kontenplan folgen) und einen Benutzer, der Anweisungen in natürlicher Sprache über eine Konversation hinweg gibt, die viele Runden umfassen kann.

Die Erkenntnisse zu pass^k sind das für uns am besten umsetzbare Ergebnis. Wenn ein State-of-the-Art-Modell wie Claude 3.5 Sonnet ein pass@4 von nur 0,462 im Retail-Bereich erreicht – einer relativ verzeihenden Domäne –, sollten wir eine ähnliche oder schlechtere Konsistenz beim Write-Back ins Hauptbuch erwarten, wo sich Fehler über Transaktionen hinweg potenzieren und Richtlinienverstöße möglicherweise nicht sofort sichtbar sind. Das Design von Anfang an auf k-Versuchs-Konsistenz auszurichten – statt nur pass@1 zu optimieren – verändert die Architektur: Es spricht für eine konservative Tool-Nutzung (fragen vor dem Schreiben, nicht danach), explizite Richtlinienprüfschritte vor jedem API-Aufruf und einen separaten Verifizierer-Agenten, der den vorgeschlagenen Datenbank-Diff prüft, bevor er festgeschrieben wird.

Die Methodik der Datenbankzustands-Evaluierung ist ebenfalls direkt übertragbar. Das strukturierte Dateiformat von Beancount macht es einfach, den erwarteten Zustand des Hauptbuchs mit dem tatsächlichen Zustand nach einer Write-Back-Sitzung zu vergleichen, was uns die gleiche Art von objektivem Evaluierungssignal liefert, das τ-bench verwendet.

Was man als Nächstes lesen sollte

• τ²-bench (arXiv:2506.07982): Der Nachfolger, der auf Dual-Control-Umgebungen erweitert wird, in denen Benutzer ebenfalls Tools aufrufen; direkt relevant, wenn wir den Benutzer als aktiven Teilnehmer an Hauptbuchkorrekturen und nicht nur als passiven Anfragesteller modellieren.
• AgentEval / GAIA (arXiv:2311.12983): Der GAIA-Benchmark bewertet allgemeine KI-Assistenten bei praxisnahen Aufgaben, die Webbrowsing und Tool-Nutzung erfordern; eine nützliche Ergänzung zum domänenspezifischen Fokus von τ-bench.
• WorkArena (arXiv:2403.07718): Evaluiert Agenten bei realen Aufgaben in Unternehmenssoftware innerhalb von ServiceNow; die Domäne ist näher an Buchhaltungs-Workflows als Retail oder Airline und ist für Lektionen zum Aufgabendesign lesenswert.