Tu pila de embeddings obliga a un reindexado del 100% solo para cambiar de modelos. Y la mayoría de los equipos lo tratan como algo inevitable. Imagina que construiste un pipeline RAG con un gran modelo de embeddings para una alta calidad de recuperación, y se envía a producción. Seis meses después, el tráfico de tu aplicación y los costos de tu modelo de embeddings están por las nubes mientras tu pipeline lucha por escalar. Quieres cambiar a un modelo que priorice el costo y la latencia para satisfacer esta nueva demanda. Pero tus embeddings existentes viven en un espacio vectorial, mientras que el nuevo modelo produce embeddings en uno diferente, lo que los hace incompatibles. Cambiar de modelos ahora significa reconstruir el índice: - Cada documento necesita ser re-embebido - Cada fragmento debe ser recalculado - Millones de vectores tienen que ser regenerados antes de que las consultas funcionen de nuevo La mayoría de los equipos miran esto y deciden absorber el costo en lugar de cambiar. Con el tiempo, esto se convierte en una regla no escrita. O optimizas para la calidad o optimizas para el costo, y vives con la decisión que tomaste al principio. Pero esta no es una limitación fundamental de los embeddings. Es una elección de diseño. ¿Qué pasaría si los modelos de embeddings compartieran el mismo espacio vectorial? En esa configuración, podrías indexar documentos usando un modelo grande y consultarlos usando uno más ligero, sin reconstruir nada. ...