Sua pilha de embedding força um reindexamento de 100% só para mudar de modelo. E a maioria das equipes trata isso como algo inevitável. Imagine que você construiu um pipeline RAG com um grande modelo de embedding para alta qualidade de recuperação, e ele é enviado para produção. Seis meses depois, os custos do tráfego de aplicações e do modelo de incorporação estão disparando enquanto seu pipeline luta para escalar. Você quer mudar para um modelo que priorize custo e latência para atender a essa nova demanda. Mas seus embeddings existentes vivem em um espaço vetorial, enquanto o novo modelo produz embeddings em outro, o que os torna incompatíveis. Mudar de modelo agora significa reconstruir o índice: - Cada documento precisa ser reincorporado - Cada bloco deve ser recalculado - Milhões de vetores precisam ser regenerados antes que as consultas funcionem novamente A maioria das equipes olha para isso e decide absorver o custo em vez de trocar. Com o tempo, isso se torna uma regra não dita. Você ou otimiza a qualidade ou otimiza o custo, e convive com a decisão que tomou no início. Mas isso não é uma limitação fundamental dos embeddings. É uma escolha de design. E se modelos de embedding compartilhassem o mesmo espaço vetorial? Nesse esquema, você poderia indexar documentos usando um modelo grande e consultá-los usando um modelo mais leve, sem precisar reconstruir nada. ...