{"id":723,"date":"2026-09-15T18:34:29","date_gmt":"2026-09-15T21:34:29","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/consistency-gap-agentes-ia-mean-pass\/"},"modified":"2026-09-15T18:34:29","modified_gmt":"2026-09-15T21:34:29","slug":"consistency-gap-agentes-ia-mean-pass","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/consistency-gap-agentes-ia-mean-pass\/","title":{"rendered":"Consistency Gap em Agentes de IA: Entendendo a Diferen\u00e7a entre Mean@k e Pass^k"},"content":{"rendered":"

Um agente de IA acerta uma tarefa no ensaio e erra a mesma tarefa no dia seguinte, sem nada mudar no pedido. Isso n\u00e3o \u00e9 bug de c\u00f3digo, \u00e9 uma caracter\u00edstica estat\u00edstica do pr\u00f3prio agente que quase nenhum benchmark reporta. A IBM Research publicou no blog do Hugging Face em 15 de setembro de 2026 um artigo mostrando um diagn\u00f3stico espec\u00edfico para esse problema, junto com uma extens\u00e3o do toolkit open source ALTK-Evolve. O artigo original \u00e9 Your Agent Aced the Task. Will It Do It Again?<\/em>, dos times de Evelyn Duesterwald e Vinod Muthusamy.<\/p>\n

O n\u00famero que abre o texto \u00e9 o que interessa: no benchmark AppWorld, Evolve melhorou a confiabilidade do agente em +8,9 pontos no geral, com aumento relativo de 74% em tarefas dif\u00edceis multi-step. Mas o dado novo \u00e9 outro. Um agente ReAct rodando GPT-4.1 no AppWorld tem 77,4% de acerto m\u00e9dio em 5 execu\u00e7\u00f5es, e apenas 53,0% das tarefas passam nas 5 rodadas. A diferen\u00e7a de 24,4 pontos \u00e9 o que eles chamam de consistency gap<\/em>.<\/p>\n

O que o benchmark esconde: Mean@k, Pass@k e Pass^k<\/h2>\n

Tr\u00eas m\u00e9tricas parecidas, tr\u00eas perguntas diferentes. Vale fixar antes de continuar.<\/p>\n

    \n
  • Mean@k<\/strong>: roda a tarefa k vezes, tira m\u00e9dia. \u00c9 o “77% de acerto” que aparece na leaderboard.<\/li>\n
  • Pass@k<\/strong>: mede a probabilidade de que pelo menos uma de k tentativas independentes seja bem sucedida. M\u00e9trica otimista, usada em gera\u00e7\u00e3o de c\u00f3digo onde voc\u00ea pode verificar e escolher a boa.<\/li>\n
  • Pass^k<\/strong> (l\u00ea-se “pass power k”): estima a probabilidade de que um agente tenha sucesso em todas as k tentativas independentes. Isso \u00e9 \u00fatil para avaliar consist\u00eancia e confiabilidade.<\/li>\n<\/ul>\n

    A rela\u00e7\u00e3o matem\u00e1tica \u00e9 fixa: Pass^k \u2264 Mean@k \u2264 Pass@k, sempre. E, como observa a \u03c4-bench, para tarefas de agente do mundo real que exigem confiabilidade e consist\u00eancia como atendimento ao cliente, prop\u00f5e-se uma nova m\u00e9trica, pass^k, definida como a chance de que todas as k tentativas i.i.d. sejam bem sucedidas, tomada como m\u00e9dia entre tarefas.<\/p>\n

    Traduzindo em usu\u00e1rio final: Pass@k \u00e9 “pelo menos um caminho funciona, e eu escolho”. Pass^k \u00e9 “o mesmo pedido, feito por dois usu\u00e1rios diferentes, tem que dar certo para os dois”. Em produ\u00e7\u00e3o, quase sempre voc\u00ea quer Pass^k.<\/p>\n

    Como funciona: distribui\u00e7\u00f5es agudas contra distribui\u00e7\u00f5es planas<\/h2>\n

    Toda decis\u00e3o que um LLM toma, qual API chamar, qual argumento passar, se tenta de novo ou n\u00e3o, sai de uma distribui\u00e7\u00e3o de probabilidade sobre os pr\u00f3ximos tokens. O que decide se a decis\u00e3o vai se repetir amanh\u00e3 n\u00e3o \u00e9 a temperatura, \u00e9 a forma<\/em> dessa distribui\u00e7\u00e3o.<\/p>\n

    Pense num juiz de futebol decidindo p\u00eanalti. Se a jogada foi um carrinho descarado dentro da \u00e1rea, dez ju\u00edzes diferentes marcam p\u00eanalti. A decis\u00e3o \u00e9 aguda: a op\u00e7\u00e3o vencedora est\u00e1 muito \u00e0 frente das outras. Agora, se foi um leve toque no calcanhar com o atacante j\u00e1 caindo, alguns marcam, outros mandam seguir. A decis\u00e3o \u00e9 plana: duas ou tr\u00eas op\u00e7\u00f5es est\u00e3o praticamente empatadas, e qualquer pequeno vi\u00e9s (o juiz estar mais cansado, o barulho do est\u00e1dio) decide para um lado ou outro. A analogia quebra num ponto: no LLM, o “vi\u00e9s” n\u00e3o vem de humor, vem de n\u00e3o-associatividade de ponto flutuante em GPU, de como o batching agrupou seu request, de detalhes do provedor. Mas a mec\u00e2nica \u00e9 a mesma: distribui\u00e7\u00e3o aguda resiste ao ru\u00eddo, distribui\u00e7\u00e3o plana reordena.<\/p>\n

    E a trajet\u00f3ria de um agente encadeia dezenas dessas decis\u00f5es. Uma probabilidade pequena de flipar em cada passo vira uma probabilidade grande de flipar em algum lugar. \u00c9 da\u00ed que sai o gap de 24 pontos.<\/p>\n

    Consequ\u00eancia pr\u00e1tica: temperature=0 n\u00e3o resolve<\/strong>. Decodifica\u00e7\u00e3o greedy e seed fixo governam como uma distribui\u00e7\u00e3o vira um token, n\u00e3o a distribui\u00e7\u00e3o em si. No endpoint hospedado, as probabilidades se mexem um pouco de uma execu\u00e7\u00e3o para outra, e um quase-empate pode resolver para um lado hoje e para o outro amanh\u00e3, mesmo com temperatura zero. O experimento da IBM roda a temperatura 0.0 exatamente para deixar claro que o gap medido n\u00e3o \u00e9 sampling.<\/p>\n

    O Consistency Analyzer: diagn\u00f3stico sem re-executar a tarefa<\/h2>\n

    Aqui est\u00e1 o que muda de arquitetura no ALTK-Evolve. A parte antiga do sistema j\u00e1 era conhecida: um LLM extrai dicas estruturadas (guidelines) a partir de uma trajet\u00f3ria bruta em tr\u00eas categorias, estrat\u00e9gia, recupera\u00e7\u00e3o e otimiza\u00e7\u00e3o, agrupa em mem\u00f3ria duplamente indexada (embedding mais metadados de categoria\/prioridade\/contexto\/proced\u00eancia) e as recupera em runtime por similaridade de cosseno ou consulta guiada por LLM. A novidade \u00e9 o que vem antes disso: um est\u00e1gio que decide quais guidelines vale a pena extrair, mirando consist\u00eancia em vez de sucesso.<\/p>\n

    O pipeline tem dois est\u00e1gios:<\/p>\n

    1. Detectar decis\u00f5es inst\u00e1veis<\/h3>\n

    Voc\u00ea tem uma trajet\u00f3ria gravada, uma sequ\u00eancia de passos que o agente j\u00e1 executou. O Consistency Analyzer pega cada passo de decis\u00e3o e faz uma \u00fanica chamada ao modelo pedindo k completions<\/strong> (k=5 por padr\u00e3o) sobre o mesmo contexto que j\u00e1 estava registrado. Isso \u00e9 o ponto cr\u00edtico da arquitetura: n\u00e3o \u00e9 rerodar a tarefa inteira, n\u00e3o \u00e9 chamar as ferramentas de novo, n\u00e3o \u00e9 interagir com o ambiente. \u00c9 replay do contexto contra o modelo, offline, uma vez por passo de decis\u00e3o.<\/p>\n

    Se as k respostas concordam, o passo \u00e9 agudo. Se divergem, o passo \u00e9 plano e vai para uma scorecard. O m\u00e9todo \u00e9 black-box: nada de logits, nada de instrumenta\u00e7\u00e3o al\u00e9m do trace que voc\u00ea j\u00e1 tem. Isso importa porque, em produ\u00e7\u00e3o, muitas vezes voc\u00ea n\u00e3o consegue rerodar uma tarefa nem uma vez, o efeito colateral seria real (mandaria e-mail, escreveria no banco, cobraria cart\u00e3o).<\/p>\n

    2. Gerar guidelines direcionadas<\/h3>\n

    Cada passo sinalizado vira uma candidata a consistency guideline<\/em>, no mesmo formato que o ALTK-Evolve j\u00e1 usa. Um exemplo real que o artigo mostra, gerado pelo GPT-4.1 a partir de uma trajet\u00f3ria de contagem de itens em uma nota do SimpleNote:<\/p>\n

    [Guideline 1] Ao contar marcadores de checkbox no conte\u00fado\nde uma nota, use regex ancorado por linha em vez de contagem\nde substring simples; t\u00edtulos de nota costumam repetir o\ns\u00edmbolo do marcador em uma linha de legenda.\n\n[Guideline 2] Sempre verifique resultados de busca de notas\nchecando por m\u00faltiplos matches e confirmando a nota correta\nantes de prosseguir.<\/code><\/pre>\n
    Repare que nada disso \u00e9 trivialidade espec\u00edfica da tarefa. S\u00e3o padr\u00f5es de decis\u00e3o que aparecem com alta incerteza em v\u00e1rias tarefas do AppWorld. O analisador mira instabilidade, n\u00e3o falha, ent\u00e3o captura passos que o agente acertou desta vez mas poderia errar na pr\u00f3xima.<\/p>\n
    O que isso significa na pr\u00e1tica<\/h2>\n
    Os n\u00fameros do experimento, no AppWorld test_normal (168 tarefas), ReAct com GPT-4.1, gerando guidelines a partir de uma trajet\u00f3ria-base por tarefa e testando em 5 novas execu\u00e7\u00f5es:<\/p>\n