Engenharia de RAG: chunking, embeddings e reranking

A qualidade de um sistema RAG é decidida antes do modelo gerar qualquer texto. Ela é decidida em como o documento foi dividido, qual embedding representa cada pedaço, como esse pedaço compete com outros na recuperação e se o pipeline consegue medir, de forma objetiva, se está recuperando o conteúdo certo. Este artigo cobre essas quatro decisões.

Chunking por estrutura, não por tamanho fixo

Dividir documentos em blocos de tamanho fixo (por exemplo, 500 tokens com sobreposição de 50) é o ponto de partida mais comum e o mais frequentemente responsável por recuperação ruim. O problema: tamanho fixo ignora a estrutura semântica do documento, cortando uma tabela ao meio ou separando um título de sua explicação.

A alternativa é chunking guiado pela estrutura do documento:

• Documentos com markup (Markdown, HTML, DOCX com estilos) — usar cabeçalhos como limites naturais de chunk, preservando a hierarquia (um chunk de subseção carrega o título da seção pai como contexto).
• Tabelas — tratar como unidade atômica, nunca dividir uma tabela entre chunks; se a tabela for muito grande, serializar por linha com o cabeçalho repetido em cada chunk.
• Documentos jurídicos/contratuais — usar cláusulas ou artigos numerados como unidade, porque é essa a granularidade que será citada depois.
• Código-fonte — usar função ou classe como unidade, não linha ou caractere.

Um teste prático: se um humano, ao ler apenas aquele chunk isoladamente, não consegue entender do que se trata sem contexto adicional, o chunk está mal cortado.

Escolha e versionamento de embeddings

A escolha do modelo de embedding não é definitiva — modelos evoluem, e trocar de embedding é inevitável ao longo da vida do sistema. Isso tem uma implicação de engenharia direta: o índice vetorial precisa ser versionado junto com o modelo que o gerou.

embedding_model_id     string   -- ex: "text-embedding-v3"
embedding_dim          int
index_version          string
chunk_id               uuid
vector                 float[]
generated_at           datetime

Nunca misture vetores de modelos de embedding diferentes no mesmo índice de busca por similaridade — distâncias entre embeddings de modelos diferentes não são comparáveis. Trocar de modelo exige reindexação completa, não incremental.

Critérios objetivos para escolher um modelo de embedding: desempenho em benchmark de domínio (não apenas benchmarks genéricos como MTEB, que pode não refletir o vocabulário do seu domínio), custo por token, dimensionalidade (impacta custo de armazenamento e latência de busca) e suporte ao idioma predominante do seu corpus.

Reindexação

Reindexação acontece em três cenários, com estratégias distintas:

Para troca de modelo, mantenha os dois índices em paralelo durante a transição e valide a qualidade de recuperação do novo índice contra o mesmo conjunto de avaliação antes do cutover — nunca troque o índice de produção sem esse gate.

Reranking

Busca vetorial recupera candidatos por similaridade semântica aproximada, mas similaridade de embedding não é sinônimo de relevância para a pergunta específica. Um estágio de reranking, aplicado sobre os top-k candidatos (tipicamente k=20 a 50) antes de selecionar os poucos que vão para o prompt (tipicamente 3 a 8), corrige boa parte desse desvio.

Reranking com um cross-encoder (que avalia o par pergunta-chunk conjuntamente, ao contrário do bi-encoder usado na busca vetorial) tem custo computacional maior por par avaliado, mas é aplicado a um conjunto pequeno de candidatos, o que o torna viável em latência. Na prática, reranking costuma trazer o ganho de qualidade mais visível e barato de todo o pipeline de RAG — geralmente mais impactante do que trocar de modelo de embedding.

Avaliação de recuperação

Sem métrica, não há como saber se uma mudança no pipeline (novo chunking, novo embedding, novo reranker) melhorou ou piorou a recuperação. As métricas padrão:

• Recall@k — de todos os chunks relevantes para uma pergunta, quantos aparecem entre os top-k recuperados. Mede se o conteúdo certo está no conjunto de candidatos.
• nDCG (normalized Discounted Cumulative Gain) — pondera não apenas se o chunk relevante apareceu, mas em que posição, penalizando relevantes que aparecem distantes do topo.

Construir esse conjunto de avaliação exige um passo manual: um conjunto de perguntas reais (ou representativas) com os chunks corretos anotados por humano. Sem esse gabarito, qualquer mudança no pipeline é avaliada por impressão, não por dado.

query: "qual o prazo de garantia do produto X?"
relevant_chunk_ids: ["doc_42#chunk_7", "doc_42#chunk_8"]

Rode essa avaliação como parte do pipeline de CI sempre que chunking, embedding ou reranker mudarem — trate regressão de recall@k como trataria uma regressão de teste automatizado.

Citação de fonte e versão vigente

Todo chunk recuperado e citado na resposta final deve carregar metadado suficiente para apontar de volta ao documento de origem e à versão vigente no momento da resposta. Isso serve dois propósitos: permite ao usuário verificar a informação, e permite auditoria posterior caso o documento-fonte tenha sido atualizado ou corrigido depois da resposta ter sido gerada.

O que fazer na segunda-feira

1. 1.Revise sua estratégia de chunking atual: se for tamanho fixo sem considerar estrutura, priorize migrar para chunking estrutural nos tipos de documento com maior volume de consulta.
2. 2.Adicione ${'embedding_model_id'} e ${'index_version'} como metadados obrigatórios do índice, se ainda não existirem.
3. 3.Monte um conjunto de avaliação com 30 a 50 perguntas reais anotadas e meça recall@k e nDCG do estado atual antes de qualquer mudança.
4. 4.Se ainda não há reranking, adicione um estágio de cross-encoder sobre os top-20 antes de qualquer outro investimento em RAG — é o ajuste de maior retorno por esforço.

Leitura complementar

Trilha executiva:

• RAG não é mágica: o custo real de dar contexto corporativo à IA — a leitura de negócio deste mesmo tema.