Tau-Bench: KI-Agenten testen, wo es wirklich zählt - Kundenservice

Die meisten KI-Agenten-Benchmarks geben dem Modell eine Aufgabe und lassen es isoliert arbeiten. Keine nervigen Menschen. Keine mehrdeutigen Richtlinien. Kein Hin und Her. Das ist bequem für die Evaluation, spiegelt aber nicht wider, wie Agenten tatsächlich eingesetzt werden.

Tau-bench (Tool-Agent-User Interaction Benchmark) von Sierra macht etwas anderes: Es versetzt den Agenten in ein realistisches Kundenservice-Szenario, in dem er mit einem simulierten Nutzer sprechen, komplexe Domänenrichtlinien befolgen und die richtigen API-Aufrufe an eine echte Datenbank machen muss - alles gleichzeitig. Und dann geht Tau-squared-bench noch weiter, indem es dem Nutzer eigene Werkzeuge und Handlungsfähigkeit gibt und eine Dual-Control-Umgebung schafft, in der beide Seiten auf die Welt einwirken können.

TL;DR

Tau-bench simuliert echte Kundenservice-Interaktionen, bei denen ein LLM den Nutzer spielt und der Agent Informationen sammeln, Richtlinien befolgen und Datenbankoperationen über mehrturnige Konversation ausführen muss.
Die Evaluation prüft fundierte Ergebnisse, nicht subjektive Konversationsqualität. Im ursprünglichen Benchmark bedeutet das den finalen Datenbankzustand plus erforderliche nutzerrelevante Informationen; in Tau-squareds Telekommunikationsdomäne werden aufgabenspezifische Assertionsfunktionen über den finalen Weltzustand verwendet.
Die pass^k-Metrik misst Konsistenz, nicht nur einmaligen Erfolg. Sie fragt: Wenn Sie dieselbe Aufgabe k-mal ausführen, gelingt sie jedes Mal? Zum Beispiel fällt GPT-4o von ~61% (pass^1) auf unter 25% (pass^8) bei Retail-Aufgaben.

Warum Tau-Bench wichtig ist

Hier ist das Szenario: Sie bauen einen KI-Agenten für den Kundensupport einer Fluggesellschaft oder eines Online-Shops. Ihr Agent muss Reservierungen nachschlagen, Stornierungsrichtlinien und Gepäckbestimmungen prüfen, vielleicht einen Flug umbuchen - alles während er mit einem Nutzer spricht, der vage sein könnte, mitten im Gespräch seine Meinung ändert oder etwas verlangt, was die Richtlinie nicht erlaubt.

Das ist der Kern-Anwendungsfall für KI-Agenten in der Produktion. Und genau hier versagen die meisten Benchmarks. Sie testen Tool-Aufrufe isoliert (kann das Modell den richtigen Funktionsaufruf generieren?) oder evaluieren auf statischen Datensätzen, bei denen alle Informationen von vornherein gegeben sind.

Tau-bench schließt diese Lücke, indem es drei Fähigkeiten gleichzeitig testet:

Mehrturnige Konversation mit einem Menschen. Der Nutzer gibt nicht alles in einer Nachricht preis. Er enthüllt Informationen schrittweise, braucht manchmal Nachfragen und stellt möglicherweise zusammengesetzte Anfragen.
Domänenspezifische Richtlinienkonformität. Der Agent erhält ein detailliertes Richtliniendokument (z.B. “Basic-Economy-Flüge können nicht geändert werden” oder “Umtausch ist nur bei gelieferten Bestellungen möglich”) und muss es präzise befolgen, selbst wenn die Anfrage des Nutzers im Widerspruch zu den Regeln steht.
Korrekte Tool-Nutzung mit einer echten Datenbank. Der Agent interagiert über Python-API-Tools mit JSON-Datenbanken - sucht Nutzer, fragt Flüge ab, ändert Bestellungen. Falsche Argumente, fehlende Felder oder inkorrekte Sequenzen führen zum Scheitern.

Das LLM als Nutzer

Der Nutzer in Tau-bench wird von einem Sprachmodell gespielt. Jede Aufgabe enthält eine versteckte Anweisung, die dem simulierten Nutzer mitteilt, wer er ist, was er will und wie er sich verhalten soll:

“Sie sind Mei Davis aus PLZ 80217. Sie möchten die Wasserflasche zurückgeben und das Tierbett sowie den Bürostuhl gegen die günstigste Version umtauschen. Erwähnen Sie die beiden Dinge zusammen. Wenn Sie nur eines der beiden tun können, bevorzugen Sie das, was Ihnen am meisten Geld spart, aber Sie wollen die Ersparnis in beiden Varianten wissen. Sie haben Schulden und sind heute traurig, aber sehr wortkarg.”

Der Agent sieht diese Anweisung nie. Er sieht nur die Nachrichten des Nutzers, die natürlich aus der Interpretation des Szenarios durch das LLM entstehen. Das erzeugt stochastische Variation - dieselbe Aufgabe läuft jedes Mal anders ab, weil der Nutzer Dinge anders formuliert, Informationen in anderer Reihenfolge preisgibt oder unvorhersehbar auf die Fragen des Agenten reagiert.

Diese Stochastizität ist ein Feature, kein Bug. Sie ermöglicht die pass^k-Metrik (mehr dazu unten) und spiegelt echte Kundeninteraktionen wider, bei denen dieselbe zugrundeliegende Anfrage auf unzählige Arten auftreten kann.

Wie die Evaluation funktioniert: Fundierte Ergebnisprüfungen

Hier wird Tau-bench elegant. Anstatt zu versuchen, Konversationsqualität mit einem freien LLM-Richter zu beurteilen, bewertet es fundierte Ergebnisse anhand vorab definierter Erfolgskriterien.

In den ursprünglichen Retail- und Airline-Domänen ist jede Aufgabe um einen einzigen korrekten Endzustand gemäß der Domänenrichtlinie herum konzipiert. Falls eine Aufgabe mehrere gültige Ergebnisse zulassen würde, verfeinern die Autoren die Anweisungen, bis nur ein definierter Zielzustand verbleibt.

Die Belohnungsfunktion ist binär: r = r_action x r_output, wobei:

r_action = 1 wenn der Endzustand die fundierten Aktionskriterien der Aufgabe erfüllt. Im ursprünglichen Tau-bench ist das primär ein Datenbankzustandsabgleich mit dem definierten Zielzustand.
r_output = 1 wenn die Antworten des Agenten an den Nutzer alle notwendigen Informationen enthielten (zum Beispiel den richtigen Erstattungsbetrag oder andere erforderliche Details)

Beide Bedingungen müssen erfüllt sein. Ein Agent, der die richtigen Datenbankänderungen vornimmt, aber dem Nutzer falsche Preisinformationen gibt, scheitert trotzdem. Ein Agent, der perfekt kommuniziert, aber das falsche API aufruft, scheitert ebenfalls.

Tau-squared erweitert dies weiter. Sein Evaluationsmenü umfasst DB-Prüfungen, Kommunikationsinformations-Prüfungen, natürlichsprachliche Assertionen, Aktionsabgleich und Zustandsassertionen; in der Telekommunikationsdomäne werden Aufgaben laut Paper mit Assertionsfunktionen statt einfachen Datenbankvergleichen evaluiert.

Die Pass^k-Metrik: Zuverlässigkeit messen

Hier enthüllt Tau-bench etwas Unbequemes über aktuelle KI-Agenten.

Die Standardmetrik in Agenten-Benchmarks ist pass@k: Hat der Agent mindestens einmal in k Versuchen Erfolg gehabt? Das misst Entdeckung - kann der Agent bei genügend Versuchen eine Lösung finden? Das ist nützlich für Code-Generierung, wo man Testsuiten durchlaufen kann, um die richtige Antwort auszuwählen.

Tau-bench führt pass^k (pass-hat-k) ein: Hat der Agent in allen k Versuchen Erfolg gehabt? Das misst Zuverlässigkeit - können Sie sich darauf verlassen, dass dieser Agent denselben Anfragetyp konsistent bearbeitet?

Für den Kundenservice zählt Zuverlässigkeit. Sie können nicht jede Kundeninteraktion acht Mal durchführen und die beste auswählen. Jedes Gespräch muss funktionieren.

Die Ergebnisse sind ernüchternd. GPT-4o, das beste Modell im Originalpaper, erreicht:

61,2% pass^1 bei Retail (etwa 6 von 10 Aufgaben gelöst)
~25% pass^8 bei Retail (nur 1 von 4 Aufgaben konsistent über 8 Durchläufe gelöst)
35,2% pass^1 bei Airline (kaum ein Drittel)

Die Kluft zwischen pass^1 und pass^8 offenbart Fragilität. Der Agent scheitert nicht nur gelegentlich an schwierigen Aufgaben - er scheitert inkonsistent an Aufgaben, die er manchmal lösen kann. Kleine Variationen in der Formulierung des Nutzers oder im Sampling des LLMs selbst kippen das Ergebnis.

Wo Agenten scheitern

Die Autoren analysierten 36 gescheiterte GPT-4o-Trajektorien bei Retail-Aufgaben und fanden drei Hauptkategorien des Scheiterns:

Falsche Argumente oder Informationen. Der Agent ruft das richtige API auf, aber mit falschen Parametern - falsche Artikel-IDs, falsche Zahlungsmethoden, inkorrekte Preisberechnungen. Oder er nennt dem Nutzer den falschen Gesamtpreis, was dazu führt, dass der Nutzer Entscheidungen auf Basis falscher Informationen trifft, was kaskadenartig zu einem inkorrekten Datenbankzustand führt.

Falsche Entscheidungsfindung. Der Agent missversteht oder ignoriert die Domänenrichtlinie. Zum Beispiel besagt die Richtlinie: “Alle umzutauschenden Artikel müssen in einer Liste gesammelt und in einem API-Aufruf umgetauscht werden”, aber der Agent tauscht Artikel einzeln um, wodurch der zweite Umtausch fehlschlägt, weil der Umtausch nur einmal pro Bestellung aufgerufen werden kann.

Teilweise Lösung zusammengesetzter Anfragen. Wenn ein Nutzer mehrere Dinge verlangt (Adressen auf allen Bestellungen ändern, einen Artikel zurückgeben und einen anderen umtauschen), bearbeitet der Agent einen Teil der Anfrage und hört auf. Er verliert den Überblick über den gesamten Aufgabenumfang im Verlauf der mehrturnigen Konversation.

Tau-Squared: Die Fortsetzung mit Nutzer-Handlungsfähigkeit

Ein Jahr nach dem Original adressierte Tau-squared-bench eine fundamentale Einschränkung von Tau-bench: Im ursprünglichen Setup kann nur der Agent Werkzeuge nutzen. Der Nutzer redet nur.

Im echten Kundenservice ist das oft nicht so. Denken Sie an technischen Support: Der Agent sagt “bitte starten Sie Ihr Telefon neu” und der Kunde muss es tatsächlich tun. Der Nutzer hat Handlungsfähigkeit über seine eigene Umgebung, und der Agent muss ihn durch Aktionen leiten, die Ergebnisse verifizieren und sich anpassen, wenn etwas nicht wie erwartet funktioniert.

Tau-squared modelliert dies als Decentralized Partially Observable Markov Decision Process (Dec-POMDP) - ein Framework, in dem zwei Spieler (Agent und Nutzer) jeweils eigene Aktionsräume, Beobachtungsräume und Werkzeuge haben und auf einen gemeinsamen Weltzustand einwirken, den keiner vollständig beobachtet.

Die neue Telekommunikationsdomäne

Die Haupterweiterung ist eine Telekommunikations-Kundenservice-Domäne, in der Nutzer mit Telefonproblemen anrufen - kein Service, mobile Daten funktionieren nicht, MMS-Fehler. Der entscheidende Unterschied: Der Nutzer hat eigene Werkzeuge, die mit seinem Telefon interagieren.

Der Agent hat CRM-Tools wie get_customer_by_id, get_details_by_id und enable_roaming. Der Nutzer hat telefonseitige Tools wie get_network_status, toggle_data, toggle_airplane_mode und reseat_sim_card. Der Agent kann das Kundenkonto einsehen und Backend-Änderungen vornehmen, aber er kann das Telefon des Nutzers nicht direkt sehen oder steuern. Er muss den Nutzer anweisen, den Telefonstatus zu prüfen, Einstellungen umzuschalten oder die SIM-Karte neu einzusetzen - und dann die gemeldeten Beobachtungen interpretieren, um das Problem zu diagnostizieren.

Das erzeugt genuines kollaboratives Problemlösen. Eine typische Trajektorie sieht so aus:

Nutzer: “Meine mobilen Daten funktionieren nicht.”
Agent: “Könnten Sie Ihren Netzwerkstatus prüfen?”
Nutzer ruft get_network_status() auf -> sieht, dass mobile Daten deaktiviert sind
Nutzer: “Es scheint, dass meine Daten deaktiviert sind.”
Agent: “Könnten Sie Ihre Daten durch Umschalten aktivieren?”
Nutzer ruft toggle_data() auf -> “Mobile Daten sind jetzt EIN.”
Nutzer: “Erledigt, mobile Daten sind jetzt an.”

Die Telekommunikationsdomäne hat 5 Tarife, 9 Leitungen, 4 Kunden, mit 15 Schreib- und 15 Lese-Tools für den Nutzer, plus 6 Schreib- und 7 Lese-Tools für den Agenten. 114 kuratierte Aufgaben werden aus einem viel größeren Pool von 2.285 programmatisch generierten Kombinationen ausgewählt.

Kompositionaler Aufgabengenerator

Eine der größten Verbesserungen in Tau-squared ist die Art der Aufgabenerstellung. Anstatt jedes Szenario von Hand zu erstellen, verwendet der Benchmark einen kompositionalen Aufgabengenerator, der vielfältige Aufgaben aus atomaren Bausteinen aufbaut.

Jede atomare Teilaufgabe wird durch drei Funktionstypen definiert:

Initialisierungsfunktionen richten das Problem ein (z.B. set_airplane_mode(True))
Lösungsfunktionen spezifizieren die benötigten Werkzeuge zur Behebung (z.B. toggle_airplane_mode())
Assertionsfunktionen verifizieren, dass die Behebung funktioniert hat (z.B. assert_service_status("connected"))

Atomare Teilaufgaben werden so gruppiert, dass sich gegenseitig ausschließende Alternativen in derselben Gruppe sind. Zusammengesetzte Aufgaben werden erstellt, indem Teilaufgaben aus verschiedenen Gruppen ausgewählt und kombiniert werden. Die Aufgabenkorrektheit wird automatisch verifiziert: Wenn alle Assertionsfunktionen nach Anwendung der Lösungsfunktionen bestehen (aber nicht vorher), ist die Aufgabe gültig.

Dieser Ansatz gewährleistet beweisbare Korrektheit, vollständige Domänenabdeckung, explizite Kontrolle über den Schwierigkeitsgrad (durch Variation der Teilaufgabenanzahl) und eliminiert den manuellen Aufwand und die potenzielle Fragilität handgefertigter Aufgabensuiten.

Nutzer-Personas für mehr Realismus

Tau-squared führt Nutzer-Personas mit unterschiedlicher technischer Expertise ein:

Einfache Persona: Ein 41-jähriger Büroadministrator, vertraut mit grundlegenden Telefonfunktionen, bevorzugt klare Schritt-für-Schritt-Anleitungen
Schwierige Persona: Ein 64-jähriger pensionierter Bibliothekar, begrenzte technische Kenntnisse, wird leicht nervös, macht sich Sorgen um Fotoverlust beim Neustart

Die schwierige Persona schneidet bei allen Modellen merklich schlechter ab - nicht weil die zugrundeliegende Aufgabe anders ist, sondern weil der Agent seinen Kommunikationsstil anpassen und mit ängstlichen, verwirrten Nutzern umgehen muss, die mit besorgten Fragen unterbrechen. Interessanterweise schneidet die “None”-Persona (keine Persona-Information) auf dem Niveau oder schlechter als die schwierige Persona ab, was unterstreicht, wie wichtig es ist, mit gut definierten Nutzerprofilen zu testen.

Was das für die Entwicklung von KI-Agenten bedeutet

Richtlinienkonformität ist eine eigenständige Fähigkeit neben Tool-Nutzung. Eine Ablation im Originalpaper entfernte das Richtliniendokument aus dem System-Prompt des Agenten. Bei Retail-Aufgaben (einfachere Richtlinien) sank GPT-4o nur um 4,4%. Bei Airline-Aufgaben (komplexe Richtlinien) sank es um 22,4%. Der Agent nutzte ohnehin meist gesunden Menschenverstand für einfache Regeln - das Richtliniendokument half nur bei komplexen, domänenspezifischen Einschränkungen. Das bedeutet, dass Agenten gezielt auf Richtlinienbefolgung evaluiert werden müssen, nicht nur auf Tool-Aufrufe.

Konsistenz zählt mehr als Spitzenleistung. Die pass^k-Metrik sollte jeden nervös machen, der Agenten einsetzt. Ein Agent, der zu 60% erfolgreich ist, aber nicht zuverlässig dieselbe Aufgabe zweimal bewältigt, ist eine Belastung in der Produktion. Die Kluft zwischen pass^1 und pass^8 ist der Punkt, an dem das Vertrauen in der realen Welt zusammenbricht.

Nutzer anzuleiten ist fundamental anders als allein zu handeln. Die Tau-squared-Ergebnisse beweisen, dass Kommunikation und Koordination mit aktiven Nutzern ein eigenständiger Engpass sind - nicht nur eine Steuer auf die Reasoning-Leistung. Agenten, die Probleme autonom lösen können, scheitern möglicherweise trotzdem, wenn sie einen Menschen durch dieselben Schritte anleiten müssen.

Nutzersimulation wird ein erstklassiges Forschungsproblem. Beide Paper ringen mit der Zuverlässigkeit LLM-basierter Nutzersimulatoren. Tau-squareds Ansatz, Nutzerverhalten durch Werkzeuge einzuschränken, ist eine vielversprechende Richtung, aber die 16% Fehlerquote in der besten Domäne bedeutet immer noch, dass etwa 1 von 6 Gesprächen durch Simulatorartefakte kontaminiert ist.

Das größere Bild

Tau-bench und Tau-squared stehen für einen Wandel in der Art, wie wir über Agenten-Evaluation denken. Anstatt isolierte Fähigkeiten zu testen (kann man eine Funktion aufrufen? kann man das Web durchsuchen?), testen sie die gesamte Schleife: Konversation, Reasoning, Richtlinienkonformität, Tool-Nutzung und jetzt Koordination - alles auf einmal, alles in einem realistischen Setting.

Die Benchmarks sind Open Source (Tau-bench auf GitHub, Tau-squared auf GitHub) und relativ günstig durchzuführen (~40$ für einen vollständigen Durchlauf über alle Domänen). Wenn Sie kundenorientierte KI-Agenten bauen, gehören diese zu den engsten Annäherungen an reale Leistung, die heute existieren.