Graph RAG: cómo dejar de tratar tus datos como islas y empezar a razonar sobre relaciones

El RAG (Retrieval-Augmented Generation) se ha convertido en el estándar para conectar modelos de lenguaje con datos privados. La fórmula clásica funciona así: trocear documentos, convertirlos en vectores mediante embeddings, almacenarlos en una base vectorial y recuperar los k resultados más similares mediante similitud coseno. Es efectivo para búsqueda semántica sencilla, pero tiene un punto ciego enorme cuando los datos son altamente interdependientes.

Piensa en una pregunta como: "¿Cómo afectará el retraso del Componente X a la entrega del Cliente Y en el Q3?" Una búsqueda vectorial tradicional encontrará el documento sobre el retraso, pero no "sabe" que el Componente X alimenta directamente al Cliente Y. El LLM recibe información parcial y hace suposiciones, o simplemente responde "no lo sé" a pesar de que todos los datos existen.

El patrón Graph RAG no es una herramienta más — es un cambio arquitectónico que combina la flexibilidad semántica de la búsqueda vectorial con el determinismo estructural de las bases de datos de grafos.

El problema: cuando la búsqueda vectorial pierde contexto

Las bases de datos vectoriales son expertas en capturar significado pero descartan la topología. Cuando un documento se trocea y se embebe, las relaciones explícitas (jerarquía, dependencias, pertenencia) se aplanan o se pierden. El embedding captura qué significa cada fragmento, pero no con qué está conectado.

Ejemplo concreto: imagine una cadena de suministro donde una base de datos SQL sabe que el Proveedor A suministra el Componente X a la Fábrica B. Simultáneamente, un informe de noticias dice que "una inundación ha detenido la producción del Proveedor A". Una búsqueda vectorial por "riesgos de producción" recuperará la noticia, pero no podrá vincularla con la Fábrica B downstream. El resultado es alucinación: el LLM intenta conectar los puntos pero carece del enlace explícito.

La solución: arquitectura de recuperación híbrida en tres capas

Ingesta: la estructura debe imponerse en el momento de la ingestión. Durante este paso se extraen entidades (nodos) y relaciones (aristas) de los textos. Se puede usar un LLM o un modelo NER para identificar entidades y enlazarlas con registros existentes en el grafo.

Almacenamiento: una base de datos de grafos (como Neo4j) almacena el grafo estructural. Los embeddings vectoriales se almacenan como propiedades de nodos específicos — por ejemplo, un nodo RiskEvent tiene su vector asociado.

Recuperación híbrida: se ejecuta una consulta en dos pasos. Primero, búsqueda vectorial para encontrar puntos de entrada en el grafo según similitud semántica. Segundo, recorrido del grafo (graph traversal) para expandir el contexto desde esos puntos de entrada siguiendo las relaciones.

Ejemplo de código en Python con Neo4j y OpenAI:

# Ingesta: enlazar texto no estructurado al grafo

risk_event = "Severe flooding at TechChip Inc facility"

embedding = openai.Embedding.create(input=risk_event, model='text-embedding-3-small')

MERGE (r:RiskEvent {text: $event}) SET r.embedding = $embedding

MATCH (s:Supplier {name: 'TechChip Inc'}) MERGE (s)-[:HAS_RISK]->(r)

# Recuperación híbrida con Cypher

CALL db.index.vector.querySimilarity('risk_embeddings', 3, $query_embedding)

YIELD node AS risk MATCH (supplier)-[:HAS_RISK]->(risk) MATCH (supplier)-[:SUPPLIES]->(factory)

RETURN risk.text, supplier.name, factory.name

El resultado: en lugar de un fragmento de texto genérico, el LLM recibe un payload estructurado como [{"issue": "Severe flooding", "impacted_supplier": "TechChip Inc", "risk_to_factory": "Assembly Plant Alpha"}], lo que le permite responder con precisión.

Latencia y consistencia: las lecciones de producción

El impuesto de la latencia: los recorridos de grafos son más caros que las búsquedas vectoriales simples. Un RAG vectorial puro ronda los 50-100ms; Graph RAG puede alcanzar los 200-500ms dependiendo de la profundidad de saltos. La mitigación es usar semantic caching: si una pregunta es similar (cosim > 0.85) a una consulta anterior, se sirve el resultado en caché.

El problema del "arco obsoleto": en bases vectoriales los datos son independientes. En un grafo son dependientes. Si el Proveedor A deja de suministrar a la Fábrica B, hay que actualizar el grafo. Un borde obsoleto puede generar recomendaciones que parecen plausibles pero son incorrectas.

Cuándo usar Graph RAG: si tus datos son principalmente documentos independientes (artículos, reportes), el RAG vectorial clásico es suficiente. Pero si trabajas en dominios con relaciones estructurales densas — cadena de suministro, cumplimiento financiero, detección de fraude, gestión de riesgo — Graph RAG marca la diferencia entre un sistema que responde y uno que realmente razona sobre tus datos.

La idea central es sencilla: dejar de tratar cada documento como una isla y empezar a tratar tu base de conocimiento como lo que realmente es: una red de entidades interconectadas.