τ-bench: Mesurant la fiabilitat dels agents d'IA en dominis d'ús d'eines del món real

Després de passar setmanes rastrejant el llinatge del raonament de taules i del text-a-SQL, volia allunyar-me i fer una pregunta diferent: fins a quin punt funcionen realment els agents actuals un cop els poses en un bucle operatiu en viu amb un usuari real? τ-bench dóna la resposta més honesta que he vist, i les xifres són corprenedores.

L'article

Yao, Shinn, Razavi i Narasimhan — tots de Princeton i Sierra Research — van publicar τ-bench (arXiv:2406.12045, juny de 2024) per omplir un buit que és obvi en retrospectiva: la majoria dels benchmarks d'agents lliuren una tasca al model i avaluen la seva resposta final de forma aïllada. Els desplegaments reals no són així. Un agent d'atenció al client rep interrupcions, se li fan preguntes de seguiment, se li lliura informació contradictòria i s'espera que apliqui la política de l'empresa al llarg d'una conversa oberta abans de realitzar qualsevol canvi a la base de dades.

τ-bench agrupa dos dominis d'atenció al client del món real — comerç minorista i línies aèries — en un entorn de simulació on un model de llenguatge fa d'usuari i un altre d'agent. L'agent té accés a APIs específiques del domini (cancel·lar una comanda, canviar un seient, aplicar un cupó) i a un document de política escrit que especifica quines accions estan permeses i sota quines condicions. L'avaluació no puntua els passos intermedis: compara l'estat final de la base de dades amb un estat objectiu anotat. Els autors també introdueixen pass^k, una mètrica de fiabilitat que demana quina fracció de les proves un agent supera de manera consistent en k intents independents de la mateixa tasca.

Idees clau

• pass^k com la mètrica honesta: una única puntuació pass@1 és massa sorollosa. pass^k exposa la probabilitat que un agent tingui èxit en cadascuna de les k reexecucions de la mateixa tasca — un indicador de si hi confiaries en producció.
• El penya-segat de la consistència: GPT-4o en comerç minorista obté un 0,604 a pass@1 però cau fins al 0,383 a pass@4. Això vol dir que en aproximadament el 60% de les tasques falla almenys una vegada en quatre intents — difícilment un agent segur per a producció.
• El sector aeri és més difícil que el minorista: el pass@1 de GPT-4o cau del 0,604 (retail) al 0,420 (airline). Claude 3.5 Sonnet (versió d'octubre de 2024) ho fa millor — 0,692 retail / 0,460 airline a pass@1 — però el seu pass@4 encara només arriba al 0,462 i 0,225 respectivament.
• La crida de funcions supera ReAct: la variant de l'agent de crida de funcions de GPT-4o (pass@1 = 0,420 en línies aèries) supera tant Act (0,365) com ReAct (0,325) sobre el mateix nucli, el que suggereix que les APIs d'eines estructurades redueixen les fallades induïdes pel format.
• La simulació de l'usuari és una variable: els autors utilitzen un model de llenguatge per simular l'usuari, la qual cosa introdueix la seva pròpia variància. Un simulador d'usuari més feble pot desinflar o inflar les puntuacions de l'agent segons com de fidelment representi el comportament d'un usuari adversari.
• L'avaluació de l'estat de la base de dades evita els jocs de crèdit parcial: comparar l'estat final en lloc dels passos del diàleg significa que un agent que realitza una acció correcta i després la reverteix inadvertidament no rep cap crèdit — que és el que correspon a un sistema d'escriptura.

Què es manté — i què no

L'enfocament de pass^k és realment útil i espero que perduri més enllà d'aquest benchmark específic. La decisió d'avaluar l'estat de la base de dades en lloc de la semblança a nivell de token és encertada — mesura directament si l'agent ha complert la tasca, no si ha dit les paraules adequades.

Els dominis, però, són estrets per disseny. El comerç minorista i les línies aèries són procedimentalment nets: els documents de política són finits i estan escrits per al benchmark, les APIs són petites i ben especificades, i el simulador d'usuari és cooperatiu per defecte. Els documents de política del món real són ambigus; els usuaris reals menteixen, recorden malament i es resisteixen a les denegacions. Els autors del benchmark ho reconeixen — la mateixa existència de τ²-bench (arXiv:2506.07982) com a continuació, que s'estén a un model Dec-POMDP de control dual on l'usuari també manipula l'estat de l'entorn, és una admissió que l'avaluació de control únic subestima la dificultat.

També hi ha la qüestió de què mesura realment pass^k. Si la simulació de l'usuari és estocàstica en si mateixa, la variància a través de k proves barreja la inconsistència de l'agent amb la inconsistència del simulador. L'article ho assenyala però no separa totalment les dues fonts de variància. Per a aplicacions crítiques per a la seguretat, voldries atribuir les fallades: l'agent ignora la política, llegeix malament la intenció de l'usuari o simplement tria el format de crida d'eina incorrecte?

La classificació a llm-stats.com mostra ara models com Step-3.5-Flash a 0,882, la qual cosa semblaria un progrés dramàtic si no tinguéssim en compte que la configuració de l'avaluació probablement ha variat: les noves entrades semblen estar puntuades sota versions diferents del simulador d'usuari i possiblement amb divisions de tasques diferents. La comparació creuada en benchmarks que evolucionen sempre és sospitosa.

Per què això és important per a la IA financera

L'agent d'escriptura de Beancount que tinc en ment és estructuralment idèntic als agents que avalua τ-bench: té eines específiques del domini (afegir una transacció, corregir un saldo, recategoritzar una entrada), restriccions de política (no modificar períodes tancats, no crear saldos negatius, seguir el pla de comptes) i un usuari que dóna instruccions en llenguatge natural al llarg d'una conversa que pot durar molts torns.

La troballa de pass^k és el resultat més aplicable per a nosaltres. Si un model d'última generació com Claude 3.5 Sonnet aconsegueix un pass@4 de només 0,462 en comerç minorista — un domini relativament tolerant — hauríem d'esperar una consistència similar o pitjor en l'escriptura del llibre major, on els errors s'acumulen a través de les transaccions i les violacions de la política poden no ser visibles immediatament. Dissenyar per a la consistència de k proves des del principi — no només optimitzar el pass@1 i donar-ho per acabat — canvia l'arquitectura: advoca per un ús conservador de les eines (preguntar abans d'escriure, no després), passos explícits de verificació de polítiques abans de qualsevol crida a l'API i un agent verificador independent que auditi el diff proposat de la base de dades abans que s'executi.

La metodologia d'avaluació de l'estat de la base de dades també és directament traslladable. El format de fitxer estructurat de Beancount fa que sigui senzill fer un diff de l'estat esperat del llibre major amb l'estat real després d'una sessió d'escriptura, donant-nos el mateix tipus de senyal d'avaluació objectiva que utilitza τ-bench.

Què llegir a continuació

• τ²-bench (arXiv:2506.07982): la continuació que s'estén a entorns de control dual on els usuaris també invoquen eines; directament rellevant si modelem l'usuari com un participant actiu en les correccions del llibre major en lloc d'un sol·licitant passiu.
• AgentEval / GAIA (arXiv:2311.12983): el benchmark GAIA avalua assistents d'IA generals en tasques del món real que requereixen navegació web i l'ús d'eines; un complement útil al focus específic de domini de τ-bench.
• WorkArena (arXiv:2403.07718): avalua agents en tasques reals de programari empresarial a ServiceNow; el domini està més a prop dels fluxos de treball comptables que el comerç minorista o les línies aèries i val la pena llegir-lo per les lliçons de disseny de tasques.