falla de manera predecible. La recuperación devuelve fragmentos defectuosos; el modelo alucina. Arreglas tu fragmentación y sigues adelante. La superficie de depuración es pequeña porque la arquitectura es simple: recuperar una vez, generar una vez y listo.
Agentic RAG falla de manera diferente porque la forma del sistema es diferente. No es un oleoducto. Es un bucle de control: planificar → recuperar → evaluar → decidir → recuperar de nuevo. Ese bucle es lo que lo hace poderoso para consultas complejas y es exactamente lo que lo hace peligroso en producción. Cada iteración es una nueva oportunidad para que el agente tome una mala decisión, y las malas decisiones se agravan.
Tres modos de falla aparecen repetidamente una vez que los equipos mueven el RAG agente más allá de la creación de prototipos:
Retrieval Thrash: el agente sigue buscando sin converger en una respuesta. Tormentas de herramientas: llamadas excesivas a herramientas que se suceden en cascada y se reintentan hasta que se agotan los presupuestos. Inflación de contexto: la ventana de contexto se llena con contenido de señal baja hasta que el modelo deja de seguir sus propias instrucciones.
Estos fallos casi siempre se presentan como “el modelo empeoró, pero la causa fundamental no es el modelo base”. Carece de presupuestos, reglas de detención débiles y nula observabilidad del ciclo de decisión del agente.
Este artículo desglosa cada modo de falla, por qué sucede, cómo detectarlo temprano con señales específicas y cuándo omitir por completo el RAG agente.
Qué es el RAG agente (y qué lo hace frágil)
Classic RAG recupera una vez y responde. Si la recuperación falla, el modelo no tiene mecanismo de recuperación. Genera el mejor resultado posible a partir de lo que regresó. Agentic RAG agrega una capa de control en la parte superior. El sistema puede evaluar su propia evidencia, identificar lagunas y volver a intentarlo.
El bucle del agente se ejecuta más o menos así: analiza la pregunta del usuario, crea un plan de recuperación, ejecuta la recuperación o las llamadas a herramientas, sintetiza los resultados, verifica si responden a la pregunta, luego se detiene y responde o retrocede para realizar otra pasada. Este es el mismo patrón recuperar → razonar → decidir descrito en las arquitecturas de estilo ReAct, y funciona bien cuando las consultas requieren razonamiento de múltiples saltos o evidencia dispersa entre fuentes.
Pero el bucle introduce una fragilidad fundamental. El agente optimiza localmente. En cada paso pregunta: “¿Tengo suficiente?” y cuando la respuesta es incierta, el valor predeterminado es “obtener más”. Sin reglas estrictas para detenerlo, el incumplimiento se dispara. El agente recupera, más, escala, recupera nuevamente, y cada paso quema tokens sin garantizar el progreso. El tutorial oficial de RAG de LangGraph tenía exactamente este error: un bucle de recuperación infinito que requería un límite de rewrite_count para solucionarlo. Si la implementación de referencia puede repetirse para siempre, los sistemas de producción ciertamente lo harán.
La solución no es un mensaje mejor. Se trata de presupuestar, controlar y mejorar las señales.
Taxonomía del modo de falla: qué se rompe y por qué
Retrieval Thrash: el bucle que nunca converge
El thrash de recuperación es el agente que recupera repetidamente sin decidirse por una respuesta. En los rastros, lo ve claramente: consultas casi duplicadas, términos de búsqueda oscilantes (ampliándose, luego estrechándose, luego ampliándose nuevamente) y una calidad de respuesta que se mantiene estable a lo largo de las iteraciones.
Un escenario concreto. Un usuario pregunta: “¿Cuál es nuestra política de reembolso para empleados remotos en California?” El agente recupera la póliza general de reembolso. Su verificador marca la respuesta como incompleta porque no menciona las reglas específicas de California. El agente reformula: “Reembolso por trabajo remoto de California”. Recupera un documento de recursos humanos relacionado tangencialmente. Todavía no estoy seguro. Vuelve a reformular: “Reembolso de gastos del código laboral de California”. Tres iteraciones más después, ha agotado su presupuesto de recuperación y la respuesta es apenas mejor que después de la primera ronda.
Las causas fundamentales son consistentes: criterios de detención débiles (el verificador rechaza sin decir qué falta específicamente), reformulación deficiente de la consulta (reformulación en lugar de apuntar a un espacio vacío), resultados de recuperación de señal baja (el corpus realmente no contiene la respuesta, pero el agente no puede reconocerla), o un bucle de retroalimentación donde el verificador y el recuperador oscilan sin converger. La orientación de producción de varios equipos converge en el mismo número: tres ciclos de recuperación de límites. Después de tres pases fallidos, devuelva una respuesta de mejor esfuerzo con un descargo de responsabilidad.
Tormentas de herramientas y aumento del contexto: cuando el agente se inunda a sí mismo
Las tormentas de herramientas y la inflación del contexto tienden a ocurrir juntas, y cada una empeora a la otra.
Una tormenta de herramientas ocurre cuando el agente realiza llamadas excesivas a herramientas: reintentos en cascada después de tiempos de espera, llamadas paralelas que devuelven datos redundantes o una estrategia de “llamar a todo para estar seguro” cuando el agente no está seguro. Una startup documentó que agentes hicieron 200 llamadas de LLM en 10 minutos, gastando entre 50 y 200 dólares antes de que alguien se diera cuenta. En otro caso, los costos aumentaron un 1700 % durante una interrupción del proveedor cuando la lógica de reintento se salió de control.
La inflación del contexto es el resultado posterior. Los resultados masivos de las herramientas se pegan directamente en la ventana contextual: JSON sin formato, resúmenes intermedios repetidos, memoria creciente hasta que la atención del modelo se dispersa demasiado para seguir las instrucciones. Las investigaciones muestran consistentemente que los modelos prestan menos atención a la información oculta en medio de contextos prolongados. El estudio “Lost in the Middle” de Stanford y Meta encontró caídas en el rendimiento de más de 20 puntos porcentuales cuando la información crítica se encuentra en el medio del contexto. En una prueba, la precisión del control de calidad de varios documentos en realidad cayó por debajo del rendimiento a libro cerrado con 20 documentos incluidos, lo que significa que agregar el contexto recuperado empeoró activamente la respuesta.
Las causas fundamentales: sin presupuestos ni límites de velocidad por herramienta, sin estrategia de compresión para los resultados de las herramientas y configuraciones de recuperación de “relleno de todo” que tratan el top 20 como un valor predeterminado razonable.
Cómo detectar estas fallas tempranamente
Puede detectar los tres modos de falla con un pequeño conjunto de señales. El objetivo es hacer visibles los fallos silenciosos antes de que aparezcan en su factura.
Señales cuantitativas para seguir desde el primer día:
Llamadas de herramientas por tarea (promedio y p95): los picos indican tormentas de herramientas. Investigar más de 10 llamadas; hard-kill por encima de 30. Iteraciones de recuperación por consulta: si la mediana es 1–2 pero p95 es 6+, tiene un problema de destrucción en las consultas difíciles. Tasa de crecimiento de la longitud del contexto: ¿cuántos tokens se agregan por iteración? Si el contexto crece más rápido que la evidencia útil, estamos hinchados. Latencia p95: la latencia de cola es donde se esconden las fallas de agente, porque la mayoría de las consultas terminan rápido mientras que algunas entran en espiral. Costo por tarea exitosa: la métrica más honesta. Penaliza los intentos desperdiciados, no sólo el coste medio por ejecución.
Rastros cualitativos: obliga al agente a justificar cada bucle. En cada iteración, registre dos cosas: “¿Qué nueva evidencia se obtuvo?” y “¿Por qué esto no es suficiente para responder?” Si las justificaciones son vagas o repetitivas, el bucle se agita.
Cómo se asigna cada falla para señalar picos: la recuperación se muestra como iteraciones que aumentan mientras la calidad de la respuesta se mantiene estable. Las tormentas de herramientas se manifiestan a medida que el recuento de llamadas aumenta junto con los tiempos de espera y los aumentos de costos. La inflación del contexto se muestra a medida que los tokens de contexto aumentan mientras que el seguimiento de instrucciones se degrada.
Reglas de Tripwire (establecidas como límites estrictos): máximo 3 iteraciones de recuperación; máximo de 10 a 15 llamadas a herramientas por tarea; un límite de token de contexto relativo a la ventana efectiva de su modelo (no su máximo declarado); y un reloj de pared con hora en cada carrera. Cuando se activa un cable trampa, el agente se detiene limpiamente y devuelve su mejor respuesta con incertidumbre explícita, sin más reintentos.
Mitigaciones y marco de decisión
Cada modo de falla se asigna a mitigaciones específicas.
Para thrash de recuperación: limite las iteraciones a tres. Agregue un “umbral de evidencia nueva”: si la última recuperación no revela contenido significativamente diferente (medido por similitud con resultados anteriores), deténgase y responda. Restringir la reformulación de modo que el agente deba centrarse en una brecha identificada específica en lugar de simplemente reformularla.
Para tormentas de herramientas: establezca presupuestos por herramienta y límites de tarifas. Deduplicar resultados entre llamadas a herramientas. Agregue alternativas: si una herramienta se agota dos veces, use un resultado almacenado en caché u omítala. Los equipos de producción que utilizan enrutamiento basado en intención (clasificando la complejidad de las consultas antes de elegir la ruta de recuperación) reportan reducciones de costos del 40 % y mejoras de latencia del 35 %.
Para el aumento del contexto: resuma los resultados de las herramientas antes de inyectarlos en el contexto. Una respuesta API de 5000 tokens se puede comprimir a 200 tokens de resumen estructurado sin perder señal. Limite top-k entre 5 y 10 resultados. Deduplicar fragmentos de manera agresiva: si dos fragmentos comparten más del 80% de superposición semántica, conserve uno. LLMLingua de Microsoft logra una compresión rápida de hasta 20 veces con una pérdida mínima de razonamiento, lo que aborda directamente la hinchazón en los canales de agentes.
Políticas de control que se aplican en todas partes: cronometrar cada ejecución. Agregue un modo de “respuesta final requerida” que se activa cuando se alcanza cualquier presupuesto, lo que obliga al agente a responder con cualquier evidencia que tenga, junto con marcadores de incertidumbre explícitos y próximos pasos sugeridos.
La regla de decisión es simple: use RAG agente solo cuando la complejidad de la consulta sea alta y el costo de equivocarse sea alto. Para preguntas frecuentes, búsquedas de documentos y extracción sencilla, el RAG clásico es más rápido, más económico y mucho más fácil de depurar. Si la recuperación de un solo paso falla habitualmente en sus consultas más difíciles, agregue un segundo paso controlado antes de volverse totalmente agente.
Agentic RAG no es un RAG mejor. Es RAG más un circuito de control. Y los bucles de control exigen presupuestos, reglas de parada y seguimientos. Sin ellos, estará enviando un flujo de trabajo distribuido sin telemetría y la primera señal de falla será su factura de la nube.