RAG frente a Agentic RAG frente a Graph RAG: Elegir la arquitectura de recuperación adecuada
Aprenda cómo el ingenuo RAG falla con preguntas de múltiples pasos y datos estructurados, y cómo los bucles agentes y la recuperación basada en grafos resuelven respectivamente debilidades diferentes.
El problema que RAG fue creado para resolver
Cualquier modelo de lenguaje grande posee conocimientos que dejan de acumularse una vez finaliza su entrenamiento, y solo puede razonar sobre lo que cabe dentro de su ventana de contexto. La generación reforzada por recuperación aborda este problema al incorporar una memoria externa a la que el modelo puede recurrir al responder a una pregunta. En lugar de depender únicamente de lo que aprendió durante el entrenamiento, el modelo obtiene texto relevante de una colección de documentos y utiliza ese material como base para su respuesta.
Los pasos subyacentes probablemente ya le resulten familiares:
- Los documentos de origen se dividen en fragmentos más pequeños y se convierten en embeddings vectoriales.
- Esos embeddings se almacenan en una base de datos vectorial; herramientas como Pinecone, Weaviate, pgvector y similares son opciones comunes.
- Cuando un usuario envía una consulta, esta se convierte en un embedding utilizando el mismo método.
Toda esta secuencia se ejecuta una sola vez, de principio a fin: una recuperación y una generación. Es económico, su comportamiento es fácil de comprender, y para una amplia gama de casos de uso —buscar documentos internos, responder preguntas de soporte a partir de una base de conocimientos o gestionar preguntas y respuestas con un conjunto estático de documentos — funciona de manera excelente.
Dónde falla el RAG ingenuo
Cuando este sencillo proceso falla, los problemas suelen encuadrarse en unas pocas categorías reconocibles:
- Preguntas que requieren conectar varios hechos. Algo como “¿qué proveedores renovaron los contratos después de la actualización de políticas del tercer trimestre?” necesita dos piezas de información separadas que casi con certeza se encuentran en secciones diferentes. La similitud vectorial identifica secciones que son semánticamente similares a la consulta, no la combinación específica de hechos necesaria para responderla.
- No hay condición de parada integrada. El sistema siempre devuelve sus secciones más relevantes, independientemente de si esas secciones contienen realmente la respuesta. Cuando la respuesta real está fuera de ese conjunto de las k mejores, el modelo o bien inventa algo plausible o da una respuesta vaga e inútil.
- No existe bucle de retroalimentación. Si la recuperación inicial no da en el clavo, nada en el proceso detecta eso y prueba una consulta mejor formulada. Simplemente continúa con lo que obtuvo.
Ninguno de estos problemas es realmente un error; son consecuencias naturales de la suposición fundamental inherente a la arquitectura: que la búsqueda por similitud en fragmentos de texto desconectados es un sustituto suficiente para la verdadera relevancia. Agentic RAG y Graph RAG abordan cada uno un punto débil distinto de esa suposición.
Agentic RAG: Darle a la recuperación de información un bucle de toma de decisiones
Agentic RAG reemplaza la secuencia rígida de recuperar información y luego generar un texto por un bucle en el que un LLM actúa como coordinador, decidiendo qué buscar, si se necesita otra búsqueda y cuándo ya ha recopilado suficiente información para producir una respuesta.
En lugar de un solo paso de recuperación, el proceso se parece más a esto:
- El modelo lee la consulta y analiza qué información necesita realmente.
- Determina si la recuperación es necesaria en primer lugar, y de ser así, construye una consulta de búsqueda, posiblemente descomponiendo una pregunta complicada en subpreguntas más pequeñas.
- Recupera los resultados, evalúa si son adecuados y, de no serlo, vuelve a redactar la consulta y realiza una nueva búsqueda.
- Puede recurrir a varias fuentes diferentes según sea necesario: un almacén de vectores, una base de datos SQL, una API de búsqueda web o un servicio interno, dependiendo de lo que exija la pregunta.
- Solo después de concluir que cuenta con pruebas suficientes genera una respuesta final.
En efecto, esto envuelve a RAG dentro de un bucle agente, adoptando el mismo patrón de llamada a herramientas utilizado por los asistentes de programación: planificar, actuar, observar el resultado y luego decidir si continuar. La recuperación de información deja de ser un paso obligatorio inicial para convertirse en solo una herramienta entre varias, que se invoca de forma selectiva y no automáticamente con cada solicitud.
La ventaja es la flexibilidad. Una pregunta simple desencadena una sola búsqueda; una pregunta que requiere tres búsquedas secuenciales en diferentes sistemas recibe exactamente eso. La configuración también permite la autocorrección: si los fragmentos recuperados están claramente erróneos, el agente puede darse cuenta de ello y realizar una consulta diferente en lugar de responder con confianza a partir de un contexto poco fiable.
Esa flexibilidad conlleva un costo real. Cada paso de planificación y cada paso de evaluación representa por sí mismo una llamada al modelo separada, por lo que se termina con más invocaciones del LLM por consulta, mayor latencia y un perfil de costos mucho más difícil de predecir con antelación. El Agentic RAG funciona bien cuando la complejidad de las consultas varía mucho de una solicitud a otra, ya que un pipeline fijo de un solo paso desperdiciaría esfuerzos en preguntas simples o no sería suficiente para las complejas. Es una opción menos adecuada cuando se necesita una latencia consistentemente baja, o cuando las consultas son lo suficientemente específicas como para que un recuperador de un solo disparo ajustado cuidadosamente ya las maneje bien.
Graph RAG: Recuperar la estructura destruida por el chunking
Graph RAG aborda una limitación completamente diferente: la búsqueda vectorial simple sobre fragmentos no tiene una noción integrada de cómo se relacionan entre sí las entidades.
En lugar de depender únicamente de un índice vectorial (aunque aún puede utilizar uno además), Graph RAG construye un grafo de conocimiento directamente a partir del material de origen. Esto implica extraer entidades —personas, productos, organizaciones, conceptos— junto con las relaciones que las conectan, como trabaja-en, depende-de, es-causado-por o es-una-versión-de. La recuperación deja de ser puramente una búsqueda por similitud y se convierte en parte en un problema de recorrido de grafos: partiendo de una entidad relevante, el sistema puede pasar a entidades conectadas y obtener información que nunca surgiría mediante la búsqueda por palabras clave o coincidencias de embeddings solamente, simplemente porque se encuentra a varias relaciones de distancia en un documento completamente diferente.
La investigación GraphRAG de Microsoft es la implementación más citada de este enfoque, y presenta una función adicional especialmente valiosa para un tipo específico de consulta: la detección de comunidades. El sistema agrupa el grafo en clústeres de entidades estrechamente relacionadas y calcula previamente un resumen para cada clúster. Esto le da a Graph RAG una ventaja real en preguntas amplias que abarcan todo el corpus, como “¿cuáles son los temas recurrentes en todo este conjunto de informes?”, que es precisamente la categoría con la que el RAG tradicional tiene más dificultades, ya que ningún fragmento individual contiene la respuesta completa; la respuesta solo surge al sintetizar toda la información del conjunto de datos.
Los costos aquí son estructurales, no incidentales. Construir el grafo es caro, ya que requiere realizar un proceso de extracción de entidades y relaciones sobre todo el corpus, generalmente impulsado por un LLM, además del paso adicional de generar resúmenes de comunidades. Tampoco es adecuado para corpus que cambian con frecuencia, porque el grafo debe reconstruirse o actualizarse de forma incremental cada vez que cambian los documentos, lo cual es una operación mucho más compleja que simplemente insertar un nuevo vector en un índice de embeddings.
Comparación de los tres enfoques
Cabe señalar que estos enfoques no son mutuamente excluyentes. Un patrón común en la práctica es un bucle agente equipado tanto con un recuperador de vectores como con uno de grafos como herramientas disponibles, lo que permite al agente elegir entre ellos o utilizar ambos, según lo exija la consulta. La capa de agente es en realidad una estrategia de orquestación que se sitúa por encima del mecanismo de recuperación que utilices, por lo que se integra naturalmente sobre Graph RAG en lugar de competir con él.
Un marco de toma de decisiones práctico
En lugar de elegir un enfoque porque sea popular en este momento, resulta útil seguir un proceso de toma de decisiones concreto:
- Comience con RAG simple. Es la opción más económica para desarrollar y solucionar problemas, y para una gran parte de las aplicaciones del mundo real ya es suficiente. Evite agregar complejidad antes de tener pruebas de que realmente la necesita.
- Actualícelo a RAG agente una vez que detecte patrones específicos de fallo: preguntas que requieren obtener información de varias fuentes, respuestas incorrectas porque el modelo tuvo que buscar, evaluar lo encontrado y buscar de nuevo, o una carga de trabajo que mezcla consultas fáciles y difíciles de tal manera que un único flujo fijo resulta excesivo o insuficiente.
La conclusión principal refleja un patrón que se repite en todo el diseño de sistemas: una arquitectura más sofisticada no es inherentemente superior, sino que lo es solo para un tipo específico de fallo. El RAG ingenuo tropieza con el razonamiento multi-paso y las preguntas relacionales. El RAG agente aborda la brecha en el razonamiento al introducir iteraciones. El Graph RAG resuelve la brecha relacional al incorporar estructura. Diagnosticar correctamente qué tipo de fallo estás enfrentando es lo más importante.
Lecturas relacionadas
- Por qué el coste de la IA agente explota: Un modelo de costes centrado en la arquitectura — Explica por qué los costes de los agentes basados en LLM deben medirse por tarea completada y no por llamada, y describe mecanismos arquitectónicos como el enrutamiento de modelos, los presupuestos de contexto y el caché para controlar los gastos.
- Segundo cerebro: Conviertiendo transcripciones de reuniones en un grafo de conocimiento interrogable — Explica cómo un sistema agente extrae entidades de las transcripciones de reuniones y las almacena en Cosmos DB para permitir la recuperación mediante lenguaje natural y la exploración del grafo de conocimiento.