RAG bem feito: o guia prático para dar memória à sua IA

RAG é a forma mais prática de dar contexto atualizado a um LLM sem retraining. Você tem documentos, dados, conhecimento que mudou ontem — RAG permite que o modelo acesse isso em tempo real.

Mas RAG bem feito é mais arte que ciência. A gente vê muito "RAG de brinquedo" — joga um PDF num vector store e acha que funcionou. Depois estranha por que a IA retorna resposta genérica ou cita documento que não tem nada a ver.

Este post é o guia que a gente seguir em projetos reais.

O que é RAG e quando usar (de verdade)

RAG significa Retrieval-Augmented Generation. Traduzindo pros pratos: ao invés de pedir ao modelo "conte-me sobre X", você pede "aqui estão 3 documentos sobre X, use-os e responda".

Caso de uso perfeito: você tem um monte de documentos (policies, logs, documentação técnica, base de conhecimento) que mudam com frequência. RAG permite que você sempre tenha informação fresca sem retraining.

Caso de uso horrível: você está tentando usar RAG para "resolver" um modelo burro. RAG não melhora capacidade de raciocínio. Se o modelo não consegue fazer math básico, documentos sobre math não vão ajudar.

A gente usa RAG quando:

• Há um corpus de informação que muda regularmente
• A resposta correta requer contexto específico de negócio/domínio
• Você precisa de traceabilidade (mostrar de onde veio a informação)
• O contexto é grande demais pra estar no prompt fixo

Chunking: a arte de dividir documentos

Como você corta um documento de 50 páginas em pedaços que o LLM consegue processar? Essa é a pergunta que faz ou quebra RAG.

Chunking por tamanho fixo

documento: "O Brasil tem 215 milhões de habitantes...
           X milhões vivem em áreas urbanas...
           A densidade populacional é..."

tamanho: 512 tokens
resultado:
  chunk 1: "O Brasil tem 215 milhões de habitantes..."
  chunk 2: "X milhões vivem em áreas urbanas..."

Vantagem: simples, fast, previsível. Desvantagem: quebra frases no meio, contexto pode estar em dois chunks.

Chunking semântico

Você corta onde faz sentido semanticamente — fim de parágrafos, mudança de tópico, headers.

documento com estrutura:
  # Seção A
  parágrafo 1
  parágrafo 2
  ## Subseção A1
  parágrafo 3
  
resultado:
  chunk 1: Seção A inteira (se caber em token limit)
  chunk 2: Subseção A1

Vantagem: respeita estrutura do documento. Desvantagem: chunks de tamanhos variados, pode caber um documento inteiro (2 mil tokens) e quebrá-lo depois.

Chunking recursivo (sweet spot)

Começa grande, depois quebra se ultrapassar limite:

tentativa 1: split por seção
tentativa 2: split por parágrafo
tentativa 3: split por sentença
tentativa 4: split por tamanho fixo

Isso preserva contexto melhor e evita chunks gigantescos.

Recomendação prática: comece com 512 tokens, overlap de 128 tokens (as últimas 128 tokens de um chunk viram as primeiras 128 do próximo). Depois tune baseado em resultados.

Embeddings: transformando texto em números

Um embedding é uma representação numérica de um texto em um espaço vetorial. "Paris é a capital da França" vira algo como [0.234, 0.891, -0.123, ...] com centenas de dimensões.

A qualidade do embedding determina se o retrieval vai funcionar. Um bom embedding entende semântica.

Opções em 2026

Modelo	Provider	Dimensões	Custo	Melhor para
text-embedding-3-small	OpenAI	1536	$0.02 / 1M tokens	Uso geral, produção
text-embedding-3-large	OpenAI	3072	$0.13 / 1M tokens	Quando precision importa muito
multilingual-e5-large	Hugging Face	1024	Free (self-hosted)	Multilíngue, barato
bge-large-pt	Hugging Face	768	Free (self-hosted)	Português específico
voyage-2	Voyage AI	1024	$0.1 / 1M tokens	RAG com filtros complexos

Pick prático: OpenAI text-embedding-3-small é confiável, barato e rápido. Se seu negócio depende de Português específico, bge-large-pt (open source) roda local.

Retrieval híbrido: BM25 + vetorial

Busca vetorial é ótima pra semântica, mas falha em queries exatas.

Query: "qual é o CPF do José Silva?" Embedding da query ≠ embedding de "CPF" + "José Silva" juntos.

Retrieval híbrido faz duas buscas em paralelo:

1. BM25 (full-text search tradicional): procura por palavras exatas, pesando frequência e raridade
2. Vetorial: procura por semelhança vetorial

Depois combina os resultados (RRF — Reciprocal Rank Fusion é um método simples: classifica cada resultado por posição nas duas buscas e faz média).

Pseudocódigo:

resultados_bm25 = full_text_search(query, documentos)
resultados_vetorial = vector_search(embed(query), embeddings)

ranking_híbrido = {}
para rank, doc_id em enumerate(resultados_bm25):
    ranking_híbrido[doc_id] += 1 / (rank + 1)
para rank, doc_id em enumerate(resultados_vetorial):
    ranking_híbrido[doc_id] += 1 / (rank + 1)

top_k = sorted(ranking_híbrido)[:10]

Resultado: você pega os melhores de ambos os mundos.

Re-ranking: quando o top-10 não é bom o suficiente

Retrieval traz 10 documentos. Mas qual deles é REALMENTE mais relevante?

Re-ranking usa um modelo neural dedicado pra reordenar. Cohere Rerank é padrão:

query: "Como configuro CORS no Express?"
top_10_from_vector_search: [doc_a, doc_b, doc_c, ...]

rerank_scores = cohere_rerank(query, top_10)
resultado: [doc_c (0.94), doc_a (0.87), doc_b (0.42), ...]

Custa mais (é uma chamada extra), mas vale pra queries críticas onde você precisa de top-1 perfeito.

Avaliação: como saber se seu RAG está funcionando

Recuperação ruim = resposta ruim. Você precisa medir.

Métricas importantes:

• MRR (Mean Reciprocal Rank): em qual posição (1-10) o documento certo aparece? Média pra 100 queries.
• Precision@k: de k documentos retornados, quantos são relevantes?
• Recall: de todos os documentos relevantes, quantos você encontrou?

Exemplo: query "qual é a política de refund?" com 3 documentos relevantes.

Se você retorna [doc_a (relevante), doc_b (irrelevante), doc_c (relevante), ...]:

• MRR = 1 (primeiro é relevante)
• Precision@3 = 2/3 = 0.67
• Recall = 2/3 = 0.67 (dos 3 relevantes, encontrou 2)

Workflow: crie um eval set de 30-50 queries com respostas esperadas. Depois teste seu RAG nelas, calcule métricas, melhore.

Pitfalls comuns (e como evitar)

Chunks gigantescos

Você embute um capítulo inteiro de 2 mil tokens. Vector search retorna "relevante" mas o LLM fica perdido — a resposta está ali, mas em 5 páginas de contexto.

Solução: chunks de 256-512 tokens. Sim, mais chunks. Mas mais precisão.

Embedding na língua errada

Você embute documentos em Português mas usa OpenAI English embedding. Semelhança semântica é quebrada.

Solução: use bge-large-pt pra Português, ou text-embedding-3-small da OpenAI (que é multilíngue).

Context window waste

Você retorna 10 documentos de 512 tokens cada (5 mil tokens) e manda tudo pro LLM. Mas o modelo só "lê" os primeiros 2-3.

Solução: retorne menos documentos (3-5), ou use re-ranking pra pegar só os top-2.

Não atualizar embeddings

Você criou embeddings há 6 meses. Agora tem 1000 documentos novos que não estão indexados.

Solução: rastreie data de última indexação. Reindex documentos que mudaram.

Pipeline RAG completo em pseudocódigo

# 1. Ingestão
documentos = load_documents('base_conhecimento/*.pdf')
chunks = chunk_recursivo(documentos, size=512, overlap=128)

# 2. Embedding
embeddings = []
para chunk em chunks:
    emb = openai.embed(chunk.texto)
    salva_em_vector_db(emb, metadata={'source': chunk.fonte})

# 3. Query
query_usuario = "como faço refund?"
query_emb = openai.embed(query_usuario)

# 4. Retrieval híbrido
bm25_results = bm25_search(query_usuario)
vector_results = vector_search(query_emb)
hybrid_results = rrf_combine(bm25_results, vector_results)

# 5. Re-ranking
reranked = cohere_rerank(query_usuario, hybrid_results[:10])

# 6. Context + LLM
top_3 = reranked[:3]
prompt = f"Contexto:\n{top_3}\n\nPergunta: {query_usuario}"
resposta = openai.chat(prompt)

# 7. Observabilidade
log({
    'query': query_usuario,
    'retrieved_docs': len(top_3),
    'sources': [d.fonte for d in top_3],
    'resposta_confianca': avaliar_confiança(resposta)
})

Começar simples, escalar depois

A gente vê muito time querendo começar com Pinecone, re-ranking e tudo. Comece assim:

1. Chunks de tamanho fixo + vector search (Chroma ou Postgres + pgvector)
2. Meça MRR em 30 queries
3. Se < 0.8, melhorar chunking ou usar retrieval híbrido
4. Se ainda ruim, re-ranking
5. Só depois considere vector db mais sofisticado

RAG é um sistema que precisa ser tunado iterativamente. A gente aperfeiçoa contra dados reais.

Na Alienhub, ajudamos times a construir RAG que funciona — não no demo, mas em produção com documentos de verdade e queries de verdade. Se seu caso de uso precisa disso, vamos conversar.