RAG - retrieval-augmented generation

RAG junta busca e geração: o modelo só responde depois de puxar os trechos relevantes de uma base externa, então a resposta é ancorada em material que existe e pode ser citado.

LangChainLlamaIndexHaystackPinecone

O que é

RAG (Retrieval-Augmented Generation) é um padrão de arquitetura em que o modelo de linguagem recebe, junto com o prompt do usuário, um conjunto de documentos vindos de uma busca. O retrieval acontece antes da geração, e o que o LLM lê é essa mistura: a pergunta mais o contexto recuperado. A resposta sai do modelo, mas ancorada no que o retrieval trouxe.

A ideia central é simples: um LLM puro responde com base no que aprendeu no treino, então erra fatos recentes, mistura domínios e inventa referências. Com RAG, o sistema puxa primeiro a parte relevante de uma base atual (uma wiki, um índice de manuais, uma coleção de PDFs) e entrega para o modelo como evidência. O texto final passa a ter fonte.

Em uma definição curta: o retrieval decide com o que o modelo conversa, e a geração decide como ele responde.

Como funciona

O fluxo tem cinco etapas, todas determinísticas e auditáveis:

1. o usuário envia uma pergunta; o sistema escreve uma versão limpa dela (às vezes expandida por um LLM de query expansion).
2. a pergunta vira um vetor (embedding) e o sistema busca os k trechos mais próximos no índice vetorial.
3. a busca lexical (palavras exatas) roda em paralelo e entra em uma fusão com o vetor, formando o ranking híbrido.
4. um reranker reordena os candidatos por relevância percebida, descartando os que não contribuem.
5. os melhores trechos viram contexto no prompt do LLM, junto com a pergunta; o modelo responde citando as fontes.

Na prática

O exemplo abaixo mostra o pipeline mínimo em TypeScript: recebe uma pergunta, recupera os k chunks, monta o prompt e chama o LLM. Não é produção, mas é o esqueleto que aparece em todo projeto.

rag/pipeline.tstypescript

type Chunk = { id: string; text: string; source: string };

async function retrieve(query: string, k = 5): Promise<Chunk[]> {
  // 1. embedding da pergunta
  const qVec = await embedder.embed(query);

  // 2. busca densa
  const dense = await vectorStore.search(qVec, { topK: k * 2 });

  // 3. busca lexical (BM25) + fusão
  const lexical = await bm25.search(query, { topK: k * 2 });
  const fused = rrf([dense, lexical]);

  // 4. rerank
  const reranked = await reranker.rerank(query, fused, { topK: k });

  return reranked;
}

async function answer(query: string) {
  const chunks = await retrieve(query);
  const context = chunks.map((c) => `[${c.source}] ${c.text}`).join("\n\n");
  const prompt = `Contexto:\n${context}\n\nPergunta: ${query}\nResponda citando as fontes.`;
  return await llm.generate(prompt);
}

Variações comuns

Três variações aparecem em quase toda arquitetura séria. A primeira é RAG agentivo, em que o agente decide se chama retrieval, quantas vezes e com quais filtros, em vez do retrieval rodar sempre. A segunda é RAG multi-hop, em que a resposta de uma rodada vira a consulta da próxima, montando a partir de várias buscas encadeadas. A terceira é GraphRAG, em que o índice é um grafo de entidades e a busca segue arestas.

Todas compartilham o mesmo princípio: a geração fica restrita ao que o retrieval consegue encontrar, então a qualidade da resposta depende da qualidade do índice. Trocar o LLM sem revisar o retrieval raramente muda o resultado.

Pontos fortes

ancoragem em fonte: cada resposta tem referência verificável, então alucinação factual cai e auditoria fica possível
conhecimento atualizável: trocar a base é reindexar; o modelo não precisa de retreino nem fine-tune
controle de escopo: dá para limitar a busca a um domínio (manuais da empresa, jurisprudência, contratos) e bloquear o resto
custo mais baixo que fine-tune: indexar e buscar custa ordens de grandeza menos do que treinar ou adaptar pesos

Limitações

qualidade herdada do retrieval: retrieval ruim vira contexto ruim, e contexto ruim vira resposta ruim, mesmo com LLM excelente
limitada: muitos chunks forçam corte, e o que sai muitas vezes é justamente o relevante
custo de manutenção: índice desatualizado, embeddings sem revisão e chunking mal escolhido degradam em silêncio
raciocínio multi-documento continua difícil: o modelo lê chunks, não conecta fatos entre eles; GraphRAG ataca parte disso

Janela de contextocontext windowTamanho máximo de tokens que o modelo consegue ler de uma só vez: prompt, todo o histórico concatenado e a saída que vai gerar. É a memória de curto prazo do LLM. Janelas enormes parecem resolver RAG, mas amplificam custo, latência e o risco de o modelo se perder no meio do texto, então contexto bom é contexto pequeno e bem escolhido.ver no glossário →

conexões no mapa

Retrievalalimenta contextoRAG - retrieval-augmented generation
RAG - retrieval-augmented generationinjeta contextoLLM - large language model
Evals - qualidade medida em produçãomede a recuperaçãoRAG - retrieval-augmented generation

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

Estude antes

teste o que entendeu

Carregando perguntas…