Corrective RAG: quando a IA precisa desconfiar da própria busca

O RAG nasceu como uma resposta prática a uma limitação importante dos modelos de linguagem: eles não conhecem automaticamente os documentos, regras e informações específicas de um negócio.

Ao recuperar trechos de uma base de conhecimento antes de gerar a resposta, o sistema pode produzir respostas mais contextualizadas e menos dependentes apenas do conhecimento interno do modelo.

Mas existe uma fragilidade que muitas vezes passa despercebida: e se a busca recuperar o conteúdo errado?

É nesse ponto que entra o Corrective RAG.

O problema: RAG depende da qualidade da recuperação

Um sistema RAG pode ter um bom modelo de linguagem, uma boa interface e uma base extensa de documentos. Ainda assim, pode responder mal se a recuperação falhar.

Isso acontece porque a resposta final costuma ser construída a partir dos trechos encontrados. Se os trechos forem irrelevantes, incompletos, antigos ou contraditórios, a resposta pode parecer bem escrita, mas estar mal fundamentada.

Alguns problemas comuns:

• a busca recupera um trecho parecido com a pergunta, mas não o trecho correto;
• o documento encontrado está desatualizado;
• o contexto recuperado responde apenas parte da pergunta;
• os trechos recuperados se contradizem;
• o sistema encontra exemplos, mas não encontra a regra geral;
• a pergunta exige uma fonte que não está na base;
• a IA usa contexto fraco com confiança excessiva.

Em outras palavras, o RAG pode reduzir alucinações, mas não elimina automaticamente respostas frágeis. A qualidade da recuperação continua sendo decisiva.

O que o Corrective RAG tenta corrigir?

O Corrective RAG, também conhecido como CRAG em parte da literatura, parte de uma ideia simples: antes de gerar a resposta, o sistema deve avaliar se o conteúdo recuperado é bom o bastante.

Em vez de seguir diretamente para a geração, o pipeline inclui uma etapa de crítica ou verificação.

Essa etapa pode classificar o contexto recuperado como:

• relevante: os documentos recuperados parecem responder à pergunta;
• ambíguo ou insuficiente: há alguma relação, mas faltam evidências;
• irrelevante: os documentos recuperados não sustentam uma resposta adequada.

Dependendo dessa avaliação, o sistema pode seguir caminhos diferentes.

Como um pipeline Corrective RAG pode funcionar?

Existem várias formas de implementar essa lógica. Uma versão simplificada pode seguir este fluxo:

1. o usuário faz uma pergunta;
2. o sistema recupera documentos ou trechos relevantes;
3. um avaliador verifica se o conteúdo recuperado sustenta a resposta;
4. se o conteúdo for bom, a IA responde com base nele;
5. se o conteúdo for incompleto, o sistema reformula a busca ou consulta outra fonte;
6. se o conteúdo for inadequado, o sistema evita responder com falsa segurança;
7. a resposta final explicita limites, incertezas e próximos passos quando necessário.

O avaliador pode ser um modelo de linguagem, uma regra, uma combinação de métricas ou um componente treinado para classificar a relevância do contexto.

O ponto central não é a ferramenta usada, mas a existência de uma etapa explícita de verificação.

O corretor não precisa ser o mesmo modelo que responde

Em alguns desenhos, o mesmo modelo avalia e responde. Em outros, um componente separado avalia a relevância dos trechos recuperados antes da geração.

Separar essas funções pode ajudar a tornar o fluxo mais controlável:

• um componente recupera documentos;
• outro avalia a qualidade do contexto;
• outro reformula a consulta quando necessário;
• outro gera a resposta final;
• regras de negócio determinam quando parar ou encaminhar.

Essa separação é importante porque avaliar evidência e escrever uma resposta são tarefas diferentes.

Quando refazer a busca?

Refazer a busca pode ser útil quando o sistema encontrou algo parcialmente relacionado, mas não suficiente.

Isso pode acontecer quando:

• a pergunta está vaga;
• os termos usados pelo usuário não aparecem nos documentos;
• o sistema recuperou exemplos, mas não regras;
• o documento certo existe, mas não apareceu entre os primeiros resultados;
• a busca semântica capturou o tema, mas perdeu uma palavra crítica;
• o contexto recuperado não cobre todos os critérios da pergunta.

Nesses casos, a reformulação da consulta pode ajudar. O sistema pode expandir termos, trocar palavras, incluir sinônimos, recuperar trechos mais longos ou combinar busca semântica com busca por palavra-chave.

Mas refazer a busca sem critério também tem custo. Pode aumentar latência, consumo de tokens e risco de trazer ainda mais ruído.

Quando consultar outra fonte?

Em alguns casos, a resposta não está na base original. Continuar procurando no mesmo índice pode apenas repetir o erro.

Um fluxo corretivo pode decidir consultar outra fonte, como:

• uma base documental mais atual;
• um banco de dados estruturado;
• uma planilha de produtos ou serviços;
• um sistema interno;
• uma política oficial;
• uma fonte pública autorizada;
• um atendente humano.

O importante é que essa mudança de fonte seja controlada. A IA não deve sair buscando em qualquer lugar sem regra, autorização ou critério de confiabilidade.

Quando a melhor resposta é “não tenho informação suficiente”?

Um dos maiores ganhos do Corrective RAG não é responder mais. É responder melhor quando não deve responder.

Em muitos contextos, a resposta correta é reconhecer a limitação:

• “não encontrei essa informação na base disponível”;
• “os documentos recuperados não são suficientes para confirmar isso”;
• “há informações conflitantes”;
• “essa solicitação precisa ser avaliada por uma pessoa”;
• “posso explicar o procedimento geral, mas não confirmar este caso específico”.

Essa postura pode parecer menos impressionante, mas é mais segura e mais profissional.

Para negócios, confiança não vem de uma IA que responde tudo. Vem de um sistema que sabe respeitar limites.

Exemplo prático: atendimento com regras desatualizadas

Imagine um assistente que responde perguntas sobre políticas comerciais.

Um cliente pergunta:

“Ainda posso contratar o plano antigo com desconto anual?”

A busca recupera um documento com uma campanha promocional antiga. O texto é parecido com a pergunta e contém exatamente os termos “plano antigo” e “desconto anual”.

Um RAG sem correção poderia usar esse trecho e responder que sim.

Um Corrective RAG deveria verificar se o documento está vigente, se há uma política mais recente, se a promoção expirou e se a resposta pode ser dada automaticamente.

Se a base não trouxer confirmação atual, a resposta mais segura seria informar que não há evidência suficiente para confirmar o desconto e encaminhar para atendimento comercial.

Exemplo prático: suporte técnico

Em suporte técnico, uma busca ruim pode levar a uma orientação inadequada.

Uma pessoa pergunta sobre um erro em uma versão específica de um software. A busca recupera um artigo sobre uma versão anterior com sintomas parecidos.

A resposta pode parecer correta, mas estar errada para a versão atual.

Um pipeline corretivo deveria avaliar se a versão recuperada corresponde ao caso informado, se há notas de atualização mais recentes e se a solução sugerida se aplica ao ambiente descrito.

Aqui, a palavra-chave, a data e a versão podem ser tão importantes quanto a similaridade semântica.

Corrective RAG e Hybrid RAG se complementam

Hybrid RAG melhora a recuperação ao combinar busca semântica e busca lexical.

Corrective RAG entra em outro ponto: ele avalia se aquilo que foi recuperado é bom o bastante.

As duas abordagens podem ser combinadas.

Um sistema pode primeiro usar busca híbrida para recuperar candidatos e, depois, aplicar uma etapa de avaliação para classificar a qualidade do contexto.

Se o resultado for fraco, o sistema pode reformular a busca, alterar pesos, consultar outra fonte ou responder de forma limitada.

Corrective RAG e Agentic RAG também se encontram

O Corrective RAG pode ser implementado dentro de um fluxo mais agente.

Nesse caso, o sistema avalia a recuperação e decide o próximo passo:

• responder;
• refazer a busca;
• consultar outra ferramenta;
• pedir mais contexto;
• encaminhar para uma pessoa;
• parar por falta de evidência.

A diferença é que o componente corretivo foca na qualidade da evidência recuperada, enquanto o componente agente decide a sequência operacional.

O que pode dar errado em um sistema corretivo?

A correção também pode falhar.

Um avaliador pode classificar como ruim um contexto que era suficiente, ou aceitar como bom um contexto frágil.

Alguns riscos:

• critérios de avaliação mal definidos;
• excesso de buscas corretivas sem ganho real;
• aumento de custo e latência;
• dependência excessiva da autocrítica do próprio modelo;
• falsos negativos, descartando documentos úteis;
• falsos positivos, aceitando documentos irrelevantes;
• respostas muito cautelosas quando a base era suficiente;
• dificuldade de explicar por que um documento foi rejeitado.

Por isso, o Corrective RAG precisa ser testado com casos reais, perguntas ambíguas, informações ausentes, documentos conflitantes e exemplos de recuperação ruim.

Como avaliar a qualidade do Corrective RAG?

A avaliação deve observar tanto a resposta final quanto as decisões intermediárias.

Algumas perguntas úteis:

• o sistema identificou quando os documentos recuperados eram irrelevantes?
• o sistema reconheceu quando a evidência era parcial?
• a busca reformulada trouxe contexto melhor?
• o sistema evitou responder sem base suficiente?
• a resposta final citou ou refletiu corretamente o contexto recuperado?
• os limites e incertezas foram comunicados com clareza?
• o custo adicional da correção se justificou pelo ganho de qualidade?

Em projetos profissionais, essa avaliação precisa ser feita com perguntas representativas do uso real, não apenas com exemplos simples.

Quando Corrective RAG faz sentido?

Essa abordagem tende a fazer sentido quando respostas erradas têm custo relevante.

Alguns cenários:

• assistentes de atendimento com regras comerciais ou políticas internas;
• suporte técnico com versões, configurações e procedimentos específicos;
• consulta a contratos, normas ou documentos regulatórios;
• assistentes internos que orientam processos da empresa;
• respostas que dependem de informação atualizada;
• sistemas que precisam reconhecer ausência de evidência;
• fluxos em que uma resposta incorreta pode gerar retrabalho, risco ou perda de confiança.

O denominador comum é a necessidade de evitar que a IA responda com segurança quando a base recuperada não sustenta a resposta.

Quando talvez não valha a complexidade?

Corrective RAG adiciona etapas, custo e tempo de resposta.

Se a base é pequena, bem estruturada, as perguntas são simples e os riscos são baixos, um RAG tradicional ou híbrido pode ser suficiente.

Também pode não valer a pena quando:

• a aplicação é exploratória e não exige precisão alta;
• o volume de consultas não justifica o custo adicional;
• a empresa ainda não tem uma base minimamente organizada;
• os critérios de relevância não foram definidos;
• o maior problema ainda está no conteúdo, não na recuperação.

Antes de adicionar uma camada corretiva, vale resolver problemas básicos de base de conhecimento, metadados, chunking, atualização e regras de resposta.

Como começar de forma prática

Uma forma simples de começar é coletar perguntas em que o RAG atual falha.

Depois, classificar as falhas:

• o documento correto não foi recuperado;
• o documento recuperado era antigo;
• a resposta usou apenas parte do contexto;
• a pergunta precisava de outra fonte;
• o sistema deveria ter dito que não sabia;
• a base não tinha informação suficiente.

A partir disso, é possível definir uma camada corretiva pequena:

1. avaliar se os trechos recuperados respondem à pergunta;
2. verificar data, fonte e tipo de documento quando isso for importante;
3. reformular a busca quando a evidência for fraca;
4. usar busca híbrida quando termos exatos forem decisivos;
5. encaminhar para uma pessoa quando a resposta não puder ser sustentada;
6. registrar falhas para melhorar a base e o pipeline.

O objetivo não é criar uma arquitetura complexa. É impedir que a IA use contexto ruim como se fosse bom.

Conclusão: a busca também precisa ser avaliada

RAG melhora muito a capacidade de uma IA responder com base em conhecimento externo.

Mas o RAG depende da recuperação.

Se a busca falha, a resposta também pode falhar — mesmo que o texto final pareça claro, coerente e bem escrito.

Corrective RAG adiciona uma camada importante: avaliar a qualidade do contexto recuperado antes de gerar a resposta.

Isso permite refazer buscas, consultar outras fontes, reconhecer incertezas e evitar respostas sem base.

Nem todo projeto precisa dessa complexidade. Mas quando a confiança da resposta depende da qualidade da evidência, a IA precisa aprender a desconfiar da própria busca.

Antes de perguntar se o modelo sabe responder, vale perguntar: o que ele encontrou sustenta a resposta?

Referências

• Yan et al.: Corrective Retrieval Augmented Generation
• Asai et al.: Self-RAG — Learning to Retrieve, Generate, and Critique through Self-Reflection
• LangChain: Retrieval e agentic RAG com self-correction
• LangGraph: Build a custom RAG agent