τ-bench: Medindo a Confiabilidade de Agentes de IA em Domínios de Uso de Ferramentas no Mundo Real

Depois de passar semanas rastreando a linhagem de raciocínio em tabelas e text-to-SQL, eu quis recuar e fazer uma pergunta diferente: quão bem os agentes atuais realmente se saem quando colocados em um loop operacional ao vivo com um usuário real? O τ-bench oferece a resposta mais honesta que já vi, e os números são impactantes.

O artigo

Yao, Shinn, Razavi e Narasimhan — todos em Princeton e Sierra Research — lançaram o τ-bench (arXiv:2406.12045, junho de 2024) para preencher uma lacuna óbvia em retrospecto: a maioria dos benchmarks de agentes entrega uma tarefa ao modelo e avalia sua resposta final isoladamente. Implementações reais não funcionam assim. Um agente de atendimento ao cliente é interrompido, recebe perguntas de acompanhamento, informações contraditórias e deve aplicar as políticas da empresa durante uma conversa aberta antes de fazer qualquer alteração no banco de dados.

O τ-bench envolve dois domínios de atendimento ao cliente do mundo real — varejo e aviação — em um ambiente de simulação onde um modelo de linguagem interpreta o usuário e outro interpreta o agente. O agente tem acesso a APIs específicas do domínio (cancelar um pedido, trocar um assento, aplicar um cupom) e um documento de política escrito especificando quais ações são permitidas sob quais condições. A avaliação não pontua etapas intermediárias: ela compara o estado final do banco de dados com um estado de objetivo anotado. Os autores também introduzem o pass^k, uma métrica de confiabilidade que questiona em qual fração de tentativas um agente tem sucesso de forma consistente em k tentativas independentes na mesma tarefa.

Ideias principais

• pass^k como a métrica honesta: uma única pontuação pass@1 é muito ruidosa. O pass^k expõe a probabilidade de um agente ter sucesso em cada uma das k reexecuções da mesma tarefa — um indicador de se você confiaria nele em produção.
• O abismo de consistência: O GPT-4o no varejo atinge 0,604 no pass@1, mas cai para 0,383 no pass@4. Isso significa que em cerca de 60% das tarefas ele falha pelo menos uma vez em quatro tentativas — dificilmente um agente seguro para produção.
• O setor aéreo é mais difícil que o varejo: O pass@1 do GPT-4o cai de 0,604 (varejo) para 0,420 (aviação). O Claude 3.5 Sonnet (versão de outubro de 2024) se sai melhor — 0,692 no varejo / 0,460 na aviação em pass@1 — mas seu pass@4 ainda atinge apenas 0,462 e 0,225, respectivamente.
• Chamada de função supera o ReAct: a variante de agente com chamada de função do GPT-4o (pass@1 = 0,420 na aviação) supera tanto o Act (0,365) quanto o ReAct (0,325) no mesmo modelo base, sugerindo que APIs de ferramentas estruturadas reduzem falhas induzidas pelo formato.
• A simulação de usuário é uma variável: os autores usam um modelo de linguagem para simular o usuário, o que introduz sua própria variância. Um simulador de usuário mais fraco pode reduzir ou inflar as pontuações do agente, dependendo de quão fielmente ele representa o comportamento de um usuário adversário.
• A avaliação do estado do banco de dados evita jogos de crédito parcial: comparar o estado final em vez das etapas do diálogo significa que um agente que toma uma ação correta e depois a reverte inadvertidamente não recebe crédito — o que é a decisão correta para um sistema de gravação (write-back).

O que se sustenta — e o que não se sustenta

O enquadramento pass^k é genuinamente útil e espero que dure mais do que este benchmark específico. A decisão de avaliar o estado do banco de dados em vez da similaridade ao nível de tokens está correta — ela mede diretamente se o agente realizou a tarefa, não se ele disse as coisas certas.

Os domínios, no entanto, são limitados por design. Varejo e aviação são processualmente limpos: os documentos de política são finitos e escritos para o benchmark, as APIs são pequenas e bem especificadas, e o simulador de usuário é cooperativo por padrão. Documentos de política do mundo real são ambíguos; usuários reais mentem, lembram-se incorretamente e resistem a recusas. Os autores do benchmark reconhecem isso — a própria existência do τ²-bench (arXiv:2506.07982) como sequência, que se estende para um modelo Dec-POMDP de controle duplo onde o usuário também manipula o estado do ambiente, é uma admissão de que a avaliação de controle único subestima a dificuldade.

Há também a questão do que o pass^k realmente mede. Se a simulação do usuário for estocástica, a variância entre as k tentativas confunde a inconsistência do agente com a inconsistência do simulador. O artigo observa isso, mas não separa totalmente as duas fontes de variância. Para aplicações críticas de segurança, você desejaria atribuir as falhas — o agente está ignorando a política, interpretando mal a intenção do usuário ou apenas escolhendo o formato errado de chamada de ferramenta?

O placar no llm-stats.com agora mostra modelos como o Step-3.5-Flash com 0,882, o que pareceria um progresso dramático se você não notasse que a configuração de avaliação provavelmente mudou: entradas mais recentes parecem ser pontuadas sob diferentes versões de simuladores de usuário e possivelmente diferentes divisões de tarefas. A comparação entre entradas em benchmarks em evolução é sempre suspeita.

Por que isso importa para a IA nas finanças

O agente de gravação (write-back) do Beancount que tenho em mente é estruturalmente idêntico aos agentes que o τ-bench avalia: ele possui ferramentas específicas de domínio (adicionar uma transação, corrigir um saldo, recategorizar uma entrada), restrições de política (não modificar períodos encerrados, não criar saldos negativos, seguir o plano de contas) e um usuário que dá instruções em linguagem natural ao longo de uma conversa que pode durar vários turnos.

A descoberta do pass^k é o resultado mais aplicável para nós. Se um modelo de última geração como o Claude 3.5 Sonnet atinge um pass@4 de apenas 0,462 no varejo — um domínio relativamente flexível — devemos esperar uma consistência semelhante ou pior na gravação do livro-razão, onde os erros se acumulam nas transações e as violações de política podem não ser visíveis imediatamente. Projetar para a consistência em k-tentativas desde o início — e não apenas otimizar o pass@1 — altera a arquitetura: isso sugere o uso conservador de ferramentas (perguntar antes de gravar, não depois), etapas explícitas de verificação de política antes de qualquer chamada de API e um agente verificador separado que audite a diferença (diff) proposta no livro-razão antes que ela seja confirmada.

A metodologia de avaliação do estado do banco de dados também é diretamente portável. O formato de arquivo estruturado do Beancount torna simples comparar o estado esperado do livro-razão com o estado real após uma sessão de gravação, fornecendo o mesmo tipo de sinal de avaliação objetiva que o τ-bench utiliza.

O que ler a seguir

• τ²-bench (arXiv:2506.07982): a sequência que se estende para ambientes de controle duplo onde os usuários também invocam ferramentas; diretamente relevante se modelarmos o usuário como um participante ativo nas correções do livro-razão, em vez de um solicitante passivo.
• AgentEval / GAIA (arXiv:2311.12983): o benchmark GAIA avalia assistentes de IA gerais em tarefas do mundo real que exigem navegação na web e uso de ferramentas; um complemento útil ao foco específico de domínio do τ-bench.
• WorkArena (arXiv:2403.07718): avalia agentes em tarefas reais de software empresarial no ServiceNow; o domínio é mais próximo dos fluxos de trabalho contábeis do que o varejo ou a aviação e vale a leitura pelas lições de design de tarefas.