Embeddings não são mágica. São uma compressão dos seus dados.

Toda proposta de RAG que reviso tem o mesmo slide: documentos entram, embeddings saem, busca por similaridade encontra a resposta. A seta entre o chunk e o vetor é desenhada como se fosse gratuita e exata. Não é nenhuma das duas coisas. Um embedding é uma compressão com perdas de um trecho de texto em algumas centenas ou milhares de números, e quem decide o que fica e o que é jogado fora é um modelo treinado com dados de outra pessoa para o propósito de outra pessoa. Quando você enxerga assim, a maioria das falhas de retrieval deixa de ser misteriosa.

O que é jogado fora

Um vetor de tamanho fixo não consegue guardar tudo o que há em um parágrafo. O modelo de embedding preserva o que foi útil para o objetivo de treino, que costuma ser alguma versão de "esses dois textos falam da mesma coisa". O tema sobrevive. O tom quase sempre sobrevive. Identificadores exatos, números, negações e datas sobrevivem mal. Dois chunks que dizem "o paciente recebeu o medicamento" e "o paciente não recebeu o medicamento" caem perto um do outro na maioria dos espaços de embedding, porque falam do mesmo assunto. Em um sistema onde essa distinção importa, e nos meus ela sempre importa, similaridade de cosseno é a ferramenta errada para o último trecho. Já auditei pipelines que devolviam o documento certo com a polaridade errada e ninguém percebia porque as métricas de retrieval estavam ótimas.

Seus dados não são os dados de treino

Modelos de embedding são treinados em texto genérico. Seu corpus é contrato, ou ticket, ou anotação de laboratório, ou SKU de produto. Quando o vocabulário do seu domínio é raro no conjunto de treino, o modelo comprime mal: siglas internas, códigos de produto e números de peça colapsam para uma região genérica de "ruído técnico". O sintoma é um retrieval que funciona lindamente nas queries da demo, escritas em linguagem natural, e falha nas queries que usuários reais digitam, cheias dos identificadores que o modelo nunca aprendeu. A solução raramente é um modelo de embedding maior. É retrieval híbrido: keyword ou BM25 para os tokens exatos, vetores para o significado, e um reranker para combinar os dois.

Chunking é uma decisão de compressão

O chunk é a unidade de compressão, e ninguém fala disso. Um chunk de dois mil tokens embutido em um único vetor é uma média de tudo o que há dentro dele, então um fato específico no meio é diluído pelo boilerplate ao redor. Um chunk de cinquenta tokens preserva o fato e perde o contexto que diz a que ele se refere. Não existe tamanho certo universal. Existe o tamanho certo para os seus documentos e as suas queries, e você o encontra medindo, não copiando o default de um tutorial. Mantenho um pequeno conjunto de evals com queries reais e trechos corretos conhecidos, e rodo de novo toda vez que o chunker, o modelo ou o corpus muda. Esse conjunto já pegou mais regressões do que qualquer dashboard.

Trate como formato, não como oráculo

• Versione o modelo de embedding como um schema, porque trocá-lo invalida todos os vetores armazenados.
• Guarde o texto de origem ao lado do vetor, sempre, para poder rerankear e exibir o que de fato foi recuperado.
• Meça recall nas suas próprias queries, não em benchmark público.
• Combine vetores com matching exato para qualquer coisa que tenha identificador.

Quando um time internaliza que embedding é um formato de compressão com um perfil de perda específico, a conversa de arquitetura muda. Param de perguntar "qual banco vetorial" e começam a perguntar "o que meu retrieval precisa preservar, e o que posso me dar ao luxo de perder". Essa é a pergunta certa, e ela tem o mesmo formato de toda pergunta de engenharia de dados que já respondi.