RAG a Fundo: Arquitetura, Chunking, Embeddings e os Erros que Quebram em Produção

RAG (Retrieval-Augmented Generation) é provavelmente a arquitetura de IA mais usada e mais mal implementada de 2026. O conceito é simples: em vez de esperar que o modelo “saiba” a resposta, você busca o conhecimento relevante e o entrega ao modelo junto com a pergunta. O diabo, como sempre, mora nos detalhes — e é onde a maioria das implementações quebra.

Por que RAG existe

Um LLM tem três limitações que RAG resolve:

1. Não conhece seus dados privados (seus contratos, sua base de clientes, sua documentação interna).
2. Tem corte de conhecimento — não sabe de nada depois da data de treino.
3. Alucina — quando não sabe, inventa com confiança.

RAG ataca os três: você dá ao modelo o trecho certo da sua base no momento da pergunta. A resposta passa a ser ancorada (grounded) em fonte real, não na memória difusa do modelo.

O pipeline completo

INGESTÃO (offline)
documentos -> chunking -> embeddings -> vector store

CONSULTA (online)
pergunta -> embedding -> retrieval -> rerank -> prompt+contexto -> resposta

Cada etapa tem decisões que determinam se o RAG funciona ou vira gerador de respostas erradas com fonte.

Chunking: a decisão mais subestimada

Você não joga um PDF de 80 páginas no modelo. Você quebra em pedaços (chunks) que serão recuperados individualmente. Como você quebra define o que dá para recuperar.

• Chunk grande demais: traz contexto irrelevante junto, dilui o sinal e gasta tokens.
• Chunk pequeno demais: perde o contexto que dava sentido ao trecho (uma frase solta sem o parágrafo).
• Chunk no lugar errado: cortar no meio de uma tabela ou de um raciocínio destrói a informação.

Estratégias que funcionam melhor que “corta a cada 500 caracteres”:

• Chunking semântico: quebrar em fronteiras naturais (parágrafos, seções, títulos).
• Overlap: sobrepor um pouco entre chunks vizinhos para não perder contexto na fronteira.
• Preservar estrutura: manter tabelas, listas e cabeçalhos íntegros, e anexar metadados (de qual documento/seção veio).

2. Embeddings e vector store

Cada chunk vira um vetor (embedding) que captura seu significado. A pergunta também vira vetor, e você busca os chunks cujos vetores estão mais próximos. Pontos práticos:

• A escolha do modelo de embedding importa — e modelos multilíngues lidam melhor com português que os focados em inglês.
• A dimensão do vetor afeta custo de storage e velocidade de busca.
• O vector store (pgvector, Qdrant, etc.) precisa de índice adequado para escalar; busca por força bruta morre com volume.

3. Retrieval: similaridade não basta

O erro clássico é parar na busca vetorial pura. Dois reforços que mudam o resultado:

• Busca híbrida: combinar busca vetorial (semântica) com busca por palavra-chave (BM25). A vetorial pega significado; a por keyword pega termos exatos (códigos, nomes, números) que a semântica às vezes ignora.
• Reranking: recuperar, digamos, 20 candidatos e passá-los por um modelo reranker que reordena por relevância real à pergunta, ficando só com os 3-5 melhores. Esse passo, sozinho, costuma ser a maior melhoria de qualidade num RAG mediano.

Os erros que quebram RAG em produção

1. Chunking ingênuo. Cortar por tamanho fixo ignorando estrutura é a causa nº 1 de RAG ruim.
2. Sem reranking. Mandar os 10 chunks “mais parecidos” sem reordenar enche o contexto de quase-relevantes.
3. Contexto demais. Jogar 15 chunks no prompt não ajuda — o modelo se perde, custa mais e às vezes ignora o trecho certo (o problema do “perdido no meio”).
4. Não tratar o “não encontrei”. Se o retrieval não achou nada bom, o sistema tem que dizer “não sei”, não preencher o vazio com alucinação.
5. Sem citar a fonte. Resposta de RAG sem referência ao documento de origem é impossível de auditar e de confiar.

Como avaliar RAG (porque sem isso é fé)

RAG tem dois pontos de falha, e você avalia os dois separadamente:

• Qualidade do retrieval: os chunks certos foram recuperados? (métricas como recall@k, precision@k — você precisa de um conjunto de perguntas com os documentos corretos marcados).
• Qualidade da geração: a resposta é fiel ao contexto recuperado (faithfulness) e responde à pergunta (relevância)? Aqui entra LLM-as-judge comparando resposta × contexto.

Se a resposta está errada, essa separação te diz onde: ou o retrieval não trouxe a informação (problema de busca/chunking), ou trouxe e o modelo ignorou/distorceu (problema de geração/prompt). Sem medir os dois, você fica chutando.

Conclusão

RAG não é “plugar um vector store e pronto”. É um pipeline onde chunking, embeddings, busca híbrida e reranking se somam — e onde cada etapa mal feita degrada silenciosamente a resposta final. A diferença entre um RAG de demo e um RAG de produção está nos detalhes que ninguém posta: como você corta os documentos, se você reordena os resultados, se você trata o “não sei”, e se você mede retrieval e geração separadamente. O modelo de linguagem é a parte fácil; o retrieval é onde o trabalho mora.