¿Ha vivido la situación en la que su sistema RAG devuelve fragmentos relevantes pero la respuesta sigue siendo incorrecta? Busca quién aprobó el contrato n.º 2024-0034 y el sistema encuentra el documento sobre procesos de aprobación y el documento que contiene el número de contrato — pero no conecta que el aprobador fue una persona concreta mencionada en un tercer documento. Cada paso tiene la respuesta en otro sitio. El problema no está en la búsqueda; está en las relaciones que faltan.
Precisamente para este tipo de preguntas nació GraphRAG — una extensión del retrieval-augmented generation clásico con un grafo de conocimiento (knowledge graph). No es una actualización que basta con activar. Es una decisión arquitectónica con costes reales y beneficios reales — pero solo para una determinada clase de problemas. En este artículo analizamos qué resuelve GraphRAG, cómo funciona técnicamente, cuál es el coste real y en qué casos merece la pena de verdad.
Lo que el RAG clásico no puede hacer
El pipeline RAG estándar funciona bien cuando la respuesta a una pregunta se encuentra en uno o dos fragmentos de texto cercanos. Se toma la pregunta, se convierte en embedding, se localizan los k fragmentos más próximos en la base de datos vectorial, se le pasan al modelo y se obtiene la respuesta.
Este enfoque tiene un punto ciego: las relaciones entre entidades a lo largo de documentos. El RAG clásico no sabe que la persona mencionada en el documento A es la misma que en el documento C, que el evento descrito en un informe es la causa del problema analizado en otro informe, o que el proveedor de la factura está vinculado patrimonialmente con la empresa de la reclamación. La similitud vectorial coteja texto, no conexiones semánticas.
Aquí es donde entra en juego GraphRAG. En lugar de fragmentos aislados, trabaja con un grafo — nodos (entidades: personas, empresas, productos, procesos, ubicaciones) y aristas (relaciones: aprobó, suministra, es responsable de, causó, pertenece a). La recuperación deja de ser «encuentra texto similar» y pasa a ser «encuentra el camino o subgrafo relevante para esta pregunta».
Cómo funciona GraphRAG técnicamente
La implementación original de Microsoft, que popularizó el término, consta de dos fases: indexación y consulta.
Fase de indexación
Es el paso más costoso. Para cada documento del corpus se invoca un LLM (o una serie de llamadas LLM) que extrae entidades y relaciones. A partir de frases como *«El ingeniero Novák aprobó el cambio del equipo P-12 en la línea 3 el 14 de enero»*, extrae los nodos Novák (persona), P-12 (equipo), Línea 3 (ubicación) y las aristas aprobó → cambio, está ubicado en → Línea 3.
Sobre el grafo así extraído se aplica detección de comunidades (algoritmos como Leiden o Louvain), que agrupa entidades relacionadas en comunidades — por ejemplo, todas las entidades relativas a la línea 3, o todas las transacciones con un proveedor concreto. Para cada comunidad se genera una descripción resumida (denominada community report), que sirve como contexto de alto nivel al responder preguntas globales.
Fase de consulta
Cuando llega una pregunta, el sistema elige entre dos estrategias:
Local search — la pregunta se refiere a entidades concretas o relaciones locales. El sistema localiza los nodos relevantes y recorre el subgrafo de su entorno. Adecuada para preguntas del tipo «quién aprobó este pedido» o «qué equipos están relacionados con esta avería».
Global search — la pregunta exige sintetizar información de todo el corpus. El sistema trabaja con community reports en lugar de documentos en bruto. Adecuada para preguntas como «cuáles son los principales patrones de avería en las líneas durante el último año» o «identifica proveedores con retrasos de entrega reiterados».
Frente al RAG clásico, GraphRAG añade toda una capa de estructura semántica — pero esta capa no es gratuita.
El coste real de la indexación
Aquí es donde la realidad sorprende a muchos interesados en GraphRAG. Microsoft reportó en su investigación que la indexación de grandes datasets con la implementación original costaba del orden de decenas de miles de USD — en función del tamaño del corpus y el modelo elegido. El motivo: cada documento (o cada chunk) requiere una llamada LLM para la extracción de entidades. Con cientos de miles de documentos, el número de tokens escala a cifras astronómicas.
Esto tiene una consecuencia concreta: la indexación no es un proceso único. Cuando un documento cambia o se añade uno nuevo, hay que actualizar el grafo. A diferencia de una base de datos vectorial, donde basta con re-embedar los nuevos fragmentos, la actualización del grafo puede exigir volver a recorrer el entorno del nodo modificado.
Este es el motivo fundamental por el que GraphRAG no es adecuado para corpus dinámicos con alta frecuencia de actualizaciones.
LazyGraphRAG y alternativas open-source
Microsoft era consciente del problema de costes y publicó LazyGraphRAG — una variante que aplaza la extracción LLM de entidades y relaciones. En lugar de extraer entidades para cada documento durante la indexación, construye el grafo base con métodos más baratos (extracción NLP, keyword extraction) y realiza las llamadas LLM en el momento de la consulta, solo para el subconjunto relevante. Resultado: costes de indexación notablemente inferiores con una calidad de respuesta comparable para muchos tipos de preguntas.
La comunidad ha desarrollado entre tanto varias implementaciones alternativas con distintos compromisos:
- LightRAG — hace énfasis en la eficiencia, menos llamadas LLM durante la indexación, buenos resultados en documentos técnicos
- HippoRAG — inspirado en la memoria del hipocampo, interesante para la retención de conocimiento a largo plazo
- Fast-GraphRAG — orientado a la velocidad manteniendo la estructura de grafo
Ninguna de estas alternativas es «la ganadora en todo» — cada una hace compromisos distintos entre coste de indexación, calidad del grafo y velocidad de consulta. Para despliegues en producción recomendamos probar la alternativa concreta sobre su corpus real, no sobre datasets de benchmark.
Cuándo compensa GraphRAG
Esta es la pregunta clave que hay que hacerse antes de cualquier decisión de adopción.
GraphRAG tiene un beneficio real en:
- Preguntas multi-hop — la respuesta exige conectar información de tres o más documentos a lo largo de una cadena de relaciones. «¿Qué tecnólogo es responsable del equipo que causó la avería en la línea con el OEE más alto?» — tres entidades, dos aristas, tres documentos.
- Análisis de impacto — «¿qué procesos se verán afectados si cambiamos el proveedor X?» — requiere recorrer el grafo de dependencias.
- Resumen de entidades — «resume todos los incidentes relacionados con el producto Y en los últimos dos años» — las comunidades del grafo lo gestionan mejor que los chunks de una base de datos vectorial.
- Detección de patrones — «identifica patrones recurrentes en las reclamaciones por proveedor y categoría de equipo» — búsqueda global a través de community reports.
- Compliance y audit trails — «demuestra la cadena de aprobaciones para el contrato Z» — tarea directa para el traversal de grafo.
Probablemente no necesita GraphRAG si:
- Sus preguntas son mayoritariamente factuales y la respuesta está en un único fragmento («¿cuál es la temperatura máxima del equipo P-12?»).
- Su corpus cambia diariamente o varias veces al día — los costes de re-indexación serán prohibitivos.
- Tiene menos de unos pocos miles de documentos — el hybrid search con rerank clásico gestiona la mayoría de los casos a una fracción del coste y la complejidad.
- No tiene una ontología de entidades y relaciones claramente definida — un grafo extraído de texto no estructurado sin contexto de dominio contendrá mucho ruido.
La cifra reportada por Microsoft — GraphRAG alcanza alrededor del 80 % de respuestas correctas en preguntas multi-hop frente a alrededor del 50 % para RAG naïve — es orientativa y se aplica a un tipo concreto de preguntas sintéticas de benchmark. La mejora real sobre su corpus puede ser diferente. Mida siempre sobre sus propios datos.
Integración con el stack RAG existente
GraphRAG no es un sustituto de la base de datos vectorial — es un complemento. Los sistemas de producción modernos que lo adoptan operan típicamente con una arquitectura híbrida:
- 1.Base de datos vectorial (p. ej.
Qdrant) para dense retrieval — rápido, económico, adecuado para preguntas factuales. - 2.Capa de grafo (neo4j, Amazon Neptune, o un grafo en memoria para corpus más pequeños) para consultas relacionales.
- 3.Router/orquestador — clasifica la pregunta entrante y decide qué capa usar (o combinar ambas).
La orquestación de este sistema es más compleja. LangGraph (framework para grafos de agentes con estado) es la elección natural para este patrón — permite definir nodos de decisión que determinan dinámicamente si la consulta va por la base de datos vectorial, por la capa de grafo o necesita ambas. Para la evaluación de resultados merece la pena mirar las métricas de RAGAS — véase cómo evaluar RAG.
Nota importante sobre herramientas: LlamaIndex dispone en sus versiones actuales de soporte nativo para indexación GraphRAG, lo que reduce considerablemente la barrera de implementación respecto a ensamblar el pipeline manualmente.
Dónde vemos GraphRAG en la práctica industrial
De los despliegues que resolvemos con clientes del sector manufacturero e ingenieril, GraphRAG o los enfoques híbridos de grafo se revelan justificados en estos escenarios:
Gestión de documentación técnica — grandes empresas con miles de manuales técnicos, SOPs, informes de servicio y protocolos de revisión. La pregunta «¿cuál es el procedimiento ante una avería de la bomba tipo X en la zona ATEX II?» requiere conectar el manual del equipo, el protocolo ATEX de la zona, el SOP de seguridad y el historial de intervenciones de servicio. El RAG clásico no lo resuelve de forma fiable.
Compliance y audit trails regulatorios — en sectores regulados (farmacia, energía, alimentación) hay que demostrar la cadena de responsabilidad y aprobaciones. El grafo es la estructura de datos natural para «quién aprobó, cuándo, en base a qué, con referencia a qué normativa».
Análisis de la cadena de suministro — conexiones entre proveedores, componentes, reclamaciones y averías. «¿Cuántos componentes críticos provienen de proveedores que han tenido más de 10 días de retraso en el último año?» — multi-hop a través de cuatro tipos de entidades.
Por el contrario, para chatbots internos sobre documentación FAQ o búsqueda en catálogos de productos, GraphRAG es complejidad innecesaria. Véase también arquitecturas agentic RAG, donde la capa de grafo se combina de forma natural con el retrieval controlado por agentes.
Procedimiento práctico: cómo empezar
Si ha decidido probar GraphRAG, recomendamos un enfoque incremental:
- 1.Defina la ontología — antes de cualquier implementación, defina explícitamente qué tipos de entidades y relaciones quiere tener en el grafo. Sin este paso obtendrá un grafo ruidoso lleno de nodos irrelevantes.
- 2.Empiece con un corpus pequeño — 1 000–5 000 documentos bastan para verificar si la estructura de grafo responde a sus preguntas. La indexación será manejable incluso con LazyGraphRAG.
- 3.Compare con el baseline — para cada tipo de pregunta (factual, multi-hop, resumen) mida la precisión de GraphRAG frente al hybrid search. Si GraphRAG no añade más de un 15 % sobre sus preguntas reales, valore si la complejidad está justificada.
- 4.Planifique el ciclo de actualización — decida cómo mantendrá el grafo actualizado. ¿Re-indexación batch una vez a la semana? ¿Actualización incremental al añadir documentos? Esta decisión condicionará la arquitectura global.
- 5.No olvide el fallback — en un sistema de producción mantenga siempre el vector retrieval clásico como respaldo para los casos en que la consulta de grafo no devuelva resultados suficientemente fiables.
Preguntas frecuentes
¿Es GraphRAG mejor que el RAG clásico?
Depende del tipo de preguntas. Para preguntas multi-hop que exigen conectar entidades a lo largo de documentos — sí, claramente. Para preguntas factuales simples con la respuesta en un único fragmento, GraphRAG es innecesariamente costoso y más lento. Mida siempre sobre su caso de uso concreto.
¿Cuánto cuesta la indexación de GraphRAG en la práctica?
La implementación original de Microsoft reporta costes del orden de decenas de miles de USD para corpus grandes. LazyGraphRAG y las alternativas open-source (LightRAG, Fast-GraphRAG) reducen significativamente estos costes. El precio exacto depende del tamaño del corpus, el LLM elegido y la granularidad de la extracción de entidades.
¿Necesito una base de datos de grafo especial?
No necesariamente. Para grafos más pequeños (hasta el orden de millones de nodos) funciona la representación en memoria o librerías como networkx. Para despliegues de producción más grandes, Neo4j, Amazon Neptune o TigerGraph son las opciones estándar. Algunas implementaciones (p. ej. LlamaIndex GraphRAG) abstraen la capa de almacenamiento y permiten elegir el backend.
¿Funciona GraphRAG para documentos en español?
La extracción de entidades depende de la calidad del LLM que la realiza. Los modelos frontier (Claude, GPT, Gemini) manejan el español correctamente. Con modelos locales más pequeños hay que verificar la calidad de la extracción sobre una muestra de texto en español antes del despliegue. La estructura de grafo en sí es language-agnostic.
¿Cuándo decidir no usar GraphRAG?
Si su corpus cambia diariamente, si tiene menos de unos pocos miles de documentos, si sus preguntas son mayoritariamente de un solo salto, o si no tiene capacidad para definir y mantener una ontología de entidades. En estos casos, el hybrid search clásico con rerank le dará el 90 % del resultado con el 10 % del coste y la complejidad.
*GraphRAG no es para todos los proyectos — pero para aquellos en los que las relaciones entre entidades determinan la corrección de la respuesta, es una herramienta sin alternativa. En MP Industrial Solutions ayudamos a las empresas a evaluar si su caso de uso concreto es candidato a GraphRAG, a diseñar la ontología y a estimar los costes reales de indexación antes de adquirir ningún compromiso. Si está resolviendo preguntas complejas de documentación o compliance, empiece con una evaluación.*