Seu agente acertou a tarefa uma vez, mas vai acertar de novo?
A Hugging Face e a IBM Research mostram por que a média de acerto esconde a inconsistência dos agentes de IA e propõem uma forma de medir e reduzir esse gargalo em produção.
O cenário é conhecido por quem já colocou um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → para rodar de verdade: no ensaio ele resolve a tarefa, mas na demo ao vivo escolhe outro caminho e falha na mesma requisição. No palco é constrangedor. Em produção, é um problema de confiabilidade, e para trabalho crítico (reconciliar uma transação financeira, checar uma obrigação num contrato) vira impeditivo.
Um artigo publicado pela Hugging Face, assinado por pesquisadores da IBM Research, ataca exatamente esse ponto: a maioria dos benchmarks esconde essa variabilidade atrás de uma média. O texto apresenta o Consistency Analyzer e um novo tipo de guideline no toolkit open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → ALTK-Evolve, com o objetivo de medir e melhorar consistência, não só acerto médio.
A métrica que quase ninguém reporta
A avaliação padrão de agentes usa Mean@k: roda o benchmark k vezes e tira a média da taxa de acerto. É o número de todo leaderboard, o tal "77% de acurácia". Ele responde "quão bom é esse agente na média?", mas não responde a pergunta que o usuário real faz: se eu repetir exatamente a mesma requisição, vai funcionar de novo?
Para isso existe o Pass^k: a fração de tarefas em que o agente acerta em todas as k rodadas independentes. E aqui está o cuidado importante que o artigo faz questão de destacar, porque a confusão de letra é fácil:
- Pass@k (otimista): pelo menos uma das k tentativas passou. É a pergunta certa quando você pode verificar e tentar de novo, comum em papers de geração de código.
- Pass^k (pessimista): toda tentativa precisa passar.
- A relação é sempre
Pass^k ≤ Mean@k ≤ Pass@k.
Os números do estudo dão o tamanho do buraco. Um agente ReAct rodando GPT-4.1 no AppWorld (test_normal, 168 tarefas) marca Mean@5 de 77,4%, genuinamente forte. Mas o Pass^5 é de apenas 53,0%. Ou seja: quase um quarto do benchmark é composto de tarefas que o agente às vezes resolve e às vezes não, sem que nada mude entre as rodadas. Essa diferença (Mean@k menos Pass^k) é o que os autores chamam de consistency gap, aqui de 24,4 pontos percentuais, chegando a 30 pontos nas tarefas difíceis.
O ponto que muda a cabeça de quem constrói: isso não é falta de capacidade que um modelo maior resolve. É um eixo ortogonal. Um agente pode ser capaz e inconsistente ao mesmo tempo.
Por que o agente muda de ideia
Toda vez que um agente LLM decide algo (qual API chamar, qual argumento passar, se vale tentar de novo), essa decisão sai de uma distribuição de probabilidade sobre os próximos tokens. O que importa é o formato dessa distribuição.
Uma distribuição afiada concentra quase toda a massa num único token: os segundos colocados ficam bem atrás e a mesma escolha sai rodada após rodada. Uma distribuição plana espalha massa parecida entre vários tokens quase empatados, e qual deles vence é praticamente cara ou coroa.
O detalhe cruel é que essa instabilidade sobrevive às suas configurações de decoding. O artigo é explícito: o agente do experimento roda a temperatura 0.0, então nada dessa variância é sampling comum. Greedy decoding e seed fixa governam apenas como a distribuição vira token, não a distribuição em si. Em um endpoint hospedado, efeitos de plataforma (não associatividade de ponto flutuante na GPU, batching de requisições) empurram os números o suficiente para reordenar um empate técnico. E como uma trajetória encadeia dezenas de decisões, uma pequena chance de flip por passo se acumula numa grande chance de que alguma rodada saia diferente. É daí que vem o gap de 24 pontos.
Diagnosticar antes de corrigir
O problema vira uma busca: quais passos daquela trajetória eram os "planos", e o que fazer com eles depois de identificados. A resposta é um pipeline de duas etapas que se encaixa na máquina que o ALTK-Evolve já tinha (ele já transformava trajetórias passadas do agente em guidelines reutilizáveis injetadas na inferência).
1. Detectar, o Consistency Analyzer. Dada uma única trajetória gravada, o analyzer reprocessa cada passo de decisão com resampling controlado, medindo quanto a saída do modelo de fato varia ali. Na prática é uma chamada extra ao modelo por passo de decisão, feita uma vez, offline, pedindo k completions de uma vez (k=5 por padrão), reproduzida contra o contexto já gravado. Não há nova chamada de ferramenta, nem nova interação com o ambiente, nem um segundo rollout ponta a ponta da tarefa. Cada passo ganha um score de consistência num scorecard que aponta exatamente quais decisões correm risco de virar na próxima rodada.
Dois pontos práticos aqui importam mais do que o resto para quem opera em produção: a detecção é totalmente black-box (sem logits, sem internals do modelo, só o trace que você já tem) e não precisa de ground truth nem de replay ao vivo. Isso é o que torna a técnica usável em tráfego real, onde muitas vezes você não consegue reexecutar uma tarefa nem uma vez.
2. Gerar guidelines direcionadas. Cada passo sinalizado vira uma guideline candidata no formato padrão do ALTK-Evolve. O artigo mostra um exemplo real gerado pelo GPT-4.1 a partir da tarefa "quantas atividades da minha bucket list estão na minha nota do SimpleNote?":
- Ao contar marcadores tipo checkbox no conteúdo de uma nota, use regex ancorado por linha em vez de contagem de substring simples, porque títulos costumam repetir o símbolo do marcador numa linha de legenda.
- Sempre verifique os resultados de busca de notas checando múltiplos matches e confirmando a nota correta antes de prosseguir.
Repare: nada disso é trivia específica da tarefa. Bug de contagem de string e resultado de busca não verificado são pontos de decisão com alta incerteza que aparecem em muitas tarefas. O analyzer mira instabilidade, não falha, ou seja, pega passos que o agente acertou desta vez mas poderia errar na próxima.
Os números: corta o gap sem perder acurácia
Gerando guidelines de consistência a partir de uma única trajetória baseline por tarefa e testando em 5 novas rodadas, o resultado agregado foi:
- Pass^5 sobe de 53,0% para 69,0%, enquanto o Mean@5 sobe de 77,4% para 81,0%. O gap cai de 24,4pp para 12,0pp, aproximadamente metade.
- Quase um terço das tarefas antes inconsistentes passam a acertar em todas as rodadas.
- Os ganhos maiores estão no meio e no topo da dificuldade: Medium +22,9pp (+44% relativo) e Hard +14,3pp (+45% relativo). Easy sobe +12,2pp, com menos espaço para melhorar.
- O Mean@5 nunca cai. Preservar a acurácia média era requisito, não bônus: um sistema que aumenta o Pass^5 trocando por Mean@5 só estaria empurrando a falta de confiabilidade para outro canto.
Há evidência de que as guidelines generalizam, não só remendam uma trajetória. Aplicadas a uma tarefa diferente mas relacionada no mesmo cenário do AppWorld, ainda elevam o Pass^5 em +13,0pp, só 3 pontos abaixo do número na mesma tarefa. E num modelo mais fraco, o gpt-oss-120b, o ganho em tarefa similar (+8,7pp) chegou a superar o da mesma tarefa (+6,0pp), sugerindo que estão capturando padrões de falha reutilizáveis em vez de decorar uma trajetória.
O que muda pra quem está subindo agente
A lição direta do artigo para quem já tem agente em produção ou prestes a subir:
- Reporte Pass^k ao lado do Mean@k. Média não distingue um agente confiável de um agente sortudo. Mesmo com k=3 já aparece um gap que você não sabia que tinha.
- Espere o gap crescer com a dificuldade. É justamente na sua camada mais difícil que um número médio único mais engana.
- Não puxe primeiro por um modelo maior. Consistência é ortogonal a capacidade. Modelo mais forte sobe o Mean@k, mas não necessariamente fecha o gap de consistência.
- O diagnóstico não precisa de grader nem de replay. Uma chamada extra ao LLM por passo de decisão basta.
O Consistency Analyzer e a geração de guidelines já estão no repositório open source do ALTK-Evolve, e a metodologia completa está no relatório técnico no arXiv. Para o dev brasileiro que hoje mede seu agente por "passou na demo", o recado prático é anterior à ferramenta: começar a rodar a mesma requisição múltiplas vezes e olhar em quantas ela passou em todas, não na média. Esse é o número que o usuário sente.
Fonte: Hugging Face Blog
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
