O seu stack de embeddings força um reindexação de 100% apenas para mudar de modelos. E a maioria das equipas trata isso como inevitável. Imagine que 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, o tráfego da sua aplicação e os custos do seu modelo de embedding estão a disparar enquanto o seu pipeline luta para escalar. Você quer mudar para um modelo que prioriza custo e latência para atender a essa nova demanda. Mas os seus embeddings existentes vivem em um espaço vetorial, enquanto o novo modelo produz embeddings em um espaço diferente, o que os torna incompatíveis. Mudar de modelos agora significa reconstruir o índice: - Cada documento precisa ser re-embarcado - Cada pedaço deve ser recomputado - Milhões de vetores têm que ser regenerados antes que as consultas funcionem novamente A maioria das equipas olha para isso e decide absorver o custo em vez de mudar. Com o tempo, isso se torna uma regra não falada. Você ou otimiza para qualidade ou otimiza para custo, e vive 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 os modelos de embedding compartilhassem o mesmo espaço vetorial? Nesse arranjo, você poderia indexar documentos usando um modelo grande e consultá-los usando um mais leve, sem reconstruir nada. ...