O que é RAG (Retrieval-Augmented Generation)?

RAG (Retrieval-Augmented Generation, ou "geração aumentada por recuperação") é uma arquitetura que combina um mecanismo de busca em uma base de dados externa com um modelo de linguagem (LLM) que gera a resposta final. Em vez de depender só do que o modelo aprendeu no treinamento, o sistema busca trechos relevantes de documentos antes de responder — e passa esses trechos como contexto para o LLM. É a técnica por trás da maioria dos chatbots que respondem sobre documentação interna, bases de conhecimento ou dados que mudam com frequência.

O que é RAG, na prática

O termo foi cunhado no artigo "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", de Lewis et al. (Facebook AI Research, 2020). A ideia central: um modelo puramente paramétrico (que só usa o que memorizou nos pesos durante o treino) tem dificuldade para acessar informação específica, recente ou privada. RAG resolve isso somando duas memórias — a paramétrica (o próprio LLM) e a não paramétrica (um índice de documentos consultável em tempo real).

Na prática, RAG serve para responder perguntas sobre conteúdo que não estava nos dados de treino do modelo: documentação interna de uma empresa, contratos, tickets de suporte, catálogos de produto, ou qualquer base que mude depois que o LLM foi treinado. Para entender a base técnica que torna a busca possível, veja o artigo sobre [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia) — é o mecanismo que converte texto em vetores comparáveis por similaridade.

Como funciona o pipeline de RAG

Um sistema RAG típico tem duas fases: indexação (feita uma vez, ou sempre que a base muda) e consulta (feita a cada pergunta do usuário).

• Chunking: os documentos-fonte são divididos em pedaços menores (chunks), porque indexar um documento inteiro como uma única unidade prejudica a precisão da busca.
• Embedding: cada chunk é convertido em um vetor numérico por um modelo de embeddings (como text-embedding-3 da OpenAI ou gemini-embedding-001 do Google).
• Indexação: os vetores são armazenados em um banco vetorial (Pinecone, Weaviate, Qdrant, pgvector, entre outros), que permite busca por similaridade em escala.
• Retrieval: quando o usuário faz uma pergunta, ela também é transformada em vetor e o banco retorna os chunks mais próximos semanticamente.
• Reranking (opcional, mas recomendado): um modelo especializado reordena os chunks recuperados por relevância real antes de passá-los adiante.
• Geração aumentada: os chunks selecionados são inseridos no prompt como contexto, e o LLM gera a resposta final com base neles — não apenas com o que já sabia.

Chunking e embeddings: a base da recuperação

A qualidade do RAG depende mais da estratégia de chunking do que da escolha do banco vetorial: um documento bem dividido recupera bem em qualquer banco, enquanto um chunking ruim degrada a recuperação mesmo no banco mais rápido do mercado. Não existe um tamanho de chunk universalmente ideal — divisão por página venceu benchmarks internos da NVIDIA por manter a menor variância entre tipos de documento, enquanto chunking semântico (que respeita limites de significado, não de caracteres) pode melhorar o recall em até 9% sobre métodos simples, segundo comparações independentes de mercado. Um ponto de partida comum na indústria é dividir em blocos de 400 a 512 tokens com sobreposição entre eles.

RAG vs fine-tuning: qual escolher

RAG e fine-tuning resolvem problemas diferentes e não são substitutos automáticos um do outro.

• RAG dá ao modelo acesso a informação que não estava no treinamento, buscando em uma fonte externa a cada consulta — ideal para bases de conhecimento grandes, privadas ou que mudam com frequência.
• Fine-tuning ajusta os pesos do modelo com exemplos adicionais, ensinando um comportamento, estilo de escrita ou vocabulário específico — não é a forma eficiente de "ensinar fatos" que mudam com frequência.
• RAG exige mais recursos em tempo de execução (busca a cada chamada); fine-tuning exige mais investimento antes do deploy (rodadas de treinamento).
• RAG mantém a informação sempre atualizada trocando o índice; fine-tuning precisa de novo treinamento sempre que os dados mudam.

Exemplo prático: RAG mínimo em Python

O trecho abaixo é uma versão simplificada — só para ilustrar o fluxo, sem tratamento de erro ou otimização — de um retrieval por similaridade de cosseno, sem depender de um banco vetorial externo. Para uma base pequena isso já funciona; para produção, um banco vetorial dedicado é o caminho recomendado (ver passo de indexação no pipeline acima).

import numpy as np
from openai import OpenAI

client = OpenAI()

def embed(texts):
    resp = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in resp.data])

# 1. Indexação: converte os chunks da base em vetores
chunks = [
    "A política de reembolso permite devolução em até 30 dias.",
    "O suporte técnico funciona de segunda a sexta, das 9h às 18h.",
    "Planos anuais têm 20% de desconto sobre o valor mensal.",
]
chunk_vectors = embed(chunks)

# 2. Retrieval: busca os chunks mais próximos da pergunta
def retrieve(query, k=2):
    query_vector = embed([query])[0]
    sims = chunk_vectors @ query_vector / (
        np.linalg.norm(chunk_vectors, axis=1) * np.linalg.norm(query_vector)
    )
    top_idx = np.argsort(sims)[::-1][:k]
    return [chunks[i] for i in top_idx]

# 3. Geração aumentada: injeta o contexto recuperado no prompt
def answer(query):
    context = "\n".join(retrieve(query))
    prompt = f"Contexto:\n{context}\n\nPergunta: {query}\nResponda usando apenas o contexto acima."
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

print(answer("Quantos dias tenho para pedir reembolso?"))

Reranking e Contextual Retrieval: refinando a recuperação

Buscar por similaridade vetorial pura nem sempre traz os melhores resultados no topo. Uma técnica comum é o pipeline em três estágios: busca por palavra-chave (BM25) combinada com busca densa (embeddings), seguida de reranking por um cross-encoder que reordena os candidatos pela relevância real à pergunta.

A Anthropic propõe uma técnica complementar chamada Contextual Retrieval: antes de gerar o embedding de cada chunk, um LLM adiciona uma frase de contexto que situa aquele trecho dentro do documento completo — resolvendo o problema de chunks que, isolados, perdem sentido. Segundo a documentação técnica da Anthropic, a técnica reduziu em até 67% os erros de recuperação nos testes internos da empresa, e melhorou o desempenho de Pass@10 de aproximadamente 87% para 95% em um de seus benchmarks. São números autodeclarados pela Anthropic sobre seus próprios testes, não um resultado universal — mas indicam a direção: o texto ao redor do chunk importa tanto quanto o chunk em si.

Como avaliar um sistema RAG

O framework RAGAS (Retrieval Augmented Generation Assessment) é uma referência de mercado para medir RAG sem precisar de respostas de referência escritas à mão, decompondo a avaliação em métricas de recuperação e de geração:

• Faithfulness: mede se a resposta gerada está apoiada no contexto recuperado — valor baixo indica alucinação, mesmo com o contexto certo disponível.
• Context precision: mede se os chunks recuperados são relevantes (pouco ruído misturado ao que importa).
• Context recall: mede se o contexto recuperado contém toda a informação necessária para responder.
• Answer relevance: mede se a resposta final realmente endereça a pergunta feita, e não só está "correta" em abstrato.

Separar essas métricas ajuda a diagnosticar onde o sistema está falhando: se o recall do contexto está baixo, o problema é de recuperação (chunking, embeddings, k pequeno); se a faithfulness está baixa com bom recall, o problema é de geração (o modelo ignorou ou distorceu o contexto).

Onde o RAG falha (e por que ainda pode alucinar)

• Chunking ruim: se a divisão corta uma informação no meio, nenhuma busca vai recuperá-la inteira.
• Retrieval não traz o trecho certo: se a pergunta usa vocabulário muito diferente do documento, a similaridade vetorial pode falhar — daí a vantagem de combinar busca por palavra-chave com busca semântica.
• Índice desatualizado: RAG só resolve o problema de dados desatualizados se o índice for reprocessado quando a fonte muda; um índice parado tem o mesmo problema que um modelo sem RAG.
• Alucinação apesar do contexto: ter o trecho certo disponível não garante que o LLM vá usá-lo corretamente — é o que a métrica de faithfulness mede.
• Custo e latência: cada consulta agora inclui uma etapa de busca (e, opcionalmente, reranking) antes da geração, o que aumenta o tempo de resposta e o custo por interação.

Quando usar RAG

RAG faz sentido quando a resposta depende de uma base de conhecimento específica, privada ou que muda com frequência: suporte ao cliente sobre documentação de produto, busca em contratos e políticas internas, assistentes sobre bases de código, ou qualquer aplicação em que a resposta precisa citar uma fonte verificável. Para entender a camada de modelo por trás de tudo isso, veja [o que é um LLM](/artigo/o-que-e-um-llm-guia-modelos-linguagem) e, para o panorama geral da área, [o que é Inteligência Artificial](/artigo/o-que-e-inteligencia-artificial-guia-completo-iniciantes). Quem for implementar RAG em Python encontra o comparativo de linguagem e ecossistema em [Python ou TypeScript para IA](/artigo/python-ou-typescript-para-ia).