GraphRAG: cuando las relaciones entre documentos importan más que el contenido

La pregunta que la búsqueda vectorial no puede responder bien

La búsqueda vectorial es muy eficaz para una familia concreta de preguntas: encontrar fragmentos de texto cuyo significado sea parecido al de una consulta. Es la herramienta natural para recuperar secciones de documentación, artículos relacionados con un tema o párrafos que explican una funcionalidad determinada.

Pero no todas las preguntas son preguntas de similitud semántica.

Por ejemplo:

“Dame los artículos que hablan de RAG, publicados después de enero de 2026, que enlazan documentación de Azure AI Search y que además comparten al menos dos etiquetas con el artículo actual”.

Esa consulta no pide “texto parecido”. Pide recorrer relaciones:

• artículo → etiquetas;
• artículo → recursos externos;
• artículo → fecha de publicación;
• artículo → otros artículos relacionados;
• artículo → autor o propietario.

Un índice vectorial puede ayudar a encontrar contenido semánticamente próximo, pero no es la estructura más adecuada para expresar filtros relacionales, caminos entre entidades o dependencias entre documentos. Para eso necesitamos otra representación: un grafo.

GraphRAG aparece precisamente en esa intersección: usar grafos para enriquecer la recuperación de información que alimenta a un modelo generativo.

Qué es GraphRAG

GraphRAG no debe entenderse simplemente como “RAG con una base de datos de grafos”. El enfoque descrito por Microsoft Research combina extracción de información desde texto, análisis de red, prompting con modelos de lenguaje y técnicas de resumen para construir una representación más rica de un corpus.

En términos prácticos, GraphRAG busca que el sistema no recupere solo fragmentos aislados, sino también entidades, relaciones, agrupaciones y contexto global del conjunto de documentos.

Un RAG clásico suele trabajar así:

1. dividir documentos en fragmentos;
2. generar embeddings;
3. buscar los fragmentos más parecidos a la pregunta;
4. pasarlos al modelo como contexto.

Un enfoque GraphRAG añade una capa adicional:

1. identificar entidades, conceptos, documentos o recursos;
2. representar relaciones entre ellos;
3. analizar comunidades o grupos de entidades relacionadas;
4. usar el grafo para guiar la recuperación;
5. combinar el resultado estructural con texto relevante para generar la respuesta.

Esto permite responder mejor preguntas que dependen de relaciones, patrones globales o conexiones indirectas entre elementos del corpus.

GraphRAG aplicado a un blog técnico

En un blog técnico, muchas preguntas útiles no son puramente semánticas. Algunas dependen de la estructura editorial:

• qué artículos comparten etiquetas;
• qué posts enlazan a la misma documentación externa;
• qué contenidos pueden quedar obsoletos si cambia un servicio;
• qué artículos cubren el mismo producto desde ángulos distintos;
• qué temas están sobrerrepresentados o poco conectados;
• qué recursos externos aparecen como dependencias frecuentes.

En una implementación sencilla, el grafo puede incluir nodos como:

• Article: representa un artículo publicado o en borrador;
• Tag: representa una etiqueta temática;
• ExternalResource: representa una URL externa enlazada desde un artículo;
• Author: representa el autor o responsable del contenido;
• Product: representa un servicio, SDK, librería o plataforma mencionada.

Y relaciones como:

• HAS_TAG: un artículo tiene una etiqueta;
• LINKS_TO: un artículo enlaza a un recurso externo;
• WRITTEN_BY: un artículo fue escrito por un autor;
• MENTIONS_PRODUCT: un artículo menciona un producto o servicio;
• RELATED_TO: dos artículos están relacionados por reglas editoriales o análisis del contenido.

La ventaja no está en sustituir el texto, sino en hacer explícitas conexiones que un índice vectorial no modela por sí solo.

Apache AGE sobre PostgreSQL

Una forma de implementar esta capa de grafo es usar Apache AGE, una extensión de PostgreSQL que añade capacidades de grafo y permite consultar con Cypher sobre datos almacenados en PostgreSQL.

En entornos Azure, esto puede ser interesante cuando ya existe una arquitectura basada en PostgreSQL y se quiere evitar desplegar una base de datos de grafos independiente. Aun así, conviene verificar siempre que la extensión está disponible y permitida en la versión concreta de Azure Database for PostgreSQL Flexible Server que se vaya a usar. No todas las extensiones están necesariamente habilitadas en todos los entornos, versiones o configuraciones.

Una inicialización básica con Apache AGE suele tener esta forma:

CREATE EXTENSION IF NOT EXISTS age;
LOAD 'age';

SET search_path = ag_catalog, "$user", public;

Después se crea el grafo lógico:

SELECT create_graph('azurebrains_blog');

A partir de ahí, se pueden crear nodos y relaciones mediante consultas Cypher ejecutadas desde PostgreSQL.

Ejemplo de creación de un artículo:

SELECT *
FROM cypher('azurebrains_blog', $$
  CREATE (a:Article {
    slug: 'rag-fundamentos-recuperacion-aumentada',
    title: 'RAG: Retrieval Augmented Generation y por qué sigue siendo fundamental',
    date: '2025-11-10',
    word_count: 1800,
    status: 'published'
  })
  RETURN a
$$) AS (a agtype);

Ejemplo de creación de una etiqueta:

SELECT *
FROM cypher('azurebrains_blog', $$
  CREATE (t:Tag {
    name: 'RAG',
    category: 'AI'
  })
  RETURN t
$$) AS (t agtype);

Y ejemplo de relación entre artículo y etiqueta:

SELECT *
FROM cypher('azurebrains_blog', $$
  MATCH (a:Article {slug: 'rag-fundamentos-recuperacion-aumentada'})
  MATCH (t:Tag {name: 'RAG'})
  CREATE (a)-[r:HAS_TAG]->(t)
  RETURN r
$$) AS (r agtype);

Estos ejemplos son deliberadamente simples. En producción habría que añadir control de duplicados, estrategia de actualización, validación de metadatos y mecanismos de borrado o reconciliación cuando cambie el contenido original.

Consultas de grafo para reutilización editorial

Un caso útil para GraphRAG en un sistema editorial es ayudar a reutilizar conocimiento existente antes de generar o revisar un nuevo artículo.

Supongamos un agente encargado de detectar artículos relacionados, evitar redundancias y sugerir enlaces internos. Con un grafo puede resolver consultas que serían incómodas o poco fiables con búsqueda vectorial pura.

Artículos relacionados por solapamiento de etiquetas

Antes de redactar un nuevo contenido sobre RAG, el sistema puede buscar artículos publicados que compartan varias etiquetas con el borrador:

SELECT *
FROM cypher('azurebrains_blog', $$
  MATCH (candidate:Article {slug: 'nuevo-articulo-rag'})-[:HAS_TAG]->(t:Tag)<-[:HAS_TAG]-(existing:Article)
  WHERE existing.status = 'published'
  WITH existing, count(t) AS shared_tags
  WHERE shared_tags >= 2
  RETURN existing.slug, existing.title, existing.date, shared_tags
  ORDER BY shared_tags DESC, existing.date DESC
  LIMIT 10
$$) AS (
  slug agtype,
  title agtype,
  date agtype,
  shared_tags agtype
);

Esto no responde a “qué texto se parece más”, sino a “qué artículos están conectados estructuralmente con este borrador”.

Artículos que enlazan recursos del mismo dominio

También se puede localizar qué artículos enlazan documentación o recursos externos de determinados dominios:

SELECT *
FROM cypher('azurebrains_blog', $$
  MATCH (a:Article)-[:LINKS_TO]->(r:ExternalResource)
  WHERE a.status = 'published'
    AND (r.domain = 'learn.microsoft.com'
      OR r.domain = 'techcommunity.microsoft.com')
  WITH a, collect(r.url) AS external_links
  RETURN a.slug, a.title, external_links
  ORDER BY a.date DESC
  LIMIT 5
$$) AS (
  slug agtype,
  title agtype,
  external_links agtype
);

Esta consulta es útil para revisar coherencia editorial: si varios artículos enlazan al mismo conjunto de documentación, quizá convenga unificar criterios, actualizar enlaces o detectar contenidos duplicados.

Detección de contenidos potencialmente obsoletos

Otro caso práctico es localizar artículos que dependen de una ruta, producto o documentación concreta.

Por ejemplo, si cambia la nomenclatura o estructura de documentación de un servicio, se pueden buscar artículos que enlazan URLs afectadas:

SELECT *
FROM cypher('azurebrains_blog', $$
  MATCH (a:Article)-[:LINKS_TO]->(r:ExternalResource)
  WHERE a.status = 'published'
    AND r.domain = 'learn.microsoft.com'
    AND r.url CONTAINS '/azure-cognitive-services/'
  RETURN a.slug, a.title, a.date, r.url
  ORDER BY a.date DESC
$$) AS (
  slug agtype,
  title agtype,
  date agtype,
  url agtype
);

La búsqueda vectorial podría recuperar artículos que mencionan conceptos relacionados, pero no garantiza encontrar todos los documentos que enlazan una ruta concreta. El grafo, en cambio, permite recorrer relaciones explícitas y auditar dependencias.

Integración con recuperación semántica

GraphRAG no reemplaza necesariamente a la búsqueda vectorial. En muchos diseños, la complementa.

Un flujo razonable puede ser:

1. usar el grafo para aplicar filtros estructurales;
2. obtener una lista de artículos, entidades o comunidades relevantes;
3. limitar la búsqueda semántica a ese subconjunto;
4. recuperar los fragmentos textuales más útiles;
5. entregar al modelo tanto el texto como el contexto relacional.

Por ejemplo:

“Encuentra fragmentos sobre configuración de HNSW en artículos relacionados con Azure AI Search publicados en los últimos seis meses”.

Una estrategia híbrida podría resolverlo así:

1. el grafo filtra artículos por etiqueta, producto y fecha;
2. la búsqueda semántica encuentra los fragmentos concretos que hablan de HNSW;
3. el modelo recibe tanto los fragmentos como los metadatos de relación.

La parte vectorial sigue siendo importante, porque es la que localiza pasajes relevantes dentro del texto. La parte de grafo aporta control estructural, trazabilidad y capacidad de navegación entre entidades.

Diferencia entre grafo editorial y GraphRAG de investigación

Conviene distinguir dos niveles.

El primero es un grafo editorial o documental, construido a partir de metadatos explícitos: títulos, etiquetas, autores, enlaces, fechas y productos mencionados. Es relativamente fácil de auditar y mantener.

El segundo es un GraphRAG derivado con ayuda de LLMs, como el enfoque investigado por Microsoft Research, donde el sistema extrae entidades y relaciones desde texto narrativo, agrupa información y genera resúmenes de comunidades. Este enfoque puede capturar relaciones que no estaban modeladas manualmente, pero también exige más controles de calidad.

En sistemas reales, ambos niveles pueden convivir:

• metadatos explícitos para relaciones verificables;
• extracción con LLM para descubrir entidades o relaciones no anotadas;
• revisión humana o reglas automáticas para validar lo que entra en el grafo;
• recuperación semántica para trabajar con fragmentos textuales.

La clave es no tratar el grafo generado por un modelo como verdad absoluta. Si una relación se va a usar para decisiones editoriales, cumplimiento, auditoría o recomendaciones críticas, debe ser trazable y revisable.

Límites y riesgos de GraphRAG

GraphRAG aporta mucho valor cuando las relaciones importan, pero no es una solución mágica.

Algunos riesgos habituales:

• calidad del grafo: relaciones incompletas o incorrectas degradan las respuestas;
• coste de indexación: extraer entidades, relaciones y resúmenes puede ser más caro que crear embeddings;
• actualización incremental: hay que decidir qué ocurre cuando cambia un artículo, una URL o una etiqueta;
• duplicados: una misma entidad puede aparecer con nombres distintos;
• permisos: si hay contenido con restricciones de acceso, el grafo también debe respetarlas;
• explicabilidad: el sistema debe poder justificar qué relaciones usó para recuperar información;
• sobreingeniería: para preguntas simples, un RAG vectorial clásico puede ser suficiente.

La recomendación práctica es empezar con relaciones explícitas y de alto valor: etiquetas, enlaces externos, productos, autores y fechas. Después, si el caso lo justifica, añadir extracción automática de entidades y relaciones.

Cuándo merece la pena usar GraphRAG

GraphRAG tiene sentido cuando las preguntas dependen de conexiones entre elementos del corpus, no solo de similitud textual.

Es especialmente útil en escenarios como:

• bases documentales con muchos enlaces cruzados;
• investigación sobre corpus narrativos extensos;
• análisis de dependencias entre documentos;
• soporte técnico con productos, versiones y componentes relacionados;
• revisión editorial de contenidos obsoletos;
• sistemas de agentes que necesitan memoria estructurada;
• análisis de conocimiento organizativo no modelado en una base de datos tradicional.

En cambio, si el caso principal es responder preguntas localizadas sobre fragmentos independientes, un pipeline RAG clásico con buenos embeddings, chunking adecuado y filtros de metadatos puede ser suficiente.

Conclusión

La búsqueda vectorial responde bien a “qué fragmentos se parecen a esta pregunta”. GraphRAG ayuda con una pregunta distinta: “qué entidades, documentos y conceptos están conectados de forma relevante”.

Esa diferencia es importante. Muchos problemas de recuperación en organizaciones no fallan porque falte similitud semántica, sino porque las relaciones están implícitas, dispersas o no son consultables.

Representar esas relaciones en un grafo permite auditar dependencias, descubrir conexiones, filtrar mejor el contexto y combinar recuperación estructural con recuperación semántica. En un sistema RAG maduro, ambas piezas no compiten: se complementan.