RAG na prática: quando montar um pipeline de recuperação

RAG é um dos conceitos mais repetidos em IA aplicada e um dos que mais sofrem com implementação preguiçosa. A ideia central parece simples: você conecta um LLM a uma base de documentos e ele para de inventar respostas. Se fosse só isso, todo mundo já estaria usando em produção sem problema.

Não é.

O que é RAG e por que faz sentido na prática

RAG significa Retrieval-Augmented Generation. Em vez de depender só do que o modelo aprendeu no treinamento, você recupera trechos relevantes de uma base de documentos e injeta esses trechos no prompt na hora da geração.

O modelo não "acessa" sua base de dados em tempo real. Ele recebe como contexto o que você recuperou, e usa isso para gerar a resposta. É uma distinção que parece técnica, mas afeta bastante o design do sistema.

O problema que a arquitetura resolve é real: LLMs têm knowledge cutoff, não sabem de documentos internos da sua empresa e alucinam quando não têm informação suficiente. Injetar contexto relevante na hora certa melhora a qualidade das respostas de forma mensurável. Quando a recuperação é boa. Quando não é, adiciona ruído.

O que acontece dentro do pipeline de RAG

Indexação

Você pega os documentos, divide em pedaços (chunks), gera embeddings para cada pedaço e armazena num banco vetorial. Esse processo acontece uma vez, ou toda vez que a base muda. Para entender como embeddings funcionam antes de continuar, o post sobre embeddings para busca semântica cobre os fundamentos sem enrolação.

Recuperação

Quando uma pergunta chega, você gera o embedding dela e faz busca por similaridade na base. Os N trechos mais próximos são recuperados. Aqui está um dos principais pontos de falha: o tamanho dos chunks, o modelo de embedding escolhido e o valor de N afetam diretamente o que o modelo vai receber.

Geração

Os trechos recuperados entram no prompt junto com a pergunta. O modelo gera a resposta com base nisso. Simples na teoria, delicado na prática quando os trechos recuperados são irrelevantes ou contraditórios entre si.

Quando o RAG faz sentido usar

O RAG resolve bem quando:

• Você tem documentos que mudam com frequência e não pode fazer fine-tuning toda semana
• As perguntas exigem informações de documentos internos que o modelo não tem como saber
• A base é grande demais para caber na janela de contexto do modelo
• Você precisa que o modelo cite a fonte e o usuário vai verificar

Fora desses cenários, você provavelmente está adicionando complexidade sem ganho real. Um sistema simples de busca por palavras-chave seguido de geração já resolve muito mais do que as pessoas imaginam antes de montar um pipeline completo.

Quando o RAG não é a resposta certa

Esse é o ponto que mais vejo sendo ignorado.

Se seus documentos cabem na janela de contexto do modelo, colocar tudo direto no prompt é mais simples, mais barato e geralmente mais eficiente do que montar indexação e recuperação. O post sobre janela de contexto de LLMs ajuda a calcular se você está nesse caso antes de gastar tempo montando infraestrutura.

Se o problema é que o modelo precisa de ajuste de tom, vocabulário ou raciocínio específico de domínio, você precisa de fine-tuning, não de RAG. RAG adiciona informação. Não muda como o modelo escreve ou raciocina.

Se a base de documentos é bagunçada, com duplicatas, contradições ou qualidade inconsistente, o RAG vai recuperar lixo e injetar lixo no contexto. Garbage in, garbage out vale dobrado aqui porque você ainda tem o custo da infraestrutura em cima.

Como validar se o pipeline de RAG está funcionando

Montar o pipeline não é suficiente. Você precisa medir se a recuperação está funcionando separada da geração.

Duas métricas básicas que funcionam na prática:

• Precisão da recuperação: dos N trechos recuperados, quantos eram realmente relevantes para a pergunta? Você consegue avaliar isso manualmente com um conjunto de perguntas de teste.
• Qualidade da resposta final: a resposta gerada é melhor do que a resposta sem RAG para as mesmas perguntas?

Esses dois números raramente são avaliados antes de ir para produção. Quando o sistema começa a dar respostas ruins, a investigação começa pela geração quando o problema costuma estar na recuperação. Separar os dois é o primeiro passo para qualquer diagnóstico real.

O paper original sobre RAG, publicado pela Meta AI Research, continua sendo a referência mais sólida para entender a motivação e os limites da arquitetura. Vale a leitura antes de tomar qualquer decisão de design importante.

Os erros mais comuns que custam caro

Sem filtro:

• Chunks grandes demais: os trechos recuperados incluem informação irrelevante junto com a relevante, e o modelo se perde no meio
• Modelo de embedding errado para o idioma: muita gente usa modelos treinados em inglês para recuperação em português e não entende por que a qualidade é ruim
• Sem re-rankeamento: recuperar os 20 mais similares e mandar tudo para o modelo é diferente de recuperar os 20 e selecionar os 5 mais úteis
• Ignorar metadados: documentos têm data, autor, categoria. Usar só o embedding sem filtrar por metadados gera recuperação de informações desatualizadas

RAG vs. fine-tuning: a comparação que sempre aparece

A confusão entre os dois é comum. RAG adiciona conhecimento externo em tempo de inferência. Fine-tuning muda o comportamento do modelo durante o treinamento.

Na prática: use RAG quando o conhecimento muda com frequência, é grande demais para o contexto ou precisa ser rastreável. Use fine-tuning quando você quer mudar o estilo, o tom ou o raciocínio de forma consistente. O post sobre fine-tuning vs. prompt engineering cobre os critérios com mais detalhe, inclusive quando nenhum dos dois é a resposta certa.

Não são mutuamente exclusivos. Tem casos onde um modelo fine-tunado com RAG faz sentido. Mas começa sempre pelo caso mais simples possível.

FAQ

RAG resolve o problema de alucinação dos LLMs?

Reduz, não elimina. O modelo ainda pode alucinar se os trechos recuperados não forem suficientes ou se ele não conseguir reconciliar informações contraditórias. Com recuperação ruim, às vezes piora, porque o modelo tenta forçar uma resposta a partir de contexto errado.

Qual banco vetorial usar para começar?

Se você já usa PostgreSQL, pgvector é o caminho natural. Evita nova infraestrutura sem perda real de qualidade em casos simples. Só faz sentido migrar para um banco dedicado quando o volume e a latência de busca começarem a exigir.

Quantos documentos justificam montar um RAG?

Não tem número mágico. A pergunta certa é: esses documentos cabem no contexto do modelo? Se sim, começa sem RAG. Se não, ou se a base cresce de forma imprevisível, aí o pipeline vale a complexidade.

Minha recuperação parece boa mas as respostas ainda são ruins. O que verificar?

Verifica primeiro se os trechos recuperados respondem à pergunta quando lidos isoladamente. Depois olha o tamanho total do contexto que vai para o modelo. Contexto muito longo com informação irrelevante no meio degrada a geração mesmo quando os chunks certos estão lá.

Preciso de uma ferramenta específica para montar RAG?

Não. A arquitetura é independente de framework. O que você precisa é de um modelo de embedding, um banco vetorial e um LLM. Frameworks como LangChain e LlamaIndex ajudam a conectar as peças, mas abstraem decisões que você precisa entender antes de deixar automatizadas.

Construa pequeno, meça primeiro

RAG funciona bem quando bem aplicado. O problema é que "bem aplicado" inclui uma série de decisões de design que raramente aparecem nos tutoriais de 10 minutos.

Começa com um caso de uso específico e uma base pequena. Mede a recuperação antes de medir a geração. Valida manualmente antes de confiar em métricas automáticas. Se a recuperação não estiver boa, não tenta consertar no prompt, porque não vai funcionar.

A complexidade que o RAG adiciona só vale quando o problema realmente precisa dela. Quando precisa, a diferença de qualidade é visível e mensurável.

Dois próximos passos concretos:

• Antes de subir qualquer pipeline em produção, define suas métricas com o post sobre avaliação de LLM em produção para separar problemas de recuperação de problemas de geração
• Revisa a qualidade da base de documentos antes de indexar. A etapa de indexação não conserta conteúdo ruim, só o escala