τ²-bench: Midiendo el costo del control dual en agentes de IA conversacional

He estado leyendo la línea de τ-bench durante las últimas semanas y τ²-bench (arXiv:2506.07982) es el artículo que estaba esperando: finalmente se pregunta qué sucede cuando el usuario no es un dispensador de información pasivo sino un participante activo con su propio conjunto de herramientas. Para cualquiera que esté construyendo un agente de contabilidad conversacional, esa brecha siempre ha sido evidente.

El artículo

Victor Barres, Honghua Dong, Soham Ray, Xujie Si y Karthik Narasimhan (Sierra AI y la Universidad de Toronto) presentan τ²-bench como una extensión directa del τ-bench original. La observación central es que las pruebas de rendimiento anteriores para agentes de IA conversacionales son de control único: solo el agente puede invocar herramientas; el usuario se limita a mensajes en lenguaje natural. El soporte técnico del mundo real rompe esta suposición. Cuando un agente de servicio al cliente te dice que "desactives el modo avión", estás realizando una llamada a una herramienta en tu propio dispositivo, no solo narrando tus preferencias.

Los autores modelan esto como un Proceso de Decisión de Markov Parcialmente Observable Descentralizado (Dec-POMDP), donde tanto el agente como el simulador de usuario tienen espacios de acción distintos (llamadas a funciones y mensajes) sobre un estado del mundo compartido y dinámico. El lado del agente se parece a un CRM estándar: puede consultar registros de clientes, habilitar el roaming o reemplazar una SIM. El lado del usuario es un teléfono simulado con herramientas de lectura (get_status_bar, get_sim_status) y herramientas de escritura (toggle_airplane_mode, toggle_data, reseat_sim_card). La prueba de rendimiento se lanza con un nuevo dominio de telecomunicaciones (114 tareas muestreadas de 2,285 variantes generadas programáticamente) junto con los dominios verificados de comercio minorista (115 tareas) y aerolíneas (50 tareas) del τ-bench original.

Ideas clave

• Formalismo de control dual: La representación Dec-POMDP separa limpiamente lo que cada jugador observa y qué herramientas puede llamar cada uno. Esto es más riguroso que el concepto ad-hoc de "usuario con un teléfono" que se podría añadir a un entorno de agente único existente.
• Generador de tareas compositivo: Las tareas se ensamblan a partir de 15 grupos de subtareas atómicas que cubren tres tipos de intención (service_issue, mobile_data_issue, mms_issue) con un escalado de dificultad explícito según el número de pasos de resolución requeridos.
• Rendimiento en telecomunicaciones (pass¹): GPT-4.1 alcanza solo el 34%; o4-mini el 42%; Claude 3.7 Sonnet el 49%; GPT-4.1-mini alrededor del 50%. Todos los modelos obtienen puntuaciones sustancialmente más bajas aquí que en comercio minorista o aerolíneas.
• Penalización por control dual: Una ablación compara el modo Predeterminado (el usuario tiene herramientas) con el modo Sin Usuario (el agente controla cada herramienta por sí mismo). GPT-4.1 cae 18 puntos porcentuales; o4-mini cae 25 puntos. Esta brecha es el costo de coordinarse con un usuario activo, desvinculado de la pura dificultad de razonamiento.
• Brecha del plan oráculo: Incluso cuando se le entrega al agente la secuencia completa de acciones de antemano, el rendimiento no llega al 100%, lo que nos indica que la ejecución y la coordinación con el usuario añaden errores además de la planificación.
• Las herramientas de usuario estructuradas reducen drásticamente el ruido del simulador: El simulador de usuario de telecomunicaciones produce solo un 16% de errores (6% críticos), en comparación con el 40% de errores (12% críticos) para el comercio minorista en el τ-bench original. La mejora proviene de reemplazar las instrucciones de usuario de lenguaje natural sueltas con una interfaz de herramientas estrictamente limitada que rastrea el estado del dispositivo.

Lo que se sostiene — y lo que no

El marco Dec-POMDP es una de las formulaciones de problemas más cuidadosas que he visto en la evaluación comparativa de agentes. El generador de tareas programático es genuinamente útil: proporciona tareas demostrablemente correctas y una complejidad explícitamente controlable, a diferencia de las colecciones de tareas hechas a mano que plagan la mayoría de las pruebas de rendimiento. Las cifras de confiabilidad del simulador de usuario son convincentes; reducir los errores críticos del 12% al 6% importa mucho cuando intentas confiar en tu señal de evaluación.

Dicho esto, el dominio de las telecomunicaciones es estrecho. Cuatro clientes, nueve líneas, cinco planes: esto es un laboratorio controlado, no un sistema empresarial. Los números pass¹ para gpt-4.1-mini y Claude 3.7 Sonnet (~50%) parecen sorprendentemente altos considerando lo difícil que los autores dicen que es el dominio, lo que me hace preguntar si 114 tareas son suficientes para evitar que ejecuciones afortunadas inflen las puntuaciones. Los autores reconocen que su conjunto de tareas es una submuestra. También encuentro delgado el análisis de la personalidad del usuario: el artículo muestra que la personalidad "Difícil" (jubilado de 64 años con baja confianza tecnológica) es más difícil que la personalidad "Fácil", lo cual no es sorprendente. Lo que me gustaría ver es si el tipo de falla de coordinación difiere: ¿una personalidad más difícil produce más errores de razonamiento o más errores de comunicación?

El artículo tampoco explora qué sucede cuando el documento de política del agente es incorrecto o está incompleto, lo cual es un escenario realista para implementaciones de producción. Cada resultado asume que el agente recibe políticas precisas.

Por qué esto es importante para la IA financiera

La suposición de control único integrada en τ-bench, WorkArena y la mayoría de las pruebas de rendimiento de diálogo orientadas a tareas se aplica mal al escenario de soporte real de Beancount. Un usuario que le pide a un agente de Beancount que corrija su libro mayor no está simplemente narrando un problema; puede estar editando simultáneamente el archivo en su editor de texto, ejecutando bean-check o cargando una nueva exportación CSV de su banco. Ese es un entorno de control dual exactamente en el sentido de τ²-bench.

La caída de 18 a 25 puntos porcentuales al cambiar del modo Sin Usuario al modo Predeterminado es la cifra a la que seguiré volviendo. Sugiere que incluso si construyéramos un agente de Beancount que fuera casi perfecto en la manipulación autónoma de libros mayores, la introducción de un usuario activo que comparte el acceso de escritura reduciría las tasas de éxito en aproximadamente una cuarta parte. Los diseños de escritura segura que hemos estado considerando (GuardAgent, ShieldAgent, MCP verificable) fueron diseñados para entornos de control único; necesitan ser replanteados si el usuario también es un agente que llama a herramientas sobre el mismo entorno.

La mejora de la confiabilidad del simulador de usuario también es directamente aplicable. Si quiero realizar evaluaciones fuera de línea de un agente de Beancount sin reclutar contadores humanos, acoplar estrechamente al usuario simulado a un entorno de libro mayor determinista —en lugar de confiar en el juego de roles de LLM de forma libre— es la decisión de ingeniería correcta.

Qué leer a continuación

• τ-bench (Yao et al., arXiv:2406.12045): La base que este extiende; vale la pena leer la construcción de tareas original y el diseño de la métrica pass^k antes de interpretar los resultados de τ²-bench.
• ToolSandbox (Lu et al., arXiv:2408.04682): Introduce herramientas con estado para una evaluación de agentes detallada; la arquitectura más relevante para diseñar un banco de pruebas de control dual para Beancount.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 tareas dentro de una empresa de software simulada con herramientas internas reales; la prueba de rendimiento de automatización empresarial más realista disponible actualmente y el próximo artículo en mi lista de lectura.