El RAG no se rompe: se degrada
Publicado el
Un sistema de recuperación no falla de golpe. Pierde calidad despacio, y por eso nadie lo mira hasta que ya es tarde.
Hay una idea cómoda que conviene desmontar: que montar un sistema RAG (recuperación aumentada por generación, el patrón que conecta un modelo de lenguaje a tus documentos) es el proyecto. No lo es. Montarlo es el día uno. El proyecto de verdad empieza cuando ya funciona y nadie lo mira.
Un buen artículo en Hacker News lo plantea bien: los sistemas RAG en producción no se caen, se degradan. La diferencia importa. Una caída se ve, dispara una alerta, alguien acude. La degradación es silenciosa. Las respuestas siguen llegando, siguen pareciendo correctas, y la calidad baja un grado cada semana sin que ningún panel se ponga rojo.
Por qué empeora solo
La causa no es un bug. Es el tiempo.
El corpus crece. Lo que el día uno eran mil documentos limpios, a los seis meses son veinte mil, con duplicados, versiones viejas que contradicen a las nuevas y notas que nadie debió indexar. El recuperador, que antes acertaba porque había poco donde elegir, ahora tiene que distinguir entre cinco respuestas parecidas y a veces escoge la obsoleta.
Las preguntas también cambian. Los usuarios aprenden a usar la herramienta y le piden cosas para las que no se diseñó. El sistema que respondía bien a “¿cuál es la política de vacaciones?” empieza a recibir “¿puedo encadenar vacaciones con una baja?”, y ahí la recuperación simple ya no basta.
Y luego está lo invisible: un cambio en el modelo de embeddings, una actualización del proveedor, un reajuste del prompt que alguien hizo “para mejorar otra cosa”. Cada pieza se mueve por su cuenta. El conjunto deriva.
El error de marco
Casi todo el mundo trata esto como un problema de ingeniería. Mejor chunking, mejor reranker, otra base vectorial. Son mejoras reales, pero atacan el síntoma.
El problema de fondo es de gobierno. Un sistema RAG es un activo vivo que consume documentación, decisiones y contexto de la empresa, y los devuelve transformados a quien toma decisiones. Eso no es una librería que se instala. Es un proceso que hay que mantener, medir y rendir cuentas, igual que la contabilidad o el control de calidad.
La pregunta correcta no es “¿qué arquitectura uso?”. Es “¿quién es responsable de que esto siga siendo fiable dentro de un año?”. Si la respuesta es nadie, el sistema ya está degradándose, solo que todavía no lo sabes.
Lo que sí se puede hacer
Tres decisiones, ninguna técnica.
Primero, medir la fiabilidad como métrica de negocio, no de laboratorio. No basta con evaluaciones del día del lanzamiento. Hace falta una muestra continua de preguntas reales revisadas por personas que conozcan las respuestas correctas. Lento, pero es la única señal honesta.
Segundo, dar dueño al corpus. Alguien tiene que decidir qué entra, qué caduca y qué se retira. Un documento que nadie poda es deuda que crece.
Tercero, aceptar que la fiabilidad cuesta dinero de forma recurrente. Un RAG no es un gasto de capital que se amortiza, es un gasto operativo que se paga siempre. Quien lo presupueste como una obra terminada se llevará la sorpresa.
Construyo en abierto y esto lo veo en mi propio sistema: la parte difícil nunca fue conectar el modelo a mis notas, fue que las notas siguieran mereciendo la pena meses después. La tecnología fue el viernes por la tarde. El mantenimiento es el lunes, y todos los lunes siguientes.
La pregunta que dejaría sobre la mesa de cualquier comité que esté desplegando IA interna: ¿tenéis un plan para el día 200, o solo para el día uno?