No artigo anterior, vimos o desastre geométrico que acontece quando você troca o modelo de embedding do seu RAG de um GPT-1 para um DeepSeek ao longo do tempo. Os vetores vão parar em espaços latentes completamente diferentes. A busca semântica morre porque a matemática por trás dela — o cálculo de distância entre matrizes — deixa de fazer sentido.
A pergunta que fica é: como nós, engenheiros, resolvemos isso no mundo real sem derrubar o sistema?
Aqui estão as abordagens arquiteturais e matemáticas que a indústria utiliza para sobreviver à evolução dos modelos de IA.
1. A Regra de Ouro: O vetor nunca é a fonte da verdade
O erro mais comum de quem está começando com RAG é tratar o banco de dados vetorial como o armazenamento principal. O vetor é um dado volátil, um estado derivado.
A fonte da verdade deve ser sempre o texto bruto original armazenado em um banco de dados relacional sólido (como um PostgreSQL). Se você perder os vetores, ou se a matemática deles ficar obsoleta, você deve ser capaz de recriá-los a partir do texto original a qualquer momento.
2. Re-embedding Assíncrono (A Força Bruta Elegante)
A solução mais comum e definitiva não tem magia: se você mudou para um modelo novo, precisa reprocessar toda a sua base histórica. O segredo está em como fazer isso sem downtime.
A arquitetura padrão envolve mensageria e processamento em background:
- Você levanta uma nova tabela ou coleção vetorial (ex:
documentos_embeddings_v2). - Enfileira todos os IDs dos documentos antigos em um message broker (RabbitMQ, Kafka, etc.).
- Os workers consomem essa fila de forma controlada, batem na nova API, geram os novos vetores e salvam no novo esquema.
- Quando a migração termina, você simplesmente vira a chave (o roteamento) da aplicação para apontar para a coleção
v2.
3. Versionamento de Índices e Roteamento de Queries
Mas o que acontece durante as semanas em que o re-embedding está rodando? Você não pode parar a operação.
A solução é o versionamento de espaço vetorial. Durante a transição, seu sistema precisa ter consciência de qual modelo gerou qual dado. Quando uma busca entra, a aplicação faz o embedding da query usando ambos os modelos (o antigo e o novo).
- A query V1 busca no índice antigo.
- A query V2 busca no índice novo (que está sendo preenchido).
Você consolida e re-ranqueia os resultados antes de devolver para o LLM gerar a resposta.
4. A Abordagem Matemática: Matrizes de Projeção (Transformação Linear)
Para quem gosta de quebrar a cabeça com a matemática pura, existe uma saída onde você não reprocessa o texto, mas sim traduz o vetor.
Se os espaços vetoriais de dois modelos mantêm propriedades topológicas semelhantes, você pode treinar uma pequena rede neural ou calcular uma matriz de transformação linear (W) que mapeia o espaço antigo para o novo. Em termos simples, você pega o vetor antigo (v_antigo) e multiplica pela matriz de projeção:
v_projetado = v_antigo × W
Isso aproxima as coordenadas antigas do espaço vetorial do modelo novo. É computacionalmente muito mais barato do que chamar a API para reler todo o texto, embora a precisão quase sempre sofra alguma perda. É uma técnica avançada, usada quando o volume de dados na casa dos bilhões de registros torna o re-embedding financeiramente inviável.
Conclusão
Migrar modelos de IA não é uma questão de apenas alterar a URL de uma API e a chave de autenticação. Exige um planejamento rigoroso de migração de dados, filas de processamento assíncrono e, acima de tudo, o respeito pelos contratos estabelecidos pela matemática do espaço latente.
Construir IA escalável é, no fim das contas, engenharia de software e sistemas distribuídos clássicos.
