Benchmark ThinkingBox mostra que agentes de IA erram no banco mesmo dizendo que terminaram a tarefa

O chamado que o agente "resolveu" (mas não resolveu)

Uma cliente escreve reclamando que um eletrodoméstico de 745 dólares está preso havia 15 dias numa exceção da transportadora. O agente faz nove chamadas de ferramenta: puxa o pedido, checa o rastreio, confere o perfil, lê a política de reembolso duas vezes, confirma que não existe chamado aberto, abre um, documenta a linha do tempo e aplica a política corretamente (o segmento da conta realmente não dá direito a compensação por atraso).

Então ele encerra o chamado como resolvido e responde:

Já que sua dúvida foi resolvida, posso ajudar em mais alguma coisa?

Since your query is resolved, is there anything I may assist you with?Resposta de agente registrada no caso ST003_006 do benchmark ThinkingBox

Dois problemas: a exceção da transportadora continua aberta (o estado exigido era "em espera", não "resolvido"), e a cliente nunca recebeu resposta real ao que perguntou. Um avaliador que checasse só as chamadas de ferramenta veria nove chamadas bem formadas. O post da Hugging Face e Microsoft usa esse caso, reproduzível com o arquivo sandbox_external_retail_group1.py:test_case_ST003_006, para ilustrar o problema central do ThinkingBox: quem discorda do agente é o banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →.

Um tool call bem-sucedido não é um resultado correto

O ThinkingBox-Bench cobre 507 fluxos de trabalho com estado (retail, seguro de automóvel, viagem, neobank e consultoria), cada um rodado 20 vezes contra sessões MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → isoladas. Numa ablação com conjunto comum cobrindo 121.680 tentativas válidas em 12 modelos, 79.853 falharam nas checagens executáveis sobre o estado final.

O dado que mais importa pra quem constrói agente: 67,24% dessas falhas terminaram de forma limpa, chamaram uma ferramenta que muda estado e não reportaram nenhum erro de ferramenta. Mesmo assim, as checagens executáveis encontraram valores de campo errados em 77,61% delas, efeitos colaterais indesejados em 43,30% e efeitos obrigatórios ausentes em 25,36% (as categorias se sobrepõem). Em outras palavras: o agente terminou feliz, e o banco registrou outra coisa.

Três métricas, três perguntas diferentes

Como cada tarefa roda 20 vezes a partir de um backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → limpo, o ThinkingBox reporta três números com perguntas distintas por trás:

No pass@1 geral ponderado por tarefa, Claude Opus 5.5 lidera com 67,16%, meio ponto à frente de Claude Opus 5 (66,50%); GPT-5.4 vem em seguida com 65,36%. Entre os modelos abertos, Kimi-K3 lidera com 57,37%. O domínio pesa tanto quanto o modelo: Claude Opus 4.6 marca 68,62% em retail e só 8,30% em seguro de automóvel.

A ruptura entre amplitude e consistência

O pass@1 sozinho esconde a pergunta que importa em produção: será que o mesmo agente acerta de novo? Kimi-K3 tem a maior cobertura do benchmark: resolve 93,89% das tarefas ao menos uma vez (476 de 507), apenas 31 tarefas o derrotam por completo. Mas é também um dos modelos menos consistentes, com só 68 das 507 tarefas (13,41%) passando nas 20 tentativas.

Claude Opus 5 inverte o quadro: resolve menos tarefas ao menos uma vez (79,09%, 106 tarefas nunca resolvidas), mas completa 47,53% do benchmark em toda tentativa, sem exceção. Kimi-K3 resolve 75 tarefas a mais que Opus 5 pelo menos uma vez; Opus 5 resolve 173 tarefas a mais de forma consistente que Kimi-K3.

O upgrade de versão também não resolve isso sozinho. Claude Opus 5.5 supera Opus 5 no pass@1 médio (67,16% contra 66,50%) e resolve mais tarefas ao menos uma vez, mas passa exatamente o mesmo número de tarefas nas 20 tentativas: 241. Meio ponto de acurácia na manchete não comprou confiabilidade adicional nenhuma.

Uma trajetória é uma alegação. O estado do banco de dados é a evidência. A repetição é o teste de confiança.

A trajectory is a claim. Database state is the evidence. Repetition is the trust test.Tuhin Kundu, autor do post, Hugging Face e Microsoft

Quanto custa ser confiável

O time precificou cada modelo pelo uso de tokens da campanha completa (507 tarefas × 20 rodadas) com as tarifas de lista do OpenRouter, e dividiu o custo por tentativa bem-sucedida. GPT-5.4 custa 43,49 dólares para 507 tentativas e tem 65,36% de pass@1, o que dá 0,131 dólar por tentativa bem-sucedida.

Na fronteira de custo por sucesso, só três modelos sobrevivem sem serem dominados: GPT-5.6 Sol é o mais barato (0,127 dólar), GPT-5.4 ganha 3,45 pontos de pass@1 por só 0,004 dólar a mais, e Claude Opus 5.5 soma outros 1,80 ponto a 0,276 dólar. Claude Opus 5, a 0,475 dólar e 66,50% de pass@1, é dominado: mais caro e menos preciso que Opus 5.5.

Mas custo por sucesso não é custo por confiabilidade. Dividindo o custo da campanha completa de 20 rodadas pelo número de tarefas que passaram 20 de 20 vezes, o ranking muda: GPT-5.4 é o mais barato a 6,80 dólares por tarefa dependável (mas só 128 tarefas, 25,25%, chegam lá), GPT-6 Astra custa 7,45 dólares para 231 tarefas (45,56%) e Claude Opus 5.5 custa 7,80 dólares para 241 tarefas (47,53%).

Claude Opus 5 também passa 241 tarefas, mas a 13,30 dólares cada, dominado por Opus 5.5. GPT-5.6 Sol, o mais barato por sucesso isolado, sobe para 9,76 dólares por tarefa dependável: o caminho mais barato até uma resposta certa não é o caminho mais barato até uma resposta confiável.

Por que falha: não é raciocínio, é manuseio de ferramenta

Cada traço com falha recebe uma assinatura diagnóstica determinística, e o padrão é claramente acionável: cerca de quatro em cada cinco falhas são de manuseio de ferramenta, não de raciocínio.

• Uso de ferramenta: 79,9% das falhas
• Atualizações de estado erradas: 10,3%
• Resoluções incompletas para o usuário: 7,0%
• Nenhuma ação que muda estado: 2,9%

O padrão prático descrito no post: o agente costuma chegar perto o bastante de completar o fluxo e então não se recupera de um erro de ferramenta, uma pré-condição falha ou uma busca vazia. Isso é, antes de tudo, um problema de retry e recuperação de erro, não um problema de modelo. A dificuldade também varia por domínio: retail tem média de 59,52% de pass@1 entre os modelos listados, contra 33,83% em seguro de automóvel.

Como funciona por baixo: sessão isolada, juízes determinísticos

Cada tarefa define um estado inicial de backend, um objetivo do usuário, as ferramentas MCP disponíveis, a política do domínio e checagens executáveis sobre o estado terminal. Um usuário simulado guarda contexto privado (um número de reserva, uma data de nascimento) e só o revela quando perguntado. Cada tentativa recebe uma sessão MCP isolada com estado recém-inicializado, de modo que duas tentativas da mesma tarefa nunca compartilham linha de banco ou cache: é o que torna a comparação de 20 rodadas significativa.

No fim, um extrator de efeitos colaterais deriva o que realmente mudou, e juízes determinísticos comparam isso contra o estado exigido, aceitando qualquer trajetória que produza o resultado certo e rejeitando efeito errado, faltante ou extra. Para requisitos sem valor limpo de banco ("o agente avisou que isso não é garantido?"), uma rubrica binária estreita cobre a semântica; 477 das 507 tarefas são julgadas só pelo estado, 30 somam rubricas de resposta. O modelo sob teste vê tarefas, diálogo e esquemas de ferramenta; estado dourado, asserções, lógica de julgamento e credenciais ficam do lado do avaliador.

Rodando o benchmark você mesmo

O ThinkingBox está publicado na Hugging Face como harness e dataset, atrás da interface OpenEnv, com cada episódio devolvendo uma recompensa binária de passou/falhou. O fluxo básico, resumido do próprio post, pede Python 3.11+, uv e Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps →:

git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

Depois sobe o Typesense (índice usado pelos servidores MCP), os próprios servidores MCP e o servidor OpenEnv apontando para um YAML com os três endpoints de modelo (agente, usuário simulado e juiz podem ser o mesmo endpoint). Com tudo de pé, dá pra pontuar um episódio real com thinkingbox-eval, passando um arquivo com a tarefa (sandbox_external_retail_group1.py:test_case_ST002_001) e recebendo results.jsonl e errors.jsonl separados, para que falhas operacionais não se misturem com falhas do modelo. As execuções ficam presas a um commit fixo do framework, uma versão fixa do dataset e um hash do pacote: um resultado "canônico" é verificável, não apenas declarado.

O que muda para quem constrói agente em produção

O recado prático dos autores é direto: trate a taxa 20/20 como insumo de design, não como veredito. O mesmo sinal pelo qual o benchmark julga está disponível em produção: cheque o estado terminal antes de dar o commit, não o resumo que o modelo faz dele. Classifique erros de ferramenta e de sistema para que o retry mire só os recuperáveis, reduza a superfície de ferramentas ao que o fluxo realmente precisa, e exija aprovação humana nas mudanças que não dá pra desfazer barato. Os próprios autores admitem que não mediram o ganho real de nenhuma dessas práticas dentro do benchmark, só que agora o ambiente torna isso testável.

Vale a ressalva: todas as tarefas públicas são reconstruções sintéticas modeladas em padrões reais de agente corporativo, e os custos por tentativa são um índice comparativo com tarifas de lista, não a fatura real de rodar um agente na nuvem. Para quem decide qual modelo colocar atrás de um agente que grava pedido, reembolso ou apólice, a lição do ThinkingBox é que pass@1 sozinho mede a habilidade errada: o que precisa ser cobrado é repetição sobre estado real, porque é isso que o banco de dados vai registrar depois que o agente já disse que terminou.

Fonte: Hugging Face Blog