Mantener actualización, observabilidad y feedback

Un sistema RAG puede degradarse aunque el código no cambie. Se modifica el corpus, aparecen nuevas preguntas, cambian permisos, se sustituye una versión de modelo o una nueva política usa vocabulario distinto.

Operar RAG significa poder responder: qué fuente estaba activa, qué se recuperó, qué versión respondió, qué falló y cómo sabemos que el problema está resuelto.

Convierte cambios de fuente en eventos operativos

Define eventos para:

• alta;
• actualización;
• retirada;
• cambio de permiso;
• cambio de vigencia;
• fallo de sincronización.

Cada evento debe producir una operación verificable. Conserva identidad de la fuente, versión, estado y resultado de indexación.

Cuando sea posible, procesa de forma incremental. Pero la optimización no debe impedir consistencia: si un cambio afecta estructura global o permisos, quizá sea necesario regenerar más contenido.

Diseña operaciones idempotentes

Un evento repetido no debería crear duplicados ni restaurar una versión retirada. Usa identidades y estados que permitan repetir una sincronización con efecto controlado.

Después de un timeout, no asumas que nada ocurrió. Comprueba el estado y reconcilia.

La idempotencia operativa es especialmente útil en pipelines con colas, webhooks o procesos periódicos que pueden reenviar eventos.

Instrumenta el pipeline por fases

Una consulta atraviesa varias etapas:

entrada → autorización → transformación → recuperación → reranking → generación → citas → salida

Asigna un identificador de correlación y mide cada fase. OpenTelemetry distingue señales como traces, metrics y logs; puedes utilizar un estándar así o una alternativa equivalente.

Lo importante es poder reconstruir el recorrido sin almacenar indiscriminadamente información sensible.

Decide qué registrar y qué no

Para depuración puedes necesitar:

• versión de corpus;
• filtros;
• IDs de candidatos;
• posiciones;
• fragmentos enviados;
• versión de modelo;
• latencia;
• errores;
• citas.

Pero preguntas, contenido y respuestas pueden contener datos sensibles. Define minimización, acceso, retención y redacción.

En muchos casos es suficiente conservar identificadores y hashes para operación ordinaria y habilitar una captura más detallada bajo condiciones controladas.

Convierte feedback en casos de regresión

Un pulgar arriba o abajo no explica la causa. Ofrece categorías:

• fuente incorrecta;
• respuesta incompleta;
• dato obsoleto;
• cita incorrecta;
• permiso;
• no encontró respuesta;
• formato poco útil.

El feedback no debe modificar automáticamente el corpus ni «entrenar» el sistema. Primero se revisa y se decide qué capa cambia.

Cuando se confirma un fallo, añade la consulta y el resultado esperado al conjunto de regresión.

Monitoriza señales accionables

Algunas señales útiles:

• porcentaje de consultas sin resultados;
• abstenciones;
• errores de permiso;
• fuentes no sincronizadas;
• documentos nunca recuperados;
• documentos retirados que reaparecen;
• latencia por fase;
• coste por consulta;
• fallos por tipo;
• feedback confirmado.

No todo necesita una alerta. Una métrica es útil cuando existe una acción razonable asociada.

Prepara modos degradados

Define qué ocurre si falla:

• índice;
• modelo;
• reranker;
• sincronización;
• fuente principal.

Según el caso puedes pasar a búsqueda sin generación, mostrar solo documentos, bloquear respuestas nuevas o utilizar la última versión conocida.

El modo degradado debe preservar permisos y no presentar información obsoleta como actual sin advertencia.

Versiona la configuración que produjo cada respuesta

Una traza útil debería poder identificar, cuando proceda:

• versión del corpus;
• versión de la lógica de ingestión;
• configuración de búsqueda;
• modelo de embeddings;
• configuración de reranking;
• modelo generativo;
• versión del prompt o contrato;
• política de permisos.

No necesitas exponer todos esos datos al usuario, pero sí poder correlacionarlos internamente cuando aparece una regresión.

Define objetivos de servicio

Además de calidad, establece límites operativos:

• disponibilidad;
• latencia;
• tasa de error;
• coste;
• frescura del índice;
• tiempo máximo para propagar una retirada;
• tiempo de resolución de incidentes de acceso.

Un sistema puede contestar con buena calidad media y seguir siendo inaceptable si tarda demasiado en retirar información sensible o si la sincronización falla sin alertar.

Separa feedback de incidente

Una respuesta «poco útil» y una posible filtración de permisos no entran en la misma cola. Define severidad y rutas distintas.

Los incidentes de seguridad requieren contención y análisis inmediato. El feedback editorial puede seguir un ciclo de revisión y priorización. Esta separación evita que un riesgo crítico quede escondido entre mejoras de relevancia.

Ejercicio: runbook operativo

Crea un runbook para tres incidentes:

1. se detecta una política retirada en una respuesta;
2. un usuario reporta una cita de un documento no autorizado;
3. las abstenciones se duplican después de un cambio de índice.

Para cada uno define detección, contención, diagnóstico, responsable, rollback, prueba de corrección y actualización del benchmark.

Resultado de la lección

Debes terminar con un sistema observable y un circuito de mejora controlado. Una mala respuesta deja de ser una anécdota: puede rastrearse, clasificarse, corregirse y convertirse en una prueba que evite la regresión.