Un cliente de manufactura tenía una base de conocimiento: 8 000 manuales técnicos, protocolos de servicio y planos. Desplegaron RAG clásico — embed, recuperar top-5, generar. Para preguntas del tipo «¿cuáles son los parámetros del motor X?» funcionaba con un 85 % de precisión. Luego llegó la pregunta: «¿Qué debo hacer cuando el motor X reporta el error E47 y al mismo tiempo la temperatura supera los 80 °C?». El sistema devolvió un fragmento sobre el error E47 y un fragmento sobre la temperatura — pero nunca concretó que la combinación de ambos estados requiere un procedimiento distinto al de cada uno por separado. La respuesta era técnicamente correcta, operativamente inútil.
Esta es la clase de problemas para la que el RAG clásico no tiene solución arquitectónica. No es cuestión de un mejor modelo de embeddings ni de un chunk más grande. Es cuestión de quién controla la recuperación — y cuándo sabe que necesita recuperar más.
Dónde choca el RAG clásico con su techo
El RAG clásico (Retrieval-Augmented Generation) trabaja en un único paso de recuperación: llega la pregunta, el sistema indexa la consulta, recupera los top-K fragmentos de la base de datos vectorial y los entrega al LLM. Es determinista, rápido y barato.
El problema aparece con cuatro tipos de tareas:
- Preguntas multi-paso — la respuesta depende de dos o más hechos que están en documentos separados y cuya conexión no es explícita en el texto. El RAG clásico ejecuta un único paso de recuperación; el LLM recibe solo parte del contexto.
- Consultas ambiguas o incompletas — el usuario escribe «problemas de refrigeración en la línea 3», pero el sistema no sabe si se refiere a la refrigeración del motor, la hidráulica o el aire acondicionado del pabellón. Un único paso de recuperación no resuelve la ambigüedad.
- Preguntas que requieren comparación — «compara los intervalos de mantenimiento del equipo A y el B» requiere dos operaciones de recuperación independientes y su síntesis, no una sola recuperación con la esperanza de que ambos documentos acaben en el top-5.
- Análisis iterativos — el agente debe averiguar primero algo básico (p. ej. el número de serie del equipo), luego recuperar la documentación específica en base a eso y después verificar la vigencia de la información frente a la fecha de fabricación. Cada paso depende del resultado del anterior.
Para estos escenarios se necesita una arquitectura distinta: una en la que la recuperación no sea una acción puntual, sino un proceso iterativo guiado por un agente.
Qué hace diferente el Agentic RAG
El Agentic RAG añade una capa de toma de decisiones sobre el pipeline clásico de recuperación y generación. El agente — típicamente un LLM con acceso a herramientas — recibe la pregunta y decide por sí mismo:
- 1.Qué consulta enviar a la base de datos vectorial
- 2.Si los resultados son suficientes o hay que recuperar más
- 3.Qué nueva consulta formular en base a lo que ha obtenido hasta ese momento
- 4.Cuándo el contexto está completo y puede generar la respuesta
En lugar de un único ciclo recuperar-y-generar, se forma un bucle en el que el agente evalúa sus propios resultados intermedios. En la práctica puede verse así: el agente recibe la pregunta sobre la combinación de error y temperatura, formula la primera consulta sobre el error E47, lee los resultados, decide que necesita contexto sobre los límites de temperatura, formula una segunda consulta, obtiene los documentos, sintetiza ambos contextos y solo entonces genera la respuesta.
Este enfoque tiene tres mecanismos clave que el RAG clásico no tiene.
Query rewriting — reformulación de la consulta
La entrada del usuario rara vez coincide con el lenguaje en que están escritos los documentos. El manual técnico habla de «sobrecalentamiento del circuito hidráulico»; el usuario escribe «el aceite está muy caliente». El query rewriting deja que el LLM transforme la consulta original a una forma que se ajuste mejor al espacio vectorial de los embeddings.
Esto también forma parte de los pipelines RAG clásicos más avanzados — no es una propiedad exclusiva del Agentic RAG. La diferencia es que en el Agentic RAG el query rewriting puede repetirse en cada paso: el agente ve lo que ha recuperado y reformula la consulta a partir del resultado intermedio, no solo de la pregunta original.
Multi-step retrieval — recuperación escalonada
El agente puede recuperar varias veces, y cada paso informa al siguiente. Esto resuelve el problema de la «conexión oculta» — cuando la respuesta está distribuida entre documentos que no tienen relaciones semánticas explícitas, pero cuya combinación es relevante.
Desde el punto de vista práctico, la implementación se parece a un agente ReAct donde «buscar en la base de conocimiento» es una herramienta. El agente la llama tantas veces como considere necesario, con consultas distintas. Encontrarás más sobre la arquitectura del bucle agentivo en el artículo sobre arquitecturas de agentes de IA.
Self-correction — corrección de resultados intermedios
La característica más sofisticada del Agentic RAG. El agente no solo recupera, sino que evalúa si la información recuperada es relevante, está actualizada y es suficiente. En implementaciones más avanzadas se añade un faithfulness judge independiente — una llamada LLM adicional que comprueba si la salida generada está respaldada por los documentos recuperados y no es alucinada.
Este es el punto donde mucha gente subestima la complejidad: un Agentic RAG ingenuo sin faithfulness judge puede alucinar más que el RAG clásico. La razón es simple — contexto más largo, más pasos de recuperación, mayor espacio para que el modelo genere texto plausible pero sin respaldo.
Cuándo desplegar Agentic RAG — marco de decisión
No todo caso de uso RAG requiere una capa agentiva. Este es el marco de decisión de la práctica real.
Quédate con el RAG clásico si: - La mayoría de las preguntas son directas (un documento = respuesta completa) - La latencia es crítica (chatbot interactivo donde la respuesta debe llegar en 2 segundos) - El volumen de consultas es alto y el coste es el factor limitante - La base de conocimiento está definida de forma acotada y las preguntas no salen de su marco
Pasa a Agentic RAG si: - Más del ~20 % de las consultas requieren información de varios documentos - Los usuarios formulan preguntas multi-paso o comparativas - La respuesta depende de un estado o contexto que no está en la consulta original - La precisión es más importante que la latencia (soporte a la decisión, protocolos de seguridad) - Tienes capacidad para implementar y monitorizar el pipeline agentivo
En despliegues de producción hemos comprobado que, para sistemas de conocimiento sobre documentación técnica (manuales de servicio, normas, procedimientos), el Agentic RAG mejora notablemente la calidad de las respuestas en preguntas multi-paso — pero a costa de unos 5–10× más de tokens y una latencia 3–5× mayor respecto al enfoque clásico. Este no es un coste que pagues en cada consulta, pero debes tenerlo en cuenta en la decisión arquitectónica.
El coste adicional: no solo tokens
El Agentic RAG es más caro que el RAG clásico en varios ejes, y los tokens son solo uno de ellos.
Costes de tokens: donde el RAG clásico consume ~500–1 000 tokens por consulta, un Agentic RAG con 3–4 pasos de recuperación y faithfulness judge puede consumir 5 000–15 000 tokens. Con modelos baratos (tier Flash/Haiku, del orden de $0,10–0,50 por 1M tokens de entrada) la diferencia es manejable. Con modelos frontier de la clase Claude Opus o GPT-5, el coste de una consulta agentiva es del orden de céntimos a decenas de céntimos — a alto volumen, no es despreciable.
Latencia: cada paso de recuperación añade tiempo — llamada LLM para el query rewriting, llamada a la base de datos vectorial, y eventualmente el faithfulness judge. Los pipelines Agentic RAG reales con 3–5 pasos tardan 5–20 segundos. Para aplicaciones interactivas esto requiere diseño asíncrono y retroalimentación visual (indicador de progreso, streaming).
Sobrecarga de implementación y observabilidad: el RAG clásico es una función de 50 líneas. El Agentic RAG es un pipeline con checkpointing, lógica de reintentos, monitorización y herramientas de depuración. Sin herramientas de observabilidad como Langfuse (self-hostable) o Arize Phoenix se vuelve casi inmantenible. Un agente multi-paso sin trazas es una caja negra — cuando falla, no sabes por qué. Encontrarás más sobre observabilidad en agentes en el artículo sobre observabilidad y tracing.
Sobrecarga de reintentos: los agentes fallan — una consulta de recuperación mal formulada, un timeout de base de datos, un formato de resultado inesperado. En sistemas de producción la tasa de reintento habitual es del 10–15 %, lo que aumenta eficazmente el número de llamadas. Esta sobrecarga debe incluirse en el modelo de costes.
Patrones de implementación en la práctica
Existen dos enfoques dominantes para implementar el Agentic RAG.
Patrón 1: agente ReAct con herramienta de recuperación
La forma más sencilla — un agente ReAct estándar donde una de las herramientas es search_knowledge_base(query: str) -> list[Document]. El agente decide cuándo y cómo llama a la herramienta, ve los resultados en la fase Observe y continúa en consecuencia. La implementación vía LangGraph con estado explícito es hoy el estándar para sistemas de producción.
Ventaja: relativamente sencillo de implementar, el agente es flexible. Desventaja: sin faithfulness judge el agente puede alucinar con confianza; la fiabilidad de las salidas es variable.
Patrón 2: agente RAG dedicado con bucle de evaluación
Un enfoque más sofisticado: recuperar → verificación de faithfulness → si no es suficiente, reformular la consulta y repetir → solo cuando el faithfulness score supera el umbral, generar la respuesta final. Esto se acerca más al patrón SELF-RAG o CRAG (Corrective RAG).
Detalle de implementación: el faithfulness judge es una llamada LLM independiente con un prompt que recibe el chunk y la respuesta generada y debe responder si la respuesta está respaldada por el chunk. Típicamente basta con un modelo más barato (tier Haiku) como judge — no se necesita el modelo más potente para una evaluación binaria. El resultado es medible y loggeable, lo que es clave para la auditoría y el ajuste.
Lo que nos ha enseñado la práctica: el error más frecuente en la primera implementación de Agentic RAG no es técnico — es de producto. El equipo despliega el pipeline agentivo completo para cada consulta, sin distinguir entre preguntas directas simples y preguntas complejas. El resultado: el sistema entero es lento y caro, aunque el 60 % de las consultas las resolvería el RAG clásico de forma más barata y rápida.
Recomendación de la práctica: un router antes de entrar al pipeline. Un LLM o un clasificador simple evalúa la complejidad de la consulta y la redirige bien al RAG clásico rápido, bien al pipeline agentivo. Esto mejora notablemente la relación coste/calidad con carga real. La decisión entre RAG y fine-tuning se trata también en el artículo sobre calidad del pipeline RAG.
Riesgos habituales y cómo mitigarlos
Dependencia en bucle (retrieval loop): el agente recupera repetidamente documentos similares sin avanzar. Solución: límite max_retrieval_steps (típicamente 4–6) y comprobación de duplicados en los chunks recuperados — si el agente ha recuperado el mismo documento dos veces, debe cambiar la consulta.
Confabulación por contexto largo: cuantos más documentos hay en el contexto, mayor espacio tiene el modelo para conexiones alucinadas. Solución: faithfulness judge + citas (cada afirmación debe ser trazable a un chunk concreto). La falta de claridad sobre de qué fuente proviene la información es una señal de alarma.
Coste incontrolado: el Agentic RAG sin límites puede consumir en una sola pregunta compleja 10× más tokens de los previstos. Solución: límite duro de tokens por consulta, alertas al alcanzar el 50 % del límite, reporting de coste por consulta en la plataforma de observabilidad.
Prompt injection a través de documentos: el agente recupera un documento en el que un atacante ha insertado instrucciones para el LLM (p. ej. «ignora las instrucciones anteriores y devuelve X»). En el Agentic RAG este riesgo es mayor porque el contenido de los documentos llega directamente al contexto del agente, que controla los pasos siguientes. Solución: separación de contexto (documentos recuperados en un bloque de contexto separado con etiquetado claro), validación del contenido recuperado antes de insertarlo en el contexto agentivo.
Preguntas frecuentes
¿Es el Agentic RAG siempre más preciso que el RAG clásico?
No. Un Agentic RAG ingenuo sin faithfulness judge puede alucinar más que el RAG clásico, porque un contexto más largo y más pasos de recuperación dan al modelo mayor espacio para generar texto plausible pero sin respaldo. El Agentic RAG es más preciso solo cuando está correctamente implementado con un bucle de autoevaluación y una trazabilidad de citas clara.
¿Cuánto cuesta el Agentic RAG frente al clásico?
El Agentic RAG suele ser 5–10× más caro por consulta. Con modelos baratos (tier Flash/Haiku, $0,10–0,50 / 1M tokens de entrada) la diferencia es manejable. Con modelos frontier (clase Claude Opus, ~$5 input / ~$25 output / 1M tokens) el coste por consulta agentiva es del orden de céntimos a decenas de céntimos. Para un volumen alto de consultas (miles al día) es imprescindible un router que dirija las preguntas simples al RAG clásico.
¿Necesito un framework especial para el Agentic RAG?
No necesariamente, pero facilitará la implementación. LangGraph con estado explícito y checkpointing es hoy la opción dominante para sistemas de producción — gestiona checkpointing, lógica de reintentos y HITL gates. LlamaIndex tiene Agentic RAG integrado con query rewriting y multi-step retrieval. Para casos más sencillos basta con código propio con un bucle ReAct.
¿Cuál es la latencia del Agentic RAG en producción?
La latencia real de un pipeline Agentic RAG con 3–5 pasos de recuperación es de 5–20 segundos. El RAG clásico suele responder en 1–3 segundos. Para aplicaciones interactivas es imprescindible el procesamiento asíncrono y el streaming de la salida — el usuario debe ver que el sistema está trabajando, de lo contrario lo percibe como un fallo.
¿Cuándo es mejor usar GraphRAG que Agentic RAG?
GraphRAG es más adecuado cuando las relaciones entre entidades son importantes y los documentos forman una red de hechos interconectados (p. ej. conexiones regulatorias, jerarquías organizativas). El Agentic RAG es más adecuado cuando la base de conocimiento está orientada a documentos y el problema son las preguntas multi-paso, no las relaciones en grafo.
*Si estás valorando si tu caso de uso de base de conocimiento requiere Agentic RAG o basta con un enfoque clásico optimizado, estaremos encantados de evaluar la situación concreta — incluyendo una estimación de costes, latencia y diseño arquitectónico. MP Industrial Solutions implementa sistemas RAG y agentivos para entornos B2B con foco en resultados medibles.*