Agentic RAG vs. RAG clásico: ¿cuál es la diferencia?

Agentic RAG es una evolución de la Retrieval-Augmented Generation en la que un agente de IA autónomo decide de forma dinámica si se recupera conocimiento, qué se recupera y con qué frecuencia. La recuperación es aquí una herramienta que el agente invoca de forma reflexiva, en varios pasos y desde varias fuentes. El RAG clásico, en cambio, pasa cada consulta por un pipeline fijo de una sola pasada, sin lógica de decisión.

• RAG clásico = pipeline estático: generar embeddings, recuperar una vez, insertar en el prompt, generar. Siempre el mismo flujo.
• Agentic RAG = política dinámica de herramientas: un agente planifica, decide en cada consulta, invoca la recuperación de forma iterativa y se corrige a sí mismo.
• Contrapartida: Agentic RAG aumenta la calidad en preguntas complejas, pero a cambio cuesta más latencia y más dinero, y conlleva el riesgo de bucles de herramientas descontrolados.

RAG clásico: el pipeline estático

El RAG clásico (clasificado en la investigación como Naive RAG y Advanced RAG, Gao et al. 2023/2024) sigue un flujo determinista. La consulta recorre siempre la misma secuencia de pasos, tanto si se trata de una pregunta factual trivial como de una pregunta anidada de varios pasos.

La ruta típica de una consulta en un pipeline de RAG clásico en producción es la siguiente:

1. Consulta del usuario
2. Query Rewriter / HyDE (opcional, una sola vez)
3. Embedding + consulta BM25
4. Recuperación híbrida (top_k = 50-100)
5. Re-Ranker (top_k = 5-10)
6. Plantilla de prompt + citación de fuentes
7. LLM (generador)
8. Salida + comprobación de faithfulness

La premisa central: un único paso de recuperación aporta suficiente contexto para la respuesta. Es sólido, predecible y fácil de medir. La debilidad aparece en preguntas que necesitan varias rondas de recuperación, en las que no está claro qué fuente es relevante o en las que la formulación original encaja mal con el índice. El pipeline no puede volver a buscar, cambiar de rumbo ni recurrir a una segunda fuente, porque no tiene lógica de decisión.

Agentic RAG: la recuperación como herramienta de un agente

Según la revisión de referencia de Singh et al. 2025 (arXiv:2501.09136), Agentic RAG integra agentes autónomos en el pipeline de RAG. Estos agentes utilizan cuatro patrones de diseño agénticos para controlar de forma dinámica la estrategia de recuperación:

• Reflection (autocrítica): el agente evalúa las fuentes recuperadas y su propia respuesta intermedia, y decide si hay que volver a buscar.
• Planning: el agente descompone una pregunta compleja en pasos parciales (Plan-and-Execute).
• Tool Use: la recuperación es solo una de varias herramientas, junto a la búsqueda web, las consultas a bases de datos u otras API.
• Multi-Agent Collaboration: varios agentes especializados se reparten el trabajo.

Una formalización temprana de este principio es Self-RAG (Asai et al. 2023, arXiv:2310.11511), que aprende mediante tokens de autorreflexión cuándo hace falta una recuperación y si la generación se mantiene fiel a las fuentes. Conceptualmente, una arquitectura de Agentic RAG tiene este aspecto:

• Agente (planificador): planifica los pasos y elige la herramienta adecuada.
• Herramienta search_kb(query): invoca el pipeline de RAG.
• Herramienta web_search(query): busca en la web.
• Herramienta db_query(...): consulta datos estructurados.
• Memoria: búfer de conversación y memoria episódica.
• Reflection: critique(answer, sources) contrasta la respuesta con las fuentes y, si es necesario, lanza otra ronda.

Las cuatro decisiones que toma un agente

La diferencia decisiva se resume en cuatro decisiones en tiempo de ejecución que en el RAG clásico están fijadas de antemano:

• SI se recupera (enrutamiento de consultas): un saludo o una simple operación aritmética no necesitan recuperación. El agente puede saltarse la recuperación.
• QUÉ se recupera (reescritura de consultas, elección de fuente): el agente reformula la consulta o la dirige a la fuente adecuada (base de conocimiento interna, web o base de datos estructurada).
• CUÁNTAS VECES se recupera (multi-hop): si una respuesta no basta, el agente vuelve a buscar con una consulta más precisa.
• SI la respuesta sirve (autocorrección): mediante Reflection, el agente contrasta el resultado con las fuentes y lo corrige, en lugar de generar a ciegas.

Comparación directa

Fuentes: Gao et al. 2023/2024 (arXiv:2312.10997); Singh et al. 2025 (arXiv:2501.09136).

Ventajas y desventajas: calidad frente a latencia y costes

El punto fuerte de Agentic RAG es la calidad de respuesta en preguntas complejas. Las preguntas multi-hop («¿Qué proveedor de la región X tuvo la mayor tasa de reclamaciones en el último trimestre y qué dice al respecto el contrato marco?») requieren varias recuperaciones de varias fuentes, además de razonamiento intermedio. Un pipeline estático fracasa ante ellas por su propia estructura; un agente puede resolverlas paso a paso.

Esta calidad tiene un precio concreto:

• Latencia: cada ronda de Reflection y de multi-hop es una llamada adicional al LLM. Una respuesta puede convertirse rápidamente en entre tres y cinco generaciones secuenciales.
• Costes: más llamadas al LLM por consulta significan directamente costes más altos. En alemán se añade una dificultad: según el tokenizador, las palabras compuestas alemanas consumen aproximadamente entre 1,3 y 1,7 veces más tokens que su equivalente en inglés, lo que encarece cada paso de razonamiento adicional.
• Estabilidad: el modo de fallo típico documentado en la investigación son los bucles de herramientas descontrolados y la explosión de costes (Singh et al. 2025). Sin límites estrictos de iteraciones, presupuesto y timeout, el comportamiento se vuelve impredecible.
• Madurez del término: en 2026, «Agentic RAG» todavía no es un término claramente consolidado. Abarca desde un simple ReAct con retriever hasta arquitecturas multiagente (HM-RAG, M-RAG). Hay que tenerlo en cuenta al elegir herramientas y al gestionar expectativas.

Un matiz importante: Agentic RAG se basa en el RAG clásico y no lo sustituye. El pipeline subyacente (búsqueda híbrida, re-ranking, Contextual Retrieval) sigue siendo la base que el agente invoca como herramienta. Del mismo modo, el debate paralelo sobre el contexto largo (ventanas de contexto de 1-2 millones de tokens) es en 2026 un complemento del RAG, no un sustituto: en el test multi-needle del informe de Gemini 1.5 Pro (Google, 2024; versión del modelo de febrero de 2024, 100 needles, hasta 1 millón de tokens), el recall se quedó en algo más del 60 %. A esto se suman, con contexto largo, una latencia y unos costes por consulta claramente más altos que con una recuperación RAG específica.

Ejemplo concreto: la misma pregunta, dos arquitecturas

Consulta: «Compara nuestros plazos de supresión según el RGPD con la práctica actual de las autoridades de control y señala las discrepancias».

RAG clásico: embedding de la pregunta, una recuperación híbrida de la base de conocimiento interna, re-ranking al top-5, generación. Resultado: los plazos de supresión internos se citan correctamente. Falta la «práctica actual de las autoridades de control», porque no está en la base interna y el pipeline no puede consultar una segunda fuente. Una generación, costes bajos y estables, pero una respuesta incompleta.

Agentic RAG: el agente planifica dos subpreguntas. Paso 1: search_kb("interne DSGVO-Löschfristen") devuelve los valores internos. Paso 2: Reflection detecta que falta la referencia externa de comparación y llama a web_search("aktuelle Aufsichtspraxis Löschfristen"). Paso 3: el agente combina ambas fuentes y marca las discrepancias. Resultado: una respuesta completa, pero tres rondas de LLM en lugar de una y, en consecuencia, más latencia y costes más altos.

Esta comparación muestra el criterio de decisión: si el esfuerzo adicional por consulta compensa, medido según la mejora de calidad para cada caso de uso.

Cuándo compensa Agentic RAG

Agentic RAG está justificado si se cumple al menos uno de estos factores:

• Una parte relevante de las consultas requiere razonamiento multi-hop sobre varios hechos.
• Hay que incorporar varias fuentes heterogéneas (base de conocimiento interna, web, base de datos estructurada).
• Las consultas suelen ser ambiguas y se benefician del enrutamiento y la reescritura de consultas.
• Un único pipeline fijo ofrece valores de faithfulness o context recall que, según las mediciones, son demasiado bajos (RAGAS).

Una vía intermedia pragmática es un híbrido con enrutamiento: una ruta clásica rápida para la mayoría de las preguntas factuales sencillas y una ruta agéntica solo para los casos complejos. Así, los costes elevados solo aparecen donde realmente mejoran la respuesta. En cualquier caso, hacen falta guardrails estrictos: límite de iteraciones, presupuesto de costes por consulta, timeout y tracing de extremo a extremo (por ejemplo, LangSmith o Arize Phoenix).

Para agencias y decisores B2B

Para las agencias y los equipos B2B en Europa, el mensaje es sobrio: Agentic RAG es una decisión de arquitectura consciente con consecuencias en costes, no una mejora estándar. Empieza con un pipeline de RAG clásico bien hecho (búsqueda híbrida, re-ranking, evaluación con RAGAS) y mide primero dónde falla en preguntas multi-hop o con varias fuentes. Solo esos datos justifican el paso a Agentic RAG y te dan el argumento para defender el presupuesto. Si quieres planificar o evaluar esta arquitectura, el enrutamiento entre la ruta clásica y la agéntica y los guardrails necesarios para el mercado europeo, Blck Alpaca te acompaña desde la decisión de arquitectura hasta la implementación en producción conforme al RGPD con alojamiento en la UE.