Verificação adversarial: vale usar um segundo agente para derrubar o achado do primeiro?

Pedir pra um segundo agente confirmar o achado do primeiro é quase sempre teatro, porque concordar é barato

Você já viu essa cena: o agente entrega um achado bonito, bem escrito, com trecho de código citado e tudo

Aí você chama outro agente, pergunta "isso procede?" e ele responde que sim

Parece validação, mas não é: ninguém tentou matar o achado, só pediram uma segunda opinião pra quem já viu a primeira

Neste post eu vou por partes: o que é verificação adversarial de verdade, quando ela melhora a precisão, quando ela só queima token, e COMO fechar o veredito quando você tem vários votos na mesa

O que é verificação adversarial (e por que refutar rende mais que confirmar)

A diferença toda está no mandato

Um agente com mandato de "revisar" procura razões pra concordar

Um agente com mandato de "refutar" procura o furo, e furo é uma coisa bem mais específica de achar

Antes de falar de dois agentes, vale lembrar por que UM sozinho não resolve

Pedir pro próprio modelo revisar e corrigir a resposta usando só o julgamento dele, sem nenhum sinal externo, não conserta o raciocínio

A pesquisa sobre autocorreção intrínseca mostra que LLMs têm dificuldade de se autocorrigir sem feedback externo e que, em alguns casos, o desempenho DEGRADA depois da autocorreção

Ou seja: mais uma passada do mesmo modelo, com a mesma cabeça, olhando pro mesmo texto, não é verificação, é repetição

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

O padrão Refute-or-Promote:

Isso já foi formalizado

A metodologia Refute-or-Promote monta agentes adversariais com mandato explícito de derrubar candidatos em cada portão de promoção

Tem mais três peças que fazem a coisa funcionar:

• revisores em partida a frio, pra reduzir cascata de ancoragem (o segundo não começa lendo a conclusão do primeiro)
• crítico entre modelos de famílias diferentes, não o mesmo modelo se olhando no espelho
• validação empírica como portão final: o que decide não é voto, é teste

E o filtro morde de verdade: cerca de 79% de 171 candidatos foram mortos antes da divulgação numa campanha de 31 dias sobre 7 alvos

O que sobreviveu virou 4 CVEs (3 públicos, 1 embargado), LWG 4549 aceito no working paper de C++ e 5 PRs editoriais de C++ mesclados

Massa, né? O filtro não é enfeite de processo, ele é o que separa achado plausível de achado real

Quando a verificação adversarial melhora a precisão e quando só encarece

Agora a parte honesta, porque nem todo cenário paga esse custo

Melhora de verdade:

• Evidência contraditória ou insuficiente: debate multiagente estruturado supera baselines de agente único em checagem de fatos, com ganhos mais equilibrados justamente nas classes difíceis (evidência contraditória e evidência insuficiente)
• Achado caro de errar que dá pra testar no fim: se existe teste que roda, o adversário corta o lixo antes e o teste dá a palavra final
• Julgamento por painel de modelos pequenos de provedores distintos: no PoLL, um painel de 3 modelos pequenos de provedores diferentes (command-r, gpt-3.5-turbo e haiku) teve correlação MAIOR com julgamento humano que o GPT-4 sozinho em 6 datasets, com menos viés intramodelo e custo mais de 7 vezes menor

Sacou a lógica? Diversidade de família é o ingrediente, não tamanho do juiz

Se você quer variar de família sem estourar conta, dá até pra rodar um modelo local só pro papel de crítico

Só encarece:

• Debate homogêneo e sem papéis definidos: multiplicador de 2,1x a 3,4x de tokens em relação à autocorreção isolada, chegando a 23.816 tokens por problema, para acurácia estatisticamente comparável ou pior
• Achar que debate é sempre melhor que prompting simples: sistemas de debate multiagente não superam de forma confiável self-consistency e ensembling com múltiplos caminhos de raciocínio; com ajuste de hiperparâmetros alguns protocolos (como Multi-Persona) melhoram, o que indica alta sensibilidade a configuração e dificuldade de otimizar

Traduzindo: N agentes iguais conversando é caro e não compra precisão

O que compra é papel diferente, cabeça diferente e um portão empírico no fim

Confirmar, refutar, debater: o que cada arranjo custa e entrega

Como montar um verificador adversarial com subagentes no Claude Code

Bora ver na prática?

1. Delegue a verificação a um subagente, não a mais um turno da mesma conversa

Segundo a documentação de subagentes do Claude Code, cada subagente roda na própria janela de contexto, com system prompt próprio, acesso específico a ferramentas e permissões independentes

O contexto dele começa do ZERO, sem a conversa do pai, e só a mensagem final volta pro principal (as chamadas e resultados intermediários ficam lá dentro)

Isso é exatamente a base técnica da partida a frio: ele não herda a conclusão do primeiro

O erro comum deste passo: achar que o subagente "já sabe" o que o primeiro concluiu e escrever um prompt do tipo "confere isso aí"

2. Escreva no prompt da chamada tudo que ele precisa

Caminhos de arquivo, mensagens de erro, decisões já tomadas: tudo isso tem que ir escrito no próprio prompt, porque nada mais é herdado da conversa pai

O erro comum deste passo: prompt vago que obriga o subagente a redescobrir o alvo sozinho, gastando token pra chegar onde você já estava

3. Dê mandato de refutar, não de revisar

A missão dele é matar o achado, e o veredito dele só vale se vier com o motivo

No espírito do Checker do MARCH, mantenha o verificador cego à conclusão original: passe a pergunta e as fontes, não a resposta

Missão: DERRUBAR a hipótese abaixo.
Você não recebe a conclusão de ninguém, só a pergunta e as fontes.

Pergunta: <a pergunta original, sem a resposta do primeiro agente>
Arquivos: <caminhos exatos>
Erro observado: <stack trace / saída real>

Responda: (a) sua própria conclusão, (b) o teste ou trecho que
refuta a hipótese, (c) se não conseguiu refutar, diga o que
faltou pra refutar.

O erro comum deste passo: colar a conclusão do primeiro no prompt "pra dar contexto" e ancorar o verificador na resposta que ele deveria atacar

4. Escolha o modelo do subagente com atenção à janela

A janela de contexto do subagente é definida pelo modelo DELE, não pelo modelo do agente principal

Delegar pra um modelo com janela menor dá ao subagente a janela menor, e ponto

O erro comum deste passo: mandar um alvo enorme pra um modelo de janela curta e depois culpar o "agente burro"

5. Termine em validação empírica

O portão final é teste que roda, não voto

No Refute-or-Promote a validação empírica é literalmente o último portão, e é ela que decide se o candidato vira reporte

O erro comum deste passo: promover porque "todo mundo concordou"… a próxima seção mostra por que isso é o pior sinal possível

Se você está começando agora a colocar um agente para trabalhar em tarefa real, monte esse portão desde o começo, ele é mais barato que desfazer conclusão errada depois

Os três jeitos de o painel concordar e mesmo assim estar errado

Sintoma 1: unanimidade suspeita

No próprio estudo do Refute-or-Promote, mais de 80 agentes endossaram POR UNANIMIDADE uma vulnerabilidade que não existia

Um único teste derrubou

Causa: ancoragem em cadeia, cada agente lendo (ou herdando) o que o anterior disse

Correção: partida a frio pros revisores e portão empírico no fim

Sintoma 2: o painel vira coro

O estudo do custo do consenso decompôs os modos de falha do debate multiagente: conformidade sicofântica com adoção da resposta modal em até 85,5%, fragilidade contextual com taxa de vulnerabilidade de até 70,0% e colapso de consenso com gap de oráculo de até 32,3 pontos percentuais

O setup era N=10 agentes homogêneos, R=3 rodadas, com Qwen2.5-7B, Llama-3.1-8B e Ministral-3-8B, nos benchmarks GSM-Hard e MMLU-Hard

Causa: homogeneidade sem papéis

Correção: diversidade de família e mandato adversarial explícito, porque agente igual conversando com agente igual converge pra maioria, não pra verdade

Sintoma 3: o juiz gosta do que ele mesmo escreveu

Existe viés de autopreferência documentado em LLM como juiz: o modelo avalia melhor as próprias gerações

E tem o viés de posição: a ordem em que as opções aparecem já mexe no veredito do juiz

Correção: trocar de família e nunca deixar o mesmo modelo julgar o que ele escreveu

Prevenir os três é a mesma receita, repetida: cegar o verificador, variar a família, e não deixar concordância virar promoção sem teste

Como fechar o veredito entre vários votos sem comprar o consenso

A regra prática que eu tiraria de tudo isso é curta

• Voto é filtro, não é prova: serve pra jogar candidato fora, não pra carimbar candidato como verdadeiro
• Unanimidade sem teste não promove nada: os 80+ agentes concordando com uma vulnerabilidade inexistente estão aí pra lembrar
• Empate ou dúvida derruba: o padrão do Refute-or-Promote é matar por default e promover por exceção, e o agregado dá o tom (cerca de 79% de 171 candidatos morreram antes da divulgação numa campanha de 31 dias sobre 7 alvos; num subconjunto de protocolo consolidado, lcms2 e wolfSSL, n=30, a taxa prospectiva de kill foi 83%)
• O portão final é validação empírica: teste que roda

Sobre qual regra de votação usar (2 de 3, 3 de 5, unanimidade), o trade-off é o de sempre: limiar mais duro mata mais coisa boa junto, limiar mais frouxo deixa passar plausível

E o veredito da pergunta do título?

Vale, sim, quando o mandato é REFUTAR, o verificador é cego à conclusão original e existe teste no fim

Não vale como rodada extra de concordância: aí você paga de 2,1x a 3,4x em token pra ouvir "concordo", sem ganho de acurácia

E isso já saiu da academia: o SentinelOne Labs publicou a construção de um adversarial consensus engine com múltiplos LLMs pra análise automatizada de malware

Conclusão

Resumo em uma frase: concordância é barata, refutação é que custa e informa

O próximo passo é bem concreto

Pega o próximo achado que seu agente entregar

Cria um subagente com prompt de refutação contendo os caminhos de arquivo e as mensagens de erro (lembra: nada é herdado da conversa pai)

Mantém ele cego à conclusão original

E só aceita o que sobreviver a um teste que roda de verdade 🙂

Se o achado morrer no caminho, ótimo: morreu barato, antes de você ir consertar um bug que não existia

até o próximo post!