Tau-Bench: Probando agentes de IA donde realmente importa - atención al cliente

La mayoría de los benchmarks de agentes de IA le dan al modelo una tarea y lo dejan trabajar de forma aislada. Sin humanos molestos. Sin políticas ambiguas. Sin intercambio. Eso es conveniente para la evaluación, pero no refleja cómo se despliegan realmente los agentes.

Tau-bench (Tool-Agent-User Interaction Benchmark) de Sierra hace algo diferente: coloca al agente en un escenario realista de atención al cliente donde tiene que hablar con un usuario simulado, seguir políticas de dominio complejas y hacer las llamadas API correctas a una base de datos real - todo al mismo tiempo. Y luego Tau-squared-bench va más allá al darle al usuario sus propias herramientas y agencia, creando un entorno de control dual donde ambos lados pueden actuar sobre el mundo.

TL;DR

Tau-bench simula interacciones reales de atención al cliente donde un LLM interpreta al usuario y el agente debe recopilar información, seguir políticas y ejecutar operaciones de base de datos a través de conversación multi-turno.
La evaluación verifica resultados fundamentados, no calidad subjetiva de conversación. En el benchmark original eso significa el estado final de la base de datos más la información requerida para el usuario; en el dominio de telecomunicaciones de Tau-squared se usan funciones de aserción específicas por tarea sobre el estado final del mundo.
La métrica pass^k mide consistencia, no solo éxito de un solo intento. Pregunta: si ejecutas la misma tarea k veces, ¿tienes éxito todas las veces? Por ejemplo, GPT-4o cae de ~61% (pass^1) a menos del 25% (pass^8) en tareas de retail.

Por qué importa Tau-Bench

Este es el escenario: estás construyendo un agente de IA para manejar soporte al cliente de una aerolínea o una tienda. Tu agente necesita buscar reservaciones, verificar políticas sobre cancelaciones y límites de equipaje, quizás reprogramar un vuelo - todo mientras habla con un usuario que puede ser vago, cambiar de opinión a mitad de conversación o pedir algo que la política no permite.

Este es el caso de uso fundamental para agentes de IA en producción. Y es exactamente donde la mayoría de los benchmarks se quedan cortos. Prueban llamadas a herramientas de forma aislada (¿puede el modelo generar la llamada a función correcta?) o evalúan sobre conjuntos de datos estáticos donde toda la información se da por adelantado.

Tau-bench cierra esa brecha probando tres capacidades simultáneamente:

Conversación multi-turno con un humano. El usuario no suelta todo en un mensaje. Revela información gradualmente, a veces necesita que le pregunten, y puede plantear solicitudes compuestas.
Cumplimiento de políticas específicas del dominio. El agente recibe un documento de políticas detallado (por ejemplo, “los vuelos de clase económica básica no se pueden modificar” o “los intercambios solo pueden realizarse en pedidos entregados”) y debe seguirlo con precisión, incluso cuando la solicitud del usuario contradice las reglas.
Uso correcto de herramientas con una base de datos real. El agente interactúa con bases de datos JSON a través de herramientas API de Python - buscando usuarios, consultando vuelos, modificando pedidos. Argumentos incorrectos, campos faltantes o secuencias incorrectas llevan al fracaso.

El LLM como usuario

El usuario en Tau-bench es interpretado por un modelo de lenguaje. Cada tarea viene con una instrucción oculta que le dice al usuario simulado quién es, qué quiere y cómo comportarse:

“Eres Mei Davis del código postal 80217. Quieres devolver la botella de agua e intercambiar la cama de mascota y la silla de oficina por la versión más barata. Menciona las dos cosas juntas. Si solo puedes hacer una de las dos, prefieres hacer lo que te ahorre más dinero, pero quieres saber el ahorro en ambas opciones. Tienes deudas y estás triste hoy, pero muy breve.”

El agente nunca ve esta instrucción. Solo ve los mensajes del usuario, que emergen naturalmente de la interpretación del escenario por el LLM. Esto crea variación estocástica - la misma tarea se desarrolla de manera diferente cada vez porque el usuario formula las cosas diferente, revela información en diferente orden o responde de manera impredecible a las preguntas del agente.

Esta estocasticidad es una característica, no un defecto. Es lo que habilita la métrica pass^k (más sobre esto abajo) y refleja interacciones reales con clientes donde la misma solicitud subyacente puede manifestarse de innumerables maneras.

Cómo funciona la evaluación: verificaciones de resultados fundamentados

Aquí es donde Tau-bench se vuelve elegante. En lugar de intentar juzgar la calidad de la conversación con un juez LLM de forma libre, puntúa resultados fundamentados contra criterios de éxito pre-definidos.

En los dominios originales de retail y aerolínea, cada tarea está diseñada alrededor de un único estado final correcto bajo la política del dominio. Si una tarea permitiera múltiples resultados válidos, los autores refinan las instrucciones hasta que solo queda un estado objetivo definido.

La función de recompensa es binaria: r = r_action x r_output, donde:

r_action = 1 si el estado final satisface los criterios de acción fundamentados de la tarea. En el Tau-bench original esto es principalmente una coincidencia del estado de la base de datos con el estado objetivo definido.
r_output = 1 si las respuestas del agente al usuario contenían toda la información necesaria (por ejemplo, el monto correcto del reembolso u otros detalles requeridos)

Ambas condiciones deben cumplirse. Un agente que hace los cambios correctos en la base de datos pero da al usuario información de precios incorrecta igual falla. Un agente que comunica perfectamente pero llama al API equivocado también falla.

Tau-squared expande esto aún más. Su menú de evaluación incluye verificaciones de BD, verificaciones de información de comunicación, aserciones en lenguaje natural, coincidencia de acciones y aserciones de estado; en el dominio de telecomunicaciones, el paper indica que las tareas se evalúan usando funciones de aserción en lugar de simples comparaciones de bases de datos.

La métrica Pass^k: midiendo fiabilidad

Aquí es donde Tau-bench revela algo incómodo sobre los agentes de IA actuales.

La métrica estándar en benchmarks de agentes es pass@k: ¿tuvo éxito el agente al menos una vez en k intentos? Esto mide descubrimiento - dado suficientes intentos, ¿puede el agente encontrar una solución? Es útil para generación de código donde puedes ejecutar suites de pruebas para elegir la respuesta correcta.

Tau-bench introduce pass^k (pass-hat-k): ¿tuvo éxito el agente en todos los k intentos? Esto mide fiabilidad - ¿puedes contar con que este agente maneje el mismo tipo de solicitud de manera consistente?

Para atención al cliente, la fiabilidad es lo que importa. No puedes ejecutar cada interacción con el cliente ocho veces y elegir la mejor. Cada conversación necesita funcionar.

Los resultados son aleccionadores. GPT-4o, el mejor modelo en el paper original, logra:

61,2% pass^1 en retail (aproximadamente 6 de cada 10 tareas resueltas)
~25% pass^8 en retail (solo 1 de cada 4 tareas resueltas consistentemente en 8 ejecuciones)
35,2% pass^1 en aerolínea (apenas un tercio)

La brecha entre pass^1 y pass^8 revela fragilidad. El agente no solo falla ocasionalmente en tareas difíciles - falla inconsistentemente en tareas que a veces puede resolver. Pequeñas variaciones en cómo el usuario formula las cosas, o en el propio muestreo del LLM, cambian el resultado.

Dónde fallan los agentes

Los autores analizaron 36 trayectorias fallidas de GPT-4o en tareas de retail y encontraron tres categorías principales de fallo:

Argumentos o información incorrectos. El agente llama al API correcto pero con parámetros incorrectos - IDs de artículos incorrectos, métodos de pago incorrectos, cálculos de precios incorrectos. O le dice al usuario el precio total incorrecto, lo que causa que el usuario tome decisiones basadas en información errónea, causando en cascada un estado incorrecto de la base de datos.

Toma de decisiones incorrecta. El agente malinterpreta o ignora la política del dominio. Por ejemplo, la política dice “todos los artículos a intercambiar deben recopilarse en una lista e intercambiarse en una sola llamada API”, pero el agente intercambia artículos uno por uno, causando que el segundo intercambio falle porque el intercambio solo puede llamarse una vez por pedido.

Resolución parcial de solicitudes compuestas. Cuando un usuario pide múltiples cosas (modificar direcciones en todos los pedidos, devolver un artículo e intercambiar otro), el agente maneja parte de la solicitud y se detiene. Pierde el seguimiento del alcance completo de la tarea a lo largo de la conversación multi-turno.

Tau-Squared: la secuela que añade agencia del usuario

Un año después del original, Tau-squared-bench abordó una limitación fundamental de Tau-bench: en la configuración original, solo el agente puede usar herramientas. El usuario solo habla.

En la atención al cliente real, eso a menudo no es así. Piensa en soporte técnico: el agente dice “por favor reinicie su teléfono” y el cliente realmente tiene que hacerlo. El usuario tiene agencia sobre su propio entorno, y el agente necesita guiarlo a través de acciones, verificar los resultados y adaptarse cuando las cosas no funcionan como se esperaba.

Tau-squared modela esto como un Proceso de Decisión de Markov Parcialmente Observable Descentralizado (Dec-POMDP) - un framework donde dos jugadores (agente y usuario) tienen cada uno sus propios espacios de acción, espacios de observación y herramientas, actuando sobre un estado del mundo compartido que ninguno observa completamente.

El nuevo dominio de telecomunicaciones

La adición principal es un dominio de atención al cliente de telecomunicaciones donde los usuarios llaman con problemas de teléfono - sin servicio, datos móviles que no funcionan, fallos de MMS. La diferencia clave: el usuario tiene sus propias herramientas que interactúan con su teléfono.

El agente tiene herramientas CRM como get_customer_by_id, get_details_by_id y enable_roaming. El usuario tiene herramientas del lado del teléfono como get_network_status, toggle_data, toggle_airplane_mode y reseat_sim_card. El agente puede consultar la cuenta del cliente y hacer cambios en el backend, pero no puede ver ni controlar directamente el teléfono del usuario. Tiene que instruir al usuario para que inspeccione el estado del teléfono, cambie configuraciones o reinserte la SIM - y luego interpretar las observaciones reportadas para diagnosticar el problema.

Esto crea resolución de problemas genuinamente colaborativa. Una trayectoria típica se ve así:

Usuario: “Mis datos móviles no funcionan.”
Agente: “¿Podría verificar el estado de su red?”
Usuario llama get_network_status() -> ve que los datos móviles están desactivados
Usuario: “Parece que mis datos están desactivados.”
Agente: “¿Podría activar sus datos alternándolos?”
Usuario llama toggle_data() -> “Los datos móviles ahora están ENCENDIDOS.”
Usuario: “Listo, los datos móviles están ahora encendidos.”

El dominio de telecomunicaciones tiene 5 planes, 9 líneas, 4 clientes, con 15 herramientas de escritura y 15 de lectura para el usuario, más 6 de escritura y 7 de lectura para el agente. 114 tareas curadas se seleccionan de un grupo mucho mayor de 2.285 combinaciones generadas programáticamente.

Generador de tareas composicional

Una de las mejoras más grandes en Tau-squared es cómo se crean las tareas. En lugar de crear cada escenario a mano, el benchmark usa un generador de tareas composicional que construye tareas diversas a partir de bloques atómicos.

Cada subtarea atómica se define por tres tipos de funciones:

Funciones de inicialización configuran el problema (por ejemplo, set_airplane_mode(True))
Funciones de solución especifican las herramientas necesarias para arreglarlo (por ejemplo, toggle_airplane_mode())
Funciones de aserción verifican que la corrección funcionó (por ejemplo, assert_service_status("connected"))

Las subtareas atómicas se agrupan de modo que las alternativas mutuamente excluyentes estén en el mismo grupo. Las tareas compuestas se crean seleccionando subtareas de diferentes grupos y combinándolas. La corrección de la tarea se verifica automáticamente: si todas las funciones de aserción pasan después de aplicar las funciones de solución (pero no antes), la tarea es válida.

Este enfoque asegura corrección demostrable, cobertura completa del dominio, control explícito sobre la dificultad (variando el número de subtareas), y elimina el esfuerzo manual y la potencial fragilidad de las suites de tareas creadas a mano.

Las personas de usuario añaden realismo

Tau-squared introduce personas de usuario con diferentes niveles de experiencia técnica:

Persona fácil: Un administrador de oficina de 41 años, cómodo con funciones básicas del teléfono, prefiere instrucciones claras paso a paso
Persona difícil: Un bibliotecario jubilado de 64 años, conocimiento técnico limitado, se frustra fácilmente, se preocupa por perder fotos cuando le piden reiniciar

La persona difícil obtiene resultados notablemente peores en todos los modelos - no porque la tarea subyacente sea diferente, sino porque el agente debe adaptar su estilo de comunicación y manejar usuarios ansiosos y confundidos que interrumpen con preguntas preocupadas. Curiosamente, la persona “None” (sin información de persona) obtiene resultados iguales o peores que la persona difícil, lo que destaca lo importante que es probar con perfiles de usuario bien definidos.

Qué significa esto para el desarrollo de agentes de IA

El cumplimiento de políticas es una habilidad separada del uso de herramientas. Una ablación en el paper original eliminó el documento de políticas del system prompt del agente. En tareas de retail (políticas más simples), GPT-4o solo cayó un 4,4%. En tareas de aerolínea (políticas complejas), cayó un 22,4%. El agente ya estaba usando mayormente sentido común para reglas simples - el documento de políticas solo ayudaba con restricciones complejas y específicas del dominio. Esto significa que los agentes necesitan ser evaluados específicamente en seguimiento de políticas, no solo en llamadas a herramientas.

La consistencia importa más que el rendimiento máximo. La métrica pass^k debería poner nervioso a cualquiera que despliegue agentes. Un agente que tiene éxito el 60% del tiempo pero no se puede confiar en él para la misma tarea dos veces es un lastre en producción. La brecha entre pass^1 y pass^8 es donde se desmorona la confianza en el mundo real.

Guiar a usuarios es fundamentalmente diferente de actuar solo. Los resultados de Tau-squared prueban que la comunicación y coordinación con usuarios activos es un cuello de botella distinto - no solo un impuesto sobre el rendimiento de razonamiento. Agentes que pueden resolver problemas de forma autónoma aún pueden fallar cuando necesitan instruir a un humano a través de los mismos pasos.

La simulación de usuarios se está convirtiendo en un problema de investigación de primera clase. Ambos papers lidian con la fiabilidad de los simuladores de usuarios basados en LLM. El enfoque de Tau-squared de restringir el comportamiento del usuario a través de herramientas representa una dirección prometedora, pero la tasa de error del 16% en el mejor dominio todavía significa que aproximadamente 1 de cada 6 conversaciones está contaminada por artefactos del simulador.

El panorama general

Tau-bench y Tau-squared representan un cambio en cómo pensamos sobre la evaluación de agentes. En lugar de probar capacidades aisladas (¿puedes llamar una función? ¿puedes navegar por la web?), prueban el ciclo completo: conversación, razonamiento, cumplimiento de políticas, uso de herramientas, y ahora coordinación - todo a la vez, todo en un entorno realista.

Los benchmarks son de código abierto (Tau-bench en GitHub, Tau-squared en GitHub) y relativamente baratos de ejecutar (~40$ por una prueba completa en todos los dominios). Si estás construyendo agentes de IA orientados al cliente, estos son de las aproximaciones más cercanas al rendimiento real que existen hoy.