Ciclo de vida del corpus: actualizar, deduplicar y borrar

Última entrega del bloque dedicado al corpus, y de nivel avanzado. Las cinco anteriores lo trataron como un lote que se procesa una vez, y no lo es: los documentos cambian, se duplican, se contradicen, caducan y a veces hay que borrarlos por ley. Esto es lo que ocurre después del primer día.

El problema que aparece en el segundo mes

Los proyectos de RAG suelen arrancar bien: se ingieren unos miles de documentos, se indexan y funciona. El problema llega después: alguien actualiza un manual, se conecta una fuente que contiene copias de la primera, un cliente ejerce su derecho de supresión, o el sistema responde con información que ya no es cierta y nadie sabe por qué.

Un índice vectorial es una copia derivada de una fuente de verdad que vive en otro sitio, y todo lo que sigue son mecanismos para que no se separe del original. Con una asimetría: los sistemas de origen saben actualizarse y borrar; el índice no siempre.

Detección de cambios por hash

La base del mantenimiento es saber qué ha cambiado sin reprocesar todo, y la herramienta es el hash del texto extraído —no del binario, que cambia por metadatos internos sin que el texto varíe—, comparado en cada pasada.

Conviene guardar también un hash por fragmento. Si un documento de doscientas páginas cambia en un párrafo, sólo uno o dos fragmentos difieren: se reembeben esos dos en vez de cuatrocientos, y en un corpus grande eso decide si la reindexación cabe en la ventana nocturna.

Hay que comparar por conjunto de hashes y no por posición, porque al añadir un párrafo al principio los fragmentos posteriores se desplazan aunque su texto sea idéntico: los hashes de ambos conjuntos se conservan, los del nuevo se embeben y los del viejo se borran.

Reindexación incremental

Con eso resuelto, el ciclo queda así.

 FUENTES            SINCRONIZACIÓN                     ÍNDICE
 (gestor doc.,     ───────────────                    ──────
  wiki, correo,
  base de datos)   1. LISTAR (id, fecha_mod, tamaño)
        │                  │
        └────────►  2. COMPARAR CON EL REGISTRO
                      ┌───────┬──────────┬────────┬─────────┐
                      ▼       ▼          ▼        ▼         │
                    nuevo  modificado  igual   ausente      │
                      │       │      (omitir)     │         │
                      ▼       ▼                   ▼         │
                   3. EXTRAER Y TROCEAR     6. BORRAR ───────┤
                            │                 el documento  │
                            ▼                               │
                   4. HASH POR FRAGMENTO                     │
                      ┌────────┬──────────┐                 │
                      ▼        ▼          ▼                 │
                   nuevos   iguales   sobrantes             │
                      │    (omitir)       │                 │
                      ▼                   ▼                 │
                   5. EMBEBER          BORRAR ──────────────┤
                      E INSERTAR                            ▼
                   7. ACTUALIZAR EL REGISTRO

Tres decisiones importan aquí. La primera son las ausencias: un documento borrado en el origen no genera evento, sólo deja de aparecer en el listado, y detectarlo obliga a un barrido periódico aunque haya notificaciones en tiempo real.

La segunda es la atomicidad: entre borrar lo viejo e insertar lo nuevo, el documento no existe o existe a medias. Se resuelve insertando primero y borrando después, filtrando por versión; ante un cambio de troceado o de modelo, con un índice nuevo en paralelo y conmutación por alias.

La tercera es el registro de sincronización: una tabla propia, fuera del índice, con una fila por documento y sus hashes, versiones, fechas y estado. Deducirlo del propio índice funciona con mil documentos y no con un millón.

Versionado de documentos

Hay dos políticas, y conviene elegir conscientemente porque cambiar después es caro. La sustitución —la nueva versión reemplaza a la vieja— es lo correcto para documentación operativa, donde nadie quiere que se cite un procedimiento derogado.

La coexistencia mantiene todas las versiones indexadas con su número y su periodo de vigencia. Es obligatoria cuando hay que responder a «qué decía la política en marzo de 2023», que en entornos regulados no es hipotético. El coste es que el índice crece con el histórico y que todas las consultas necesitan filtro por vigencia: sin él, las versiones antiguas compiten con la actual y a veces ganan. La regla que evita casi todos los problemas es que ese filtro actúe por defecto y el histórico haya que pedirlo.

Deduplicación

Los duplicados no sólo ocupan sitio: copan los primeros puestos de la recuperación. Si los cinco fragmentos recuperados son copias del mismo texto, el modelo recibe una idea repetida y pierde el resto del contexto.

Duplicados exactos

Se detectan con el hash normalizado, por documento y por fragmento; es barato y hay que hacerlo siempre, porque en corpus reales aparecen más de los esperados. Y no basta con borrar: hay que elegir el ejemplar canónico y anotar en sus metadatos las demás ubicaciones.

Duplicados casi exactos

Son el caso difícil: la plantilla de contrato repetida cincuenta veces con tres campos distintos, dos versiones idénticas salvo dos párrafos, el aviso legal de todos los correos. Hay dos familias de técnicas. Las huellas léxicas —MinHash con LSH, SimHash— estiman el solapamiento de n-gramas y agrupan candidatos sin comparar todos contra todos: rápidas, escalables y buenas con la copia literal parcial. Y la similitud vectorial, que aprovecha los embeddings ya calculados para detectar textos equivalentes aunque estén reescritos.

La segunda tiene una trampa: una similitud altísima también puede significar dos cosas distintas dichas de forma parecida —dos cláusulas que difieren sólo en el importe—, y borrar una destruye información. Donde la diferencia está en los detalles, deduplicar por vector es peligroso. La alternativa es no borrar, sino diversificar en la recuperación: agrupar los resultados por documento y devolver un representante de cada grupo, que da contexto variado sin decidir que dos textos son el mismo.

Documentos que se contradicen

Ninguna técnica de indexación resuelve que dos documentos digan cosas incompatibles: el sistema recuperará ambos y el modelo elegirá uno sin decir por qué, los mezclará o, con suerte, señalará la discrepancia.

Lo que sí se puede hacer es reducir el daño. Jerarquía de fuentes: declarar en los metadatos qué fuentes tienen autoridad sobre qué materias, porque un procedimiento oficial pesa más que un hilo de correo. Prioridad por frescura cuando el conflicto es temporal, que es lo habitual. Instrucción al generador para que, ante afirmaciones incompatibles, lo diga con las dos fuentes en vez de escoger en silencio. Y detección en la indexación: comparar afirmaciones con un modelo es caro y ruidoso, pero acotado a normativa, precios o plazos saca a la luz contradicciones de años.

Conviene resistir la tentación de arreglarlo con prompt: si el corpus se contradice, el problema es del corpus, y un sistema RAG es, además, un detector eficaz de la incoherencia documental de una organización.

Caducidad y frescura

Un documento puede ser correcto y estar obsoleto, y distinguirlo exige separar tres fechas: la del documento, la de indexación y la vigencia, la única que dice si sigue aplicando.

Con esas fechas se montan mecanismos simples. Una caducidad explícita por tipo de documento, que marca como no vigente lo que supere su plazo sin revisión. Un decaimiento por antigüedad en la puntuación, con moderación, porque hay corpus donde lo antiguo es lo válido. Y la revisión provocada por el uso: llevar a revisión humana los documentos que más se citan, que es donde mejor se invierte el poco tiempo disponible. Y si la fecha está en los metadatos, no se deduce del contenido: un modelo confunde la de firma, la de entrada en vigor y la que aparece en un ejemplo.

Borrado real y derecho de supresión

Aquí el mantenimiento deja de ser cuestión de calidad y pasa a ser de cumplimiento: cuando alguien ejerce su derecho de supresión, o cuando termina un contrato y hay que eliminar los datos de un cliente, no basta con dejar de mostrarlos.

El primer obstáculo es que un índice vectorial no siempre borra cuando dice que borra. Muchos motores usan un marcado lógico: el registro se etiqueta como eliminado y se excluye de los resultados, pero el vector y a menudo el texto siguen en el fichero hasta una compactación que en unos motores es automática, en otros hay que provocar y en algunos sólo llega al reconstruir el índice. Para una obligación legal, entre «no aparece» y «ya no está» está toda la diferencia.

El segundo es que el dato está en más sitios de los que uno recuerda: el índice, el almacén de documentos padre de la entrega 10, las cachés de embeddings y de respuestas, las trazas de observabilidad —que suelen guardar el texto recuperado—, las copias de seguridad, el conjunto de evaluación y los ficheros intermedios de la ingesta. Borrar del índice y olvidar las trazas es un fallo habitual que invalida el cumplimiento.

Y una particularidad de los vectores: un embedding no es texto, pero no es anónimo. Hay técnicas de inversión que reconstruyen aproximaciones del original, y en cualquier caso permite identificar y comparar. Lo prudente es tratarlo como dato personal cuando el texto del que sale lo era.

Lo que hace viable todo esto son los metadatos de la entrega anterior: si cada fragmento sabe de qué documento, fuente y cliente viene, un borrado por criterio es una consulta de filtrado; si no, obliga a reindexar desde las fuentes excluyendo lo suprimido, algo lento y difícil de demostrar. Y debe dejar registro de auditoría —qué, cuándo y sobre qué almacenes— sin que ese registro contenga el dato borrado.

Límites

Dos cosas que esto no resuelve. El mantenimiento del corpus es un compromiso continuo, no una fase: sin alguien responsable de las fuentes, el sistema se degrada aunque nadie toque el código, y en silencio, porque las métricas técnicas siguen bien mientras las respuestas empeoran. Y nada sustituye a la evaluación: sin preguntas con respuesta conocida ejecutadas tras cada reindexación, una sincronización rota la detecta antes un usuario que tú.

Qué viene ahora

Aquí se cierra el bloque del corpus. Con el material extraído, troceado, etiquetado y mantenido, el siguiente entra en las técnicas de recuperación, empezando por la línea base: el Naive RAG —embedding de la pregunta, búsqueda por similitud y respuesta— y los cuatro puntos en que se rompe siempre. Cada técnica posterior existe para arreglar uno de ellos, así que conviene tenerlos claros.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.