O que é RAG (Retrieval-Augmented Generation)?

LLMs são impressionantes, mas têm uma limitação incômoda: seu conhecimento é congelado na data do treino e eles não têm como consultar seus documentos privados. O RAG (Retrieval-Augmented Generation) é a técnica que resolve isso, conectando o modelo a uma fonte externa de conhecimento. Este artigo explica o que é RAG, como funciona o pipeline, quais decisões de engenharia importam e por que ele se tornou o padrão para construir aplicações de IA confiáveis.

O problema que o RAG resolve

Um LLM aprende tudo o que sabe durante o treinamento e, depois disso, seu conhecimento fica estático. Isso gera três problemas práticos:

Esse último ponto é especialmente perigoso, pois a alucinação é um problema estrutural da geração de linguagem (Ji et al., 2023, mencionado na pesquisa da área). O RAG ataca os três de uma vez: em vez de confiar só na "memória" do modelo, ele busca informação relevante na hora e a fornece ao LLM como contexto.

Há ainda um quarto problema que o RAG endereça e que costuma passar batido: custo e atualização. Reentreinar ou fazer fine-tuning de um modelo grande toda vez que um documento muda é caro e lento. Com RAG, atualizar o conhecimento é tão simples quanto reindexar os documentos novos — o modelo permanece o mesmo. Isso muda a economia de manter uma aplicação de IA atualizada.

A ideia central: buscar antes de gerar

O nome diz tudo. RAG combina dois passos:

A analogia útil é a de uma prova com consulta. Em vez de exigir que o modelo memorize tudo, você o deixa "abrir o livro" no momento da resposta. Ele continua usando sua habilidade linguística para redigir, mas os fatos vêm de uma fonte que você controla.

A técnica foi formalizada por Lewis et al. (2020), que combinaram um recuperador de documentos com um modelo gerador e mostraram ganhos em tarefas intensivas em conhecimento, com a vantagem de respostas mais específicas e atualizáveis.

O pipeline de RAG, passo a passo

Um sistema de RAG tem duas fases: uma de preparação (offline) e uma de consulta (online).

Fase de indexação (uma vez, ou quando os dados mudam):

Fase de consulta (a cada pergunta):

# Esqueleto simplificado da fase de consulta
pergunta = "Qual o prazo de garantia do produto X?"

vetor_pergunta = gerar_embedding(pergunta)
chunks = banco_vetorial.buscar(vetor_pergunta, top_k=4)

contexto = "\n\n".join(c.texto for c in chunks)
prompt = f"""Responda usando APENAS o contexto abaixo.
Se a resposta não estiver no contexto, diga que não sabe.

Contexto:
{contexto}

Pergunta: {pergunta}"""

resposta = llm.gerar(prompt)

A separação entre as duas fases é importante de internalizar. A indexação é cara mas roda raramente; a consulta precisa ser rápida e roda a cada pergunta. Confundir as duas — por exemplo, gerar embeddings dos documentos a cada requisição — é um erro de iniciante que derruba a performance e infla o custo.

Chunking: a decisão mais subestimada

O passo de chunking parece trivial, mas é onde muitos sistemas de RAG nascem ruins. Dividir mal os documentos contamina tudo que vem depois, porque a busca só pode recuperar o que o chunking criou.

Estratégias comuns, da mais ingênua à mais cuidadosa:

def chunk_com_overlap(texto, tamanho=500, overlap=50):
    chunks = []
    inicio = 0
    while inicio < len(texto):
        fim = inicio + tamanho
        chunks.append(texto[inicio:fim])
        inicio += tamanho - overlap  # recua para sobrepor
    return chunks

A regra prática: o chunk deve ser autossuficiente o suficiente para responder a uma pergunta sozinho, mas pequeno o bastante para não diluir a relevância. Quando um chunk mistura cinco assuntos, a busca por similaridade fica imprecisa, porque o vetor do chunk vira uma média confusa de tudo.

O papel dos embeddings e da busca

O coração do retrieval é a busca por similaridade, e ela só funciona graças aos embeddings — vetores que capturam significado. Por isso, dois documentos sobre o mesmo assunto ficam próximos no espaço vetorial mesmo usando palavras diferentes. Para entender essa base, vale ler O que são embeddings? Representando significado em vetores.

A abordagem de recuperação densa, em que pergunta e documentos são codificados no mesmo espaço, mostrou-se muito superior à busca por palavras-chave em perguntas de domínio aberto (Karpukhin et al., 2020). Para guardar e consultar milhões desses vetores com eficiência, usa-se um banco de dados vetorial, peça central da arquitetura.

A "similaridade" entre vetores costuma ser medida pela similaridade de cosseno: o ângulo entre os dois vetores. Quanto menor o ângulo, mais próximos os significados. Para milhões de vetores, comparar contra todos a cada consulta seria lento demais, então os bancos vetoriais usam índices aproximados (como HNSW) que trocam um pouco de precisão por uma busca ordens de magnitude mais rápida. Esse trade-off entre exatidão e velocidade é uma das decisões silenciosas de qualquer RAG em escala.

Busca densa, esparsa e híbrida

A busca densa (por embeddings) é ótima para captar significado, mas às vezes falha em termos exatos — um código de produto como XJ-4400, um nome próprio raro, uma sigla específica. A busca esparsa clássica (estilo BM25, por palavra-chave) acerta exatamente esses casos. Por isso, sistemas maduros usam busca híbrida: combinam os resultados das duas e os fundem, capturando tanto o sentido quanto os termos literais. É um dos ajustes que mais melhora a qualidade na prática.

Por que o RAG reduz alucinações

Ao fornecer fontes concretas no prompt e instruir o modelo a usar apenas elas, o RAG diminui drasticamente a tendência de inventar. O modelo deixa de "adivinhar" e passa a "ler e responder".

Mas atenção: o RAG reduz, não elimina, as alucinações. Se a busca trouxer o trecho errado, ou se o modelo ignorar o contexto, ele ainda pode errar. Por isso, combinar RAG com boas instruções e validação é essencial — o tema é aprofundado em O que é alucinação em IA e como reduzi-la. Uma vantagem extra: como as respostas vêm de fontes identificáveis, fica fácil citar referências, o que aumenta a confiança do usuário.

Vale separar dois tipos de falha que o RAG pode ter. A falha de recuperação acontece quando o trecho certo simplesmente não foi encontrado — culpa do chunking, do embedding ou da busca. A falha de geração acontece quando o trecho certo estava no contexto, mas o modelo o ignorou ou interpretou mal. Diagnosticar qual das duas ocorreu é o primeiro passo para consertar um RAG ruim, porque as correções são completamente diferentes: uma mexe no retrieval, a outra no prompt e no modelo.

RAG na prática: decisões de engenharia

Montar um RAG funcional envolve várias escolhas que afetam a qualidade. Um guia completo de implementação está em RAG na prática: dê memória e contexto ao seu LLM, mas vale destacar os principais pontos de decisão:

Cada uma dessas escolhas deve ser medida, não chutada. Sem avaliação, é impossível saber se um chunk maior melhorou ou piorou as respostas.

O re-ranking, com mais detalhe

O re-ranking merece atenção porque costuma dar o melhor retorno por esforço. A busca vetorial é rápida mas grosseira: ela traz, digamos, os 20 chunks mais "parecidos". Um modelo de re-ranking (um cross-encoder) então lê a pergunta junto com cada chunk e atribui uma nota de relevância muito mais precisa, ficando só com os 3 ou 4 melhores para enviar ao LLM. O padrão "recuperar muitos, reordenar, enviar poucos" entrega contexto mais limpo ao modelo e quase sempre melhora a resposta final.

Avaliação: medir antes de otimizar

"Melhorar o RAG" sem medir é tatear no escuro. As dimensões que vale acompanhar:

Com um conjunto de perguntas de teste e essas métricas, cada mudança (chunk maior, novo modelo de embedding, adicionar re-ranking) passa a ser uma hipótese que você confirma ou rejeita com dados, não com intuição.

Erros comuns ao montar um RAG

RAG vs. outras abordagens

Quando você quer que um LLM conheça informação específica, há mais de um caminho:

Na maioria dos casos de "responda com base nos meus documentos", o RAG vence por ser atualizável sem retreinar, mais barato e transparente quanto às fontes. As abordagens não são exclusivas: é comum combinar RAG com um modelo levemente ajustado.

Uma forma simples de escolher: se o que você precisa é conhecimento factual que muda, pense em RAG. Se é comportamento ou formato consistente (responder sempre num certo tom, num certo schema JSON), pense em fine-tuning. Se é um documento pequeno e pontual, talvez baste o contexto longo. E quando o janela de contexto dos modelos cresce, surge a pergunta legítima: "não dá só para colar tudo?". Para bases grandes, a resposta continua sendo não — colar milhares de documentos a cada requisição custa caro, é lento e, contraintuitivamente, costuma piorar a precisão, porque o modelo se perde em meio a tanto texto irrelevante.

Perguntas frequentes

RAG substitui o fine-tuning? Não, são complementares. RAG injeta conhecimento atualizável; fine-tuning ajusta estilo e comportamento. Muitos sistemas usam os dois juntos.

Preciso de um banco de dados vetorial? Para volumes pequenos, uma busca em memória pode bastar. Mas para escalar a milhões de chunks com baixa latência, um banco de dados vetorial com índices aproximados é praticamente obrigatório.

Com janelas de contexto enormes, o RAG ainda faz sentido? Sim. Mesmo com contextos grandes, recuperar só o relevante é mais barato, mais rápido e frequentemente mais preciso do que despejar tudo no prompt.

Como faço o RAG admitir que não sabe? Instrua explicitamente no prompt para responder apenas com base no contexto e dizer claramente quando a informação não estiver presente. Sem essa instrução, o modelo tende a inventar.

Qual o maior fator de qualidade num RAG? Quase sempre o retrieval — chunking e busca. Se o trecho certo não chega ao modelo, nenhuma engenharia de prompt salva a resposta.

Conclusão

RAG é a técnica que dá aos LLMs acesso a conhecimento atualizado, privado e verificável, combinando uma etapa de busca por similaridade com a geração de texto. Ele reduz alucinações, permite citar fontes e dispensa o retreinamento custoso sempre que os dados mudam. Entender o pipeline — chunking, embeddings, banco vetorial, re-ranking e montagem de prompt — diagnosticar se as falhas são de recuperação ou de geração, e medir cada decisão de engenharia com métricas reais é o que separa um RAG de brinquedo de um sistema de produção confiável.

Referências