CRITIC: Por que a Autocorreção de LLM Requer Feedback de Ferramentas Externas

Lendo o CRITIC (Gou et al., ICLR 2024) enquanto pensava sobre o que acontece após um agente financeiro cometer um erro. O Reflexion nos disse que agentes podem aprender com o fracasso ao longo de episódios. O CRITIC faz uma pergunta mais incisiva: pode um LLM identificar e corrigir seus próprios erros em uma única etapa de geração — e, em caso afirmativo, do que ele realmente precisa para fazer isso?

O artigo

O CRITIC introduz uma estrutura na qual um modelo de linguagem gera uma saída inicial e, em seguida, itera através de um loop de verificar-e-corrigir usando ferramentas externas — uma API de busca para afirmações factuais, um intérprete de Python para código e aritmética, e um classificador de toxicidade para moderação de conteúdo. O loop é executado por um número fixo de iterações (o artigo relata resultados eficazes em cerca de três correções), produzindo uma saída refinada que os autores avaliam em questionamento e resposta de forma livre (TriviaQA, AmbigNQ, HotpotQA), síntese de programas matemáticos e redução de toxicidade.

A afirmação central não é que os LLMs podem se autocorrigir sozinhos. É quase o oposto: o valor do CRITIC vem precisamente de fundamentar a crítica em um sinal externo que o modelo não pode forjar. Sem a API de busca, as melhorias em QA encolhem para quase zero ou regridem. A estrutura funciona porque a ferramenta diz ao modelo algo que ele genuinamente não sabia, não porque o modelo se torna um auditor interno confiável.

Ideias centrais

• Aplicado ao ChatGPT, o CRITIC alcança melhorias de 7,7 no F1-score em média em três tarefas de QA de domínio aberto e ganhos absolutos de 7,0 pontos percentuais em três benchmarks de raciocínio matemático.
• A redução de toxicidade é o resultado individual mais impressionante: uma redução de 79,2% na probabilidade de toxicidade no conjunto de dados avaliado.
• A remoção da API de busca faz com que o desempenho em QA estagne ou degrade — a habilidade intrínseca de autocrítica do modelo é quase inútil para tarefas factuais.
• O loop converge rapidamente: três rodadas de correção capturam a maior parte do ganho, com retornos decrescentes além disso.
• A estrutura é agnóstica ao modelo e não requer ajuste fino (fine-tuning); funciona em APIs de caixa preta, incluindo o Text-Davinci-003 e o ChatGPT.
• O CRITIC supera a autoconsistência (votação por maioria sobre múltiplas amostras) na maioria das tarefas, o que é significativo porque a autoconsistência não tem custo de ferramenta por etapa.

O que se sustenta — e o que não

O resultado empírico central é sólido: o feedback de ferramentas externas melhora significativamente os resultados, e a ablação removendo a API de busca é condenatória para os defensores da autocorreção ingênua. O artigo também é honesto sobre o mecanismo — os ganhos vêm da ferramenta, e não de alguma capacidade metacognitiva emergente.

O que considero pouco explorado é a taxonomia dos modos de falha. Quando o modelo gera uma crítica ruim que o afasta ainda mais da resposta correta? O artigo relata o desempenho médio, mas a variância entre tarefas e tipos de perguntas importaria enormemente para a implementação. Em um contexto financeiro, o pior resultado não é a "falta de melhoria" — é uma correção que soa plausível, mas introduz um novo erro.

A escolha de limitar a três iterações também é apresentada como uma conveniência prática, em vez de um critério de parada baseado em princípios. Três rodadas podem funcionar para o TriviaQA, onde há uma resposta de verdade fundamental para a qual convergir. Em um domínio como a reconciliação de razão contábil, onde a resposta "correta" exige raciocínio multi-documento e conhecimento de domínio, não é óbvio que três chamadas de ferramenta sejam suficientes — ou que uma API de busca de propósito geral forneça o sinal de verificação adequado.

O artigo complementar da ICLR 2024 "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv:2310.01798) confirma a própria descoberta do CRITIC pela outra direção: sem feedback externo, a autocorreção degrada confiavelmente a precisão do raciocínio. Esses dois artigos juntos formam uma imagem coerente — a capacidade que as pessoas chamavam de "autocorreção" é, em sua maioria, um refinamento impulsionado por feedback externo, e essa distinção importa.

Por que isso importa para a IA financeira

O loop do CRITIC se mapeia naturalmente no problema de segurança de escrita em agentes Beancount. Atualmente, quando um agente LLM propõe um lançamento no diário — por exemplo, categorizando uma transação ou dividindo uma despesa — não há uma maneira fundamentada de verificar sua própria saída antes de confirmá-la no disco. A arquitetura do CRITIC sugere um padrão concreto: gerar uma entrada candidata e, em seguida, executar a verificação contra uma ferramenta (uma função de verificação de saldo, um mecanismo de regras, um detector de duplicatas) e usar a saída da ferramenta para solicitar uma revisão antes que a gravação ocorra.

O resultado da toxicidade é uma analogia que considero útil reformular: uma redução de 79,2% nas violações de política não vem do modelo internalizando as regras — vem de um classificador que relata as violações de volta ao modelo. Para um livro contábil Beancount, o equivalente seria um verificador de regras que sinaliza transações contadas em duplicidade ou violações de categoria, e alimenta esse sinal na etapa de revisão do agente. O agente não precisa saber de forma independente que as regras foram quebradas; ele precisa do sinal da ferramenta.

A limitação crítica para as finanças é a dependência de APIs de busca. Agentes financeiros precisam de ferramentas de verificação que sejam específicas do domínio: verificações de integridade de saldo de conta, validadores de plano de contas, consultas de regras fiscais. É improvável que uma busca genérica na web identifique uma despesa mal classificada. Construir a camada de ferramentas correta para a correção no estilo CRITIC em contabilidade é onde está o verdadeiro trabalho de engenharia — e o artigo não aborda o design de ferramentas específicas de domínio de forma alguma.

O que ler a seguir

• "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — o argumento empírico direto de que a autocorreção intrínseca falha; deve ser lido junto com o CRITIC, pois ambos triangulam o mesmo mecanismo de direções opostas.
• "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — estende a ideia de crítica e correção de caminho único para uma árvore de busca sobre etapas intermediárias; relevante para reconciliações de múltiplas etapas onde o agente precisa explorar e retroceder.
• "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — examina como os agentes aprendem a selecionar e encadear chamadas de ferramentas, que é o problema a montante que o CRITIC assume como resolvido.