GraphRAG explicado: 7 pasos, vector vs multi-hop

La primera vez que armé un knowledge graph empecé por el final: modelé nodos elegantísimos durante tres semanas y después me pregunté qué consulta iba a resolver. La respuesta fue “ninguna que valiera la pena”. Escribo este artículo básicamente para que no repitas ese camino.

La búsqueda vectorial (vector search) resuelve un problema: “dame textos parecidos a este”. El problema es que muchas preguntas reales no son de similitud. Son de relación: “dame la causa raíz de este error de producción, incluso si la descripción no se parece en nada al log actual”.

Ahí es donde entra GraphRAG. Este recorrido de 7 pasos usa el caso público de LinkedIn como ancla numérica, y define los términos técnicos que la mayoría de los tutoriales dan por sabidos.

Ancla: qué logró LinkedIn con GraphRAG

Antes de los 7 pasos, la meta. LinkedIn publicó un paper en SIGIR 2024 (arXiv 2404.17723) donde reportan, después de 6 meses de operación real en soporte al cliente:

• Tiempo mediano de resolución: −28,6%
• MRR (Mean Reciprocal Rank): +77,6%
• BLEU: +0,32

Tres números que miden cosas distintas. El de negocio (−28,6%) es el que casi todos citan. El técnico interesante es MRR: es la métrica que dice qué tan alto en el ranking aparece la respuesta correcta. Si aparece primera, MRR = 1,0. Si aparece segunda, 0,5. Si aparece décima, 0,1. Un salto de +77,6% en MRR quiere decir que la respuesta correcta subió mucho en el orden de resultados. Ese es el efecto que hace bajar el tiempo de resolución. BLEU +0,32 mide la calidad del texto generado por el LLM, no la del retriever.

Ahora los 7 pasos, con esa mejora como referencia.

Paso 1: Define el caso de uso

Este es el paso más importante y el más ignorado. La pregunta no es “quiero un knowledge graph”, es “qué consulta específica quiero que sea rápida”.

Ejemplo débil:

“Quiero convertir toda la documentación interna en grafo.”

Ejemplo fuerte:

“Quiero que un ingeniero nuevo entienda en 30 segundos qué servicios se afectan cuando cambia un endpoint de API.”

El caso fuerte fija tres cosas de golpe: qué nodos necesitas, qué aristas importan, y qué consultas tienen que ser rápidas. El caso débil no fija nada, y el proyecto muere después del PoC.

Paso 2: Identifica las fuentes de datos

Mapea de dónde salen los datos que entran al grafo. Tres categorías, tres tratamientos distintos:

Fuente	Formato	Ejemplo
Estructurada	CSV, base de datos	Catálogo de productos, tabla de clientes
Semiestructurada	JSON, XML	Respuestas de API, configuración
No estructurada	Texto, PDF	Contratos, actas, código

La fuente donde el LLM más ayuda es la no estructurada: el LLM extrae entidades y relaciones del texto libre. En las otras dos, un ETL clásico gana casi siempre.

Paso 3: Diseña la ontología

La ontología es el plano del grafo: qué tipos de nodos existen, qué tipos de aristas los conectan.

Etiquetas de nodo:
  - Service (name, version, team)
  - API (path, method, status)
  - Developer (name, email)

Tipos de arista:
  - EXPOSES: Service -> API
  - CALLS: API -> API
  - MAINTAINS: Developer -> Service

Regla que aprendí a golpes: diseña la ontología hacia atrás, empezando por las consultas del Paso 1. Si empiezas por “qué es un nodo interesante”, diseñas 3 fines de semana y no te sirve para nada. Si empiezas por “esta consulta tiene que devolver en 100ms”, el diseño se cae solo.

Paso 4: Modelado en Neo4j (u otro motor)

El plano del Paso 3 se traduce al modelo que use tu motor. Con Neo4j (property graph), así:

CREATE (:Service {name: "UserAPI", version: "2.1", team: "Platform"})
CREATE (:API {path: "/api/users", method: "GET"})

MATCH (s:Service {name: "UserAPI"}), (a:API {path: "/api/users"})
CREATE (s)-[:EXPOSES {since: "2024-01-15"}]->(a)

CREATE INDEX FOR (s:Service) ON (s.name)

El índice no es cosmético. Sin índice en las propiedades por las que filtras, las consultas se degradan a escaneo lineal en cuanto el grafo pasa de unas decenas de miles de nodos.

Paso 5: Ingesta

Para volumen alto, LOAD CSV o APOC (Awesome Procedures On Cypher). Para no estructurada, LLM extrayendo entidades y relaciones:

prompt = """
Del texto de abajo, extrae entidades (persona, organización, tecnología)
y las relaciones entre ellas en formato JSON.

Texto: {document}
"""

Este paso es el más caro en tiempo real la primera vez. LinkedIn reporta usar E5 embeddings y GPT-4 en esta capa. Cada uno tiene su costo por 1M tokens, así que la ingesta de un corpus grande se planifica, no se improvisa.

Paso 6: Consulta multi-hop, aquí gana GraphRAG

Aquí está la razón por la que existe GraphRAG. Multi-hop (múltiples saltos) es cuando la respuesta requiere seguir dos o más aristas del grafo:

// "Qué servicios se afectan si cambio /api/users"
MATCH (target:API {path: "/api/users"})<-[:CALLS]-(caller:API)<-[:EXPOSES]-(s:Service)
RETURN s.name AS servicio_afectado, caller.path AS via_api

Esa consulta hace 2 saltos: target ← caller ← service. Un motor vectorial puro no puede hacer esto. Puede devolver documentos que hablan de /api/users, pero no puede seguir la cadena “esta API llama a esa API que la expone tal servicio”. La cadena no está en la geometría del embedding, está en las aristas.

Ese es el diagnóstico técnico detrás del MRR +77,6% de LinkedIn: no encontraron mejores textos parecidos, encontraron el ticket relacionado por la relación correcta, no por similitud léxica.

Paso 7: Operación

Un knowledge graph no es “constrúyelo y olvídate”:

• Frescura: pipeline que sincroniza el grafo con las fuentes cuando cambian
• Calidad: detectar nodos huérfanos, entidades duplicadas, aristas rotas
• Evolución del esquema: la ontología del Paso 3 va a crecer, planéalo
• Control de acceso: qué equipo puede leer qué subgrafo

Servicios manejados como Neo4j AuraDB reducen la carga de infraestructura de este paso a casi cero. Si estás construyendo el primer GraphRAG del equipo, no montes tu propio cluster; usa uno manejado hasta que sepas dónde te va a doler.

Cuándo NO usar GraphRAG

Para cerrar honestamente: GraphRAG no gana en todo. No lo uses si:

• Tu caso es realmente de similitud pura (“dame textos parecidos”): vector RAG es más simple y más barato
• No tienes relaciones interesantes en tus datos: forzar un grafo sobre un catálogo plano no ayuda
• No tienes presupuesto para operar Neo4j (u otro motor) por 6+ meses: el grafo sin mantenimiento envejece muy rápido

El truco no es “usar la técnica nueva”. El truco es hacer el Paso 1 con seriedad y saber cuándo la respuesta que necesitas requiere multi-hop.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev