τ-bench: De betrouwbaarheid van AI-agents meten in praktijkgerichte toolgebruik-domeinen

Na wekenlang de evolutie van table-reasoning en text-to-SQL te hebben gevolgd, wilde ik uitzoomen en een andere vraag stellen: hoe goed presteren de huidige agents eigenlijk zodra je ze in een live operationele loop met een echte gebruiker plaatst? τ-bench geeft het meest eerlijke antwoord dat ik tot nu toe heb gezien, en de cijfers zijn ontnuchterend.

Het artikel

Yao, Shinn, Razavi en Narasimhan — allen verbonden aan Princeton en Sierra Research — publiceerden τ-bench (arXiv:2406.12045, juni 2024) om een gat te vullen dat achteraf gezien overduidelijk is: de meeste agent-benchmarks geven het model een taak en beoordelen het eindantwoord in isolatie. Echte implementaties zien er niet zo uit. Een klantenservice-agent wordt onderbroken, krijgt vervolgvragen, krijgt tegenstrijdige informatie en wordt geacht het zakelijke beleid te handhaven gedurende een open gesprek voordat er een wijziging in de database wordt aangebracht.

τ-bench omvat twee praktijkgerichte klantenservicedomeinen — retail en luchtvaart — in een simulatieomgeving waarin het ene taalmodel de gebruiker speelt en het andere de agent. De agent heeft toegang tot domeinspecifieke API's (een bestelling annuleren, een stoel wijzigen, een kortingsbon toepassen) en een geschreven beleidsdocument dat specificeert welke acties onder welke voorwaarden zijn toegestaan. De evaluatie scoort geen tussenstappen: het vergelijkt de uiteindelijke databasestatus met een geannoteerde doelstatus. De auteurs introduceren ook pass^k, een betrouwbaarheidsmetriek die vraagt welk deel van de proeven een agent consistent succesvol afrondt over k onafhankelijke pogingen bij dezelfde taak.

Belangrijkste concepten

• pass^k als de eerlijke metriek: een enkele pass@1-score bevat te veel ruis. pass^k laat de waarschijnlijkheid zien dat een agent slaagt bij elk van de k herhalingen van dezelfde taak — een indicator of je het systeem in productie zou vertrouwen.
• De consistentie-vallei: GPT-4o in retail scoort 0,604 bij pass@1, maar zakt naar 0,383 bij pass@4. Dat betekent dat hij bij ongeveer 60% van de taken minstens één keer faalt in vier pogingen — nauwelijks een agent die veilig is voor productie.
• Luchtvaart is lastiger dan retail: de pass@1 van GPT-4o daalt van 0,604 (retail) naar 0,420 (luchtvaart). Claude 3.5 Sonnet (versie van oktober 2024) doet het beter — 0,692 retail / 0,460 luchtvaart bij pass@1 — maar de pass@4 bereikt nog steeds slechts respectievelijk 0,462 en 0,225.
• Function calling verslaat ReAct: de function-calling variant van de GPT-4o agent (pass@1 = 0,420 in luchtvaart) presteert beter dan zowel Act (0,365) als ReAct (0,325) op hetzelfde model, wat suggereert dat gestructureerde tool-API's fouten door opmaak verminderen.
• Gebruikerssimulatie is een variabele: de auteurs gebruiken een taalmodel om de gebruiker te simuleren, wat eigen variantie introduceert. Een zwakkere gebruikerssimulator kan de scores van de agent verlagen of verhogen, afhankelijk van hoe getrouw deze vijandig gebruikersgedrag vertegenwoordigt.
• Evaluatie op basis van databasestatus omzeilt discussies over gedeeltelijke punten: het vergelijken van de eindstatus in plaats van dialoogstappen betekent dat een agent die een correcte actie onderneemt en deze vervolgens onbedoeld ongedaan maakt, geen punten krijgt — wat de juiste beslissing is voor een write-back systeem.

Wat overeind blijft — en wat niet

Het pass^k-kader is werkelijk nuttig en ik verwacht dat het deze specifieke benchmark zal overleven. De beslissing om te evalueren op basis van de databasestatus in plaats van overeenkomst op token-niveau is correct — het meet direct of de agent de taak heeft volbracht, niet of hij de juiste dingen heeft gezegd.

De domeinen zijn echter bewust beperkt gehouden. Retail en luchtvaart zijn procedureel overzichtelijk: de beleidsdocumenten zijn eindig en specifiek voor de benchmark geschreven, de API's zijn klein en goed gedefinieerd, en de gebruikerssimulator is standaard coöperatief. In de echte wereld zijn beleidsdocumenten ambigu; echte gebruikers liegen, herinneren zich dingen verkeerd en gaan in tegen weigeringen. De auteurs van de benchmark erkennen dit — het bestaan van τ²-bench (arXiv:2506.07982) als vervolg, dat zich uitbreidt naar een dual-control Dec-POMDP-model waarbij de gebruiker ook de omgevingsstatus manipuleert, is een erkenning dat evaluatie met enkelvoudige controle de moeilijkheidsgraad onderschat.

Er is ook de vraag wat pass^k feitelijk meet. Als de gebruikerssimulatie zelf stochastisch is, wordt de variantie over k pogingen een vermenging van agent-inconsistentie en simulator-inconsistentie. Het artikel merkt dit op, maar scheidt de twee bronnen van variantie niet volledig. Voor veiligheidskritische toepassingen zou je de fouten willen toewijzen: negeert de agent het beleid, begrijpt hij de intentie van de gebruiker verkeerd, of kiest hij gewoon het verkeerde formaat voor de tool-aanroep?

Het klassement op llm-stats.com toont nu modellen zoals Step-3.5-Flash op 0,882, wat een enorme vooruitgang zou lijken als je niet merkt dat de evaluatie-opstelling waarschijnlijk is veranderd: nieuwe inzendingen lijken te zijn gescoord met andere versies van de gebruikerssimulator en mogelijk andere taakverdelingen. Vergelijkingen tussen verschillende inzendingen op evoluerende benchmarks zijn altijd verdacht.

Waarom dit belangrijk is voor financiële AI

De Beancount write-back agent die ik in gedachten heb, is structureel identiek aan de agents die τ-bench evalueert: hij heeft domeinspecifieke tools (een transactie toevoegen, een saldo corrigeren, een post hercategoriseren), beleidskaders (pas geen gesloten periodes aan, creëer geen negatieve saldi, volg het rekeningschema) en een gebruiker die instructies geeft in natuurlijke taal gedurende een gesprek dat vele beurten kan beslaan.

De bevinding over pass^k is voor ons het meest bruikbare resultaat. Als een state-of-the-art model zoals Claude 3.5 Sonnet een pass@4 van slechts 0,462 behaalt in retail — een relatief vergevingsgezind domein — moeten we vergelijkbare of slechtere consistentie verwachten bij grootboek-write-back, waar fouten zich door transacties heen opstapelen en beleidsschendingen mogelijk niet direct zichtbaar zijn. Ontwerpen voor consistentie over k pogingen vanaf het begin — in plaats van alleen pass@1 optimaliseren — verandert de architectuur: het pleit voor conservatief toolgebruik (eerst vragen, dan schrijven), expliciete beleidscontrolestappen vóór elke API-aanroep, en een afzonderlijke verifiërende agent die het voorgestelde database-verschil (diff) controleert voordat het wordt doorgevoerd.

De evaluatiemethode op basis van databasestatus is ook direct overdraagbaar. Het gestructureerde bestandsformaat van Beancount maakt het eenvoudig om het verwachte grootboek te vergelijken met de werkelijke status na een write-back sessie, wat ons hetzelfde soort objectieve evaluatiesignaal geeft als τ-bench gebruikt.

Wat nu te lezen

• τ²-bench (arXiv:2506.07982): het vervolg dat zich uitbreidt naar dual-control omgevingen waar gebruikers ook tools aanroepen; direct relevant als we de gebruiker modelleren als een actieve deelnemer aan grootboekcorrecties in plaats van een passieve aanvrager.
• AgentEval / GAIA (arXiv:2311.12983): de GAIA-benchmark evalueert algemene AI-assistenten op praktijktaken die webbrowsen en toolgebruik vereisen; een nuttige aanvulling op de domeinspecifieke focus van τ-bench.
• WorkArena (arXiv:2403.07718): evalueert agents op echte taken in bedrijfssoftware in ServiceNow; het domein ligt dichter bij boekhoudkundige workflows dan retail of luchtvaart en is de moeite waard voor lessen over taakontwerp.