ThinkingBox Avalia Agentes de IA com Base nos Resultados de Bases de Dados e na Fiabilidade Repetida

4 de outubro de 2026 – Investigadores da Microsoft divulgaram o ThinkingBox na plataforma Hugging Face, introduzindo uma nova forma de avaliar agentes de grandes modelos de linguagem (LLM) que interagem com ferramentas externas. Ao contrário dos benchmarks anteriores, que recompensam uma resposta correta em linguagem natural ou uma chamada de ferramenta sintacticamente válida, o ThinkingBox mede o estado final do backend e os efeitos colaterais depois de um agente ter executado um fluxo de trabalho empresarial. O benchmark contém 507 processos empresariais distintos e com estado – como registo de encomendas, atualização de inventário ou modificação de registo de cliente – cada um executado 20 vezes em sessões isoladas da ferramenta Microsoft Copilot (MCP). Ao focar nos resultados reais das bases de dados, o conjunto procura revelar problemas de fiabilidade que só se manifestam após um uso repetido e no mundo real.

Como Funciona o ThinkingBox

Cada um dos 507 fluxos de trabalho está codificado como uma sequência de chamadas de ferramentas que manipulam uma base de dados relacional. O benchmark executa um isolamento completo do ambiente da ferramenta MCP para cada tentativa, garantindo que nenhuma contaminação entre execuções possa mascarar erros. Depois de o agente concluir uma execução, o ThinkingBox inspeciona a captura instantânea final da base de dados e a compara com uma especificação de referência que enumera as linhas esperadas, valores de colunas e efeitos colaterais, como registos de auditoria. O rubro de avaliação não considera se o agente produziu um resumo textual fluente; regista apenas se o estado do backend corresponde à especificação, se ocorreram alterações não intencionadas e se alguma ferramenta reportou um erro.

A avaliação abrangeu 12 agentes de LLM disponíveis publicamente, desde modelos de código aberto até ofertas comerciais. No total, o experimento gerou 121 680 tentativas válidas – o produto de 507 fluxos de trabalho, 20 repetições e 12 modelos. Destas, 79 853 tentativas falharam na fase de verificação executável, o que significa que o agente não emitiu uma chamada de ferramenta necessária ou produziu uma chamada que não pôde ser analisada. Notavelmente, 67,24 % dessas tentativas falhadas ainda terminaram sem um erro final de ferramenta, tendo invocado pelo menos uma ferramenta que altera o estado antes de parar. Este padrão evidencia uma desconexão entre o aparente sucesso de um agente e as inconsistências ocultas que permanecem na base de dados.

Principais Conclusões

Quando uma tentativa falha na verificação executável, o benchmark regista três categorias de desvio. Valores de campo incorretos apareceram em 77,61 % das tentativas falhadas, indicando que os agentes frequentemente escrevem dados errados mesmo quando a chamada de ferramenta tem sucesso. Efeitos não intencionados – ações que alteram partes da base de dados não especificadas pelo fluxo de trabalho – foram observados em 43,30 % das falhas, enquanto efeitos ausentes – alterações esperadas que nunca se materializaram – ocorreram em 25,36 % dos casos. As percentagens sobrepõem‑se porque uma única execução pode apresentar múltiplos tipos de erro simultaneamente. Estes números demonstram que a maioria das falhas impulsionadas por ferramentas ainda deixa a base de dados num estado inconsistente ou apenas parcialmente correto.

O desempenho variou amplamente entre os modelos. O Claude Opus 5.5 atingiu a maior pontuação pass@1, conseguindo sucesso em 67,16 % das 121 680 tentativas na sua primeira tentativa. O Kimi‑K3 apresentou um perfil diferente: resolveu 93,89 % das tarefas pelo menos uma vez ao longo das 20 repetições, mas apenas 13,41 % das execuções tiveram sucesso em todas as repetições. Este contraste sublinha a importância de medir a fiabilidade ao longo de execuções repetidas, em vez de considerar apenas um caso ótimo único. Os restantes modelos agruparam‑se entre estes extremos, com muitos apresentando taxas pass@1 abaixo de 50 % e variabilidade substancial entre as repetições.

Limitações do Benchmark

O ThinkingBox foi deliberadamente limitado a um conjunto curado de fluxos de trabalho empresariais, e os autores salientam que os números não representam todos os cenários de produção que uma empresa pode encontrar. O benchmark isola cada tentativa numa nova sessão MCP, o que elimina a influência da acumulação de estado a longo prazo, caching ou dependências entre fluxos que existem em sistemas ao vivo. Além disso, a avaliação foca‑se nos resultados de bases de dados relacionais; agentes que interagem com serviços não‑SQL, sistemas de ficheiros ou APIs externas não são cobertos. Por fim, a métrica trata qualquer desvio da especificação de referência como falha, mesmo quando o desvio poderia ser inofensivo num contexto empresarial específico.

• 79 853 tentativas falharam nas verificações executáveis de um total de 121 680 tentativas.
• 67,24 % das tentativas falhadas terminaram limpas sem um erro final de ferramenta.
• 77,61 % das falhas reportaram valores de campo errados na base de dados.
• 43,30 % das falhas produziram efeitos colaterais não intencionados.
• 25,36 % das falhas omitiram efeitos esperados.
• Claude Opus 5.5 liderou o pass@1 com 67,16 % de sucesso.
• Kimi‑K3 resolveu 93,89 % das tarefas pelo menos uma vez, mas apenas 13,41 % em todas as 20 execuções.

As implicações práticas são imediatas para os programadores que constroem automação impulsionada por IA. Ao expor a frequência com que os agentes escrevem silenciosamente dados errados ou perdem actualizações necessárias, o ThinkingBox incentiva uma mudança de “a chamada de ferramenta tem sucesso?” para “a base de dados termina correta?”. As equipas podem agora usar o benchmark para priorizar testes de robustez, adicionar transacções compensatórias ou redesenhar prompts que reforcem melhor o comportamento idempotente. Os dados também dão aos fornecedores um alvo concreto: melhorar a repetibilidade entre execuções, não apenas alcançar uma elevada taxa de sucesso numa única tentativa. À medida que as empresas adotam agentes de LLM para tarefas críticas de back‑office, a capacidade de certificar que os dados subjacentes permanecem confiáveis torna‑se um diferencial competitivo.

Para o futuro, a Microsoft e a comunidade de investigação mais ampla planeiam expandir o ThinkingBox com categorias adicionais de fluxos de trabalho, rastreamento mais rico de efeitos colaterais e integração com pipelines de integração contínua. O benchmark já está disponível no Hugging Face, permitindo que qualquer pessoa execute os mesmos 507 fluxos de trabalho contra os seus próprios agentes e compare os resultados com a linha de base publicada. Ao tornar a avaliação centrada nos resultados aberta e repetível, o ThinkingBox está preparado para mudar a forma como a indústria mede a fiabilidade dos agentes de IA, deslocando a conversa do nível superficial da correção para a questão mais profunda de se a base de dados – a fonte final de verdade – reflete o resultado empresarial pretendido.