Cuando Microsoft publicó el paper de GraphRAG a mediados de 2024, la promesa era clara: donde el RAG vectorial clásico fallaba, preguntas que exigían sintetizar información de varios documentos o seguir relaciones entre entidades, un grafo construido a priori con el propio LLM daba mejores respuestas. Un año y medio después, en abril de 2026, queda suficiente despliegue real para separar el mito del patrón. La respuesta corta: GraphRAG funciona donde la información tiene estructura relacional densa y falla caro donde solo hay documentos sueltos. La respuesta larga merece el resto del artículo.
Qué es GraphRAG en la práctica
El RAG vectorial clásico recupera fragmentos de texto por similitud semántica con la pregunta. Funciona bien para preguntas puntuales donde la respuesta vive literalmente en un fragmento. Falla cuando la pregunta exige relaciones transitivas, “qué clientes están afectados por el cambio de política que aprobamos la semana pasada”, o síntesis global, “cuáles son los temas recurrentes en las quejas del último trimestre”. No hay un fragmento que contenga la respuesta; hay que navegar el corpus.
GraphRAG resuelve ese problema construyendo durante la ingesta un grafo de entidades y relaciones extraídas de los documentos por un LLM, más un esquema de comunidades calculado sobre el grafo. En tiempo de consulta, el sistema decide si la pregunta es local, donde usa recuperación vectorial más contexto del subgrafo, o global, donde agrega respuestas por comunidad para sintetizar. El resultado es notablemente mejor en preguntas con alcance amplio, y esa es la parte defendible de la promesa.
Lo que funciona y lo que no, con un año de datos
Los despliegues que han sobrevivido comparten un perfil claro. Corpus con entidades identificables y recurrentes, clientes, productos, contratos, procesos, donde las relaciones son estables y nombrables. Helpdesks corporativos donde las entidades son sistemas, módulos y clientes; áreas legales donde son contratos, cláusulas y partes; soporte a ventas donde son cuentas, oportunidades y productos. En estos casos GraphRAG pasa de novedad a herramienta operativa y el retorno es visible.
Los despliegues que se han abandonado o reducido comparten otro perfil. Corpus de documentos sueltos sin jerarquía clara, actas sin estructura recurrente, notas personales, correo corporativo mezclado, tickets sin taxonomía. Aquí el grafo extraído por el LLM acaba siendo ruido con aspecto de señal: entidades duplicadas con grafías variantes, relaciones inventadas por alucinación, comunidades sin cohesión semántica. El coste de ingesta se dispara, el mantenimiento se vuelve infernal, y la calidad de respuesta no supera al RAG vectorial bien afinado.
La regla que ha emergido es sencilla: si no puedes explicar a un humano cuáles son las cinco tipologías de entidades más importantes de tu corpus, tu corpus probablemente no esté listo para GraphRAG. No es un defecto de la técnica, es un requisito de entrada que se pasó por alto en muchos pilotos.
El coste real de la ingesta
La parte que no cuentan los demos es el coste de construir el grafo. Extraer entidades, relaciones y comunidades con un LLM cuesta, en tokens, entre diez y treinta veces más que vectorizar el mismo corpus. Para un corpus de un millón de documentos medianos, eso son miles de euros solo en la primera ingesta, y cada actualización masiva repite parte del ejercicio. Los equipos que han hecho los números cuidadosamente suelen descubrir que el coste de ingesta supera con mucho el coste de consulta, inversión del patrón clásico de RAG vectorial.
Las optimizaciones que han emergido son pragmáticas. Usar modelos pequeños y baratos para la extracción y modelos frontera solo para la consulta es la primera palanca. La ingesta incremental, donde solo los documentos nuevos o modificados se procesan y su grafo se fusiona con el existente, es la segunda y la que separa los prototipos de los sistemas productivos. La deduplicación de entidades, crítica para no explotar el grafo con variantes, ha generado un subcampo propio donde el embedding semántico de nombres más reglas de fusión ha ganado sobre enfoques puramente LLM.
# Patrón de ingesta incremental GraphRAG, abril 2026
def ingest(doc, graph_store, entity_resolver):
extracted = llm_small.extract_entities_and_relations(doc)
resolved = entity_resolver.resolve(extracted, graph_store)
graph_store.upsert_nodes(resolved.nodes)
graph_store.upsert_edges(resolved.edges)
affected_communities = graph_store.communities_touching(resolved.nodes)
for community in affected_communities:
community.invalidate_summary()
# summaries se regeneran bajo demanda, no en ingestaMantenimiento: lo que nadie avisa
Un grafo corporativo no es inmutable. Clientes se fusionan, productos se renombran, departamentos se reorganizan. Un grafo construido hace seis meses con entidades que hoy son otras entidades empieza a responder con información estructuralmente obsoleta aunque los documentos sean nuevos. Los equipos que han evitado problemas tienen un proceso de reconciliación periódica donde entidades se unen, se dividen o se renombran según cambios del negocio, y donde las comunidades se recalculan tras umbrales de modificación.
La trazabilidad es la otra pieza incómoda. Cuando un humano pide explicar por qué el sistema dio una respuesta global, el grafo ofrece un esqueleto útil: entidades involucradas, relaciones consultadas, comunidades agregadas, documentos fuente de cada arista. Pero esa cadena de razonamiento solo es revisable si se guarda desde el principio. Los despliegues que se apoyaron en los trazados implícitos del LLM han tenido problemas para auditar; los que desde el principio persistieron el camino de recuperación como estructura consultable tienen una ventaja enorme para cumplimiento.
Arquitecturas que han sobrevivido
Hay tres patrones que se repiten en los despliegues productivos. El híbrido vectorial más grafo, donde el retriever decide en cada consulta si activa el grafo o se queda en vectorial, es el más común y el más defendible: gastas el grafo donde aporta y no cuando no. La extracción en capas, donde un LLM pequeño extrae entidades y uno grande consolida y resume comunidades bajo demanda, es el patrón de coste estable. Y el grafo federado, donde cada dominio corporativo mantiene su propio grafo con esquema propio y un grafo superior de entidades comunes sirve de puente, es el patrón que sobrevive a reorganizaciones sin reingerir todo.
El almacenamiento ha convergido menos de lo esperado. Neo4j sigue siendo el más común por inercia y herramientas, pero PostgreSQL con la extensión Apache AGE o directamente con tablas de aristas ha ganado terreno porque muchos equipos prefieren no añadir una base de datos más al inventario. Las soluciones propietarias de grafos gestionados en nube tienen clientes contentos pero también facturas que sorprenden. Para grafos medianos, bajo el millón de entidades, PostgreSQL con índices bien pensados es económicamente sensato y operativamente familiar.
Mi lectura
GraphRAG no es una bala de plata ni un experimento académico. Es una herramienta con un perfil de aplicación claro: si tu corpus tiene estructura relacional explícita y preguntas que exigen síntesis, vale el coste. Si no, el RAG vectorial bien afinado, con reranking y mejor chunking, sigue siendo suficiente para el 80% de casos y mucho más barato de operar.
La decisión que más separa éxitos de fracasos es la del alcance inicial. Los equipos que empezaron con un dominio acotado, contratos, tickets de un producto concreto, un área legal específica, aprendieron el coste real, depuraron el pipeline de extracción y ampliaron desde una base probada. Los que empezaron queriendo unificar todo el conocimiento de la empresa desde el primer día gastaron mucho y concluyeron poco. La lección es clásica y transferible: con GraphRAG, el éxito se construye por amplificación desde un núcleo que funciona, no por ambición desde el mapa completo.
