RAG do Zero: Busca + Geração

RAG — sigla de retrieval-augmented generation, ou geração aumentada por recuperação — soa sofisticado, mas a arquitetura cabe numa frase: antes de o modelo responder, busque os trechos certos e os entregue a ele. O resto é cuidar bem de cada etapa. São quatro, e vamos percorrê-las na ordem em que acontecem.

Etapa 1: indexar os documentos

Tudo começa preparando a base de conhecimento. Você não joga documentos inteiros no sistema — eles são recortados em pedaços menores, os chunks. Esse recorte, o chunking, existe porque trechos menores produzem buscas mais precisas e cabem melhor no contexto do modelo.

Cada chunk passa então por um modelo de embedding, que o converte num vetor (o conceito está no guia sobre embeddings). Os vetores são guardados num banco vetorial, junto com o texto original e metadados úteis — fonte, data, seção. Essa etapa roda uma vez, e se repete só quando os documentos mudam.

Etapa 2: recuperar os trechos relevantes

Quando chega uma pergunta, ela também é convertida num vetor pelo mesmo modelo de embedding usado na indexação — detalhe não negociável, sob pena de comparar coordenadas de mapas diferentes. O banco vetorial então busca os chunks cujos vetores estão mais próximos do vetor da pergunta: os mais parecidos em significado.

Em geral se recuperam os k trechos mais próximos — tipicamente de três a dez. Essa é a etapa que mais decide a qualidade final, e a que mais é negligenciada.

Etapa 3: montar o prompt com contexto

Os trechos recuperados são costurados num prompt entregue ao LLM, num formato que, em essência, diz: "Use o contexto abaixo para responder à pergunta. Contexto: [trechos recuperados]. Pergunta: [a pergunta do usuário]."

É aqui que se ganha controle. Uma boa instrução pede que o modelo responda apenas com base no contexto fornecido e admita quando a informação não está lá — o que reduz a tentação de inventar. É também aqui que se pede para citar a fonte de cada trecho usado.

Etapa 4: gerar a resposta

Com o prompt montado, o LLM faz o que faz de melhor: redige uma resposta fluente, agora ancorada nos trechos reais que recebeu. O ganho é duplo — a resposta tende a ser factual e pode apontar de onde veio cada afirmação. O modelo deixa de ser um oráculo opaco e passa a ser um redator que cita fontes.

Boas práticas que fazem diferença

• Tamanho do chunk: nem grande demais (dilui o sentido e estoura o contexto), nem pequeno demais (perde a coerência da ideia). Um parágrafo coeso costuma ser um bom alvo, e uma pequena sobreposição entre chunks vizinhos evita cortar frases ao meio.
• Reranking: depois da busca inicial, um segundo modelo — o reranker — reordena os trechos recuperados por relevância real à pergunta. É um dos ajustes que mais elevam a qualidade com menos esforço.
• Busca híbrida: combinar busca semântica com busca por palavra-chave recupera tanto o que é parecido em sentido quanto o que casa termos exatos, como nomes e códigos.
• Metadados: filtrar por data, autor ou seção antes da busca semântica estreita o espaço e melhora a precisão.

As armadilhas mais comuns

A lei que governa o RAG é curta: recuperação ruim, resposta ruim. Se a etapa 2 traz o trecho errado, nem o melhor modelo do mundo salva a etapa 4 — ele responderá com confiança a partir de um contexto irrelevante. Por isso o erro mais caro é investir num LLM caro e deixar a busca mal ajustada.

Há outras ciladas. Chunks mal recortados quebram ideias ao meio. Bases desatualizadas devolvem respostas obsoletas. E mesmo com bom contexto, o modelo pode extrapolar além do que o trecho diz. Medir a qualidade da recuperação — não só da resposta final — é o hábito que separa um RAG de demonstração de um RAG de produção.

Perguntas Frequentes

Qual o tamanho ideal de chunk?

Não há número universal. Depende do tipo de documento e do modelo de embedding, mas um parágrafo coeso — algo entre algumas centenas e mil tokens — é um ponto de partida razoável. Vale testar e medir, não chutar.

RAG substitui o fine-tuning?

São coisas distintas. RAG é melhor para conhecimento factual e atualizável; o fine-tuning é melhor para fixar formato, tom e comportamento. Muitos sistemas maduros usam os dois em camadas, não um no lugar do outro.

Por que meu RAG responde "não sei" demais?

Em geral porque a recuperação não encontra os trechos certos — chunks mal recortados, base incompleta ou modelo de embedding inadequado ao idioma. Recuperar mais trechos ou adicionar reranking costuma ajudar antes de mexer no modelo gerador.

Preciso de um banco vetorial para fazer RAG?

Para poucos documentos, dá para guardar os vetores em memória e comparar diretamente. Bancos vetoriais tornam-se necessários quando o volume cresce e a latência da busca passa a importar.