τ²-bench: Mesurant el cost del control dual en agents d'IA conversacional

He estat llegint el llinatge τ-bench durant les últimes setmanes i τ²-bench (arXiv:2506.07982) és l'article que estava esperant veure: finalment es pregunta què passa quan l'usuari no és un simple dispensador passiu d'informació, sinó un participant actiu amb el seu propi conjunt d'eines. Per a qualsevol persona que construeixi un agent de comptabilitat conversacional, aquesta bretxa sempre ha estat evident.

L'article

Victor Barres, Honghua Dong, Soham Ray, Xujie Si i Karthik Narasimhan (Sierra AI i la Universitat de Toronto) presenten τ²-bench com una extensió directa del τ-bench original. L'observació central és que els punts de referència (benchmarks) anteriors per a agents d'IA conversacional són de control únic: només l'agent pot invocar eines; l'usuari està limitat a missatges en llenguatge natural. El suport tècnic del món real trenca aquesta suposició. Quan un agent d'atenció al client et diu que "desactivis el mode avió", estàs realitzant una crida a una eina al teu propi dispositiu, no només narrant les teves preferències.

Els autors ho modelen com un Procés de Decisió de Markov Parcialment Observable Descentralitzat (Dec-POMDP), on tant l'agent com el simulador d'usuari tenen espais d'acció diferents (crides a funcions i missatges) sobre un estat del món compartit i dinàmic. El costat de l'agent sembla un CRM estàndard: pot consultar registres de clients, activar el roaming o substituir una SIM. El costat de l'usuari és un telèfon simulat amb eines de lectura (get_status_bar, get_sim_status) i eines d'escriptura (toggle_airplane_mode, toggle_data, reseat_sim_card). El benchmark s'entrega amb un nou domini de telecomunicacions (114 tasques mostrejades de 2.285 variants generades programàticament) juntament amb els dominis verificats de venda al detall (115 tasques) i aerolínies (50 tasques) del τ-bench original.

Idees clau

• Formalisme de control dual: La representació Dec-POMDP separa clarament el que observa cada jugador i quines eines pot utilitzar cadascú. Això és més rigorós que el sistema ad-hoc d'"usuari amb un telèfon" que es podria afegir a una plataforma existent d'agent únic.
• Generador de tasques compositiu: Les tasques s'assemblen a partir de 15 grups de subtasques atòmiques que cobreixen tres tipus d'intenció (service_issue, mobile_data_issue, mms_issue) amb un escalat de dificultat explícit segons el nombre de passos de resolució requerits.
• Rendiment en telecomunicacions (pass¹): GPT-4.1 arriba només al 34%; o4-mini al 42%; Claude 3.7 Sonnet al 49%; GPT-4.1-mini al voltant del 50%. Tots els models puntuen substancialment més baix aquí que en els dominis de venda al detall o aerolínies.
• Penalització de control dual: Una ablació compara el mode per defecte (l'usuari té eines) contra el mode sense usuari (l'agent controla cada eina ell mateix). GPT-4.1 cau 18 punts percentuals; o4-mini cau 25 punts. Aquesta bretxa és el cost de coordinar-se amb un usuari actiu, desvinculat de la pura dificultat de raonament.
• Bretxa del pla de l'oracle: Fins i tot quan se li entrega a l'agent la seqüència d'accions completa per endavant, el rendiment no arriba al 100%, cosa que ens indica que l'execució i la coordinació amb l'usuari afegeixen errors a sobre de la planificació.
• Les eines d'usuari estructurades redueixen dràsticament el soroll del simulador: El simulador d'usuari de telecomunicacions produeix només un 16% d'errors (6% crítics), en comparació amb el 40% d'errors (12% crítics) de la venda al detall en el τ-bench original. La millora prové de substituir els missatges d'usuari de llenguatge natural lliure per una interfície d'eines estrictament limitada que rastreja l'estat del dispositiu.

Què es manté — i què no

L'enfocament Dec-POMDP és una de les formulacions de problemes més curoses que he vist en el benchmarking d'agents. El generador de tasques programàtic és realment útil: proporciona tasques demostrablement correctes i una complexitat controlable explícitament, a diferència de les col·leccions de tasques fetes a mà que plaguem la majoria de benchmarks. Les xifres de fiabilitat del simulador d'usuari són convincents: reduir els errors crítics del 12% al 6% és molt important quan intentes confiar en el teu senyal d'avaluació.

Dit això, el domini de les telecomunicacions és estret. Quatre clients, nou línies, cinc plans: això és un laboratori controlat, no un sistema empresarial. Les xifres de pass¹ per a gpt-4.1-mini i Claude 3.7 Sonnet (~50%) semblen sorprenentment altes donada la dificultat que els autors diuen que té el domini, cosa que em fa preguntar-me si 114 tasques són suficients per evitar que les tirades afortunades inflin les puntuacions. Els autors reconeixen que el seu conjunt de tasques és una submostra. També trobo que l'anàlisi de la persona de l'usuari és feble: l'article mostra que la persona "Difícil" (jubilat de 64 anys amb poca confiança tecnològica) és més difícil que la persona "Fàcil", cosa que no sorprèn. El que m'agradaria veure és si el tipus de fallada de coordinació difereix: ¿una persona més difícil produeix més errors de raonament o més errors de comunicació?

L'article tampoc explora què passa quan el document de política de l'agent és erroni o incomplet, que és un escenari realista per a desplegaments en producció. Tots els resultats assumeixen que l'agent rep polítiques precises.

Per què això importa per a les finances amb IA

L'assumpció de control únic integrada a τ-bench, WorkArena i la majoria de benchmarks de diàleg orientats a tasques s'ajusta malament a l'escenari real de suport de Beancount. Un usuari que demana a un agent de Beancount que corregeixi el seu llibre major no està simplement narrant un problema; pot estar editant simultàniament el fitxer al seu editor de text, executant bean-check o pujant una nova exportació CSV del seu banc. Aquest és un entorn de control dual exactament en el sentit de τ²-bench.

La caiguda de 18-25 punts percentuals en passar del mode Sense Usuari al mode Per Defecte és la xifra a la qual tornaré constantment. Suggereix que fins i tot si construíssim un agent de Beancount que fos gairebé perfecte en la manipulació autònoma del llibre major, la introducció d'un usuari actiu que comparteixi l'accés d'escriptura reduiria les taxes d'èxit aproximadament en una quarta part. Els dissenys d'escriptura segura que hem estat considerant (GuardAgent, ShieldAgent, MCP verificable) van ser dissenyats per a entorns de control únic; s'han de repensar si l'usuari també és un agent que crida eines sobre el mateix entorn.

La millora de la fiabilitat del simulador d'usuari també és directament aplicable. Si vull realitzar avaluacions fora de línia d'un agent de Beancount sense reclutar comptables humans, acoblar estretament l'usuari simulat a un entorn de llibre major determinista —en lloc de confiar en el joc de rol lliure d'un LLM— és la decisió d'enginyeria correcta.

Què llegir a continuació

• τ-bench (Yao et al., arXiv:2406.12045): La base que aquest amplia — val la pena llegir la construcció de la tasca original i el disseny de la mètrica pass^k abans d'interpretar els resultats de τ²-bench.
• ToolSandbox (Lu et al., arXiv:2408.04682): Introdueix eines amb estat per a l'avaluació detallada d'agents; l'arquitectura més rellevant per dissenyar un banc de proves de Beancount de control dual.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 tasques dins d'una empresa de software simulada amb eines internes reals; el benchmark d'automatització empresarial més realista disponible actualment i el següent article a la meva llista de lectura.