Loop de verificação: por que o agente não consegue revisar o próprio trabalho

Pergunte "tem certeza?" a um modelo e ele troca de resposta em 46% dos casos. A acurácia cai 17 pontos em média.

Não é que ele tenha reconsiderado e chegado a uma conclusão melhor. Ele abandonou respostas que estavam certas.

Isso importa porque a primeira ideia de quase todo mundo, ao montar um agente, é pedir que ele confira o próprio trabalho antes de entregar. A literatura mede o resultado dessa ideia há três anos, e o resultado é ruim.

A boa notícia está na segunda metade do post. O modelo sabe consertar o erro. O que ele não sabe é encontrar o erro — e essa distinção muda o que a camada de verificação precisa fazer.

O experimento mais direto sobre isso tem um nome bom: FlipFlop. Pesquisadores fizeram dez modelos resolverem sete tarefas de classificação e, na segunda rodada, apenas questionaram a resposta (Laban, Murakhovs'ka, Xiong e Wu, submetido em novembro de 2023, revisto em fevereiro de 2024; acesso em 27/08/2026).

Todos os dez modelos pioraram entre a primeira e a última previsão. Os autores chamaram isso de efeito FlipFlop, e o diagnóstico é bajulação: o modelo lê o questionamento como sinal de que errou, e cede. Treinar com dados sintéticos reduziu o estrago em cerca de 60%, sem eliminar.

O caso do agente que revisa o próprio trabalho é o mesmo mecanismo, só que sem ninguém questionando de fora. É o que a literatura chama de autocorreção intrínseca: o modelo tenta consertar a própria resposta apoiado apenas na própria capacidade, sem feedback externo.

O trabalho de referência sobre isso é "Large Language Models Cannot Self-Correct Reasoning Yet", apresentado no ICLR 2024 por pesquisadores que incluem Jie Huang, Xinyun Chen e Denny Zhou (arXiv 2310.01798, acesso em 27/08/2026). O abstract não deixa margem: os modelos têm dificuldade de se autocorrigir sem feedback externo e, às vezes, o desempenho piora depois da autocorreção.

O número que mostra por quê está no GSM8K com o GPT-3.5. De todas as respostas, ele mudou 25,3%. Dentro dessa mudança:

Sete vírgula seis por cento das respostas erradas foram corrigidas. E 8,8% das que já estavam certas viraram erradas. O saldo é negativo: a revisão desfaz mais acerto do que resgata.

No GPT-4, mais de 90% das respostas ficaram intocadas depois do processo. Quando o modelo mexe, ele tende a mexer no que estava bom.

Aqui a história vira. A autocorreção falha na etapa de detectar o erro. Corrigir, o modelo faz bem.

Em "LLMs cannot find reasoning errors, but can correct them given the error location", apresentado no ACL 2024 Findings, Gladys Tyen, Hassan Mansoor, Victor Cărbune, Peter Chen e Tony Mak separaram as duas habilidades e mediram cada uma (arXiv 2311.08516, acesso em 27/08/2026).

Os modelos têm dificuldade de identificar erro lógico mesmo em casos objetivos e sem ambiguidade. Mas quando os pesquisadores forneceram a localização real do erro, o desempenho melhorou nas cinco tarefas de raciocínio testadas. A capacidade de correção, uma vez apontado o problema, é descrita como robusta.

<!-- [UNIQUE INSIGHT] -->

E há um achado no mesmo artigo que merece parágrafo próprio: classificadores pequenos, treinados fora do domínio, superaram modelos grandes na tarefa de achar erro.

Pense no que isso significa. Achar erro não é um problema que se resolve com mais inteligência. Se fosse, o modelo maior ganharia. É um problema que se resolve com o instrumento certo — e um instrumento pequeno e específico bate um modelo geral e caro.

Um teste que falha, com nome do arquivo e número da linha, é esse instrumento. Ele custa milissegundos, não erra sobre onde falhou, e entrega ao modelo a única informação que faltava.

Nem todo feedback serve. A pergunta que separa o que funciona do que não funciona é curta: o sinal aponta um lugar ou emite uma opinião?

O survey "When Can LLMs Actually Correct Their Own Mistakes?", de Ryo Kamoi, Yusen Zhang, Nan Zhang, Jiawei Han e Rui Zhang, publicado em dezembro de 2024, organiza as condições em que a autocorreção dá certo (arXiv 2406.01297, acesso em 27/08/2026):

1. Resposta decomponível, em que verificar sai mais barato do que gerar.
2. Feedback externo confiável: código com interpretador, lógica com resolvedor simbólico, pergunta com mecanismo de busca.
3. Ajuste fino em larga escala, com 100 mil instâncias ou mais e feedback de referência.

A segunda condição é a que você consegue montar hoje. E ela tem uma forma reconhecível:

Tudo na coluna da esquerda aponta um lugar. Tudo na da direita emite um julgamento. O modelo faz bom uso da primeira coluna e se enrola com a segunda, e isso é consequência direta do gargalo da seção anterior.

Vale notar a ponte com o post de ontem: uma mensagem de erro bem escrita é interface de agente. Aqui ela ganha um segundo papel. Erro que diz o que falhou, o estado real e o próximo passo já é, sozinho, um sinal de verificação de boa qualidade.

Quatro coisas que dá para verificar

Saber que precisa de verificação não diz o que conferir. Na prática, o que se verifica cai em quatro níveis, e vale ter os quatro porque cada um pega uma família de erro diferente.

Sintático: roda? Compilação, tipos, lint. É o mais barato e o mais fácil de montar. É também o que menos pega, porque programa correto pode produzir resultado errado — foi o caso dos dois bugs contados adiante.

Semântico: faz o que foi pedido? O teste que exercita o comportamento descrito na tarefa. Aqui mora a maior parte do valor, e também a maior parte do trabalho, porque alguém precisa escrever o teste antes.

Invariante: quebrou o que funcionava? A suíte que já existia, rodando inteira. É a verificação que protege contra o modo de falha mais comum do agente em tarefa longa, que é consertar uma coisa e derrubar outra três arquivos adiante. Está entre as armadilhas mais caras de trabalhar com agente.

Contrato: a saída tem a forma certa? Campos obrigatórios presentes, tipos corretos, valores dentro da faixa, referências apontando para algo que existe. É a verificação mais subestimada da lista e a mais barata de escrever depois que se tem o esquema.

Uma regra de bolso para ordenar: se você só tem tempo para dois, comece por invariante e contrato. São os que pegam erro que ninguém previu.

O padrão de um agente que cria e outro que verifica circula como boa prática, inclusive em português. Ele decepciona na forma mais comum, e a razão está no survey.

A frase é direta: nenhum trabalho anterior demonstrou autocorreção bem-sucedida com feedback vindo de LLM instruído por prompt, fora tarefas excepcionalmente adequadas a isso. Os autores localizam o gargalo na geração do feedback, e observam que muitos estudos anteriores usaram montagens que superestimavam a eficácia.

Faz sentido quando se junta com a seção 2. Se o problema é que o modelo não acha erro, colocar um segundo modelo para achar erro não resolve — apenas move a mesma limitação para outro processo, e ainda cobra o dobro de tokens.

Agora a parte justa, porque o padrão tem uso legítimo. Quando o verificador executa ferramenta em vez de opinar, ele deixa de ser um segundo opinador e vira uma camada de verificação com outro nome. Um subagente que roda a suíte de testes, confere o schema gerado e compara o HTML renderizado com o esperado está fazendo trabalho real. A diferença não está em quantos agentes existem; está em o revisor ter ou não um oráculo.

O critério prático, para quem está montando isso: um subagente revisor precisa de ferramenta, não de instrução. Se a única coisa que ele ganhou foi um prompt pedindo rigor, você duplicou o custo sem comprar detecção.

<!-- [PERSONAL EXPERIENCE] -->

A operação que publica este blog roda uma camada de verificação com duas metades. A primeira é a padrão de qualquer projeto: npm test, tsc --noEmit, lint e next build. A segunda é específica do que se publica aqui: um analisador que mede legibilidade, desvio do tamanho de frase e ocorrências de frases batidas, e um gerador de schema que reporta referências órfãs no JSON-LD.

Nada disso opina. Tudo aponta.

O caso desta semana mostra o limite dessa camada melhor do que qualquer exemplo inventado. O site tem um campo para encurtar o título que vai para a SERP, quando o título editorial é longo demais e seria truncado. Descobri que ele só era lido do manifesto interno, e não do arquivo do post. Na prática, nenhum post novo conseguia definir um título curto.

O bug passou no tsc. Passou nos 19 testes. Passou no next build, que compilou sem um aviso sequer.

Ele só apareceu quando abri o HTML gerado e contei os caracteres da tag <title>. Eram 76, e a SERP corta bem antes disso.

Compilar não é verificar. O build responde se o código roda, e ninguém tinha perguntado se o resultado estava certo. A verificação nova entrou no laço logo depois: medir o <title> renderizado e reprovar acima do limite.

O segundo caso tem a mesma forma. O srcSet das capas declarava 1600 pixels de largura para arquivos de 1200, o que fazia o navegador escolher a imagem contando com pixels inexistentes. Também passou no build, e por semanas. Só apareceu quando a verificação passou a comparar a largura declarada com a largura real do arquivo.

Os dois bugs são da mesma família, e é a família mais chata que existe: o programa está correto e o resultado está errado. Nenhum modelo, por melhor que fosse, encontraria isso lendo o código. O que encontrou foi uma verificação nova, escrita depois do prejuízo — que é a disciplina descrita no pilar deste cluster.

Verificação dentro do laço custa tempo e token. Ignorar isso leva a um laço tão lento que ninguém usa, o que é a forma mais comum de a camada morrer.

O critério que funciona é separar por velocidade, e não por importância.

A cada passo, o que é rápido. Tipos, lint e testes unitários do arquivo tocado costumam terminar em segundos. Esses rodam sempre, porque o custo de rodar é menor que o custo de descobrir depois.

Ao final da tarefa, o que é lento. Suíte completa, build, verificação visual. Rodar isso a cada edição transforma uma sessão de vinte minutos em uma tarde.

Sob demanda, o que é caro em dinheiro. Qualquer verificação que chame modelo ou serviço pago entra com parcimônia, e de preferência uma vez por entrega. O mesmo raciocínio de custo por padrão de uso vale aqui: o gasto que dói não é o da chamada isolada, é o da chamada barata repetida centenas de vezes.

Há um detalhe que compensa o custo e quase ninguém contabiliza. Verificação rápida no lugar certo reduz o número de passos da tarefa, porque o agente descobre o erro enquanto ainda tem na cabeça o que mudou. Descobrir dez passos depois custa a reconstrução do contexto, e às vezes custa a tarefa inteira. Pela aritmética do horizonte, cada passo economizado melhora a chance de a cadeia inteira terminar certa.

Quatro passos, na ordem em que rendem.

1. Junte o que já existe num comando só. Você provavelmente já tem teste, tipo e lint. O ganho não vem de eles existirem, e sim de rodarem juntos, sempre, sem alguém escolher.

2. Faça o agente rodar isso antes de dizer que terminou. Enquanto depender de o modelo lembrar, vai falhar em algum momento. Hooks tiram a decisão do modelo.

3. Escreva a verificação que faltou para o erro que acabou de escapar. Todo bug que passou pela camada é um pedido de teste novo. Foi assim que a contagem de caracteres do <title> entrou aqui.

4. Garanta que a falha diga onde. Este é o passo que quase todo mundo pula, e é o que separa uma camada útil de um alarme inútil.

Sobre o passo 4, vale ser explícito: verificação que devolve apenas "falhou" desperdiça a única coisa que o modelo faz bem. A diferença cabe em uma tela.

Saída fraca:

FAIL  2 testes falharam
Process exited with code 1

O agente sabe que algo quebrou e não sabe mais nada. Vai reler arquivos, formular hipóteses e gastar passos para reconstruir o que a ferramenta já sabia.

Saída forte:

FAIL  lib/covers.test.ts:42
  coverSrcSet devolve o descritor com a largura real

  esperado: "harness-1080.webp 1080w, harness.webp 1200w"
  recebido: "harness-1080.webp 1080w, harness.webp 1600w"
                                                    ^^^^
  dica: o descritor está fixo em 1600; passe coverSize.width

Mesmo teste, mesma falha. A segunda versão entrega arquivo, linha, o que se esperava, o que veio e onde olhar. O agente corrige de primeira, e é a situação em que a literatura diz que ele é confiável: alguém apontou o lugar.

Esse é o retorno prático do achado da seção 2. Você não está pedindo ao modelo que seja mais esperto. Está entregando a ele a informação que a ferramenta já tinha e estava jogando fora.

Repare que nenhum dos quatro passos exige modelo melhor, e nenhum exige um segundo agente.

O agente consegue revisar o próprio trabalho?

Sem sinal externo, não de forma confiável. No GSM8K, o GPT-3.5 corrigiu 7,6% das respostas erradas e transformou em erradas 8,8% das que estavam certas, num saldo negativo. O artigo de referência é "Large Language Models Cannot Self-Correct Reasoning Yet", do ICLR 2024, e a conclusão é que o desempenho às vezes piora depois da autocorreção. Com feedback externo confiável, como um teste que falha, a história muda por completo.

Adianta perguntar "tem certeza?" para a IA?

Adianta para piorar. No experimento FlipFlop, com dez modelos e sete tarefas de classificação, o simples questionamento fez os modelos trocarem de resposta em 46% dos casos, com queda média de 17 pontos de acurácia. Todos os dez pioraram. O mecanismo é bajulação: o modelo interpreta a dúvida como sinal de erro e abandona respostas corretas.

Um agente pode revisar outro agente?

Depende do que o revisor tem em mãos. O survey de Kamoi e colegas afirma que nenhum trabalho anterior demonstrou autocorreção bem-sucedida com feedback vindo de LLM instruído por prompt. Um segundo agente que apenas opina herda a mesma limitação do primeiro e dobra o custo. Um segundo agente que executa testes, valida schema ou compara saída com referência está fazendo verificação de verdade, e aí funciona.

O que serve como sinal externo confiável?

Qualquer coisa que aponte um lugar em vez de emitir uma opinião: teste que falha com arquivo e linha, compilador, verificador de tipos, lint com a regra nomeada, assert de invariante, comparação com valor esperado. O survey cita interpretadores de código, resolvedores simbólicos e mecanismos de busca como as fontes de feedback que sustentam autocorreção.

Devo pedir para o agente escrever os próprios testes?

Sim, e vale entender por que isso não contradiz o resto do post. Escrever teste é geração, e o modelo gera bem. O que ele não faz bem é julgar sozinho se o próprio trabalho está certo.

O teste vira sinal de verificação no momento em que alguém de fora o executa e reporta onde falhou. Enquanto o teste existe apenas como texto que o agente escreveu e leu de volta, ele é opinião com aparência de rigor.

Um cuidado prático: teste escrito pelo mesmo agente que escreveu o código tende a herdar o mesmo mal-entendido sobre o requisito. Ele pega regressão com competência, e pega mal o caso de a interpretação do pedido estar errada desde o começo. Para esse risco, a revisão continua sendo humana.

E quando não existe teste automático para o que estou fazendo?

Esse é o limite honesto da abordagem. Texto, design e decisão de produto não ganham um oráculo barato que falhe com número de linha, e nesses domínios a verificação automática cobre menos. Ainda assim quase sempre sobra alguma coisa mensurável: contagem, formato, presença de campo obrigatório, comparação com uma versão anterior. Neste blog, o analisador não julga se o texto está bom — ele mede legibilidade e conta padrões. O julgamento continua humano, e o que dá para medir sai do caminho dele.

• Questionar a resposta do modelo faz ele trocar de ideia 46% das vezes, com 17 pontos de queda média.
• Autocorreção sem sinal externo tem saldo negativo: 7,6% consertadas contra 8,8% estragadas.
• O gargalo é achar o erro. Corrigir, o modelo faz bem — e classificador pequeno acha erro melhor que modelo grande.
• Sinal forte aponta um lugar. Sinal fraco emite opinião. Só o primeiro funciona.
• Compilar não é verificar. Os dois piores bugs deste blog passaram pelo build inteiro.

O próximo post do cluster trata da camada seguinte: onde travar o agente antes de ele agir, quando a verificação depois do fato já não basta. As cinco camadas estão no pilar sobre harness engineering.