Testes de Consistência de Agentes da IBM Revelam Por Que Um Sucesso Não Basta

Os testes de consistência de agentes da IBM expuseram um forte conflito entre sucesso em benchmarks e comportamento confiável. Um agente GPT-4.1 concluiu 77,4% de suas execuções no AppWorld, mas teve sucesso em todas as cinco tentativas em apenas 53,0% das tarefas.

Essa diferença de 24,4 pontos muda o que uma demonstração bem-sucedida de um agente significa. Uma execução correta pode mostrar que um agente tem a capacidade necessária. Ela não pode mostrar que os usuários receberão o mesmo resultado amanhã, ou mesmo cinco minutos depois.

A IBM Research está abordando essa distinção com novas diretrizes de consistência no ALTK-Evolve. O sistema encontra decisões instáveis em uma trajetória registrada do agente e transforma essas fragilidades em instruções reutilizáveis. Seus primeiros resultados sugerem que ganhos de confiabilidade nem sempre exigem um modelo maior.

O trabalho também pressiona a forma padrão como fornecedores apresentam o desempenho de agentes. Uma média em um ranking pode recompensar um agente que funciona com frequência, enquanto oculta quantas vezes ele falha depois de já ter tido sucesso.

Resultados de Consistência da IBM Expõem a Métrica Ausente

A descoberta central da IBM é que precisão média e sucesso repetível descrevem dois produtos materialmente diferentes.

Os pesquisadores testaram um agente ReAct alimentado por GPT-4.1 em 168 tarefas da divisão test_normal do AppWorld. ReAct é um design de agente que alterna etapas de raciocínio com ações, como chamar uma aplicação ou pesquisar informações armazenadas.

Cada tarefa recebeu cinco novas execuções. Segundo o estudo de consistência da IBM, o agente de referência alcançou uma pontuação Mean@5 de 77,4%. Mean@5 calcula a média da taxa de sucesso em cinco tentativas.

Esse número parece adequado para uma forte demonstração de produto. No entanto, o agente alcançou uma pontuação Pass^5 de apenas 53,0%. Pass^5 considera uma tarefa bem-sucedida apenas quando todas as cinco tentativas têm sucesso.

A diferença entre esses resultados é a lacuna de consistência. Nesse caso, ela chegou a 24,4 pontos percentuais. No grupo de tarefas mais difícil, a IBM afirma que a lacuna chegou a 30 pontos.

Essa distinção é importante porque Pass^5 não é a conhecida métrica Pass@5 usada em algumas avaliações de programação. Pass@5 pergunta se pelo menos uma entre cinco tentativas tem sucesso. Pass^5 pergunta se todas as tentativas têm sucesso.

Essas métricas atendem a produtos diferentes. Pass@5 funciona quando um sistema pode gerar vários candidatos, testá-los e manter o vencedor. Pass^5 se adequa a fluxos de trabalho nos quais cada execução precisa ser confiável.

Um desenvolvedor que pede a um agente cinco possíveis correções de código pode se beneficiar de uma resposta válida. Uma equipe de contas que pede a um agente para reconciliar uma transação não pode aceitar com segurança quatro execuções corretas e um erro prejudicial.

A mesma questão se aplica à análise de contratos. Um agente que identifica uma obrigação em uma revisão, mas não em outra, não é apenas variável. Ele cria decisões de negócio inconsistentes a partir de evidências idênticas.

Os resultados da IBM não mostram que o GPT-4.1 não tenha a capacidade de executar essas tarefas. Uma média de 77,4% estabelece que ele frequentemente consegue. Os resultados mostram que essa capacidade não resistiu de forma confiável à repetição nessa configuração específica de agente.

Essa é a inversão central do artigo. O primeiro sucesso é evidência de possibilidade, não evidência de confiabilidade operacional.

A comunidade mais ampla de avaliação chegou a uma conclusão semelhante. As orientações da Anthropic para avaliação de agentes separam Pass@k de Pass^k e recomendam alinhar a métrica aos requisitos do produto.

A Anthropic oferece uma ilustração simples. Uma tarefa com taxa de sucesso por tentativa de 75% tem aproximadamente 42% de chance de ter sucesso em três tentativas independentes. A qualidade aparente cai porque o requisito muda de sucesso ocasional para sucesso ininterrupto.

As médias ainda têm valor. Elas ajudam a comparar a capacidade geral e revelam se uma mudança melhora os resultados em um conjunto de tarefas. Tornam-se enganosas quando compradores as interpretam como uma garantia de confiabilidade.

Para implementações empresariais, ambos os números pertencem à avaliação. Mean@k informa às equipes com que frequência um agente funciona. Pass^k informa quantas tarefas permanecem confiáveis em usos repetidos.

Por Que um Agente Pode Mudar de Rumo com Temperatura Zero

Um agente pode se tornar inconsistente mesmo quando o prompt, o modelo, as ferramentas e a temperatura de decodificação parecem inalterados.

Um LLM escolhe cada próximo token a partir de uma distribuição de probabilidade. Algumas decisões têm uma opção claramente favorita, enquanto outras contêm várias alternativas quase empatadas.

A IBM descreve essas decisões como agudas e planas. Uma distribuição aguda concentra a maior parte da probabilidade em uma escolha. Pequenas mudanças computacionais dificilmente alterarão a vencedora.

Uma distribuição plana distribui a probabilidade entre várias escolhas plausíveis. Uma pequena mudança numérica pode alterar qual token vem primeiro, levando o agente por um caminho diferente.

Essa diferença se torna importante em sistemas que usam ferramentas. Um único token alterado pode mudar a seleção de uma API, uma consulta de busca, um argumento de ferramenta, uma decisão de nova tentativa ou a interpretação de um resultado intermediário.

Um chatbot comum pode absorver alguma variação de redação sem alterar seu significado final. Um agente age com base em suas escolhas intermediárias. Cada escolha alterada muda as informações disponíveis na próxima etapa.

O risco se acumula ao longo de uma trajetória extensa. Se um agente toma dezenas de decisões, várias podem estar próximas de limites instáveis. Basta que uma mude para que uma chamada de ferramenta posterior ou a resposta final falhe.

A IBM executou seu agente ReAct com temperatura 0.0. Por isso, os pesquisadores argumentam que a amostragem comum não causou a variabilidade observada.

Temperatura zero não torna toda execução de modelo hospedado matematicamente idêntica. Agrupamento de solicitações, comportamento do hardware, operações de ponto flutuante e detalhes de implementação do provedor podem alterar ligeiramente as probabilidades.

Essas mudanças frequentemente permanecem invisíveis na geração de texto comum. Elas importam quando duas escolhas estão quase empatadas. Uma pequena alteração pode reordená-las, apesar de a solicitação do usuário não ter mudado.

Uma semente fixa também tem limites. Ela controla parte do processo de geração, mas não congela todas as camadas de um sistema remoto de inferência. Tampouco torna uma decisão incerta mais decisiva.

Esse mecanismo explica por que um ensaio bem-sucedido pode falhar durante uma demonstração ao vivo. O agente não necessariamente esqueceu a tarefa. Ele entrou em outro ramo da mesma árvore de decisões.

Considere um agente solicitado a contar atividades concluídas em uma nota. Em uma execução, ele pode contar todos os marcadores de caixa de seleção. Em outra, também pode contar uma legenda que explica o formato da caixa de seleção.

Ambos os caminhos podem inicialmente parecer razoáveis. Apenas um produz o total pretendido. O erro surge de uma decisão não resolvida sobre como interpretar o documento, e não da falta de acesso à nota.

Fluxos de trabalho mais longos ampliam esse comportamento. Um agente de pesquisa pode escolher uma fonte diferente, interpretar mal uma data ambígua ou parar após o primeiro documento correspondente. Cada escolha molda tudo o que vem depois.

Isso torna a confiabilidade de agentes de IA parcialmente um problema de orquestração. Um modelo-base melhor pode aumentar a chance de tomar boas decisões, mas não garante que suas escolhas limítrofes desapareçam.

Condições externas acrescentam outra camada. O ReliabilityBench avalia execuções repetidas juntamente com solicitações parafraseadas e falhas de ferramentas. Seu framework de estresse para produção trata consistência, robustez e tolerância a falhas como dimensões separadas.

O experimento atual da IBM isola execuções repetidas de forma mais restrita. Esse foco torna a lacuna de consistência mais fácil de inspecionar, mas não representa todas as falhas de produção que um agente encontrará.

Implementações reais enfrentam dados alterados, credenciais expiradas, limites de taxa de APIs, respostas parciais e esquemas em evolução. Portanto, comportamento estável sob entrada idêntica é um requisito inicial, não o padrão completo de confiabilidade.

ALTK-Evolve Transforma Incerteza em Orientação Direcionada

O ALTK-Evolve tenta corrigir decisões instáveis sem reproduzir cada tarefa em um ambiente ao vivo.

O novo processo começa com uma trajetória registrada. Uma trajetória é o registro ordenado de prompts, decisões, chamadas de ferramentas, observações e respostas produzidas durante uma execução do agente.

O Analisador de Consistência da IBM revisita cada ponto de decisão usando o contexto já armazenado nesse rastreamento. Ele solicita várias conclusões alternativas e mede quanto a escolha do modelo varia.

A configuração padrão obtém cinco conclusões por meio de uma chamada adicional ao modelo para cada etapa de decisão. Ela não repete as chamadas de ferramentas externas nem executa novamente a tarefa completa.

Esse design é importante em produção. Uma reprodução completa poderia enviar outro e-mail, modificar um registro duas vezes, duplicar uma compra ou encontrar dados que já foram alterados.

A reamostragem offline evita esses efeitos colaterais. Ela também elimina a necessidade de um rótulo de verdade fundamental durante a etapa de diagnóstico.

O analisador é de caixa-preta, o que significa que não requer logits do modelo nem acesso interno. As equipes podem aplicá-lo a um modelo hospedado se possuírem o rastreamento original e puderem reenviar seus contextos de decisão.

Cada decisão recebe uma pontuação de consistência. Etapas com conclusões divergentes tornam-se candidatas a orientação adicional.

O ALTK-Evolve então transforma esses candidatos em instruções comportamentais concisas. Seu objetivo mais amplo é extrair lições úteis de trajetórias anteriores e recuperá-las durante tarefas posteriores.

Para o exemplo de contagem de notas, a orientação gerada recomendou uma expressão regular ancorada em linhas em vez de uma contagem básica de substring. Ela também instruiu o agente a inspecionar várias correspondências de busca antes de selecionar uma nota.

Essas instruções abordam padrões gerais de falha. Elas não apenas salvam a resposta numérica correta da tarefa original.

Essa diferença é essencial. Memorizar uma resposta melhoraria um item de benchmark sem fortalecer o agente. Uma regra reutilizável pode ajudar com novas notas, formatos diferentes de caixas de seleção ou decisões de busca relacionadas.

O repositório do ALTK-Evolve agora inclui o Analisador de Consistência e componentes de geração de diretrizes. O projeto usa uma licença Apache 2.0 e oferece suporte à integração por meio do Model Context Protocol.

Sua camada de recuperação leva diretrizes relevantes ao contexto do agente no momento da inferência. Isso fornece ao modelo lembretes direcionados sem exigir que cada rastreamento histórico permaneça no prompt ativo.

A abordagem se assemelha a uma forma focada de memória operacional. Em vez de pedir ao agente que releia tudo o que fez, o sistema destila lições recorrentes e recupera aquelas associadas à tarefa atual.

Essa distinção também importa para o trabalho do conhecimento. Um arquivo maior não produz automaticamente decisões melhores. Uma memória útil exige seleção, tratamento de conflitos e contexto adequado à solicitação ativa.

O mesmo princípio sustenta uma base de conhecimento de IA bem estruturada. O material armazenado se torna valioso quando um sistema consegue recuperar a evidência certa sem sobrecarregar o contexto de trabalho.

O método do ALTK-Evolve é mais restrito do que uma plataforma geral de conhecimento. Ele se concentra no comportamento de agentes e usa diretrizes derivadas de trajetórias. Ainda assim, ambos os casos expõem a mesma limitação: reter informações é mais fácil do que aplicar as informações certas no momento certo.

O mecanismo também cria um ciclo de feedback. As equipes podem coletar rastros, detectar etapas instáveis, gerar orientações candidatas e avaliar se essas orientações melhoram execuções posteriores.

No entanto, o sistema não elimina a necessidade de testes. Uma regra gerada pode estar errada, ser excessivamente ampla ou prejudicial fora da situação que a produziu.

As equipes ainda precisam de versionamento e reversão. Também precisam rastrear qual diretriz influenciou uma decisão, especialmente quando um agente realiza trabalho regulado ou com consequências financeiras.

O Ganho de Confiabilidade É Grande, mas as Evidências São Limitadas

A IBM relata uma melhoria substancial, embora o estudo ainda seja uma avaliação inicial em uma única configuração principal de benchmark.

Após a adição de diretrizes de consistência, o Pass^5 aumentou de 53,0% para 69,0% nas 168 tarefas do AppWorld. Isso representa uma melhoria de 16 pontos nas tarefas aprovadas em todas as cinco execuções.

O Mean@5 também subiu, passando de 77,4% para 81,0%. A lacuna de consistência, portanto, diminuiu de 24,4 pontos para 12,0 pontos.

Esse resultado importa porque a média não caiu. Um método que melhorasse a repetibilidade ao forçar o agente a adotar uma estratégia consistentemente medíocre não resolveria o problema subjacente.

A IBM afirma que as diretrizes mantiveram ou melhoraram o Mean@5 em todos os níveis de dificuldade. O grupo intermediário ganhou 22,9 pontos em Pass^5, enquanto o grupo difícil ganhou 14,3 pontos.

Os ganhos relativos foram de 44% para tarefas intermediárias e 45% para tarefas difíceis. As tarefas fáceis ganharam 12,2 pontos, com menos espaço disponível para melhoria.

A IBM também testou as diretrizes em uma tarefa diferente, porém relacionada, dentro do mesmo cenário do AppWorld. O Pass^5 aumentou 13 pontos, em comparação com o ganho de 16 pontos na mesma tarefa.

Esse resultado sustenta a afirmação de que algumas diretrizes são transferíveis além de uma trajetória registrada. Ele não estabelece uma generalização ampla entre aplicações, setores ou arquiteturas de agentes não relacionados.

Um segundo experimento utilizou gpt-oss-120b. Seu Pass^5 na mesma tarefa aumentou de 10,1% para 16,1%, enquanto o desempenho em tarefas semelhantes ganhou 8,7 pontos.

A linha de base mais fraca mostra que a orientação não pode substituir integralmente a capacidade. Uma melhoria de seis pontos é significativa, mas uma taxa de sucesso em todas as execuções de 16,1% continua inadequada para automação com consequências relevantes.

O relatório técnico completo apresenta a metodologia por trás dessas afirmações. Ainda assim, os leitores devem tratar os resultados como evidências da avaliação dos autores, e não como confirmação independente em sistemas de produção.

O teste principal usa uma configuração ReAct, uma divisão principal de benchmark e cinco repetições por tarefa. O AppWorld oferece cenários realistas de múltiplas aplicações, mas um benchmark continua sendo um ambiente controlado.

Cinco execuções revelam uma instabilidade que uma única execução esconde. Elas não estimam com precisão falhas raras que poderiam surgir ao longo de milhares de interações com clientes.

A avaliação também levanta uma questão estatística. O Pass^k cai naturalmente à medida que k aumenta, pois cada tentativa adicional cria outra oportunidade de falhar.

Portanto, uma equipe de produto deve escolher k com base na exposição real. Cinco execuções bem-sucedidas podem ser uma triagem de desenvolvimento razoável. Isso não comprova confiabilidade em escala empresarial.

As diretrizes também podem ficar desatualizadas. APIs mudam, políticas evoluem e soluções alternativas anteriores podem entrar em conflito com o novo comportamento do sistema.

Uma regra derivada de um ramo instável pode suprimir uma alternativa válida em outro contexto. Quanto mais diretrizes um sistema acumula, mais importantes se tornam a resolução de conflitos e a qualidade da recuperação.

Também há uma diferença entre comportamento consistente e comportamento correto. Um agente que repete a mesma ação errada tem estabilidade comportamental perfeita e valor de tarefa zero.

O experimento da IBM se protege contra esse problema ao reportar Mean@5 junto com Pass^5. As equipes de produção devem preservar a mesma combinação e adicionar medidas de segurança específicas para os resultados.

Para fluxos de trabalho sensíveis, a correção consistente deve ser o objetivo. A estabilidade, por si só, nunca deve substituir a precisão factual, a conformidade com políticas, as verificações de autorização ou a revisão humana.

Modelos Maiores Agora Enfrentam um Concorrente em Nível de Sistema

As novas evidências desafiam a suposição de que os problemas de confiabilidade devem ser resolvidos primeiro pela substituição do modelo subjacente.

As atualizações de modelo continuam atraentes porque podem melhorar muitas tarefas de uma só vez. Elas também exigem menos diagnóstico personalizado do que reconstruir a memória ou o sistema de avaliação de um agente.

No entanto, um modelo maior não revela onde um agente existente se torna instável. Ele pode elevar o desempenho médio enquanto mantém uma lacuna significativa entre o sucesso ocasional e o sucesso repetido.

A abordagem da IBM representa uma rota concorrente. Em vez de alterar o modelo, ela altera as informações fornecidas nos pontos de decisão de alto risco.

A comparação não é estritamente entre modelo e memória. Sistemas robustos usarão modelos capazes, ferramentas bem projetadas, contexto direcionado, verificações determinísticas e avaliações repetidas em conjunto.

A pressão recai sobre fornecedores de agentes e compradores corporativos que ainda reportam uma única taxa de sucesso. Quando o Pass^k entrar nas discussões de aquisição, uma média elevada será apenas parte das evidências.

Os compradores podem perguntar se a mesma tarefa foi repetida, se o ambiente foi redefinido e se cada execução alcançou um resultado aceitável. Também podem solicitar resultados por nível de dificuldade, em vez de um único número agregado.

Os desenvolvedores enfrentam uma mudança relacionada. Um relatório de bug que afirma que um agente falhou uma vez talvez não seja mais reproduzível sob demanda. As equipes precisam de rastros completos para localizar a decisão anterior que divergiu.

A observabilidade passa a fazer parte da qualidade do produto. Sem prompts armazenados, argumentos de ferramentas, resultados e escolhas intermediárias, uma execução instável pode desaparecer sem explicar a si mesma.

Isso torna a arquitetura de avaliação importante antes da implantação. As equipes precisam de tarefas representativas, estados iniciais controlados, critérios explícitos de sucesso e repetições suficientes para expor a variância.

Elas também precisam separar trabalhos que permitem novas tentativas de ações únicas. Gerar um rascunho pode tolerar várias tentativas. Enviar um pagamento, excluir um arquivo ou aprovar um contrato exige controles mais rígidos.

O Pass@k se encaixa no primeiro grupo quando as saídas podem ser verificadas automaticamente. O Pass^k é mais informativo para o segundo grupo, especialmente quando os usuários esperam que o primeiro resultado seja seguro.

Alguns fluxos de trabalho não devem depender apenas de nenhuma dessas métricas. Um agente de transações também precisa de limites de permissão, controles de idempotência, logs de auditoria e validação determinística antes de executar uma ação irreversível.

As diretrizes podem reduzir o raciocínio incerto, mas não substituem essas salvaguardas. Um agente confiável é uma propriedade do sistema, não uma pontuação de modelo.

Os resultados também reforçam o argumento a favor de um contexto de trabalho selecionado. As equipes já usam knowledge blending para conectar evidências armazenadas ao trabalho ativo. As diretrizes para agentes aplicam uma ideia semelhante às lições comportamentais.

O ponto central é a moderação. Mais contexto recuperado pode criar distrações, contradições e latência adicional. Uma instrução direcionada só tem valor quando alcança a tarefa correta e não desloca evidências essenciais.

É aí que reside o desafio de longo prazo do ALTK-Evolve. Seu diagnóstico pode identificar decisões variáveis, mas o sistema ao redor precisa administrar uma coleção crescente de lições.

Uma implantação bem-sucedida precisará de políticas de expiração, detecção de conflitos, proveniência e avaliações para mudanças nas diretrizes. Caso contrário, a correção de ontem pode se tornar a fonte oculta de falhas de amanhã.

O Que Mostrará se a Abordagem da IBM se Sustenta

Três sinais determinarão se as diretrizes de consistência se tornarão uma camada padrão para agentes ou continuarão sendo uma técnica promissora de benchmark.

O primeiro sinal é a reprodução independente em outros benchmarks e arquiteturas de agentes. Pesquisadores devem testar o método em agentes de navegador, agentes de programação, sistemas de atendimento ao cliente e fluxos de trabalho com falhas reais de API.

Uma repetição da melhoria de 16 pontos em Pass^5 fortaleceria a afirmação central da IBM. Ganhos menores ou inconsistentes sugeririam que o AppWorld contém padrões de falha especialmente adequados ao reparo por diretrizes.

As comparações devem incluir vários modelos-base. Elas também devem reportar uso de tokens, latência, custo do analisador, sobrecarga de recuperação e o número de diretrizes injetadas por tarefa.

O segundo sinal é o desempenho em períodos mais longos. Um sistema de aprendizado útil deve lidar com novas orientações sem acumular regras conflitantes ou obsoletas.

As equipes devem medir se o benefício sobrevive após centenas ou milhares de trajetórias. Também devem testar se a recuperação das diretrizes permanece precisa à medida que o repositório cresce.

Observe avaliações que congelam um conjunto de diretrizes e o testam contra versões posteriores das aplicações. Um desempenho forte mostraria que as regras capturam comportamentos duradouros. Uma degradação rápida revelaria uma carga de manutenção.

O terceiro sinal é a adoção de relatórios de execuções repetidas. Os scorecards de fornecedores devem publicar Mean@k e Pass^k juntos, com k claramente indicado.

Essa mudança permitiria aos compradores distinguir modelos que têm sucesso com frequência de sistemas que têm sucesso de forma confiável. Também desestimularia demonstrações construídas em torno de uma única execução favorável.

O setor deve ir além, combinando repetição com paráfrases e falhas controladas de ferramentas. Prompts idênticos representam apenas um tipo de pressão de produção.

O trabalho da IBM apresenta um argumento persuasivo de que uma execução bem-sucedida é um padrão fraco demais. Ele também oferece um método prático para localizar incertezas sem repetir todas as ações do mundo real.

A questão restante é se esses ganhos persistem fora da configuração de pesquisa. Os desenvolvedores podem respondê-la repetindo seus próprios fluxos de trabalho importantes, preservando rastros completos e medindo o sucesso em todas as execuções.

Se o seu agente lida com trabalho de consequências relevantes, não pergunte apenas se ele concluiu a tarefa. Pergunte com que frequência ele conclui corretamente a mesma tarefa, quais decisões variam e o que acontece quando a orientação de ontem encontra as condições de amanhã.