Cambiar el modelo de embedding en RAG: migra tu chatbot de IA sin brechas de conocimiento

Un modelo de embedding suele trabajar de forma invisible en el trasfondo de un chatbot RAG. Traduce preguntas y fragmentos de conocimiento en vectores numéricos para poder encontrar contenidos semánticamente adecuados. Precisamente porque esta parte raras veces aparece en una interfaz de usuario, cambiar de modelo puede parecer una simple modificación de configuración. Sin embargo, desde el punto de vista técnico se genera un nuevo espacio de búsqueda. Los vectores de documentos existentes, los vectores de las nuevas preguntas y la definición del índice deben volver a ser coherentes entre sí.

Por ello, quienes desean cambiar los embeddings de RAG no deberían limitarse a reemplazar el nombre del modelo en la canalización de consultas. Un cambio seguro trata el nuevo índice como una versión independiente: construido de forma reproducible, evaluado con las mismas preguntas de prueba, operado inicialmente en paralelo y activado únicamente tras una decisión de aprobación consciente. De este modo, el chatbot del sitio web permanece disponible mientras el equipo mantiene bajo control la calidad, los tiempos de ejecución, los costes y la ruta de retorno.

Por qué los embeddings no son intercambiables de forma arbitraria

Un vector solo tiene sentido dentro del espacio en el que fue generado. La documentación oficial de Azure AI Search sobre la creación de un índice vectorial describe el índice como un espacio de embeddings formado por vectores del mismo modelo. Asimismo, señala que la dimensión de cada vector debe coincidir con la definición del campo. Un nuevo modelo puede tener una dimensión diferente, distintas fortalezas lingüísticas o una distribución distinta de las distancias semánticas.

La parte de la consulta es igualmente crucial. Según la documentación de Microsoft sobre la configuración del vectorizador, la indexación y la consulta deben utilizar exactamente el mismo modelo de embedding. Si un equipo mezcla vectores de documentos antiguos con preguntas procesadas por un nuevo modelo, las puntuaciones de similitud ya no se podrán interpretar de forma fiable. Incluso si la dimensión coincide por casualidad, esto no demuestra compatibilidad semántica.

Definir un objetivo medible antes del cambio

Que un modelo sea «más nuevo» no es un criterio de aceptación suficiente. Antes del primer reindexado, el equipo necesita un motivo concreto para la migración. ¿Se busca mejorar la calidad de los resultados en terminología técnica en español? ¿Se necesitan idiomas adicionales? ¿El modelo anterior va a quedar en desuso, es demasiado lento o demasiado caro? ¿O se pretende reducir la dimensión vectorial para ahorrar almacenamiento? Del objetivo derivan las métricas de comparación.

• Calidad: fuentes relevantes en el top-k, proporción de preguntas respondibles y calidad de la respuesta final.
• Operaciones: latencia de recuperación (retrieval), tasa de errores, tiempo de indexación y comportamiento ante fallos parciales.
• Costes: generación de embeddings para todo el catálogo, cambios continuos, almacenamiento y consultas.
• Cobertura: documentos, idiomas, versiones de producto y permisos de acceso en el nuevo índice.

Los valores de partida deben figurar en el mismo informe de evaluación que los resultados del candidato. Quienes ya gestionan un conjunto de referencia (Golden Set) pueden utilizar como base la guía sobre cómo medir la calidad de las respuestas en chatbots de IA. Lo importante es no limitar la comparación a una puntuación media: las preguntas críticas de soporte, los términos técnicos poco frecuentes y los casos sin resultado merecen sus propias evaluaciones.

Dos índices en lugar de modificaciones en un sistema en producción

El estándar más robusto es mantener un índice paralelo. El índice anterior permanece inalterado atendiendo el tráfico en directo. En paralelo, se crea una nueva colección o un nuevo índice con su propia identificación de modelo, dimensión, métrica de distancia y número de versión. Ambos se construyen a partir de la misma versión de origen aprobada. De este modo, las diferencias pueden atribuirse al modelo o a la configuración del índice, en lugar de comparar contenidos que cambian simultáneamente.

La guía oficial de Weaviate sobre el cambio de un vectorizador muestra para este propósito colecciones separadas y un alias como punto de conmutación reversible. El producto concreto es intercambiable; el principio sigue siendo valioso: aislar de forma limpia los embeddings antiguos y nuevos, encauzar el acceso mediante un enrutador controlado o alias y conservar el estado anterior durante un periodo de retroceso limitado.

Identidades estables para cada fragmento de conocimiento

Cada fragmento (chunk) requiere un ID funcional estable que no dependa del vector. Resulta conveniente combinar el ID de la fuente, la versión de origen, la sección y la versión del fragmento. Adicionalmente, cada registro debería incluir el nombre del modelo, la versión del modelo, la dimensión, la fecha de creación y el hash del texto procesado. De este modo, la canalización puede identificar con precisión qué se ha procesado ya, qué debe volver a procesarse y qué errores quedan pendientes.

Consolidar la nueva canalización de forma reproducible

Antes de abordar la carga masiva de datos (backfill), una pequeña muestra representativa debería procesarse a través de la nueva canalización. En esta fase, la extracción, la limpieza y el fragmentado RAG (chunking) deben mantenerse inicialmente inalterados. Si el equipo modifica al mismo tiempo el modelo, los límites de los fragmentos, los metadatos y el jerarquizado (ranking), resultará prácticamente imposible explicar una diferencia posterior en la calidad.

La configuración debe incluirse como un manifiesto versionado en la ejecución: modelo y proveedor, dimensión, normalización, métrica de distancia, tamaño de lote, reglas de reintento, versión del fragmentador, idiomas permitidos y metadatos requeridos. Las credenciales de acceso quedan expresamente excluidas de este manifiesto. Para cada lote solo se almacenan IDs, contadores, estados y un código de error seguro. Esto permite reanudar una ejecución interrumpida sin tener que repetir de forma costosa los embeddings que se completaron con éxito.

Generar nuevos embeddings de forma controlada y demostrar la integridad

Un reindexado solo se considera completo cuando el conjunto esperado coincide con el real. Una cifra elevada de documentos no es suficiente por sí sola. La canalización debe verificar por cada fuente si están presentes todos los fragmentos previstos, si sus hashes de texto coinciden con la versión de origen aprobada y si se han migrado todos los metadatos obligatorios. Los registros fallidos se envían a una cola de reintentos limitada; los errores permanentes deben permanecer visibles junto con su ID y no pueden quedar ocultos bajo un estado global positivo.

1. Congelar o identificar de forma unívoca el catálogo de origen y la fecha de corte de la versión.
2. Crear la nueva estructura de índice con la dimensión y la métrica correspondientes.
3. Generar e ingresar los embeddings de los fragmentos en lotes limitados e idempotentes.
4. Cotejar las cifras de documentos, fragmentos y metadatos con el inventario previsto.
5. Verificar una muestra a partir del hash del texto, el ID de origen y el contenido recuperable.

Comparar la recuperación utilizando preguntas idénticas

Llegado este punto, se ejecutan las mismas preguntas de prueba contra ambos índices. Además de la tasa de aciertos y la posición en el jerarquizado, el equipo debe comparar las fuentes realmente devueltas. ¿El nuevo índice ha posicionado en los primeros lugares fragmentos semánticamente parecidos pero técnicamente incorrectos? ¿Pierde precisión en códigos de producto exactos? ¿Se localizan mejor las palabras compuestas o las consultas multilingües? Un concepto de búsqueda híbrida y reordenación (reranking) previo debe configurarse de forma idéntica para ambas opciones para que la comparación sea equitativa.

La documentación de Azure sobre relevancia y jerarquización vectorial sugiere la búsqueda exhaustiva de k vecinos más cercanos (k-nearest-neighbor) como una alternativa para construir un conjunto de verdad absoluta (Ground Truth) que permita evaluar la cobertura (Recall) de un método de búsqueda aproximada (ANN). No se trata de un umbral universal, sino de una prueba de control útil: primero la referencia exacta y luego la búsqueda más rápida en producción. En el caso del chatbot, lo que cuenta adicionalmente es si las fuentes encontradas permiten generar una respuesta correcta y respaldada.

Evaluar la respuesta final y no solo los resultados devueltos

Una mejor posición en la recuperación no garantiza por sí sola una mejor respuesta del chatbot. Por ello, la comparación debe evaluar también la referencia a las fuentes, la exhaustividad, la incertidumbre permitida y la interrupción segura en caso de evidencias insuficientes. Durante este proceso, el modelo de respuesta, las instrucciones del sistema y la temperatura deben mantenerse lo más constantes posible. De lo contrario, la prueba estaría midiendo múltiples cambios de forma simultánea.

Consultas en la sombra (Shadow Reads) antes de la conmutación definitiva

Tras las pruebas fuera de línea, un pequeño porcentaje de las consultas de búsqueda reales —tratadas con minimización de datos— se puede ejecutar en paralelo contra el nuevo índice sin mostrar el resultado a los usuarios. Esta lectura en la sombra (Shadow Read) permite medir el lenguaje real, la latencia y el comportamiento ante casos sin resultado. Los contenidos privados, los datos personales y los historiales de conversación completos no deben incluirse en los registros de comparación sin una revisión previa. A menudo basta con categorías de consulta seudonimizadas, IDs de resultados y métricas técnicas.

La conmutación (cutover) en sí es un cambio pequeño y claramente observable: el alias, el destino del enrutador o la marca de función (feature flag) cambia del Índice A al Índice B. Durante la fase inicial se aplican umbrales de alerta más estrictos para fuentes ausentes, errores de recuperación, latencia y tasa de derivación a agentes humanos (handoff). Una transición gradual resulta conveniente siempre que la arquitectura la admita sin mezclar estados de sesión.

Probar en la práctica el plan de retorno (rollback) antes de conmutar

Un plan de retorno solo es fiable si el índice antiguo se mantiene suficientemente actualizado y se ha verificado el procedimiento de conmutación inversa. Por tanto, durante la fase paralela, las fuentes nuevas o modificadas deben dirigirse de forma controlada a ambas canalizaciones. Como alternativa, el equipo puede documentar una pausa breve de cambios y una posterior actualización de datos. La guía existente sobre respuesta ante incidentes y rollback ayuda a definir los desencadenantes y las responsabilidades.

Las señales típicas para ejecutar un retorno no se limitan a errores técnicos. Una caída significativa en los aciertos relevantes del top-k, la aparición de brechas de idioma, un volumen inusualmente alto de preguntas sin respuesta o filtros de acceso aplicados de forma errónea también justifican volver al estado anterior. El índice antiguo solo se elimina cuando ha finalizado el periodo de observación, se ha documentado la aprobación de borrado y no quedan diferencias de calidad sin aclarar.

Errores frecuentes en la migración de embeddings

• Cambiar únicamente el lado de las consultas: los nuevos vectores de preguntas se comparan contra un espacio de documentos antiguo.
• Confundir la misma dimensión con compatibilidad: la longitud vectorial y el espacio semántico no son lo mismo.
• Modificar múltiples variables a la vez: el modelo, el fragmentado y el jerarquizado cambian simultáneamente; la causa de un efecto resulta imposible de determinar.
• Analizar solo valores medios: las consultas poco frecuentes, críticas para el negocio o multilingües quedan diluidas en el promedios.
• Eliminar datos demasiado pronto: el índice antiguo se borra antes de que la carga real y los datos de calidad confirmen un funcionamiento estable.
• Omitir los filtros: los criterios de idioma, versión y acceso no se aplican en el nuevo índice exactamente como en el anterior.

Lista de comprobación práctica para equipos web

• El objetivo, la línea base, los criterios de aceptación, el responsable de aprobación y la señal de retorno están documentados.
• El índice antiguo y el nuevo se mantienen separados; el modelo, la dimensión y la métrica están claramente versionados.
• Ambos índices proceden de la misma versión aprobada de fuentes y fragmentos.
• La carga masiva (backfill) es idempotente, reanudable y se ha verificado contra el inventario previsto.
• El conjunto de referencia (Golden Set), las preguntas críticas, los idiomas, los casos sin resultado y los filtros de acceso superan la comparación.
• Las lecturas en la sombra registran únicamente los datos técnicos estrictamente necesarios.
• La conmutación y el retorno son cambios pequeños, observables y probados en la práctica.
• El catálogo antiguo solo se elimina tras el periodo de observación y con una aprobación documentada.

Conclusión: El nuevo espacio vectorial requiere su propio proceso de lanzamiento

Cambiar los embeddings en un sistema RAG es una migración de datos y de calidad, no un simple ajuste en la configuración del modelo. Construir el nuevo espacio de búsqueda de forma independiente, generar de nuevo todos los embeddings, realizar comparaciones con preguntas idénticas y activar el sistema a través de un punto de conmutación reversible reduce de manera sustancial los riesgos de interrupción y pérdida de calidad. Para los equipos web, vale la pena implementar un proceso reutilizable: asegurar la línea base, crear el índice paralelo, evaluar la recuperación y las respuestas, monitorear los datos en la sombra, conmutar de forma controlada y mantener abierta la vía de retorno.

Si tu chatbot de IA ya utiliza una base de conocimiento RAG, no comiences por la migración, sino por el conjunto de datos de prueba. Entre diez y veinte categorías de preguntas especialmente relevantes, complementadas con casos complejos de idioma, producto y permisos, marcan la diferencia entre un cambio de modelo especulativo y un lanzamiento demostrablemente seguro.

Fuentes

• Microsoft Learn: Create a vector index in Azure AI Search
• Microsoft Learn: Configure a vectorizer in Azure AI Search
• Microsoft Learn: Relevance in vector search
• Weaviate Documentation: Switching vectorizers