Se você já mexeu com RAG (Retrieval-Augmented Generation), provavelmente já ouviu esses três termos sendo usados quase como sinônimos em algum momento, principalmente em conversas mais superficiais sobre o assunto. Mas eles não competem entre si. São três camadas distintas de um mesmo pipeline, e confundir suas responsabilidades é uma das causas mais comuns de RAG com recall baixo ou respostas alucinadas.
Neste artigo, vou destrinchar cada camada, mostrar onde uma termina e a outra começa, e comentar alguns trade-offs que aprendi implementando isso em produção.
O pipeline completo, de forma simples
Fonte de dados → ETL (extrai/limpa) → Chunking (divide) → Embedding (vetoriza) → Índice vetorial → Retrieval
Cada seta representa uma decisão de engenharia. Errar em qualquer uma delas degrada a qualidade final, mesmo que o LLM na ponta seja excelente.
ETL: a camada que ninguém quer fazer, mas que decide tudo
ETL (Extract, Transform, Load) é a parte "chata" do RAG, mas é onde a maior parte dos bugs de qualidade realmente nasce.
- Extract: puxar conteúdo bruto de PDFs, Confluence, Jira, banco de dados, código-fonte, etc. Cada fonte tem sua própria complexidade, um PDF escaneado não é o mesmo problema que uma página HTML do Confluence cheia de macros.
- Transform: limpar ruído (HTML, marcações, tabelas quebradas), normalizar encoding, remover boilerplate repetitivo, e, no meu caso, trabalhando com uma base de conhecimento técnica, decidir o que vale a pena manter versus o que é apenas ruído estrutural.
- Load: persistir esse conteúdo já tratado em um storage intermediário, antes de virar embedding.
Um erro clássico aqui: tratar ETL como uma etapa "genérica" de dados, igual você faria para um data warehouse. Para RAG, a transformação precisa preservar contexto semântico, não só normalizar valores. Um texto "limpo" para BI pode já ter perdido a estrutura que o LLM precisaria para responder bem.
Chunking: a decisão mais subestimada do pipeline
Chunking é dividir o texto já tratado em pedaços menores. Existe por dois motivos:
- Embeddings e LLMs têm limite de contexto.
- Chunks menores e bem delimitados geram recuperação mais precisa — você quer trazer o trecho relevante, não o documento inteiro.
As estratégias mais comuns:
- Tamanho fixo (ex: 512 tokens): simples, mas ignora a estrutura do conteúdo. Pode cortar uma explicação no meio.
- Estrutural/semântica: respeita parágrafos, seções, headers. Geralmente performa melhor em bases técnicas (documentação, ADRs, código).
- Com overlap: sobrepor uma pequena parte entre chunks vizinhos para não perder contexto na borda, muito útil quando uma ideia começa em um chunk e conclui no próximo.
Na prática, chunking ruim é silencioso: o sistema não quebra, ele só responde pior. Você pergunta algo e o retrieval traz um trecho tecnicamente relacionado, mas sem o contexto necessário para responder corretamente. É o tipo de bug que só aparece quando você já tem um harness de avaliação rodando, sem eval, passa despercebido.
Embedding: transformando texto em geometria
Só depois que o texto está limpo (ETL) e dividido (chunking) é que ele vira embedding: um vetor numérico que representa o significado semântico daquele chunk, gerado por um modelo especializado (text-embedding-3, Voyage, etc.).
Esses vetores vão para um índice vetorial, que permite busca por similaridade, é isso que possibilita, na hora do retrieval, encontrar "os pedaços de texto mais parecidos semanticamente" com a pergunta do usuário, mesmo que as palavras exatas sejam diferentes.
Um ponto importante: embedding não corrige um chunking ruim. Se o chunk já chegou fragmentado ou fora de contexto, o vetor vai representar fielmente... um pedaço de informação incompleto. Garbage in, garbage out — só que em forma de vetor.
A confusão mais comum
Muita gente trata RAG como "embedding + busca vetorial", pulando ETL e chunking como se fossem detalhes de implementação. Na prática, é o contrário: ETL e chunking são onde a maior parte do trabalho de engenharia, e da qualidade final, realmente acontece. O embedding é só a etapa que converte um bom trabalho de preparação em algo pesquisável.
Conclusão
RAG não falha por causa do modelo de embedding escolhido na maioria das vezes. Falha porque a fonte de dados foi mal extraída, o texto foi mal limpo, ou o chunking cortou informação no lugar errado. Antes de trocar de modelo de embedding ou tunar hiperparâmetros de busca, vale sempre auditar essas duas camadas anteriores primeiro.
Este artigo faz parte de uma série sobre implementações reais de RAG e engenharia de IA aplicada.
