Guía de GraphRAG: cuándo los grafos de conocimiento ganan al RAG vectorial (y cuándo no)
GraphRAG no está muerto, pero tampoco es la opción por defecto. microsoft/graphrag publicó la v3.1.1 el 2026-07-18 con 35.088 estrellas en GitHub, y tres benchmarks de 2026 ya reportan, sin rodeos, que a menudo pierde frente a la recuperación vectorial de toda la vida. Así que esta guía de GraphRAG responde a la única pregunta que queda: ¿vale un grafo de conocimiento lo que cuesta indexarlo?
¿Deberías usar GraphRAG? La respuesta corta
Usa GraphRAG cuando tus preguntas crucen entidades o abarquen todo el corpus, como «¿a qué otros proveedores también vende nuestro mayor cliente?». Quédate con el RAG clásico o híbrido para consultas de un solo salto, documentos que cambian rápido y presupuestos de latencia ajustados. El grafo se paga solo en preguntas multi-salto y cuesta dinero en todo lo demás.
GraphRAG no está muerto y tampoco es la opción por defecto. Se gana la factura de indexado cuando tus preguntas son multi-salto o globales al corpus, y pierde dinero cuando no lo son.
La versión resumida:
- GraphRAG gana en preguntas multi-salto y globales al corpus; el RAG clásico gana en consultas de un solo salto.
- Los benchmarks de 2026 son mixtos: los grafos ayudan en agregación, pero pueden empeorar los resúmenes finos.
- El coste aparece al indexar, en las llamadas LLM de extracción, no al consultar.
- Ejecuta Basic Search como grupo de control sobre tu propio corpus antes de construir nada.
Si ya tienes un pipeline de RAG vectorial que funciona, la única decisión es si un grafo encima se mantiene solo. La tabla de abajo es todo el argumento en seis filas, y donde dice que te quedes con el clásico, esa es la respuesta honesta, más a menudo de lo que los proveedores admiten. La recuperación híbrida BM25 más vectores cubre la mayoría de estos casos sin ningún grafo.
| Tu situación | RAG clásico / híbrido | GraphRAG | Por qué |
|---|---|---|---|
| Consulta de un solo salto («¿cuál es el plazo de reembolso?») | Sí | No | Una ventana top_k sobre BM25 más vectores ya responde esto; el grafo añade latencia y coste |
| Preguntas de entidades multi-salto («¿a qué proveedores también vende nuestro mayor cliente?») | No | Sí | El recorrido del grafo conecta entidades que nunca comparten fragmento |
| Preguntas temáticas globales al corpus («¿qué temas se repiten en 4.000 tickets?») | No | Sí | Los resúmenes de comunidad agregan sobre todo el conjunto de documentos |
| Requisitos de cumplimiento y procedencia explicable | Parcialmente | Sí | Las aristas dan una ruta auditable desde la respuesta hasta la fuente |
| Corpus que cambia rápido (documentos actualizados cada semana) | Sí | No | Reindexar un grafo en cada actualización es caro; los vectores se re-incrustan barato |
| Presupuesto ajustado de latencia o de indexado | Sí | No | Las llamadas de extracción hacen el indexado lento y caro antes de que corra ninguna consulta |
Qué es realmente GraphRAG: de fragmentos a comunidades
GraphRAG es generación aumentada por recuperación sobre un grafo de conocimiento en lugar de sobre fragmentos desconectados. Al indexar, un LLM extrae entidades y relaciones de tus documentos, el algoritmo Leiden agrupa esas entidades en comunidades y cada comunidad recibe un resumen. Al consultar, el grafo más esos resúmenes responden preguntas que una ventana top_k sobre fragmentos no puede responder por estructura.
El pipeline, de principio a fin:
Documents
|
v
Chunks --> LLM entity + relationship extraction
|
v
Knowledge graph (entities = nodes, relations = edges)
|
v
Leiden community detection --> community summaries
|
v
Vector index over entity + community descriptionsDos fases hacen el trabajo. La fase de indexado es la cara: cada fragmento cuesta una llamada LLM para extraer entidades y relaciones, y los resúmenes de comunidad cuestan más llamadas encima. La fase de consulta es donde aparece el beneficio. Como el grafo guarda las relaciones de forma explícita, una pregunta como «¿a qué otros proveedores también vende nuestro mayor cliente?» se convierte en un recorrido en vez de en la esperanza de que los dos fragmentos correctos caigan en la misma ventana top_k.
Los resúmenes importan porque son lo que Global Search lee de verdad: las preguntas globales al corpus se responden con prosa de comunidad preescrita, no con fragmentos crudos. Y cada arista es un juicio del LLM, guardado como una tripleta que podrías consultar en Cypher sobre una base de datos de grafos real. Ese diseño también explica por qué el indexado domina el coste, algo que las cifras de abajo vuelven concreto.
El encuadre que se gana su sitio: el RAG clásico recupera pasajes y GraphRAG recupera estructura. Tu elección de modelo de embeddings sigue importando para la capa vectorial, y tu base de datos vectorial sigue guardando las descripciones, pero el grafo es la nueva pieza portante. La documentación oficial de Index Overview describe cada fase en detalle.
¿Cuáles son los cuatro métodos de consulta de GraphRAG?
El motor de consultas de GraphRAG trae cuatro métodos: Local Search, Global Search, DRIFT Search y Basic Search. Local Search razona hacia afuera desde entidades concretas, Global Search agrega resúmenes de comunidad sobre todo el corpus, DRIFT Search combina los dos de forma recursiva y Basic Search es una línea base vectorial simple. Una quinta función, Question Generation, se apoya sobre el motor en lugar de ir junto a él.
Comprobamos la documentación en vivo en microsoft.github.io/graphrag/query/overview/ el 2026-07-30, y el conteo es cuatro. La mayoría de las guías que posicionan nombran dos o tres. La misma comprobación encontró la palabra «lazy» cero veces en las páginas de Index y Query Overview, lo cual importa para la sección de costes de abajo.
| Método | Qué responde | Perfil de coste | Úsalo cuando |
|---|---|---|---|
| Local Search | Preguntas centradas en entidades («¿qué posee Acme?») | Medio; trae contexto de la entidad y sus vecinos | Preguntas multi-salto ancladas en entidades conocidas |
| Global Search | Temas globales al corpus («¿cuáles son los principales tipos de queja?») | Alto; se despliega sobre los resúmenes de comunidad | Agregación sobre todo el conjunto de documentos |
| DRIFT Search | Consultas híbridas que piden profundidad local y amplitud global | El más alto; pasos de drift recursivos | Preguntas complejas donde Local por sí solo pierde contexto |
| Basic Search | Consultas de hechos de un solo salto | El más bajo; recuperación vectorial simple | El grupo de control contra el que comparas el grafo |
La fila que merece tu atención es la última. Basic Search es la línea base vectorial clásica integrada, y existe para que compares el grafo contra la recuperación simple sobre tu propio corpus y descubras si el grafo se está ganando su factura. Eso no es trivia; es todo el procedimiento de decisión de esta guía en una sola función. Ejecuta Basic Search primero. Si Local, Global o DRIFT Search no lo superan en las preguntas que de verdad te hacen, el grafo es un coste, no una mejora.
¿Qué encontraron realmente los benchmarks de 2026?
Tres benchmarks de 2026 encuentran que GraphRAG ayuda en tareas de agregación multi-salto y multi-hecho, pero con frecuencia rinde peor que el RAG clásico en lo demás. Uno de ellos construye un benchmark específicamente para encontrar dónde pierden los grafos. Los tres coinciden en que la victoria depende del tipo de pregunta, no del tamaño del corpus. La evidencia dice que GraphRAG es situacional, no por defecto.
| Paper | Fecha | Qué encontró |
|---|---|---|
| arXiv:2506.05690, When to use Graphs in RAG | v3 revisada 2026-02-22 | Estudios recientes reportan que los pipelines de grafos a menudo rinden peor que el RAG clásico en tareas reales; los autores crean GraphRAG-Bench para identificar dónde no es así |
| arXiv:2602.02053, WildGraphBench | 2026-02-02 | 1.100 preguntas en 12 temas; los grafos ayudan a agregar multi-hechos desde un número moderado de fuentes, pero favorecen las afirmaciones de alto nivel y debilitan los resúmenes finos |
| arXiv:2502.11371, RAG vs. GraphRAG: A Systematic Evaluation | v3 revisada 2026-03-04 | Protocolo unificado para QA y resumen basado en consultas; cada paradigma tiene fortalezas distintas, y las estrategias que combinan ambos superan a cualquiera por separado |
Un cuarto esfuerzo, GraphRAG-Bench (repositorio), evalúa nueve métodos GraphRAG en 16 disciplinas y 20 libros de texto, y llega a la misma conclusión desde un ángulo más amplio.
Los tres papers convergen en un punto: el grafo se gana su coste en agregación multi-salto y lo pierde en recuerdo fino.
Nuestra lectura: el ciclo de hype hizo el daño, y estos papers son la corrección. Ninguno dice que los grafos sean inútiles. Lo que dicen, de forma consistente, es que el paso de agregación que hace bueno a GraphRAG en temas globales al corpus es el mismo paso que emborrona el detalle fino. WildGraphBench es el ejemplo más claro: los grafos ayudaron a la agregación multi-hecho desde un número moderado de fuentes y perjudicaron la precisión del resumen en la misma evaluación. Eso no es una contradicción; es un mismo mecanismo apareciendo dos veces.
La consecuencia práctica es que no puedes decidir esto solo con la literatura. Los papers te dicen qué tipos de pregunta probar, no si tu corpus es uno de ellos. Para eso sirve exactamente el grupo de control con Basic Search de la sección de métodos de arriba.
¿Cuánto cuesta GraphRAG? (Y la advertencia de LazyGraphRAG que todos repiten mal)
El coste de GraphRAG es una factura de indexado, no de consulta, y por eso mismo sorprende a la gente. Las llamadas LLM que extraen entidades y relaciones de cada fragmento, más la pasada de resumen de comunidades, son lo que lo vuelve caro. Pagas por adelantado, antes de que corra una sola consulta. La consulta es más barata pero no gratis: Global Search se despliega sobre los resúmenes de comunidad con una llamada LLM por comunidad, por eso la tabla de métodos de arriba lo marca como alto.
Los únicos números públicos y duros vienen de Microsoft Research. El 2024-11-25 el equipo reportó que el coste de indexado de LazyGraphRAG era idéntico al del RAG vectorial y del 0,1 % del coste de GraphRAG completo, y que con un 4 % del coste de consulta de la búsqueda global de GraphRAG superó a los métodos competidores probados, tanto en tipos de consulta locales como globales (Microsoft Research). Esas son cifras de Microsoft, del blog de Microsoft, y las reportamos como tales; nosotros no hemos corrido un indexado con precios propio.
Aquí está la corrección que la mayoría de los artículos pasan por alto. LazyGraphRAG no es una opción de pip install. Según la propia nota del editor de Microsoft del 2025-06-06, se envió a Microsoft Discovery y Azure Local, no al paquete de código abierto. Comprobamos las páginas oficiales de Index Overview y Query Overview el 2026-07-30: la palabra «lazy» aparece cero veces en ambas. Así que si una guía lista LazyGraphRAG como una variante que puedes levantar esta misma tarde, está repitiendo una afirmación que dejó de ser cierta en el mundo del código abierto.
Lo que sí puedes hacer hoy: ejecutar el modelo de extracción en local. Apuntar el paso de indexado a un modelo local vía Ollama quita las tarifas de API por token de la fase más cara, y combinarlo con un almacén vectorial autoalojado mantiene el resto de la factura cerca de cero.
¿Qué biblioteca GraphRAG está realmente mantenida?
Dos de las seis bibliotecas GraphRAG más citadas no han recibido un push en seis y nueve meses. Sacamos estas cifras de la API de GitHub el 2026-07-30, y el censo de abajo es la comprobación que los resúmenes antiguos se saltan, con el comando para repetirla antes de comprometerte con una. LightRAG y microsoft/graphrag son las activas; nano-graphrag y fast-graphrag van camino del abandonware.
| Biblioteca | Estrellas | Último push | Issues abiertas | Lectura |
|---|---|---|---|---|
| HKUDS/LightRAG | 38.353 | 2026-07-30 | 217 | La más activa; backlog grande de issues |
| microsoft/graphrag | 35.088 | 2026-07-26 | 61 | Implementación de referencia; v3.1.1 publicada 2026-07-18 |
| getzep/graphiti | 29.377 | 2026-07-30 | 438 | Enfoque de grafo temporal; backlog pesado |
| neo4j/neo4j-graphrag-python | 1.237 | 2026-07-27 | 30 | Pequeña, ordenada, mantenida por el proveedor |
| gusye1234/nano-graphrag | 3.949 | 2026-01-27 | 84 | Unos seis meses desde el último push |
| circlemind-ai/fast-graphrag | 3.834 | 2025-11-01 | 38 | Unos nueve meses desde el último push |
for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; doneNuestra lectura: las estrellas son una métrica de vanidad; la fecha de push es el número que importa. LightRAG y microsoft/graphrag están ambas activamente mantenidas, con Graphiti cerca detrás con su enfoque de grafo temporal. nano-graphrag y fast-graphrag son las dos que los posts antiguos siguen recomendando solo por reputación, y ninguna ha publicado en medio año.
Cómo elegir: quédate con microsoft/graphrag si quieres la implementación de referencia con los cuatro métodos de consulta oficiales, con LightRAG si quieres el proyecto más activo y una huella más ligera, y con una biblioteca mantenida por el proveedor como neo4j-graphrag-python si ya usas la base de datos de ese proveedor. Evita cualquier cosa cuyo último push sea anterior a tu proyecto en medio año.
Graphiti merece una nota acotada: su diseño de grafo temporal está construido para recuperar sobre datos sensibles al tiempo, y se solapa con la memoria de agentes, que cubrimos por separado en nuestra guía de Graphiti y memoria de grafos temporales. Para ver el campo completo, mira las mejores herramientas RAG.
Qué se rompe después del día 200: deriva del grafo y re-extracción
La deriva del grafo es el impuesto que pagas después del lanzamiento, y es la objeción número uno de los profesionales por una razón. Todos los tutoriales tratan el grafo como algo que construyes una vez. Los equipos reales se atascan en el día 200.
Tres cosas se degradan. Primero, el reindexado al actualizar documentos. Cuando 40 documentos cambian, no puedes simplemente re-incrustarlos; tienes que volver a ejecutar la extracción LLM sobre los fragmentos cambiados, reconciliar las entidades nuevas contra el grafo viejo y recalcular las comunidades afectadas y sus resúmenes. Una guía en Medium llama fácil a la actualización incremental. Los profesionales en r/Rag discrepan. El autor de un hilo del 2026-04-25 corriendo BM25 más BGE-M3 sobre unos 600 documentos lo dijo sin rodeos: «La extracción de entidades y relaciones basada en LLM es ruidosa, y reindexar al actualizar documentos pinta doloroso».
Segundo, la degradación de la resolución de entidades. «Acme Corp», «Acme» y «ACME Corporation» llegan en documentos distintos con meses de diferencia y se dividen en tres nodos que deberían ser uno. Nada los fusiona automáticamente.
Tercero, relaciones que eran ciertas al momento de extracción y dejaron de serlo en silencio. Nadie recibe una alerta cuando una arista reports_to se queda obsoleta.
def on_documents_changed(changed_docs):
stale = find_affected_nodes(changed_docs)
re_extract(changed_docs)
reconcile_entities(stale)
recompute_communities(affected_only=True)
re_summarize(affected_communities)Un repositorio de código es el peor caso, y el más interesante. El autocompletado ya sugiere «graphrag for codebase», «graphrag claude code» y «graphrag mcp server», y un repositorio es un grafo que cambia cada hora: cada commit reescribe aristas de llamada, mueve símbolos y borra funciones. Eso es deriva del grafo en un horario que ningún reindexado nocturno puede seguir del todo. También es por eso que las herramientas serias de grafos de código se apoyan en parsers deterministas como tree-sitter y LSP para las aristas y reservan el LLM para la prosa que las rodea: docstrings, mensajes de commit, hilos de revisión. Si estás grafeando un repo, grafea la capa que se mueve lento con el LLM y la que se mueve rápido con un parser.
¿Qué dicen realmente los desarrolladores sobre GraphRAG?
Los desarrolladores en activo están divididos, y Google parece saberlo: un hilo de Reddit posiciona segundo en «graphrag vs rag», lo cual es el buscador diciéndote que este tema quiere opinión de pares, no copy de proveedores.
El escepticismo es real. En el hilo de r/Rag de 2024 «Would you always recommend (knowledge) graph RAG over normal RAG?» (10 puntos, 86 % de votos positivos), u/EncartaIt escribió: «Todos los tutoriales que he encontrado son demasiado simplistas y no hacen un caso sólido para el patrón de grafo de conocimiento». u/Prestigious_Run_4049 fue más directo: «Creo que graph rag es puro hype. A la gente le encanta hablar de ello y suena genial, pero nadie lo usa de verdad en casos de uso reales». No todos están de acuerdo. u/pytheryx, argumentando desde producción, señaló que la recuperación con grafos gana en preguntas tipo lista que necesitan contexto de más fragmentos de los que devuelve top_k; su corpus de whitepapers necesita unos 50 fragmentos para una respuesta completa.
El hilo de 2026 es más mesurado. u/Popular_Sand2773: «La mayoría de los montajes de graph rag simplemente hacen trampa a escala. Corres una búsqueda vectorial o de metadatos estándar para encontrar nodos semilla y luego caminas por el grafo». u/ggone20, corriendo un sistema de unos 300 millones de artefactos: «A escala, literalmente no puedes vivir sin ellos para responder preguntas reales».
Nuestra lectura coincide con el argumento más afilado de ambos hilos: el punto de inflexión es la complejidad de tus preguntas, no el tamaño de tu corpus. Eso es también lo que encontraron los benchmarks de arriba, por eso nos alineamos con los profesionales que acotan la herramienta al trabajo multi-salto en lugar de con los que la dan por muerta.
Cómo lo abordamos en Techsy
Aquí está la secuencia que usamos en los proyectos de clientes, y es deliberadamente aburrida.
Primero, demuestra el techo de la recuperación híbrida. La mayoría de peticiones de «necesitamos un grafo» que oímos son en realidad un problema de chunking o de reranking disfrazado. Un pipeline de BM25 más vectores con un reranker decente responde más de lo que los equipos esperan.
Segundo, ejecuta Basic Search como grupo de control sobre tu propio corpus antes de construir nada. Para eso sirve exactamente el cuarto método de consulta: una línea base vectorial simple contra la que comparar el grafo, sobre tus datos, con tus preguntas.
Tercero, construye el grafo solo cuando una clase de preguntas medida falle ese control. Si las consultas multi-salto o globales al corpus fallan, tienes un caso real. Si no fallan, te acabas de ahorrar una factura de indexado y un problema de deriva.
¿Quieres una segunda opinión sobre tu stack de recuperación? Pide una consulta gratuita.
Sobre el autor
Mert Batur es cofundador de Techsy.io, donde el equipo envía agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre el stack de herramientas LLM que el equipo de Techsy usa de verdad en producción. En los proyectos de clientes, él toma las decisiones de arquitectura de recuperación: cuándo basta con la búsqueda híbrida y cuándo un corpus necesita de verdad un grafo. Conecta con él en LinkedIn.
Preguntas frecuentes
¿Cómo funciona GraphRAG?
GraphRAG indexa tus documentos en un grafo de conocimiento. Un LLM extrae entidades y relaciones de cada fragmento, el algoritmo Leiden agrupa esas entidades en comunidades y cada comunidad recibe un resumen. Al consultar, el motor busca en el grafo y en esos resúmenes, así que puede conectar hechos que están en fragmentos distintos.
¿En qué se diferencia GraphRAG del RAG?
El RAG estándar recupera los k fragmentos más similares y se los pasa al modelo. GraphRAG recupera estructura: entidades, las relaciones entre ellas y resúmenes de comunidad preescritos. Esa estructura extra es lo que le permite responder preguntas multi-salto y globales al corpus, y también es lo que hace el indexado más lento y más caro.
¿Cuándo debería usar GraphRAG?
Úsalo cuando tus preguntas crucen entidades o abarquen todo el corpus, como preguntas de solapamiento de proveedores o análisis de temas recurrentes sobre miles de documentos. Sáltatelo para consultas de hechos de un solo salto, corpus que cambian rápido y presupuestos ajustados de latencia o coste. Si un pipeline híbrido simple ya responde una clase de pregunta, el grafo añade coste sin añadir valor.
¿GraphRAG está muerto?
No, pero tampoco es la opción por defecto. Los benchmarks de 2026 muestran que con frecuencia rinde peor que el RAG clásico en tareas cotidianas, lo cual mató el hype, mientras sigue ganando en preguntas multi-salto y de agregación. El encuadre honesto es situacional: GraphRAG se gana su coste para los tipos de pregunta correctos y pierde dinero para el resto.
¿Cuáles son los métodos de consulta de GraphRAG?
El motor de consultas oficial trae cuatro: Local Search para preguntas centradas en entidades, Global Search para agregación global al corpus, DRIFT Search para una mezcla recursiva de ambos y Basic Search para recuperación vectorial simple. Una quinta función, Question Generation, se apoya encima. Basic Search es el que más importa: es el grupo de control contra el que comparas el grafo.
¿Cuánto cuesta indexar con GraphRAG?
El coste aparece al indexar, en las llamadas LLM que extraen entidades y relaciones de cada fragmento más el resumen de comunidades. Microsoft Research reportó el indexado de LazyGraphRAG al 0,1 % del coste de GraphRAG completo e idéntico al del RAG vectorial, pero esa variante se envió a productos de Microsoft, no a la biblioteca de código abierto. Nosotros no hemos corrido un indexado con precios propio.
¿Puedo correr GraphRAG en local con Ollama?
Sí. La biblioteca microsoft/graphrag te permite apuntar el indexado y las consultas a un modelo local servido por Ollama, lo que quita las tarifas de API por token del paso de extracción. Cambias velocidad y calidad por coste: los modelos locales son más débiles en extracción de entidades, así que espera grafos más ruidosos y ejecuciones de indexado más largas en hardware modesto.
¿Qué es mejor, LightRAG o Microsoft GraphRAG?
Optimizan para cosas distintas. LightRAG (38.353 estrellas, push el 2026-07-30) es la más activa y más ligera de correr; microsoft/graphrag (35.088 estrellas, v3.1.1) es la implementación de referencia con los cuatro métodos de consulta oficiales. Elige LightRAG para un grafo de producción eficiente, y la de Microsoft para un comportamiento fiel a la especificación y el grupo de control de Basic Search.
¿Quién creó GraphRAG y cuándo?
Microsoft Research creó GraphRAG. El equipo publicó el paper en 2024 y mantiene el repositorio de código abierto microsoft/graphrag bajo licencia MIT, con documentación en microsoft.github.io/graphrag. La biblioteca de referencia llegó a la v3.1.1 el 2026-07-18, y un ecosistema activo de implementaciones de terceros, incluyendo LightRAG y Graphiti, ha crecido a su alrededor.
El veredicto: cuándo un grafo se gana su coste
La evidencia apunta en una dirección, así que aquí va la postura.
- GraphRAG no está muerto. Es situacional, y los benchmarks de 2026 lo dicen sin rodeos.
- Se gana la factura de indexado en preguntas de entidades multi-salto y agregación global al corpus. Pierde dinero en consultas de un solo salto.
- El coste es una factura de indexado, y la variante barata que todos citan, LazyGraphRAG, nunca llegó a la biblioteca de código abierto.
- El grafo se degrada después del lanzamiento: la resolución de entidades deriva y las relaciones se quedan obsoletas, así que presupuesta el reindexado.
- Ejecuta Basic Search como grupo de control sobre tu propio corpus antes de construir nada.
Una frase: un grafo de conocimiento se gana su coste cuando tus preguntas son multi-salto o globales al corpus, y no antes. Si quieres una segunda opinión sobre tu stack de recuperación, pide una consulta gratuita.