Agentic RAG vs. RAG tradicional: cuando recuperar información ya no alcanza
RAG permite que un LLM busque información propia de una organización antes de responder. Para muchas preguntas, alcanza.El problema aparece cuando la respuesta no está en un solo documento ni puede resolverse con una única búsqueda.
Preguntar cuál es la política vigente de vacaciones puede requerir encontrar un archivo. Preguntar si una excepción cumple con esa política, con antecedentes similares y con los cambios realizados durante el último año exige algo distinto. La interfaz puede ser la misma. La tarea no.
Ahí empieza la diferencia entre RAG tradicional y Agentic RAG.
RAG tradicional: recuperar información y avanzar
RAG, Retrieval-Augmented Generation o generación aumentada por recuperación, conecta un modelo de lenguaje con una base de conocimiento.
El recorrido suele ser lineal: recibe una pregunta, busca dentro de una knowledge base, recupera los fragmentos más relevantes, los incorpora al contexto y el LLM genera una respuesta.
Retrieve. Augment. Generate.
Para consultas directas funciona bien.
Si una persona necesita conocer un procedimiento, encontrar determinada información o consultar qué establece una política, probablemente no haga falta una arquitectura más compleja. La información existe. Hay que encontrarla. Pero ¿qué pasa cuando responder exige relacionar información que aparece en lugares diferentes?
Cuando encontrar documentos no alcanza
Supongamos que una dirección pregunta: ¿El crecimiento del último trimestre estuvo por encima de lo que habíamos proyectado? Responder exige recuperar al menos dos datos: el resultado actual y la proyección realizada anteriormente. Después hay que asegurarse de que correspondan a los períodos correctos, que las cifras sean comparables y que la conclusión esté respaldada por esas fuentes.
Un RAG tradicional puede buscar términos relacionados con crecimiento, ingresos y proyecciones. Pero ¿encontró exactamente la proyección correcta? ¿Recuperó la versión vigente? ¿Tiene toda la información necesaria para comparar?
Progress señala este límite al comparar Traditional RAG con Agentic RAG: en un pipeline convencional, la generación depende en gran medida de la información recuperada inicialmente. Si esa búsqueda fue incompleta, el modelo puede recibir un contexto incompleto. El problema puede empezar antes de que el LLM genere una sola palabra.
La pregunta es qué puede hacer el sistema cuando detecta que esa primera recuperación no alcanza.
Agentic RAG: buscar, evaluar y volver a buscar
Agentic RAG agrega un agente al proceso de recuperación. En lugar de ejecutar una búsqueda y pasar inmediatamente a la generación, el sistema puede analizar primero qué necesita resolver. Puede dividir una consulta compleja en preguntas menores (las query decomposition), planificar búsquedas, consultar diferentes fuentes, evaluar resultados y decidir si todavía falta información.
Progress agrupa estas capacidades alrededor de conceptos como query planning and decomposition, iterative retrieval y answer validation: planificación y descomposición de consultas, recuperación iterativa y validación de respuestas.
En el ejemplo anterior, el sistema puede buscar primero los resultados del trimestre y después localizar específicamente la proyección realizada en el período anterior. Puede verificar fechas, contrastar las cifras y recién entonces construir una respuesta. La diferencia no está solamente en hacer más búsquedas. Está en poder reconocer que todavía hace falta buscar.
Agentic RAG empieza a acercarse menos a una búsqueda simple y más a una investigación. Pero darle al sistema capacidad para decidir qué buscar también introduce nuevas decisiones dentro de la arquitectura.
Y cada una tiene un costo.
Fuente: Progress Software's John Ainsworth on agentic RAG, MCP and why bypassing business logic is too risky
Más capacidad también agrega complejidad
Agentic RAG puede incorporar multi-hop retrieval, query rephrasing, intent routing o semantic re-ranking: búsquedas de varios pasos, reformulación de consultas, selección de rutas según la intención y reordenamiento semántico de resultados. Eso amplía lo que el sistema puede hacer. También amplía lo que hay que mantener.
Descomponer una consulta puede implicar nuevas llamadas al LLM. Cada búsqueda iterativa agrega procesamiento. Cada validación suma pasos antes de generar una respuesta.
Más capacidad puede significar más latencia, mayor consumo de tokens y una arquitectura con más componentes que observar y corregir.
Progress plantea ese trade-off de manera explícita: cuando las consultas son simples y la base de conocimiento está bien delimitada, RAG tradicional puede seguir siendo más rápido, económico y sencillo.
Agentic RAG empieza a justificar esa complejidad cuando las preguntas requieren combinar fuentes, atravesar varios pasos o validar con mayor cuidado la evidencia utilizada.
La tecnología más sofisticada no necesariamente resuelve mejor cualquier pregunta. La decisión empieza en otro lugar: ¿qué tipo de preguntas necesita responder la organización?
La complejidad de la pregunta debería definir la arquitectura
Una consulta puede necesitar encontrar un dato. Otra puede exigir reconstruir una relación, comparar momentos diferentes o revisar fuentes que incluso se contradicen antes de sostener una conclusión. Tratar todas de la misma manera simplifica la arquitectura, pero también puede simplificar demasiado el problema.
En Alpha venimos trabajando una idea relacionada: la capacidad de un LLM no se transforma automáticamente en capacidad organizacional. Con RAG ocurre algo parecido.
Conectar un modelo con información propia permite superar una parte del problema. No garantiza que cualquier pregunta pueda resolverse recuperando algunos fragmentos y pasándolos al prompt.
La pregunta empieza a definir cuánto retrieval, razonamiento y validación necesita el sistema. No hace falta convertir cada consulta en una investigación. Tampoco conviene tratar una investigación como si fuera una búsqueda.
Y ahí aparece el cambio más interesante de Agentic RAG: la discusión deja de concentrarse solamente en cuánto conocimiento puede recuperar una IA y empieza a mirar qué puede hacer con él.
¿Tu organización está evaluando RAG o Agentic RAG para trabajar con su propio conocimiento?
En Alpha Discovery ayudamos a diseñar arquitecturas de IA con el contexto, la recuperación y la validación que cada caso necesita.
