¿Vas a cambiar el modelo de embeddings de RAG? Planifica la migración del índice vectorial antes de hacer el cambio
Cambiar el modelo de embeddings puede requerir regenerar los vectores de documentos y actualizar la ruta de consulta. Sigue este plan por etapas para inventariar tu configuración, reconstruir y validar un índice y preparar una vía de reversión.
Trata el cambio de embeddings como una migración de datos
Un sistema RAG suele generar embeddings del contenido de origen para almacenarlo y de las consultas de los usuarios para recuperar información. Cambiar el modelo o su configuración puede requerir regenerar los vectores de los documentos y revisar cómo se generan los embeddings de las consultas. No des por sentado que la configuración nueva funcionará con los vectores existentes: verifica el comportamiento en tu sistema antes de depender de esa combinación.
Mantén alineada la configuración que se utiliza para los documentos y las consultas, y valida la recuperación con datos representativos. Tampoco presupongas que las puntuaciones de similitud de dos configuraciones distintas son directamente comparables; comprueba qué significan en tu implementación antes de usarlas para evaluar el cambio.
La documentación de [NVIDIA para RAG](https://docs.nvidia.com/rag/latest/change-model.html) indica que, para obtener una recuperación precisa, hay que volver a ingerir los documentos después de cambiar el modelo de embeddings o las dimensiones tras la ingesta. [Qdrant documenta](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) un proceso que copia los datos a una colección nueva y vuelve a generar los embeddings de los vectores mientras las búsquedas continúan.
- Identifica el modelo y la configuración que generaron los vectores de documentos actuales.
- Planifica cómo se utilizará la configuración nueva tanto para los documentos como para las consultas entrantes.
- Mantén disponible el índice actual hasta que el reemplazo supere las comprobaciones que hayas definido.
Inventaría toda la ruta de recuperación antes de reconstruir el índice
Empieza por registrar cómo pasan los datos del contenido de origen a los pasajes recuperados. Una reconstrucción puede quedar incompleta aunque la generación de embeddings termine correctamente: el conjunto de datos de origen podría haber cambiado, podrían faltar metadatos o la ruta de consulta podría seguir usando la configuración anterior.
Anota en un mismo lugar la configuración actual y la propuesta. Incluye los identificadores de los modelos y los parámetros que afectan a los embeddings, las dimensiones vectoriales esperadas, los pasos de extracción de texto y fragmentación, los campos de metadatos y la configuración de recuperación. Registra también cómo se identifican y actualizan los documentos, para poder comparar el índice reconstruido con el corpus previsto.
Considera el preprocesamiento parte de la configuración que estás evaluando. Si durante la migración divides o normalizas el texto de otra manera, los cambios en la recuperación podrían deberse tanto a esas diferencias como al cambio de modelo. Haz explícitos esos cambios para poder revisarlos.
- Corpus: ubicaciones de origen, identificadores de documentos, cantidad prevista de elementos o fragmentos y exclusiones.
- Embeddings: modelo y configuración actuales y de destino, dimensiones y ruta de generación de embeddings de consultas.
- Procesamiento: extracción, fragmentación, transformaciones del texto y gestión de actualizaciones o eliminaciones.
- Índice y recuperación: nombre de la colección o del índice, campos de metadatos y filtros, y configuración de búsqueda.
- Operaciones: tarea de reconstrucción, permisos de acceso, almacenamiento disponible y método para inspeccionar errores.
Elige un método de migración que mantenga un estado operativo
El método adecuado depende de si tu sistema puede mantener más de un índice, del tamaño y la frecuencia de actualización del corpus y de cuánta interrupción puede tolerar la aplicación. Qdrant documenta una migración a una colección nueva que permite seguir realizando búsquedas durante el proceso; consulta su [documentación de migración](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) para conocer ese método. No es una recomendación universal para todas las implementaciones.
Una reconstrucción completa puede ser una opción si puedes programar una ventana de mantenimiento y conservar el índice anterior hasta comprobar el nuevo. Un índice paralelo puede servir si necesitas comparar la recuperación o mantener disponible el índice existente durante la reconstrucción. Un piloto con un subconjunto representativo ayuda a probar la canalización, pero no demuestra que se haya reconstruido o validado todo el corpus.
Elige el método de forma deliberada, documenta sus compensaciones y evita eliminar o sobrescribir como primer paso el único índice operativo. Comprueba las capacidades y limitaciones de tu plataforma antes de empezar.
- Considera una reconstrucción completa si puedes programar una interrupción controlada y conservar el índice anterior.
- Considera índices paralelos si necesitas mantener disponible la ruta de recuperación actual durante la reconstrucción y la validación.
- Usa un piloto de alcance limitado para probar el proceso y planifica por separado la migración y validación completas.
- Confirma la capacidad disponible, el comportamiento de escritura durante la reconstrucción y el método para dirigir las consultas al índice previsto.
Vuelve a generar los embeddings de forma coherente y controla la cobertura
Si reconstruyes el índice, genera los embeddings de los documentos con la configuración de destino y configura la generación de embeddings de consultas antes de probar la recuperación. Confirma que las dimensiones generadas coincidan con las que espera el índice. Detectar una incompatibilidad de dimensiones antes de dirigir consultas reales puede evitar fallos en esa etapa.
Registra qué elementos se procesaron y cuáles fallaron. Cuando sea posible, compara el contenido reconstruido con el corpus previsto mediante identificadores estables de documentos o fragmentos. Resuelve los elementos faltantes, duplicados, omitidos y modificados durante la tarea; no tomes la finalización del proceso como prueba de que la cobertura está completa.
Si el contenido de origen puede cambiar durante la reconstrucción, decide cómo se reflejarán esos cambios en el índice nuevo. Según el sistema, podrías pausar las escrituras, registrar los cambios para aplicarlos después o procesar las actualizaciones en el destino como parte de la migración. Prueba el método elegido en vez de asumir que el destino se mantiene actualizado.
- Usa la configuración de embeddings de destino prevista para los vectores de documentos del índice nuevo.
- Configura la ruta de embeddings de consultas para que corresponda con la ruta de recuperación que probarás.
- Comprueba las dimensiones y que el índice acepte el formato de vector esperado.
- Registra los elementos procesados, fallidos, omitidos, modificados y duplicados.
- Resuelve cómo se tratarán las actualizaciones del origen realizadas durante la reconstrucción antes del cambio de índice.
Valida la recuperación antes de dirigir a los usuarios al índice nuevo
La validación debe comprobar algo más que la capacidad del índice nuevo para aceptar consultas. Antes de la reconstrucción, prepara preguntas representativas y anota los documentos o pasajes de origen esperados. Incluye consultas frecuentes, consultas que dependan de filtros de metadatos importantes y casos en los que la fuente correcta sea menos evidente.
Ejecuta esas comprobaciones mediante la ruta de generación de embeddings de consultas y recuperación que utilizará la aplicación. Inspecciona los pasajes recuperados y sus metadatos, no solo la respuesta final: una respuesta verosímil puede ocultar una fuente faltante, irrelevante o filtrada incorrectamente. Compara las rutas anterior y nueva como configuraciones independientes, y define qué resultado es aceptable para tu caso de uso antes de interpretar las puntuaciones.
Comprueba la cobertura del corpus junto con la calidad de recuperación. Obtener buenos resultados con un conjunto de prueba pequeño no demuestra que se hayan indexado todos los documentos previstos. Registra los casos de prueba, los resultados y las diferencias pendientes para que la decisión de cambiar de índice pueda revisarse.
- Confirma que los documentos representativos estén presentes en el índice nuevo.
- Prueba la recuperación esperada para consultas representativas e inspecciona los pasajes devueltos.
- Verifica los filtros de metadatos y cualquier comportamiento importante de acceso o alcance que utilice la recuperación.
- Comprueba los casos sin resultados, ambiguos y de error pertinentes para la aplicación.
- Acuerda los criterios de aceptación antes de hacer las pruebas y registra las excepciones.
Haz el cambio con una vía de reversión
Convierte el cambio de índice en un paso operativo deliberado. Registra qué índice y qué configuración de embeddings utiliza la aplicación y cambia la ruta de consulta como un par coordinado. Después, comprueba que la aplicación esté usando el índice y la configuración previstos.
Mantén intactos el índice anterior y su configuración durante el periodo de observación que hayas acordado. Define quién puede iniciar una reversión, qué pruebas la activarían y cómo se devolverá la aplicación a la ruta anterior que funcionaba. Si los datos siguen cambiando durante el cambio o después, incorpora esos cambios al plan para que volver al índice anterior no implique perder contenido más reciente.
Elimina el índice anterior solo cuando se haya aceptado la nueva ruta, ya no haga falta la reversión y se hayan tenido en cuenta los requisitos de conservación o gobernanza. Una copia de seguridad puede formar parte del plan de recuperación, pero no sustituye un cambio de índice probado ni un procedimiento de reversión claro.
- Cambia la configuración de embeddings de consultas y el índice de destino como parte de un único cambio controlado.
- Verifica la ruta activa con un conjunto pequeño de consultas conocidas inmediatamente después del cambio.
- Mantén disponible el índice anterior hasta que la nueva ruta cumpla los criterios de aceptación acordados.
- Documenta quién puede autorizar la reversión, las condiciones que la activan, los pasos y cómo se tratarán los cambios de datos intermedios.
- Programa la limpieza solo después de la aceptación y de revisar los requisitos de conservación.
Asigna responsabilidades y conserva el registro de la migración
La migración de embeddings no termina cuando se cambia de índice. Asigna a alguien la responsabilidad de la configuración del modelo y el preprocesamiento, asigna otra función responsable de las operaciones del índice si hace falta y establece un proceso para decidir cuándo futuros cambios de modelo o dimensiones requieren una nueva ingesta o reconstrucción.
Conserva el registro de la migración junto con la configuración del índice: alcance del corpus de origen, modelo y dimensiones, decisiones de preprocesamiento, recuentos de elementos completados y fallidos, resultados de validación, hora del cambio, instrucciones de reversión y decisión de limpieza. Así, la resolución de problemas posterior dependerá menos de la memoria y será más fácil distinguir un cambio de embeddings de un cambio en el corpus o la recuperación.
La infraestructura y la gestión del índice son aspectos operativos distintos de las decisiones sobre qué documentos incluir, quién puede recuperarlos y qué calidad de recuperación es aceptable. Documenta esos límites y asigna responsables para cada decisión en tu propia configuración.
- Designa a una persona responsable de la configuración de embeddings y a otra de las operaciones del índice, si corresponde.
- Versiona o conserva de algún otro modo la configuración del modelo, el preprocesamiento y la recuperación utilizada para cada índice.
- Conserva un registro de la migración y un conjunto de validación representativo para futuros cambios.
- Revisa por separado el acceso a los datos, su conservación y las opciones de copia de seguridad.
Preguntas frecuentes
¿Tengo que volver a generar los embeddings de los documentos si cambio el modelo?
Planifica volver a generar los embeddings o ingerir de nuevo los documentos para la nueva configuración, salvo que hayas verificado que la configuración es compatible con los vectores existentes. La [documentación de NVIDIA para RAG](https://docs.nvidia.com/rag/latest/change-model.html) indica que, para obtener una recuperación precisa, hay que volver a ingerir los documentos después de cambiar el modelo de embeddings o las dimensiones tras la ingesta.
¿Puede seguir disponible el índice anterior mientras se construye uno nuevo?
Depende de la base de datos vectorial y del diseño de la implementación. [Qdrant documenta](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) un proceso que copia datos a una colección nueva, vuelve a generar los embeddings de los vectores y permite realizar búsquedas durante la migración. Comprueba el comportamiento y los requisitos operativos de tu propia configuración antes de confiar en un método similar.
¿Puedo comparar las puntuaciones de similitud de los modelos de embeddings anterior y nuevo?
No presupongas que las puntuaciones tienen una escala directamente comparable. Compara los pasajes recuperados con consultas representativas y criterios de aceptación acordados; trata cada configuración de modelo e índice como una ruta de recuperación independiente, salvo que hayas validado la comparación en tu sistema.
¿Basta con que la reconstrucción termine correctamente para aprobar el cambio?
No. Comprueba la cobertura, los errores, los metadatos y filtros, y los resultados de recuperación para consultas representativas. Después, cambia de forma coordinada la configuración de embeddings de consultas y el índice, verifica la ruta activa y conserva una opción de reversión hasta que se acepte la nueva configuración.