Ir para o conteúdo

Novo benchmark flagra agentes de IA mentindo sobre tarefas concluídas

Resposta curta

Microsoft e Hugging Face lançaram o ThinkingBox, um benchmark que verifica o que um agente de IA realmente alterou em um banco de dados, não o que ele disse ter feito. Em 507 fluxos de trabalho empresariais executados 20 vezes cada, dois terços das tentativas aparentemente limpas ainda deixavam dados errados, ausentes ou extras no backend.

O que isso significa na operação

Se o time de suporte ou operações da sua empresa usa um agente para fechar tickets, atualizar status de pedidos ou confirmar reembolsos, este benchmark é um alerta de que a própria mensagem de confirmação do agente não é prova de que algo realmente aconteceu corretamente. O mesmo modelo pode resolver um fluxo de trabalho uma vez e falhar nas quatro tentativas seguintes, então um único piloto bem-sucedido diz quase nada sobre confiabilidade em volume. Para uma empresa de 10 a 200 pessoas, o ajuste prático descrito aqui não exige comprar o benchmark: verifique o estado final do registro que o agente tocou (status do ticket, campo do pedido, saldo da conta) antes de confiar no resumo gerado, classifique os erros de ferramenta para que as tentativas de repetição mirem falhas recuperáveis em vez de reexecutar tudo, mantenha o acesso do agente às ferramentas restrito ao fluxo que ele está executando, e exija aprovação humana para qualquer alteração cara de reverter, como reembolsos ou cancelamentos.

Um post conjunto da Microsoft e da Hugging Face descreve um novo framework de avaliação de agentes, o ThinkingBox, construído em torno de uma ideia simples: avaliar um agente de IA pelo que ele efetivamente gravou em um banco de dados, não pelo que disse na resposta final.

O exemplo motivador é um agente de suporte lidando com uma entrega atrasada. Ele faz nove chamadas de ferramenta, lê corretamente a política de reembolso e fecha o ticket como resolvido. Duas coisas continuam erradas: a exceção da transportadora segue aberta, então o ticket deveria ter sido deixado em espera, e a cliente nunca recebeu resposta para sua pergunta real. Um avaliador que checasse apenas as chamadas de ferramenta ou a frase final marcaria isso como sucesso. O banco de dados discorda.

O ThinkingBox-Bench roda 507 fluxos de trabalho empresariais com estado, em domínios de varejo, seguros de automóvel, viagens, neobank e consultoria, cada um repetido 20 vezes por modelo contra 18 LLMs proprietários e de peso aberto, com cada tentativa partindo de um backend limpo idêntico. Em uma ablação de conjunto comum com 121.680 tentativas válidas em 12 modelos, 79.853 tentativas falharam nas checagens executáveis mesmo que 67,24% dessas falhas tenham terminado de forma limpa, sem erro de ferramenta reportado. Das falhas, 77,61% tinham valores de campo errados, 43,30% produziram efeitos extras não intencionais e 25,36% deixaram de executar um efeito obrigatório.

A acurácia em tentativa única (pass@1) e a consistência ao longo das 20 tentativas (20/20 observado) contam histórias muito diferentes. O Claude Opus 5.5 lidera o pass@1 geral com 67,16%, com o Kimi-K3 como o modelo de peso aberto mais forte, em 57,37%. Mas o Kimi-K3 resolve 93,89% das tarefas pelo menos uma vez, enquanto passa em apenas 13,41% (68 de 507) em todas as tentativas; o Claude Opus 5 resolve menos tarefas pelo menos uma vez (79,09%), mas passa em 47,53% (241 de 507) em todas as vezes. Um modelo mais novo, o Claude Opus 5.5, pontuou mais alto na média que o Claude Opus 5, mas passou no mesmo número exato de tarefas (241) em todas as 20 tentativas, o que significa que o ganho de acurácia não comprou nenhuma confiabilidade adicional.

O detalhamento diagnóstico das falhas é a parte mais acionável: 79,9% são erros de uso de ferramenta, 10,3% são atualizações de estado erradas, 7,0% são resoluções incompletas para o usuário, e apenas 2,9% envolvem nenhuma ação de mudança de estado. Isso significa que a maioria das falhas são problemas de repetição e recuperação, não problemas de raciocínio.

O ThinkingBox já está disponível via Hugging Face e OpenEnv, com o framework sob licença MIT e os dados do benchmark sob CDLA-Permissive-2.0.

Fonte: Hugging Face

Próximo passo

Visibility Analyzer

É isto que o Visibility Analyzer mede num site real: quais respostas citam você, quais páginas o motor não consegue recuperar e o que corrigir primeiro. Rodar é grátis.

Rodar uma auditoria de visibilidade grátis

Rodar é grátis. Sem cartão.

Preço
Grátis
Duração
Uma rodada, minutos

Plano grátis: duas análises por dia, sem cartão.