Microsoft publicó GraphRAG como proyecto abierto a principios de 2024 y desde entonces ha pasado de curiosidad académica a herramienta con despliegues empresariales documentados. La idea central, usar un grafo de conocimiento construido por el propio LLM como capa intermedia entre los documentos y la consulta, no era nueva, pero Microsoft fue el primero en ofrecer una implementación pulida y benchmarks concretos sobre tipos de pregunta donde el RAG tradicional fallaba.
Un año después, hay material suficiente para evaluar dónde GraphRAG gana y dónde no merece el esfuerzo. Este post es un balance basado en proyectos reales y en la experiencia compartida por equipos que lo han llevado a producción.
El problema que GraphRAG aborda
El RAG clásico (chunks de texto, embeddings, búsqueda por similitud, LLM) funciona muy bien para preguntas locales: «¿qué dice el documento X sobre el tema Y?». Falla cuando la pregunta requiere agregar información dispersa en múltiples documentos: «¿cuáles son los temas principales tratados en este corpus?», «¿qué relaciones hay entre los proyectos mencionados?», «¿cómo ha evolucionado la postura de la empresa sobre este tema a lo largo del año?».
Estas preguntas globales son frustrantes con RAG clásico porque ningún chunk individual contiene la respuesta. El modelo de lenguaje solo ve algunos fragmentos recuperados y tiene que adivinar el resto, con resultados erráticos.
La solución de GraphRAG es previa al momento de la consulta. Durante la indexación, un LLM lee el corpus completo, extrae entidades (personas, proyectos, conceptos) y las relaciones entre ellas, y construye un grafo. Después agrupa las entidades en comunidades (clústers de nodos fuertemente conectados) y, para cada comunidad, genera un resumen que describe los temas y patrones que contiene. Cuando llega una consulta global, en lugar de recuperar chunks, GraphRAG recupera resúmenes de comunidades y los combina para responder.
Dónde gana claramente
Lo que he visto funcionar especialmente bien es en análisis de corpus medianos con preguntas estratégicas. Archivos de correos de una empresa, documentación de proyectos, investigación acumulada en una organización, transcripciones de reuniones durante un trimestre: cuerpos de texto donde la pregunta útil no es «¿qué dice exactamente X?» sino «¿qué ha pasado? ¿qué temas han dominado? ¿qué cambios se perciben?».
Un caso paradigmático que he visto documentado es análisis de feedback de clientes. Con miles de tickets de soporte o comentarios de encuestas, el RAG clásico responde bien a «¿cuál es el problema más reciente del cliente X?», pero falla en «¿cuáles son los tres temas que más preocupan a nuestros clientes este trimestre?». GraphRAG, al haber construido el grafo de temas y relaciones durante la indexación, tiene ese resumen ya preparado.
Otro caso donde brilla es en análisis de redes de personas o organizaciones. Investigación periodística, due diligence corporativa, detección de patrones en denuncias. Todo lo que implique entender quién está conectado con quién y cómo, se beneficia enormemente del modelo de grafo explícito.
Dónde no compensa
GraphRAG no es gratis y conviene ser honesto sobre su coste.
La indexación es cara. Construir el grafo implica pasar el corpus completo por un LLM varias veces: una para extracción de entidades, otra para extracción de relaciones, otra para generación de resúmenes de comunidad. Para un corpus mediano (decenas de miles de páginas), el coste de indexación puede ascender a cientos o miles de dólares en tokens de API, dependiendo del modelo usado.
La actualización incremental es posible pero complicada. Si el corpus cambia constantemente (documentos que se añaden, se modifican, se borran), mantener el grafo sincronizado es no trivial. La implementación abierta de Microsoft ha mejorado esto durante el último año pero sigue siendo más exigente que reindexar un sistema RAG clásico.
Y para preguntas locales, GraphRAG no solo no mejora, sino que puede ser peor. Si tu consulta es «¿qué dice exactamente el documento X sobre el tema Y?», recuperar del grafo una comunidad resumida es un rodeo innecesario. El chunk literal es lo que quieres.
Por eso el patrón más efectivo que he visto es híbrido: tener los dos sistemas en paralelo y rutear las consultas según el tipo. Las preguntas con entidades concretas van al RAG clásico; las preguntas temáticas globales van al GraphRAG. Clasificar la pregunta con un LLM ligero al principio de cada consulta es suficiente para decidir.
Los patrones que han cuajado
Después de un año de despliegues, hay algunos patrones que se repiten entre equipos que han tenido éxito con GraphRAG:
Reducir el ámbito del corpus. GraphRAG no escala bien a corpus gigantescos en una sola indexación. Los despliegues exitosos suelen indexar por dominio (un proyecto, una división, un año de datos) y tener varios grafos en paralelo, con un router que elige cuál consultar según la pregunta. Esto también simplifica la actualización incremental.
Usar un modelo potente para la indexación, uno barato para la consulta. La calidad del grafo depende críticamente del modelo que extrae entidades y genera resúmenes. Ahorrar ahí es falso ahorro. En cambio, la consulta final (que toma la pregunta y los resúmenes recuperados y produce la respuesta) puede usar un modelo más ligero sin perder calidad aparente.
Mantener el RAG clásico como fallback. Para cualquier consulta donde GraphRAG no tenga una comunidad relevante clara, caer atrás a búsqueda tradicional es un seguro barato contra respuestas malas. El coste adicional es mínimo si solo se activa cuando GraphRAG no tiene respuesta.
Invertir en la visualización del grafo. Tener una interfaz que permita al usuario final ver qué entidades ha extraído GraphRAG y cómo las ha relacionado aporta mucha confianza en los resultados. Los grafos son inherentemente visuales, y aprovechar eso es una ventaja sobre el RAG tradicional.
La decisión
Si estás evaluando GraphRAG para un proyecto, el criterio práctico que uso es este:
¿Las preguntas útiles en tu caso son locales (sobre contenido específico) o globales (sobre patrones y temas)? Si son mayoritariamente locales, RAG clásico es suficiente. Si son mayoritariamente globales, GraphRAG es muy probablemente una buena inversión.
¿El corpus es estable o cambia constantemente? Si cambia mucho, el coste operativo de mantener el grafo puede superar el beneficio. Para corpus que se actualizan una vez por semana, GraphRAG va bien; para corpus que cambian cada hora, probablemente no.
¿Puedes permitirte el coste de indexación inicial? Hay que hacer números. Para un corpus de 10.000 páginas, la indexación puede costar entre 200 y 2.000 dólares según el modelo. Si tu proyecto tiene una decena de corpus de ese tamaño, hablar de decenas de miles de dólares en indexación no es trivial.
Mirando adelante
Lo que creo que va a pasar con GraphRAG este año es interesante. Las implementaciones van a seguir optimizándose (Microsoft ha publicado mejoras que reducen el coste de indexación entre un 30 y un 50 por ciento respecto a la versión inicial). Y van a aparecer alternativas más ligeras que aplican la misma idea con menos ceremonia: grafos más pequeños, extracción incremental, tecnologías de resumen más eficientes.
También es probable que el patrón híbrido se convierta en default. Los sistemas RAG serios de 2026 probablemente combinen varias técnicas: vector search clásico, búsqueda por palabras clave, grafos de conocimiento y recuperación por resúmenes de comunidad, todo seleccionado según el tipo de consulta. GraphRAG como estamos viéndolo hoy es un paso en esa dirección, no un destino final.
Si tu proyecto tiene preguntas que el RAG clásico no resuelve bien, y no lo has probado todavía, vale la pena dedicar dos semanas a un prototipo con un subconjunto del corpus. Los resultados te van a contar si la inversión mayor compensa, y lo sabrás en días en lugar de meses.
