Como criar agentes de IA que se autocorrigem de verdade

Como criar agentes de IA que se autocorrigem de verdade

Em 2024, um artigo acadêmico com o título direto “Large Language Models Cannot Self-Correct Reasoning Yet” (Modelos de Linguagem Grandes Ainda Não Conseguem se Autocorrigir) sacudiu o mundo dos agentes de IA. A descoberta foi desconfortável: quando você pede para um modelo verificar o próprio raciocínio sem nenhuma entrada externa, ele não detecta seus erros de forma confiável. Às vezes, faz o oposto: convence a si mesmo de que uma resposta errada está certa.

Mas a autocorreção em agentes de IA funciona sim — desde que uma condição específica seja atendida: o agente precisa de algo externo ao seu próprio julgamento para verificar. Pode ser um teste de código que passa ou falha, um schema de validação de formulário, ou um documento recuperado para checagem de fatos. Sem essa âncora externa, você está construindo uma versão mais cara do mesmo erro.

Os cinco blocos fundamentais

Segundo o tutorial publicado por Shittu Olumide no Machine Learning Mastery, cinco componentes aparecem em praticamente todo sistema de autocorreção em produção:

1. Loops de reflexão (Reflection Loops): o ciclo gerar-criticar-revisar. Precisam ser limitados — um postmortem de 2026 descreveu um agente de processamento de documentos que entrou em loop de retentativa durante a noite e acumulou uma conta de US$ 437 em oito horas antes que alguém percebesse.

2. Verificadores (Verifiers): checam a saída do gerador de forma independente. Os melhores verificadores são os mais simples: execute o código, valide o schema, consulte o banco de dados. Modelos de recompensa de processo (PRMs) devem ser reservados para casos em que você realmente não consegue executar ou checar a saída diretamente.

3. Pontuação de confiança (Confidence Scoring): um estudo da ACL 2026 testou três abordagens comuns (log-probabilidade, amostragem de autoconsistência e confiança verbalizada) e descobriu que todas pontuaram próximo de uma escolha aleatória (AUROC entre 0,55 e 0,6 contra linha de base de 0,5). A alternativa mais confiável é baseada em consistência: gere a solução duas vezes, de forma independente, e verifique se concordam.

4. Políticas de retentativa (Retry Policies): o padrão é backoff exponencial com jitter — esperar um pouco mais a cada falha, com aleatoriedade para evitar que todos os agentes tentem ao mesmo tempo — combinado com um circuit breaker que interrompe chamadas quando o serviço está sobrecarregado.

5. Arquitetura de recuperação (Recovery Architecture): o que acontece quando o orçamento de retentativas se esgota. O estado final de um bom caminho de recuperação não é “crash” — é uma escalação limpa, com todo o histórico de falhas registrado em um lugar que uma pessoa possa ler.

O projeto prático

O tutorial constrói um agente de geração de código que recebe uma especificação curta de função, escreve a implementação em Python, executa os testes de verdade, corrige o que falha e sabe quando parar de tentar e passar o problema para um humano. O verificador é um arquivo de testes real — não a opinião do modelo sobre se o código parece correto.

Um gate de confiança baseado em consistência é adicionado ao final: o agente gera uma segunda solução independente e só aprova quando ambas concordam. Se discordarem, o problema é escalado.

Quando a reflexão não vale a pena

O estudo CorrectBench (2025) descobriu que a autocorreção adiciona cerca de 5% de melhoria em benchmarks difíceis como MATH, mas em tarefas simples o chain-of-thought comum faz o mesmo trabalho usando 40% menos computação. A pergunta que vale fazer antes de implementar um loop de reflexão não é “será que ajuda?”, e sim: “tenho algo externo para o crítico verificar? A tarefa é difícil o suficiente para justificar as chamadas extras?”