Corpus vivo para RAG: versionar fuentes, retirar contenido obsoleto y demostrar la evidencia de cada respuesta

El problema: una cita puede ser exacta y, aun así, no servir

Un sistema de generación aumentada por recuperación, o RAG, suele evaluarse preguntando si recupera un texto relevante y si la respuesta se apoya en él. Ese control es necesario, pero no basta cuando el corpus cambia. Una respuesta puede reproducir con precisión un fragmento de una política anulada, un manual sustituido o un contrato que ya no aplica a la persona que consulta. En ese caso, el fallo no está necesariamente en la generación: está en el ciclo de vida de la evidencia.

Conviene separar dos preguntas. La primera es semántica: ¿el fragmento recuperado responde a la consulta? La segunda es de gobierno: ¿era una fuente autorizada, accesible y vigente para esta consulta y en este momento? La similitud vectorial, por sí sola, no resuelve la segunda. Un texto antiguo puede parecer más similar a la pregunta que una revisión nueva; una copia local puede contener instrucciones distintas de una política central; y un fragmento que fue indexado cuando una persona tenía acceso puede seguir apareciendo después de que pierda ese permiso.

La tesis operativa es simple: añadir archivos a un índice no crea una base de conocimiento mantenible. Para hacerlo se necesita una identidad estable para el documento, una revisión identificable, un intervalo de vigencia, una regla de autoridad, controles de acceso aplicados durante la recuperación y un registro que enlace cada respuesta con las evidencias realmente consultadas. También se necesita una retirada explícita: dejar de publicar un archivo en el origen no garantiza que desaparezca de los índices, réplicas, cachés o registros derivados.

Esta guía trata el corpus como un sistema de registros sometido a cambios, no como una carpeta de archivos. El objetivo no es prometer respuestas infalibles. Es poder demostrar por qué una evidencia era elegible, detectar cuándo dejó de serlo y abstenerse cuando las reglas disponibles no permiten determinar cuál de varias fuentes activas debe prevalecer.

Separar identidad, revisión, vigencia, autoridad y acceso

La identidad responde a qué objeto documental se está gestionando. Debe permanecer estable aunque cambie el título, la ubicación o el formato. Por ejemplo, una política corporativa puede conservar su identificador canónico al pasar de un documento de oficina a una página web. La revisión responde a qué edición concreta contiene el texto. Una corrección editorial y una sustitución normativa pueden crear revisiones distintas, aunque el cambio parezca pequeño.

La vigencia expresa cuándo una revisión puede utilizarse como evidencia. No debe confundirse con la fecha de indexación ni con la fecha de modificación técnica del archivo. Una política publicada hoy puede entrar en vigor el mes próximo; otra puede mantenerse solo para consultas históricas. Por ello, resulta útil almacenar al menos un inicio de vigencia, un final de vigencia cuando exista y un estado operativo, como borrador, aprobado, activo, retirado o restaurado excepcionalmente.

La autoridad ordena fuentes que pueden tratar el mismo asunto. Una política global aprobada puede prevalecer sobre una guía local, salvo que exista una excepción válida para una jurisdicción, una unidad o un producto. Esta regla no puede inferirse de forma fiable por la redacción ni por la similitud. Debe ser un atributo gobernado, con un propietario y una regla explícita de precedencia. Si dos fuentes activas se contradicen y no hay una regla aplicable, el comportamiento prudente es no escoger una por popularidad o cercanía semántica.

El permiso de acceso es otra dimensión independiente. Un fragmento no deja de contener información protegida porque se haya dividido, vectorizado o almacenado en un índice. Los filtros de autorización deben aplicarse antes de ordenar resultados por relevancia y deben actualizarse cuando cambian las listas de control de acceso. La documentación de servicios de búsqueda confirma que la seguridad a nivel de documento puede restringir qué documentos de un índice puede ver una persona y que los cambios de permisos exigen mantener sincronizados los documentos afectados.

Este diseño se alinea con una idea básica de procedencia: distinguir entidades, actividades y agentes. El documento canónico, su revisión y cada fragmento son entidades; la extracción, el particionado, la creación de embeddings y la indexación son actividades; el propietario, aprobador y servicio que ejecuta un proceso son agentes. Modelar estas relaciones no obliga a adoptar una tecnología concreta, pero evita convertir la trazabilidad en notas libres difíciles de consultar.

Modelo de datos mínimo para un corpus gobernado

Un modelo mínimo no necesita capturar todos los metadatos posibles, pero sí los que permiten decidir elegibilidad y reconstruir hechos. La entidad documento canónico puede incluir un identificador inmutable, tipo documental, ámbito, propietario responsable, fuente de origen y clasificación. La entidad revisión debe tener su propio identificador, una huella del contenido recibido, estado de aprobación, inicio y fin de vigencia, fecha de publicación conocida y relación con la revisión anterior o sustituida.

Cada fragmento recuperable debe llevar el identificador del documento canónico y de la revisión, una posición o rango estable dentro de la revisión, la huella de su texto normalizado y los atributos necesarios para filtrar. El embedding no es el fragmento: es una representación derivada. Por ello necesita su propio identificador de modelo, versión de configuración, fecha de cálculo y referencia al fragmento exacto que lo originó. El índice también es una entidad operativa: registre su versión, partición o réplica, configuración de búsqueda, momento de publicación y conjunto de revisiones incluido.

Añada relaciones explícitas para sustituye, deriva de, fusiona y retira. Una fusión documental no equivale necesariamente a una sustitución uno a uno: varios documentos pueden ser absorbidos por una nueva fuente, mientras que una parte de la información puede quedar sin sucesor. Esta distinción permite contestar si un documento fue retirado, cuál es su sucesor cuando existe y si una consulta histórica debe seguir pudiendo encontrarlo bajo controles específicos.

Los campos temporales merecen una disciplina especial. Guarde el tiempo observado en el origen, el tiempo de aprobación, el intervalo de vigencia de negocio, el tiempo de extracción y el tiempo de publicación en el índice. No suponga que son intercambiables. Para reconstruir una respuesta es importante saber qué se sabía y qué estaba disponible operativamente, además de qué texto decía ser vigente. Cuando los relojes de varios sistemas no están sincronizados o una fecha procede de metadatos poco fiables, registre esa incertidumbre en vez de convertirla en una certeza artificial.

Flujos de cambio: actualizar no es una única operación

El alta inicial comienza con la validación de origen, identidad, propietario, clasificación y reglas de acceso. Después se extrae el contenido, se crea una revisión, se fragmenta, se calculan representaciones y se publica una versión de índice. La publicación debe ser atómica desde el punto de vista de la consulta o, al menos, debe evitar estados en los que una parte de una revisión sea visible y otra no. Si se requieren aprobaciones, un borrador puede procesarse técnicamente sin ser elegible para responder.

Una corrección menor requiere comparar la nueva huella con la revisión anterior y localizar qué segmentos cambiaron. Recalcular solo los fragmentos afectados puede reducir trabajo, pero solo si el algoritmo de particionado mantiene referencias correctas. Si una modificación desplaza títulos, numeración o secciones, puede afectar más fragmentos de los que indica una comparación literal. La optimización debe estar subordinada a la trazabilidad: es preferible reindexar más contenido que conservar vínculos ambiguos entre un embedding y un texto.

Una sustitución de política es un evento de gobierno. Debe crear una revisión o documento sucesor, fijar la fecha de entrada en vigor, cerrar la vigencia del anterior cuando proceda y propagar la retirada a todos los artefactos derivados. En determinados sistemas de indexación, los documentos que ya no están presentes en el origen pueden requerir una acción de borrado explícita; por tanto, una reejecución no debe asumirse como prueba de retirada completa. La verificación debe consultar el estado de los índices y las réplicas, no solo el registro del origen.

Una retirada total conserva, si la política de retención lo permite, un historial no elegible para respuestas ordinarias. El historial puede ser necesario para auditoría, investigación de incidentes o reconstrucción de una respuesta pasada. Debe quedar separado de los índices activos, con controles de acceso y una finalidad definida. Restaurar una fuente retirada es excepcional: debe producir un nuevo evento, justificar el cambio de estado y desencadenar una nueva publicación verificable, en lugar de borrar el rastro de la retirada anterior.

Reindexación, cachés y duplicados: mantener coherencia entre representaciones

La reindexación selectiva es útil cuando se puede demostrar la relación entre cada representación y su entrada. Calcule diferencias de texto y de metadatos. Un cambio en el contenido exige revisar los fragmentos y embeddings afectados. Un cambio de vigencia, autoridad, jurisdicción o permiso puede no alterar el texto, pero sí cambia la elegibilidad de recuperación; por eso debe actualizar filtros, índices de metadatos y cachés. Tratar solo las modificaciones textuales deja una vía para respuestas incorrectas con contenido literalmente inalterado.

No todos los cachés almacenan lo mismo. Puede haber cachés de descarga del origen, de fragmentos procesados, de embeddings, de resultados de recuperación y de respuestas finales. Cada una necesita una clave que incorpore las dependencias relevantes, como la versión de índice, la revisión de las fuentes, la identidad de la persona o su grupo de acceso, la jurisdicción y la fecha de la consulta cuando se responde sobre vigencia. Reutilizar una respuesta sin estas dimensiones puede revelar contenido o resucitar una política retirada.

Los principios de caché web distinguen frescura, validación e invalidación, y establecen que las solicitudes que cambian el estado del recurso deben invalidar las representaciones almacenadas aplicables. En un corpus RAG, el mecanismo concreto puede diferir, pero el principio es transferible: cuando cambia una fuente o su elegibilidad, hay que localizar y retirar o invalidar las representaciones derivadas que podrían seguir sirviendo la versión anterior.

Los duplicados semánticos requieren una política explícita. Dos fragmentos pueden expresar la misma regla y pertenecer a revisiones distintas; devolver ambos puede aumentar artificialmente la confianza del modelo. Agrupe candidatos por documento canónico o por relación de revisión antes de generar la respuesta. La agrupación no debe ocultar conflictos: si dos fuentes activas e igualmente autorizadas discrepan, conserve el conflicto como señal para abstenerse o pedir revisión humana.

Recuperar con tiempo, autoridad y permisos antes de ordenar por similitud

La consulta de recuperación debe construirse como una secuencia de restricciones y ordenación, no como una búsqueda vectorial seguida de una comprobación opcional. Primero determine el contexto: identidad de quien consulta, permisos efectivos, producto, jurisdicción, audiencia, fecha relevante y posible necesidad de consultar historia. Después filtre las revisiones y fragmentos que no cumplen ese contexto. Solo los candidatos elegibles deben pasar al cálculo de similitud, a la búsqueda léxica o a una combinación de ambas.

La fecha relevante merece una decisión de producto visible. Para preguntas sobre la norma actual, use el instante de consulta. Para preguntas como “¿qué política aplicaba cuando firmé?”, solicite o infiera con cautela una fecha de referencia y busque en el historial autorizado. Si la fecha no se conoce, no presente una reconstrucción histórica como si fuera actual. Es preferible pedir el dato, mostrar el alcance temporal de la evidencia o limitar la respuesta a lo que pueda justificarse.

La autoridad puede implementarse como una puntuación, pero no debería reducirse siempre a un número. Algunas reglas son duras: una norma obligatoria para una jurisdicción puede excluir una guía general. Otras pueden ser preferentes y admitir coexistencia. Documente las reglas, su propietario y las excepciones. El sistema generativo no debería inventar una jerarquía a partir del tono de los documentos.

Antes de redactar, conserve la lista de candidatos filtrados, los motivos de exclusión, la configuración del índice y los fragmentos finalmente utilizados. El registro debe distinguir entre evidencia recuperada y evidencia citada en la respuesta. También debe registrar la hora de consulta y la versión de las reglas de filtrado. Sin esos datos, una investigación posterior podría encontrar el documento actual, pero no demostrar qué corpus produjo el resultado original.

Pruebas de regresión, criterios de parada y responsabilidades

Las pruebas deben evaluar el comportamiento del sistema ante cambios, no solo la calidad de recuperación sobre un conjunto estable. Construya casos con una política retirada que conserva mayor similitud que su reemplazo, un fragmento eliminado de una revisión, una política aprobada con fecha de vigencia futura, una copia local que contradice a una fuente central y un permiso revocado después de la indexación. Cada caso debe declarar qué documentos son elegibles, cuál debe ganar si existe una regla de autoridad y cuándo la salida correcta es abstenerse.

Pruebe además la propagación temporal. Mida el plazo entre la aprobación de una retirada y su exclusión efectiva de índices, réplicas y cachés relevantes. No basta con probar el índice principal: una respuesta previamente generada puede estar almacenada en otra capa. Defina objetivos de tiempo distintos según el riesgo de la fuente. Una política de seguridad o un documento con datos sensibles puede requerir invalidación más rápida que una guía editorial interna.

Establezca criterios de parada claros. Bloquee una respuesta cuando falte el vínculo entre fragmento y revisión, cuando los permisos no puedan evaluarse, cuando la fuente carezca de propietario o cuando haya conflicto activo sin regla de precedencia. Muestre la fecha de actualización cuando contribuya a interpretar la respuesta, pero no la use para encubrir incertidumbre. Derive a revisión humana si existe evidencia potencialmente relevante que el sistema no puede ordenar con reglas explícitas.

Las responsabilidades deben estar separadas, aunque una misma persona pueda cubrir varias en equipos pequeños. El propietario de fuente responde por el contenido y su ciclo de vigencia. El responsable de indexación responde por la extracción, publicación e invalidación técnica. El aprobador de vigencia decide cuándo una revisión es utilizable. El responsable de incidentes coordina la retirada urgente, la evaluación de exposición y la comunicación. El equipo de producto define cómo se expresa la abstención y cómo se solicita contexto adicional a la persona usuaria.

Como siguiente paso, convierta este modelo en una lista de controles verificables y relaciónelo con las guías del centro de aprendizaje sobre evaluación de asistentes, comparación de enfoques de recuperación y descubrimiento de fuentes. La implementación dependerá de la arquitectura, pero el criterio de éxito se mantiene: para cada respuesta relevante, el equipo debe poder explicar qué evidencia se podía usar, cuál se usó, por qué era autorizada y qué habría impedido responder.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.