Cómo mantener actualizado un corpus RAG y comprobar que los documentos antiguos dejan de aparecer

Mantener el corpus no es evaluar las respuestas

Un corpus RAG se mantiene cuando el contenido disponible para recuperación sigue correspondiendo a las fuentes que el equipo considera válidas. El trabajo comprende identificar documentos y versiones, procesar los cambios, actualizar las unidades indexadas y verificar el resultado. Es una tarea distinta de evaluar si el modelo redacta una respuesta correcta o si la fundamenta bien en los fragmentos recuperados. Ambas evaluaciones pueden relacionarse, pero no son intercambiables: una prueba de recuperación puede revelar que sigue apareciendo un documento retirado, aunque la respuesta generada parezca razonable.

La documentación aportada de Microsoft describe la creación de una canalización de datos no estructurada para aplicaciones de IA. La documentación de Google Cloud trata la administración de un corpus RAG e indica, según la información disponible, que abarca crear un corpus e importar o subir documentos. Estas referencias sirven como contexto sobre procesamiento e incorporación, pero la información disponible no confirma un procedimiento universal para actualizar o borrar documentos. Por eso, los pasos siguientes son un diseño operativo adaptable, no una afirmación de que una función concreta exista en cualquier producto.

El objetivo práctico es poder contestar preguntas sobre el estado del contenido: qué fuente originó un fragmento, qué versión se procesó, si hubo un fallo parcial y qué prueba demuestra que una retirada surtió efecto. Si el equipo no puede responderlas, no debería tratar el corpus como actualizado solo porque terminó una ejecución de procesamiento.

Inventariar las fuentes antes de automatizar

Empieza por enumerar las fuentes que pueden alimentar el corpus y asignar a cada una un responsable. Una fuente puede ser un repositorio de documentación interna, un catálogo, un conjunto de normas o una colección de archivos. El inventario no necesita depender de un producto específico, pero sí debe permitir distinguir cada origen y saber quién decide si el contenido se incorpora, cambia o se retira.

Para cada documento, conserva un identificador estable si el sistema de origen lo ofrece. Registra también la ubicación o colección de origen, el propietario, una fecha o versión verificable y el estado del documento, por ejemplo, activo, pendiente de procesamiento o retirado. Si no existe una versión formal, se puede registrar una señal de cambio disponible en el origen, siempre que el equipo documente qué significa y cuáles son sus límites. No presupongas que una fecha de modificación basta para distinguir dos contenidos idénticos o dos revisiones distintas.

Relaciona esas propiedades con cada unidad derivada que se indexa, como un fragmento o registro. La finalidad es poder localizar todas las unidades procedentes de una fuente cuando esta cambie o se retire. Si el mecanismo de indexación no permite almacenar metadatos o no documenta cómo filtrar y retirar registros, anótalo como una limitación que debe probarse; no des por hecho que el borrado del archivo de origen elimina automáticamente sus derivados.

Define también las reglas de incorporación y retirada. Por ejemplo, especifica quién autoriza que un documento pase a activo, qué significa una sustitución y cómo se resuelven fuentes contradictorias. Son decisiones de gobernanza del equipo, no propiedades inherentes a RAG. Dejarlas escritas evita que una actualización técnica determine por accidente qué versión debe considerarse válida.

Decidir qué cambios reprocesar

No todo cambio tiene por qué producir el mismo trabajo. Una corrección localizada podría requerir procesar un documento; un cambio en las reglas de extracción o en la forma de dividir el texto podría afectar a una colección completa. Una modificación de la configuración que transforme la representación almacenada podría justificar una reconstrucción más amplia. Estas son categorías de decisión: antes de aplicarlas, hay que comprobar qué componentes utiliza la pila y qué operaciones soporta.

Escribe una política que vincule las señales de cambio con el alcance del reprocesamiento. Por ejemplo: una nueva versión identificada en el origen activa el reprocesamiento de ese documento; un cambio global de extracción activa una revisión de la colección afectada; una duda sobre la consistencia del conjunto puede activar una reconstrucción de prueba. No conviertas estos ejemplos en automatismos sin validar primero la identidad de los documentos, la capacidad de eliminación y el comportamiento de la herramienta.

La canalización descrita por Microsoft puede servir de referencia general para pensar el procesamiento de datos no estructurados, pero la información disponible no especifica qué operaciones de actualización incremental, sincronización o eliminación implementa. Del mismo modo, la referencia de Google Cloud sobre administración del corpus confirma la temática de creación e importación, pero no permite concluir qué condiciones aplica para modificar o borrar registros. El comportamiento real debe comprobarse en la documentación de la pila elegida y mediante pruebas controladas.

Diseñar el ciclo de altas y modificaciones

Un ciclo de actualización puede organizarse en etapas explícitas. Primero se detecta una fuente nueva o un cambio mediante una señal disponible en el sistema de origen. Después se registra la versión observada y se valida que el documento sea admisible según las reglas del equipo. A continuación se extrae el contenido, se procesa con la configuración acordada y se conservan metadatos que permitan rastrearlo hasta su fuente.

Antes de publicar el resultado, decide cómo tratar la transición entre versiones. Una estrategia posible es preparar y comprobar la nueva versión antes de hacerla disponible, si la plataforma permite mantenerla separada. Otra posibilidad es sustituir el contenido directamente y verificarlo después. No se debe afirmar que una de estas estrategias es siempre superior: depende de las funciones documentadas, de la tolerancia del sistema a una interrupción y de cómo se gestione el estado parcial.

El registro de ejecución debería reflejar, como mínimo, la fuente y versión objetivo, la fecha de detección, el alcance previsto, el estado de cada etapa y el resultado de las verificaciones. Si el proceso se interrumpe, esa información ayuda a distinguir entre una fuente que no se detectó, una extracción fallida y una actualización que se aplicó solo en parte. Evita marcar como vigente una versión únicamente porque comenzó su procesamiento.

Incluye un criterio de finalización observable. Por ejemplo, la operación no pasa a completada hasta que se comprueba que las unidades esperadas son recuperables y que la versión anterior ya no aparece cuando debe haber sido sustituida. El criterio debe ser viable con la herramienta concreta. Si esta no ofrece una forma de comprobarlo, registra esa limitación y diseña una prueba externa de recuperación.

Gestionar bajas y sustituciones sin dejar restos

Retirar un archivo del origen y retirar sus representaciones del índice son acciones distintas, salvo que la integración concreta documente y demuestre lo contrario. Una baja puede dejar fragmentos, copias derivadas o registros repetidos si no se identifica todo lo que procede de la fuente. Por eso, la relación entre identificador de fuente y unidades indexadas debe diseñarse antes de que ocurra la primera retirada.

Para una sustitución, registra qué versión deja de ser válida y cuál debe ocupar su lugar. Comprueba que la nueva versión se procesa correctamente y que la anterior deja de aparecer en las búsquedas donde antes era pertinente. Si las dos versiones deben coexistir por una razón legítima, establece cómo distinguirlas y qué estado tiene cada una. No las presentes como equivalentes si la política de la fuente las considera incompatibles.

La baja debe dejar evidencia: fuente retirada, momento de la solicitud, responsable, unidades afectadas o alcance de la operación, resultado y consultas de prueba. Si la operación falla, conserva un estado pendiente o fallido y evita presentar el corpus como plenamente actualizado. La recuperación puede consistir en reintentar, reconstruir una parte o escalar el problema; la elección depende de las capacidades disponibles y debe quedar registrada.

No hay en las fuentes aportadas confirmación suficiente para afirmar que una plataforma específica elimine de forma automática todos los fragmentos derivados al borrar un documento. La conversación de Reddit incluida como fuente es anecdótica y no permite establecer un comportamiento garantizado. Verifica las funciones de eliminación en la documentación oficial del producto concreto y, sobre todo, comprueba el resultado con una prueba reproducible.

Controlar actualizaciones parciales y fallos

Un proceso de actualización puede detenerse después de detectar el cambio, durante la extracción o tras modificar solo una parte del índice. El diseño operativo debe hacer visible esa diferencia. Define estados sencillos, como pendiente, procesando, completado y fallido, y especifica qué significa cada uno. Si el equipo necesita registrar etapas más precisas, puede añadirlas siempre que los operadores entiendan cómo se relacionan.

Decide qué contenido se considera disponible mientras una actualización está incompleta. En algunos sistemas puede ser posible conservar la versión anterior hasta validar la nueva; en otros, la actualización puede producir una ventana de indisponibilidad o resultados mezclados. No prometas atomicidad ni sustitución sin interrupciones a menos que la documentación de la plataforma lo confirme y una prueba lo verifique.

Establece una política de reintentos que no cree duplicados. Antes de reejecutar un proceso, comprueba si la operación anterior dejó unidades parciales y cómo identificarlas. Si no puedes determinarlo, trata el resultado como incierto y evita una segunda escritura a ciegas. Registra el alcance, la decisión tomada y la prueba posterior, de manera que otro operador pueda reconstruir qué versión estaba disponible.

Elegir entre actualización incremental y reconstrucción

La actualización incremental limita el trabajo a documentos o colecciones afectados; puede ser adecuada cuando el sistema permite identificar con precisión cada fuente y retirar o sustituir sus derivados. La reconstrucción vuelve a procesar un conjunto más amplio y puede facilitar una comprobación integral, pero también puede requerir más tiempo y recursos. Estas son consideraciones generales de operación, no garantías de rendimiento ni descripciones de una herramienta determinada.

Compara ambas opciones con datos del entorno: volumen de fuentes, frecuencia de cambios, duración observada, coste de procesamiento, facilidad de identificar los elementos afectados y consecuencias de una actualización incompleta. Añade la capacidad documentada de la pila para actualizar, borrar, consultar estados y restaurar una versión anterior. Si una capacidad esencial no está confirmada, inclúyela como incertidumbre que se debe resolver antes de automatizar.

No elijas lo incremental solo porque parezca más barato, ni reconstruyas automáticamente ante cualquier cambio. La decisión depende de si se puede acotar el impacto y demostrar la consistencia del resultado. Una prueba de reconstrucción en un entorno controlado puede ayudar a estimar tiempo y detectar diferencias; no demuestra por sí sola que una reconstrucción en producción sea segura.

Probar que el corpus refleja el estado esperado

Las pruebas de aceptación deben comprobar el comportamiento del corpus, no solo que una tarea técnica terminó sin error. La información aportada sobre la creación de corpus orientados a RAG y su uso en evaluación respalda la pertinencia de diseñar comprobaciones para sistemas RAG, pero no prescribe aquí una batería concreta ni un umbral universal. Las consultas y los criterios deben derivarse de las fuentes y de los riesgos de cada aplicación.

Construye un conjunto pequeño y estable de consultas. Incluye consultas que deberían recuperar una versión actual, consultas distintivas de una fuente retirada y consultas sobre documentos no relacionados que deben seguir disponibles. Registra qué fuente y versión se esperan, qué resultado se observó y cuándo se ejecutó la prueba. Si la recuperación depende de orden, umbrales u otros ajustes, anota la configuración relevante para poder interpretar cambios entre ejecuciones.

Añade pruebas de duplicados y conflictos. Una búsqueda puede devolver la versión antigua y la nueva, dos copias del mismo documento o fragmentos que no conservan suficiente procedencia para distinguirlas. Define qué resultados son aceptables: por ejemplo, una sola versión activa cuando la política exige exclusividad, o ambas versiones claramente identificadas cuando la coexistencia está autorizada.

Una prueba negativa —no recuperar una fuente retirada— requiere cuidado: que no aparezca en una consulta concreta no demuestra que haya desaparecido de todo el índice. Usa varias consultas representativas y, si la herramienta lo permite, inspecciona los registros asociados al identificador de fuente. Expresa el alcance real de la comprobación y evita convertir una muestra en una garantía absoluta.

La evaluación de la recuperación tampoco determina por sí sola si el modelo redacta una respuesta correcta. Si el equipo también necesita valorar la respuesta final, debe mantener un conjunto de pruebas separado, con criterios apropiados para esa tarea. Así se puede distinguir un problema de vigencia del corpus de un problema de generación o de uso de contexto.

Rutina periódica y límites de la evidencia

Una rutina periódica debería revisar cambios pendientes, ejecuciones fallidas, fuentes sin responsable, versiones cuya vigencia no se ha confirmado y pruebas de aceptación no ejecutadas. La frecuencia depende del ritmo de cambio y del riesgo: una colección normativa puede exigir controles más frecuentes que un archivo de consulta ocasional. No existe en las fuentes aportadas una periodicidad universal; cada equipo debe justificar la suya.

Revisa también si las reglas de extracción o procesamiento cambiaron desde la última actualización y si ese cambio obliga a reprocesar documentos anteriores. Comprueba que los identificadores y metadatos siguen llegando hasta las unidades recuperadas. Si no es posible reconstruir qué fuente y versión contribuyeron a una prueba, prioriza corregir esa falta de trazabilidad antes de ampliar la automatización.

Las fuentes disponibles tienen un alcance limitado. La documentación de Microsoft confirma el tema de canalizaciones de datos no estructurados para IA; la de Google Cloud, la administración e importación de documentos en un corpus RAG; y el artículo del Instituto de Ingeniería del Conocimiento, la creación de corpus para RAG y su uso en evaluación. Ninguno de los fragmentos aportados confirma el comportamiento exacto de una plataforma para bajas, sustituciones, transacciones, reconstrucciones o actualizaciones incrementales. Esas funciones deben verificarse en la documentación vigente del producto y en pruebas del entorno real.

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.