τ²-bench: Medindo o Custo do Controle Duplo em Agentes de IA Conversacionais

Tenho lido a linhagem τ-bench nas últimas semanas e o τ²-bench (arXiv:2506.07982) é o artigo que eu esperava ver: ele finalmente questiona o que acontece quando o usuário não é um mero dispensador passivo de informações, mas um participante ativo com seu próprio conjunto de ferramentas. Para quem está construindo um agente de contabilidade conversacional, essa lacuna sempre foi evidente.

O artigo

Victor Barres, Honghua Dong, Soham Ray, Xujie Si, and Karthik Narasimhan (Sierra AI e Universidade de Toronto) apresentam o τ²-bench como uma extensão direta do τ-bench original. A observação central é que os benchmarks anteriores para agentes de IA conversacionais são de controle único: apenas o agente pode invocar ferramentas; o usuário está confinado a mensagens em linguagem natural. O suporte técnico do mundo real quebra essa premissa. Quando um agente de atendimento ao cliente diz para você "desligar o modo avião", você está executando uma chamada de ferramenta no seu próprio dispositivo, não apenas narrando suas preferências.

Os autores modelam isso como um Processo de Decisão de Markov Parcialmente Observável Descentralizado (Dec-POMDP), onde tanto o agente quanto o simulador do usuário possuem espaços de ação distintos (chamadas de função e mensagens) sobre um estado de mundo compartilhado e dinâmico. O lado do agente funciona como um CRM padrão: ele pode consultar registros de clientes, ativar roaming ou substituir um chip SIM. O lado do usuário é um telefone simulado com ferramentas de leitura (get_status_bar, get_sim_status) e ferramentas de escrita (toggle_airplane_mode, toggle_data, reseat_sim_card). O benchmark vem com um novo domínio de telecomunicações (114 tarefas amostradas de 2.285 variantes geradas programaticamente) junto com os domínios verificados de varejo (115 tarefas) e companhias aéreas (50 tarefas) do τ-bench original.

Principais ideias

• Formalismo de controle duplo: A representação Dec-POMDP separa claramente o que cada jogador observa e quais ferramentas cada um pode chamar. Isso é mais rigoroso do que o modelo ad-hoc de "usuário com um telefone" que você poderia adaptar a um sistema de agente único existente.
• Gerador de tarefas composicional: As tarefas são montadas a partir de 15 grupos de subtarefas atômicas cobrindo três tipos de intenção (service_issue, mobile_data_issue, mms_issue) com escalonamento explícito de dificuldade pelo número de etapas de resolução necessárias.
• Desempenho em telecomunicações (pass¹): GPT-4.1 atinge apenas 34%; o4-mini 42%; Claude 3.7 Sonnet 49%; GPT-4.1-mini cerca de 50%. Todos os modelos pontuam substancialmente menos aqui do que no varejo ou em companhias aéreas.
• Penalidade de controle duplo: Uma ablação compara o modo Padrão (usuário tem ferramentas) contra o modo Sem Usuário (o agente controla cada ferramenta sozinho). O GPT-4.1 cai 18 pontos percentuais; o o4-mini cai 25 pontos. Essa lacuna é o custo de coordenar com um usuário ativo, desvinculado da dificuldade pura de raciocínio.
• Gap do plano oráculo: Mesmo quando o agente recebe a sequência completa de ações antecipadamente, o desempenho não chega a 100%, o que nos indica que a execução e a coordenação do usuário adicionam erros além do planejamento.
• Ferramentas de usuário estruturadas reduzem drasticamente o ruído do simulador: O simulador de usuário de telecomunicações produz apenas 16% de erros (6% críticos), comparado a 40% de erros (12% críticos) para o varejo no τ-bench original. A melhoria vem da substituição de comandos de usuário em linguagem natural por uma interface de ferramenta rigidamente restrita que rastreia o estado do dispositivo.

O que se sustenta — e o que não

A estrutura Dec-POMDP é uma das formulações de problema mais cuidadosas que já vi em benchmarking de agentes. O gerador de tarefas programático é genuinamente útil: ele fornece tarefas comprovadamente corretas e complexidade explicitamente controlável, ao contrário das coleções de tarefas feitas à mão que assolam a maioria dos benchmarks. Os números de confiabilidade do simulador de usuário são convincentes — reduzir os erros críticos de 12% para 6% importa muito quando você está tentando confiar no seu sinal de avaliação.

Dito isso, o domínio de telecomunicações é limitado. Quatro clientes, nove linhas, cinco planos: este é um laboratório controlado, não um sistema empresarial. Os números pass¹ para gpt-4.1-mini e Claude 3.7 Sonnet (~50%) parecem surpreendentemente altos dado quão difícil os autores dizem ser o domínio, o que me faz questionar se 114 tarefas são suficientes para evitar que execuções sortudas inflem as pontuações. Os autores reconhecem que seu conjunto de tarefas é uma subamostra. Também considero a análise da persona do usuário superficial: o artigo mostra que a persona "Difícil" (aposentado de 64 anos com baixa confiança técnica) é mais difícil do que a persona "Fácil", o que não é surpreendente. O que eu gostaria de ver é se o tipo de falha de coordenação difere — uma persona mais difícil produz mais erros de raciocínio ou mais erros de comunicação?

O artigo também não explora o que acontece quando o documento de política do agente está errado ou incompleto, o que é um cenário realista para implementações em produção. Cada resultado pressupõe que o agente recebe políticas precisas.

Por que isso é importante para a IA financeira

A premissa de controle único embutida no τ-bench, WorkArena e na maioria dos benchmarks de diálogo orientados a tarefas mapeia mal o cenário real de suporte do Beancount. Um usuário pedindo a um agente Beancount para corrigir seu livro-razão não está apenas narrando um problema — ele pode estar editando simultaneamente o arquivo em seu editor de texto, executando o bean-check ou carregando uma nova exportação CSV de seu banco. Esse é um ambiente de controle duplo exatamente no sentido do τ²-bench.

A queda de 18 a 25 pontos percentuais ao mudar do modo Sem Usuário para o modo Padrão é o número ao qual sempre voltarei. Isso sugere que, mesmo que construíssemos um agente Beancount quase perfeito na manipulação autônoma de livros-razão, a introdução de um usuário ativo que compartilha o acesso de escrita reduziria as taxas de sucesso em cerca de um quarto. Os designs de write-back seguro que temos considerado (GuardAgent, ShieldAgent, MCP verificável) foram projetados para configurações de controle único; eles precisam de reformulação se o usuário também for um agente que chama ferramentas sobre o mesmo ambiente.

A melhoria na confiabilidade do simulador de usuário também é diretamente aplicável. Se eu quiser realizar avaliações offline de um agente Beancount sem recrutar contadores humanos, acoplar rigidamente o usuário simulado a um ambiente de livro-razão determinístico — em vez de depender de roleplay livre de LLM — é a decisão de engenharia correta.

O que ler a seguir

• τ-bench (Yao et al., arXiv:2406.12045): A linha de base que este expande — vale a pena ler a construção da tarefa original e o design da métrica pass^k antes de interpretar os resultados do τ²-bench.
• ToolSandbox (Lu et al., arXiv:2408.04682): Introduz ferramentas com estado para avaliação detalhada de agentes; a arquitetura mais relevante para projetar um ambiente de teste de controle duplo para o Beancount.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 tarefas dentro de uma empresa de software simulada com ferramentas internas reais; o benchmark de automação empresarial mais realista disponível atualmente e o próximo artigo na minha lista de leitura.