Una cita puede existir y apuntar a una regla retirada. Para evitarlo, un sistema de generación aumentada con recuperación, o RAG, necesita saber qué versión puede utilizar, además de encontrar pasajes relacionados con la pregunta.
Esta guía propone un diseño de actualización y retirada para equipos que ya tienen documentos fragmentados, un buscador y una aplicación que genera respuestas. Usa Azure AI Search como referencia documental, consultada el 16 de octubre de 2026. Es una propuesta de arquitectura con un ejemplo hipotético, no una integración desplegada ni un experimento de Puntoes. Las operaciones descritas deben adaptarse y probarse antes de aplicarlas a datos reales.
1. Separar identidad, versión y vigencia
Mantén tres identificadores: el documento lógico, una versión inmutable y cada fragmento de esa versión. Por ejemplo, el fragmento segundo del manual de devoluciones v4 debe distinguirse del segundo de v3. Conserva también la referencia al original y una huella de contenido para detectar cambios.
Propongo un registro de autoridad, separado de los resultados del buscador, con versiones preparadas, activas o retiradas. Distingue fecha del documento, fecha de incorporación y periodo de vigencia. Para este último, define límites inequívocos: desde una fecha incluida hasta otra excluida, con zona horaria normalizada.
Una fecha de descarga reciente no convierte un manual antiguo en vigente. Si la fuente carece de versiones o fechas fiables, alguien debe resolver esa ambigüedad antes de automatizar la elección. Los permisos del usuario siguen siendo un control adicional: estar vigente no autoriza a cualquier persona a leerlo.
2. Preparar la nueva versión antes de activarla
Genera todos sus fragmentos y comprueba cobertura, referencias y respuestas esperadas con la versión aún preparada. No actives un documento porque haya terminado una petición de carga.
En Azure AI Search, las actualizaciones se indexan en segundo plano. Hay que revisar el resultado de cada elemento y consultar después para comprobar su disponibilidad. Durante una actualización pueden observarse resultados mezclados.
Además, actualizar o insertar tres claves nuevas no elimina otras cinco anteriores. Si cambias la identidad de los fragmentos, necesitas inventariar cuáles deben retirarse. Cuando cambie el esquema o sea preferible reconstruir, puedes preparar otro índice en paralelo. Un alias de Azure AI Search permite dirigir las consultas a un índice distinto, pero no puede utilizarse como destino del indexador. Tampoco coordina por sí solo tu registro de versiones y tus cachés.
3. Elegir la evidencia antes de entregarla al modelo
Al iniciar la consulta, resuelve una instantánea de las versiones permitidas para esa fecha y usuario. Aplica ese criterio en todas las vías de recuperación utilizadas, tanto textual como vectorial, y comprueba cada resultado antes de formar el contexto.
En Azure, los metadatos necesarios deben estar configurados para admitir filtros. La documentación de filtrado vectorial distingue el filtrado durante la búsqueda del filtrado posterior; este último puede perder resultados con filtros selectivos. Ninguna modalidad corrige metadatos desactualizados.
Propongo revalidar la instantánea antes de devolver la respuesta: si una versión ha sido retirada durante la generación, descarta el resultado y repite o comunica que falta evidencia vigente. Hay que definir qué ocurre si el registro no responde; para respuestas sensibles, impedir la entrega es una opción prudente. Esta comprobación reduce la ventana de incoherencia, pero no crea una transacción entre servicios ni recupera respuestas ya entregadas.
4. Retirar primero, limpiar después
Registra la retirada de forma duradera y bloquea esa versión en las consultas antes de completar la limpieza física. Después elimina sus fragmentos y comprueba que no quedan huérfanos. Repetir un evento de retirada debe producir el mismo estado final, sin reactivar contenido.
No supongas que borrar el original borra el índice. Los indexadores de Azure Storage necesitan una estrategia de detección de borrados. Añadirla después no limpia automáticamente los documentos huérfanos anteriores. La opción nativa de borrado recuperable de blobs tiene condiciones propias, entre ellas no tener activado el versionado de blobs y conservarlos suficiente tiempo para que el indexador procese la retirada. Revisa esas condiciones antes de elegirla; no cambies el almacenamiento solo para encajar en este ejemplo.
5. Comprobar respuestas y cachés con un caso pequeño
Ejemplo ficticio, no ejecutado: un manual interno v3 tiene cinco fragmentos y menciona 30 días; v4 tiene tres y menciona 14. Esos plazos no representan condiciones comerciales reales. Si ambas versiones siguen recuperables, el modelo podría mezclar reglas incompatibles.
Prepara estas pruebas de aceptación en un entorno de ensayo:
- Con v4 activa, preguntar por el plazo actual debe recuperar y citar v4.
- Si falla la carga de uno de sus fragmentos, v4 no debe activarse parcialmente.
- Retirar el manual sin sucesor debe provocar abstención por falta de evidencia vigente.
- Repetir el evento de retirada no debe alterar ese estado.
- Repetir una pregunta almacenada en caché no debe devolver la respuesta de v3.
Incluye la instantánea de versiones y el contexto de autorización en la identidad de las cachés de recuperación y respuesta. Invalida también citas y resultados derivados al retirar evidencia. Un tiempo de caducidad es un respaldo; por sí solo permite servir contenido antiguo hasta que venza.
Si necesitas consultas históricas, hazlas explícitas, con fecha y permisos comprobados; no mezcles ese modo con la respuesta vigente. Registra versiones, huellas y decisiones para investigar fallos, minimizando el contenido sensible guardado.
El coste de mantener dos índices puede ser innecesario si una actualización incremental cumple la tolerancia demostrada del servicio. El criterio de aceptación es poder explicar qué versión respaldó una respuesta y comprobar su retirada. Eso complementa la evaluación de recuperación y fidelidad; no garantiza que el documento original diga la verdad.