Graph RAG: cuando las relaciones importan más que la similitud

Graph RAG es un enfoque de Retrieval-Augmented Generation que almacena el conocimiento no (solo) como vectores, sino como un grafo de conocimiento formado por entidades y sus relaciones. Mientras que el RAG clásico responde a una pregunta por similitud semántica, buscando los pasajes de texto más cercanos a la consulta, Graph RAG sigue las conexiones explícitas entre entidades. Eso lo hace fuerte allí donde las relaciones y las inferencias en varios pasos (multi-hop) importan más que la mera similitud textual.

• Qué es: una variante de RAG que utiliza un grafo de conocimiento (entidades más relaciones) como fuente de conocimiento, sola o además del índice vectorial.
• Cuándo ayuda: en preguntas multi-hop, preguntas sobre relaciones y preguntas globales de visión general sobre todo un corpus.
• Cuánto cuesta: costes de indexación y mantenimiento más altos que el RAG vectorial, porque la extracción del grafo se hace con ayuda de un LLM.

Por qué la similitud pura se queda corta

El RAG clásico trabaja en dos fases: en la ruta de indexación, los documentos se analizan, se dividen en chunks, se convierten en vectores con un modelo de embedding y se escriben en una base de datos vectorial. En la ruta de consulta, la pregunta también se convierte en embedding, se recuperan los chunks más similares (top-k), opcionalmente se combinan con BM25 mediante búsqueda híbrida y se afinan con un reranker, y al final todo acaba en el prompt del generador. Este patrón es sólido y suficiente para la mayoría de las preguntas de conocimiento. El Contextual Retrieval de Anthropic muestra, por ejemplo, que los errores de recuperación pueden reducirse hasta un 67 % con encabezados de contexto específicos de cada chunk y reranking (Anthropic, situación en 09/2024).

El punto ciego aparece en dos tipos de preguntas:

• Preguntas multi-hop: «¿Qué proveedores de nuestro mayor cliente están ellos mismos afectados por sanciones?» requiere una cadena de inferencias (cliente -> proveedores -> estado de sanciones) que no figura en ningún chunk individual. Aquí la similitud top-k a menudo solo devuelve fragmentos, sin establecer la conexión.
• Preguntas globales de visión general: «¿Cuáles son los cinco temas centrales en el conjunto de los 2000 tickets de soporte?» no se puede responder recuperando entre cinco y diez chunks similares. La respuesta exige una agregación sobre todo el corpus.

Justo aquí entra Graph RAG: en lugar de encontrar trozos de texto aislados, navega por una estructura de conocimiento explícita.

Construir un grafo de conocimiento en lugar de (o además de) un índice vectorial

El núcleo de Graph RAG es la indexación. A partir de los documentos fuente se extrae un grafo con ayuda de un LLM:

1. Extracción de entidades: el LLM identifica entidades (personas, organizaciones, productos, lugares, conceptos) y las describe.
2. Extracción de relaciones: reconoce las relaciones entre esas entidades («suministra a», «es filial de», «causa»), con su descripción y, si procede, un peso.
3. Construcción del grafo: las entidades se convierten en nodos y las relaciones en aristas. Las entidades mencionadas varias veces se fusionan.

El enfoque de código abierto GraphRAG de Microsoft (Microsoft Research) amplía este patrón básico con dos pasos clave (situación en 2026):

• Detección de comunidades: mediante clustering de grafos (por ejemplo, el algoritmo de Leiden), los nodos estrechamente conectados se agrupan en «comunidades» jerárquicas, es decir, subgrafos temáticos.
• Resúmenes de comunidades: para cada comunidad, un LLM genera un resumen ya en el momento de la indexación. Estos resúmenes son la clave para las preguntas globales: ante una pregunta de visión general no se usan chunks individuales, sino resúmenes de comunidades como piezas de una respuesta map-reduce.

De ahí surgen dos modos de consulta: Local Search responde preguntas concretas sobre una entidad determinada y su vecindad en el grafo; Global Search responde preguntas temáticas sobre todo el corpus a partir de los resúmenes de comunidades.

Pseudocódigo: indexación y consulta

```text

Indexación (offline, intensiva en LLM)

for documento in corpus:
entidades, relaciones = LLM_extraer(documento)
grafo.merge(entidades, relaciones)

comunidades = cluster(grafo) # p. ej., Leiden
for c in comunidades:
c.summary = LLM_resumir(c) # resumen de comunidad

Consulta (online)

if pregunta_es_global(pregunta):
respuestas_parciales = [LLM(pregunta, c.summary) for c in comunidades_relevantes]
respuesta = LLM_reduce(pregunta, respuestas_parciales) # Global Search
else:
subgrafo = grafo.recorrer(start=entidades_de(pregunta), hops=2)
respuesta = LLM(pregunta, subgrafo + chunks_asociados) # Local Search
```

Graph RAG frente a RAG vectorial: comparación directa

La decisión no consiste en elegir uno u otro: depende del tipo de pregunta y del presupuesto. La siguiente matriz resume las diferencias.

Los valores de latencia y de búsqueda híbrida para el RAG clásico proceden de la base de investigación de Blck Alpaca (matriz comparativa de arquitecturas RAG). La caracterización de Graph RAG se basa en conocimiento general contrastado sobre el proyecto GraphRAG y sobre los índices de grafo de conocimiento en frameworks como LlamaIndex.

Costes y complejidad comparados

La mayor diferencia está en la indexación. En el RAG vectorial, la operación única más cara es el embedding por chunk: como orden de magnitud, la base de investigación indica costes de indexación de unos 0,02 a 0,13 dólares estadounidenses por millón de tokens y, con el prompt caching de Anthropic para Contextual Retrieval, de aproximadamente 1,02 dólares estadounidenses por millón de tokens de documento (situación en 09/2024). Graph RAG exige varias pasadas de LLM por documento: extracción de entidades, extracción de relaciones y resúmenes de comunidades. Eso multiplica los costes y el tiempo de indexación.

Ejemplo: 50.000 documentos

Supongamos que una agencia indexa para un cliente un corpus de conocimiento de 50.000 documentos:

• RAG vectorial: embedding único más índice híbrido. Los costes principales son la API de embeddings y el alojamiento de la base de datos vectorial. Las actualizaciones se hacen de forma incremental mediante ID de documento estables.
• Graph RAG: por cada documento se necesitan varias llamadas al LLM para la extracción y, después, llamadas al LLM por comunidad para los resúmenes. Ya con un corpus de tamaño medio, los costes de indexación multiplican los del RAG vectorial, a lo que se suma el esfuerzo operativo adicional para el esquema del grafo, la deduplicación de entidades y la reindexación cuando hay cambios importantes.

La regla general: Graph RAG compensa cuando el beneficio de las respuestas basadas en relaciones justifica el esfuerzo adicional, no como opción por defecto. La investigación de Blck Alpaca advierte en general contra el antipatrón «RAG como bala de plata»; en Graph RAG esto se aplica con más fuerza aún, porque aquí el coste total de propiedad es bastante más alto.

Cuándo usar Graph RAG y cuándo no

Adecuado si:

• las respuestas tienen que conectar información de muchos documentos (cadenas de suministro, estructuras organizativas, redes de cumplimiento normativo, panoramas de investigación y patentes).
• las relaciones explícitas entre entidades son centrales para el negocio.
• hay que responder preguntas globales de visión general y temáticas sobre todo un corpus.

Mejor no, si:

• las preguntas se refieren sobre todo a hechos aislados o a pasajes muy acotados; aquí basta con un RAG híbrido con reranking.
• el corpus es pequeño o se reescribe por completo con frecuencia (el mantenimiento del grafo se convierte en un cuello de botella).
• el presupuesto no da para una indexación intensiva en LLM.

En la práctica, la arquitectura híbrida es la más sólida: el retrieval vectorial o híbrido aporta una cobertura semántica amplia y el grafo de conocimiento se activa de forma selectiva para preguntas sobre relaciones y multi-hop. Así, Graph RAG sigue siendo una capa adicional precisa en lugar de un sustituto completo y caro.

Nota DACH (Alemania, Austria y Suiza): la protección de datos también rige en el grafo

En Alemania y Austria, Graph RAG no cambia nada de los principios del RGPD. Las entidades y relaciones con datos personales deben tratarse, igual que los embeddings y los chunks en el RAG clásico, como registros direccionables y eliminables. Rigen la limitación de la finalidad y la minimización de datos (art. 5), la necesidad de una base jurídica para el tratamiento (art. 6) y el derecho de supresión (art. 17). La separación por clientes y un modelo de roles y permisos son las medidas técnicas y organizativas habituales con las que aplicas la limitación de la finalidad y la protección del acceso según el art. 25 y el art. 32 del RGPD. La Conferencia alemana de protección de datos (DSK) cita ambas como medidas acreditadas en su guía orientativa sobre sistemas RAG de octubre de 2025. Si los empleados usan el sistema para fines distintos, según la DSK deben recibir roles distintos. Alojarlo en la región de la UE es recomendable, pero no obligatorio: quien aloje fuera del EEE necesita una base conforme al capítulo V del RGPD, por ejemplo, una decisión de adecuación o cláusulas contractuales tipo.

En Austria, la autoridad competente es la Autoridad de Protección de Datos (DSB). Su posición sobre el uso de la IA figura en unas preguntas frecuentes sobre IA y protección de datos. En Suiza rige principalmente la Ley Federal de Protección de Datos revisada (revDSG, en vigor desde el 1 de septiembre de 2023). El RGPD se aplica además allí cuando una empresa ofrece bienes o servicios a personas en la UE o observa su comportamiento, en la medida en que ese comportamiento tenga lugar en la UE (art. 3, apdo. 2, del RGPD). Estos datos son informativos y no constituyen asesoramiento jurídico.

Para agencias y responsables de decisiones B2B

Graph RAG no es un sustituto de moda para el RAG vectorial, sino una herramienta especializada para conocimiento con muchas relaciones. Para las agencias, esto significa: empieza con RAG híbrido más reranking como base estándar sólida e introduce Graph RAG solo allí donde las preguntas multi-hop o de visión general aporten un valor de negocio demostrable. Para los responsables de decisiones B2B, la pregunta central no es «¿Qué técnica es más nueva?», sino «¿Qué preguntas hacen realmente nuestros usuarios y necesitan esas respuestas relaciones o solo similitud?». Blck Alpaca ayuda a hacer esta delimitación, calcula el TCO con honestidad y construye arquitecturas RAG conformes al RGPD que crecen con la necesidad real, desde un índice vectorial ligero hasta un sistema híbrido de grafo de conocimiento.