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:

• Conhecimento desatualizado: o modelo não sabe de eventos posteriores ao treino.
• Sem acesso a dados privados: ele desconhece a documentação interna da sua empresa, os tickets de suporte, os PDFs do seu produto.
• Alucinação: quando não sabe a resposta, o modelo tende a inventar algo plausível em vez de admitir ignorância.

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:

1. Retrieval (recuperação): dada a pergunta do usuário, o sistema busca em uma base de conhecimento os trechos mais relevantes.
2. Generation (geração): esses trechos são inseridos no prompt, e o LLM gera a resposta fundamentada neles.

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):

1. Coleta: reúna seus documentos (PDFs, páginas, planilhas).
2. Chunking: divida cada documento em pedaços menores ("chunks"), porque um documento inteiro raramente cabe no contexto.
3. Embedding: converta cada chunk em um vetor numérico usando um modelo de embeddings.
4. Armazenamento: guarde os vetores em um banco especializado.

Fase de consulta (a cada pergunta):

1. Embed da pergunta: transforme a pergunta do usuário em um vetor.
2. Busca: encontre os chunks mais similares no banco vetorial.
3. Montagem do prompt: junte os chunks recuperados com a pergunta.
4. Geração: o LLM responde usando esse contexto.

# 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:

• Tamanho fixo: cortar a cada N caracteres ou tokens. Simples, mas corta no meio de frases e ideias, separando uma pergunta da sua resposta.
• Por estrutura: respeitar parágrafos, seções e títulos do documento. Mantém ideias inteiras juntas.
• Com sobreposição (overlap): cada chunk repete um pedaço do anterior, para que uma informação que cai na fronteira apareça inteira em ao menos um chunk.

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:

• Tamanho do chunk: pedaços pequenos são precisos, mas perdem contexto; grandes têm contexto, mas trazem ruído. É um equilíbrio.
• Quantos chunks recuperar (top_k): poucos podem faltar; muitos enchem o contexto de ruído e aumentam o custo.
• Modelo de embedding: deve combinar com o idioma e o domínio dos seus dados.
• Re-ranking: uma etapa extra que reordena os resultados da busca para priorizar os mais relevantes.
• Metadados e filtros: restringir a busca por data, categoria ou permissão de acesso.

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:

• Context recall: a informação necessária estava entre os chunks recuperados?
• Context precision: os chunks recuperados eram de fato relevantes, ou vieram com muito ruído?
• Faithfulness (fidelidade): a resposta gerada se sustenta no contexto fornecido, sem inventar?
• Answer relevance: a resposta de fato endereça a pergunta do usuário?

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

• Achar que RAG é só "jogar documentos num banco vetorial". A qualidade vem do chunking, do retrieval e da avaliação — não do banco em si.
• Ignorar o caso "não sei". Sem instrução explícita para admitir desconhecimento, o modelo preenche lacunas com invenção. O prompt deve autorizar e incentivar o "não encontrei isso nas fontes".
• Recuperar chunks demais. Encher o contexto não melhora a resposta; dilui o sinal e aumenta custo e latência.
• Não filtrar por permissão. Em sistemas com dados sensíveis, esquecer de restringir a busca aos documentos que o usuário pode ver é uma falha de segurança séria — o RAG passa a vazar conteúdo restrito na resposta.
• Nunca reindexar. Documentos mudam; se o índice não acompanha, o RAG responde com base em versões velhas.

RAG vs. outras abordagens

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

• RAG: busca conhecimento externo em tempo real. Ideal para dados que mudam, são grandes ou precisam de citação.
• Fine-tuning: ajusta os pesos do modelo com seus dados. Bom para ensinar estilo e formato, menos eficiente para fatos voláteis.
• Contexto longo: simplesmente colar tudo no prompt. Funciona para volumes pequenos, mas escala mal em custo.

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

• Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W., Rocktäschel, T., Riedel, S., Kiela, D. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• Karpukhin, V., Oğuz, B., Min, S., Lewis, P., Wu, L., Edunov, S., Chen, D., Yih, W. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP.
• Ji, Z., Lee, N., Frieske, R., Yu, T., Su, D., Xu, Y., Ishii, E., Bang, Y., Madotto, A., Fung, P. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys.