LLMs ainda não conseguem autocorrigir raciocínio — Descobertas do ICLR 2024 e implicações para IA em Finanças

Este artigo é o contraponto direto às linhas de trabalho CRITIC e Reflexion que venho acompanhando. Huang et al. (ICLR 2024) apresentam um argumento simples e desconfortável: quando as LLMs tentam autocorrigir seu raciocínio sem qualquer sinal externo, elas não melhoram — elas pioram. Vindo logo após o LOG-013 sobre CRITIC, onde a crítica fundamentada em ferramentas genuinamente ajudou, este artigo esclarece exatamente que tipo de "autocorreção" é real e o que é um artefato da configuração experimental.

O artigo

"Large Language Models Cannot Self-Correct Reasoning Yet", de Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song e Denny Zhou (Google DeepMind / UIUC), foi publicado no ICLR 2024. A afirmação central é estreita, mas devastadora para uma certa classe de designs de agentes: a autocorreção intrínseca — pedir a uma LLM para revisar e corrigir sua própria resposta usando apenas seu próprio julgamento, sem nenhum sinal de verdade fundamental — degrada consistentemente o desempenho em benchmarks de raciocínio. Os ganhos relatados em vários artigos anteriores sobre autocorreção, argumentam os autores, resultam de uma falha metodológica sutil: esses artigos usaram rótulos de oráculo para decidir quando parar de corrigir, o que significa que o modelo corrige apenas respostas que já estão erradas. Isso não é autocorreção; é filtragem guiada por oráculo.

Ideias principais

• No GSM8K, o GPT-4 começa com 95,5% de precisão. Após uma rodada de autocorreção intrínseca, cai para 91,5% e, após uma segunda rodada, para 89,0%. O GPT-3.5 cai de 75,9% para 74,7% em duas rodadas.
• A queda é mais dramática no CommonSenseQA: o GPT-3.5 cai de 75,8% para 38,1% após uma única rodada de autocorreção, recuperando-se ligeiramente para 41,8% na segunda rodada — mas ainda catastroficamente abaixo da linha de base.
• A análise das mudanças de resposta no GSM8K mostra que o modelo transforma respostas corretas em erradas com mais frequência do que transforma respostas erradas em corretas. A direção líquida da mudança é prejudicial.
• A autocorreção guiada por oráculo de fato melhora as coisas: o GPT-4 no GSM8K com rótulos de oráculo vai de 95,5% para 97,5%, e o GPT-3.5 no CommonSenseQA de 75,8% para 89,7%. Mas isso exige saber quais respostas estão erradas — o que não se sabe em ambiente de produção.
• O debate multi-agente, outra ideia popular, tem desempenho inferior à simples autoconsistência quando se iguala o orçamento de inferência. Com 9 respostas totais, a autoconsistência atinge 88,2% no GSM8K; o debate multi-agente atinge apenas 83,0%.
• A geração restrita (CommonGen-Hard) parece uma vitória para a autocorreção à primeira vista (44% → 67%), mas esse ganho evapora se você apenas melhorar o prompt inicial (81,8%). Quando o prompt inicial já é bom, a autocorreção prejudica, derrubando a precisão para 75,1%.

O que se sustenta — e o que não se sustenta

A descoberta central é sólida: os números falam por si. Se você solicitar ao GPT-4 que reexamine suas respostas de matemática sem dizer quais estão erradas, as respostas pioram na média. A intuição que o artigo oferece também está correta — LLMs não conseguem julgar com confiabilidade a correção do seu próprio raciocínio, então, quando decidem mudar uma resposta, estão adivinhando, e adivinham errado pelo menos com a mesma frequência com que adivinham certo.

O artigo é menos convincente em suas reivindicações de generalização. Ele testa exclusivamente tarefas de raciocínio e conhecimento. Existem domínios — estilo de escrita, adesão a restrições de formato, redução de toxicidade — onde a revisão iterativa reconhecidamente ajuda, e o artigo ignora amplamente esses casos. Os autores reconhecem isso de passagem, observando que "a autocorreção pode ser mais eficaz para tarefas onde a avaliação é mais simples", mas não testam isso cuidadosamente. O experimento de geração restrita CommonGen é sugestivo, mas usar um prompt inicial inadequado como linha de base e chamar a melhoria resultante de "autocorreção" é a mesma falha metodológica que o artigo critica em outros trabalhos.

O artigo também não aborda a questão da autocorreção treinada. Um acompanhamento de 2025 (SCoRe, ICLR 2025, arXiv:2409.12917) mostra que a autocorreção treinada por RL nos próprios outputs do modelo atinge +15,6% no MATH e +9,1% no HumanEval — uma melhoria intrínseca genuína. Portanto, o título "ainda não conseguem se autocorrigir" envelheceu melhor do que uma leitura mais rigorosa permitiria; a interpretação correta é "não podem ser induzidas à autocorreção via prompt", e não "não podem aprender a se autocorrigir".

Por que isso importa para a IA em finanças

A implicação para agentes de gravação no livro-razão (ledger write-back) é concreta. Um agente que gera um lançamento de diário no Beancount, depois pergunta a si mesmo "isso parece correto?" e revisa, não está obtendo uma segunda opinião — ele está introduzindo ruído. Os dados aqui mostram que, se a primeira resposta estava errada, a autorrevisão tem tanta probabilidade de corromper uma resposta correta quanto de consertar uma errada.

O que este artigo confirma é a restrição de design que extraí do CRITIC: a autovalidação sem um oráculo externo não é confiável. Para o Beancount especificamente, o oráculo externo está disponível e é barato — as asserções de saldo (balance assertions) são executadas em milissegundos, os nomes das contas são validados contra um plano de contas conhecido e os valores devem ser reconciliados até o centavo. Uma arquitetura de agente que envia uma entrada provisória, executa o bean-check e roteia qualquer erro de volta como feedback estruturado concreto é fundamentalmente diferente de uma que pede ao modelo para "revisar seu lançamento de diário". A primeira utiliza o motor do livro-razão como oráculo. A segunda depende do mesmo mecanismo de raciocínio que produziu o erro originalmente.

Há também uma lição mais sutil aqui sobre o design de prompts. O experimento CommonGen mostra que, quando o prompt já é preciso e explícito, a autocorreção degrada o desempenho. Isso significa que, se investirmos esforço em escrever prompts de análise de transação muito claros — que declarem todas as regras de sintaxe do Beancount explicitamente —, adicionar um loop de autorrevisão sobre eles pode ativamente prejudicar a precisão. A arquitetura correta provavelmente condiciona a autorrevisão a uma falha na verificação externa, e não a cada geração.

O que ler a seguir

• SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — Abordagem baseada em RL que atinge os primeiros ganhos genuínos de autocorreção intrínseca; contexto necessário para entender o que o artigo atual descarta ou não.
• When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — Taxonomia sistemática de quando a autocorreção funciona, distinguindo variantes intrínsecas, baseadas em treinamento e assistidas por ferramentas.
• Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — O principal artigo que Huang et al. criticam; lê-lo em sequência esclarece exatamente onde a suposição do rótulo de oráculo está embutida.