Mantener un almacén de vectores fiable: ciclo de vida, arquitectura por inquilinos, metadatos, búsqueda híbrida.

Un técnico de campo le pregunta a un asistente de soporte interno cómo reemplazar una bomba hidráulica. La respuesta parece correcta: familia de equipos adecuada, tipo de bomba correcto y una secuencia de pasos razonable. Sin embargo, tiene ya medio año de antigüedad. El boletín actual exige una actualización de firmware antes de instalar la bomba, pero el antiguo nunca menciona esto. Ambos boletines se encuentran en el almacén de vectores. El nuevo fue indexado correctamente, pero nadie eliminó nunca el antiguo. El modelo no inventó nada; simplemente recibió información obsoleta.

Preguntas como estas determinan si se puede confiar en un sistema de recuperación de información.

• ¿Qué versión de un documento se puede recuperar actualmente?
• ¿Cuánto tiempo después de su aprobación se vuelve un update buscable?
• ¿Puede un cliente ver el contenido de otro cliente?
• ¿Qué ocurre cuando un usuario busca un número de pieza exacto en lugar de una descripción general?

¿Qué campos de metadatos deben existir antes de que un fragmento sea admitido en el corpus buscable?

Nada de esto tiene que ver con la calidad del modelo. Se trata de la operación diaria de un almacén de vectores.

Un escenario concreto: soporte técnico multiinquilino

Imagínese una plataforma de soporte utilizada por distribuidores de equipos en varios países. Contiene manuales de productos, boletines de reparación, catálogos de piezas, políticas de garantía, procedimientos de mantenimiento y notas escritas por cada distribuidor. Un técnico podría preguntar qué procedimiento de reemplazo está aprobado para la bomba hidráulica MX-204, versión 5.2, en su propia región.

Eso no es una búsqueda semántica simple. El sistema debe interpretar la intención de mantenimiento, conservar intactos identificadores exactos como la versión MX-204 5.2, devolver el procedimiento de reparación actual, aplicar la política regional correcta y excluir todo lo que pertenezca a otros distribuidores o cuentas. Una consulta basada únicamente en similitud no puede ofrecer esas garantías. La capa de recuperación debe funcionar como un servicio de información gestionado.

Trate la indexación como gestión de publicación de documentos

Las primeras versiones de RAG suelen considerar la indexación como un único proceso: subir, dividir en fragmentos, incrustar, escribir, listo. Después de eso, el documento permanece buscable hasta que alguien se da cuenta de un problema. Los fallos que surgen son fáciles de prever.

• Un manual revisado coexiste junto a su versión anterior.
• Una política en borrador se vuelve buscable antes de que alguien la apruebe.
• Un procedimiento retirado permanece disponible porque no existe un proceso de eliminación.
• Una falla en la cadena de procesamiento deja un documento parcialmente indexado, por lo que solo se pueden recuperar fragmentos.

Para un corpus de soporte, el conjunto más pequeño útil de estados del ciclo de vida es el siguiente:

• Borrador: recibido, aún no aprobado para su recuperación.
• Candidato: indexado y en proceso de validación.
• Activo: aprobado y listo para ser recuperado.
• Sustituido: reemplazado por una versión más reciente, conservado para auditorías y oculto de las consultas habituales.
• En cuarentena: retenido debido a un error en la validación, las verificaciones de metadatos o la revisión de contenido.
• Eliminado: retirado del corpus y también del almacenamiento subyacente cuando así lo exigen las reglas.

Existe una regla fundamental: la búsqueda solo debe aplicarse a documentos en estado Activo. Esta regla debe hacerse cumplir mediante filtros de metadatos, y no por costumbres en la denominación de archivos o instrucciones dentro de un comando.

Cada documento también necesita un ID de documento estable y un ID de versión separado. El primero identifica el recurso lógico, como un boletín de reparación específico, mientras que el segundo designa una revisión de dicho recurso. Al aprobar una nueva revisión, se activa la nueva versión y se marca la anterior como obsoleta, y este cambio debe ocurrir de forma atómica. Con esto en vigor, el sistema deja de devolver contenido que sea relevante pero ya no sea válido.

Actualización de incrustaciones: incremental, versionada, reversible

La actualización de las incrustaciones a menudo se describe como una tarea que debe realizarse cada vez que cambia el modelo. Sin embargo, los desencadenantes reales son más variados:

• Se edita un documento de origen.
• Una política alcanza su fecha de vigencia o expiración.
• El esquema de metadatos crece.
• La estrategia de particionamiento mejora.
• El modelo de incrustación se actualiza.
• Un documento se retira o se reclasifica.
• Los derechos de un inquilino cambian.

Cada situación requiere una respuesta distinta. Un boletín revisado podría necesitar solo una actualización a nivel de sección. Un nuevo modelo de incrustación podría significar tener que reconstruir todo. Un nuevo campo de metadatos exige un relleno controlado, y un documento retirado debe eliminarse inmediatamente del índice activo.

Por lo tanto, el proceso de actualización debe hacer seguimiento de cuatro versiones: la revisión de origen, la lógica de particionamiento, el modelo de incrustación y el esquema de metadatos utilizado para el filtrado. Sin ese historial, nadie puede explicar por qué dos fragmentos se comportan de manera diferente al momento de la recuperación.

En la práctica, el archivo recibido se compara con la versión activa mediante un hash de contenido o una diferencia estructurada. Las secciones que han cambiado se vuelven a dividir en fragmentos y se vuelven a incrustar, mientras que las secciones sin modificaciones permanecen tal como están, a menos que la versión de fragmentación o incrustación haya cambiado.

Las actualizaciones de modelos grandes requieren un procedimiento más seguro: crear un índice candidato paralelo, ejecutar consultas de evaluación en ambos, verificar los controles de acceso y redirigir el tráfico solo una vez que el nuevo índice funcione de manera aceptable. Lo importante no es si el nuevo modelo obtuvo una puntuación más alta en una prueba de referencia, sino si el nuevo índice devuelve las pruebas correctas y aprobadas para las consultas que realmente envían los usuarios.

Aplicar el control de tenencia antes de la recuperación, no después

Un defecto de diseño peligroso pero común en los sistemas RAG multiinquilinos es el filtrado por inquilino después de la búsqueda. El sistema recupera una gran cantidad de resultados y luego elimina aquellos que pertenecen a otras organizaciones. Eso ocurre demasiado tarde. Los filtros de inquilino y de acceso deben definir el espacio de candidatos antes de que comience cualquier coincidencia de vectores o palabras clave.

En la plataforma de soporte, el contenido se divide en tres grupos.

• Contenido global: manuales del fabricante y procedimientos de seguridad compartidos.
• Contenido de distribuidores: guías de servicio internas, acuerdos comerciales e instrucciones de operación locales.
• Contenido de clientes: historial de activos, términos de contrato y notas operativas confidenciales.

No necesitan la misma estructura de almacenamiento. El contenido global puede compartir un corpus. El contenido de los distribuidores puede compartir un índice protegido por filtros obligatorios para los usuarios. Los clientes altamente sensibles pueden requerir sus propias colecciones o índices aislados, dependiendo de los requisitos regulatorios, contractuales y de riesgo.

El usuario, el rol, la región, los derechos de acceso al producto y el nivel de confidencialidad deben provenir de la sesión autenticada y nunca de la redacción de una solicitud. Un técnico que ingrese el nombre de otro distribuidor en una consulta no debe poder cambiar los filtros. En efecto, la solicitud de búsqueda indica que solo se debe buscar lo que este usuario autenticado puede acceder, y solo entonces comienza el ranking semántico o por palabras clave. Esto protege la confidencialidad y también elimina resultados irrelevantes.

Búsqueda híbrida para identificadores exactos

La búsqueda vectorial densa es útil cuando las personas describen un problema en lenguaje cotidiano, por ejemplo al preguntar qué versión de firmware se necesita antes de instalar una bomba de repuesto en el MX-204. Los números de pieza, códigos de controlador y cadenas de versión se comportan de manera diferente, y un índice léxico es mucho más eficaz para coincidir con ellos con exactitud.

En el caso del MX-204, la recuperación léxica puede llevar al boletín exacto porque contiene los identificadores del controlador y la bomba, mientras que la recuperación densa proporciona orientación de mantenimiento relacionada. Un reclasificador puede entonces dar prioridad al documento que contiene los requisitos del firmware y la secuencia aprobada.

Cuando la recuperación es deficiente, añadir más fragmentos al contexto rara vez ayuda. Un top-k más grande suele generar ruido, retrasos y una mayor probabilidad de obtener una respuesta creíble que no está respaldada por nada. Es mejor determinar en qué etapa falló.

• ¿Estaba el documento correcto inactivo?
• ¿Lo excluyó un filtro de metadatos defectuoso?
• ¿La búsqueda léxica pasó por alto un formato alternativo de número de pieza?
• ¿El reordenador favoreció un documento más general sobre uno más específico?

Cada uno de estos representa un problema del sistema que se puede medir.

Los metadatos como plano de control

Con frecuencia, los metadatos se tratan como etiquetas opcionales que se añaden durante la ingestión. En producción, determinan qué puede recuperar el sistema. Un esquema útil abarca cinco áreas.

• Identidad: el documento de origen, el sistema que generó el fragmento y un hash de contenido.
• Ciclo de vida: versión, estado de aprobación, fechas de vigencia y vencimiento, y qué reemplaza a qué.
• Acceso: ID del usuario, región, derechos de rol, acceso al producto, clase de confidencialidad y restricciones legales.
• Recuperación: tipo de documento, idioma, modelo de equipo, familia de componentes, línea de producto y categoría de contenido.
• Operaciones: versión de incrustación, versión de fragmentación, tiempo de ingestión, ID de ejecución del pipeline y estado de validación.

Con esta estructura, las preguntas que de otro modo serían complicadas se convierten en consultas sencillas. ¿Qué documentos activos siguen utilizando el antiguo modelo de incrustación? ¿Qué procedimientos de reparación vencen el próximo mes? ¿Qué fragmentos carecen de metadatos de región? ¿Qué arrendatario tiene la tasa más alta de resultados vacíos? ¿Qué sistemas de origen causan la mayor cantidad de fallos en la ingestión?

Los metadatos deben validarse antes de que un documento ingrese al corpus activo. Un fragmento sin alcance de arrendatario, estado de ciclo de vida, línea de producto o estado de aprobación no debe poder buscarse solo porque se haya generado su incrustación. Muchos sistemas RAG dejan de ser fiables exactamente en este punto: la base de datos funciona como está diseñada, pero el modelo de metadatos es demasiado simple para expresar las reglas reales de la organización en cuanto al acceso, el ciclo de vida y las políticas.

Observabilidad que identifica la etapa con errores

Cuando un usuario informa de una respuesta incorrecta, puede haber ocurrido cualquiera de varias cosas. Es posible que la fuente adecuada nunca haya sido indexada, o haya sido indexada pero marcada como inactiva, o haya sido descartada por un filtro. También podría haber llegado al conjunto de candidatos pero haber obtenido una clasificación demasiado baja. Puede haber entrado en el contexto del modelo y haber sido ignorado. O bien, el modelo podría haber escrito algo que no está respaldado por las pruebas. Cada caso requiere una solución diferente.

Por lo tanto, un servicio de recuperación maduro registra todo el camino seguido:

• La consulta y el contexto del usuario.
• Los filtros de acceso y de ciclo de vida que se aplicaron.
• Candidatos densos y candidatos léxicos.
• La clasificación fusionada y el resultado del re-clasificador.
• Las pruebas finales entregadas al modelo.
• Las citaciones utilizadas en la respuesta.

Las medidas útiles incluyen el retraso entre la aprobación de la fuente y la activación del índice, la proporción de contenido activo en la versión de incrustación actual, los documentos con más de una versión activa, las tasas de resultados nulos por tipo de consulta, la cobertura en pruebas de respuestas conocidas, las tasas de rechazo por filtros y cualquier intento de acceso entre arrendatarios.

Una métrica útil es la cobertura de candidatos: para una consulta con respuesta conocida, ¿apareció la fuente correcta entre los candidatos antes del reclasificado? Si no, sospeche problemas en el indexado, el filtrado o el diseño de búsqueda. Si apareció pero tuvo un ranking bajo, analice la fusión o el reclasificado. Si tuvo un buen ranking y la respuesta la ignoró, el problema radica en la generación o en la composición de la instrucción. Separar las etapas evita que los equipos intenten arreglarlo todo editando la instrucción.

Una rutina operativa

Un almacén de vectores merece la misma disciplina que cualquier servicio de datos en producción. Las verificaciones diarias deben analizar los fallos en la ingesta, la acumulación de actualizaciones pendientes, los documentos atrapados en estado de candidato o en cuarentena, la falta de metadatos obligatorios y el retraso en la aprobación para indexar. Las revisiones semanales deben evaluar la calidad de las búsquedas en diversos tipos de consultas, desde preguntas conversacionales hasta códigos simples, nombres de productos, búsquedas de políticas, búsquedas en otros idiomas y solicitudes vagas.

Cualquier cambio en la división en bloques, los modelos de incrustación, el esquema de metadatos o la política de acceso debe probarse primero en un entorno de candidato. El conjunto de evaluación necesita consultas reales de usuarios, casos con respuestas conocidas, pruebas de control de acceso y consultas diseñadas para detectar fugas de información de usuarios o contenido obsoleto.

El objetivo no es recuperar más documentos, sino entregar la evidencia aprobada adecuada al usuario correcto en el momento oportuno. Un almacén de vectores no es una base de datos pasiva detrás de un chatbot, ya que es él quien decide qué evidencia se permite utilizar para formar una respuesta. Cuando los documentos obsoletos permanecen activos, los filtros de usuario son opcionales, los identificadores desaparecen en la correspondencia semántica o los metadatos no pueden expresar reglas de negocio; en tales casos, el sistema resulta poco fiable, por más capaz que sea el modelo.