Durante el último año y medio, la idea de enriquecer el RAG tradicional con estructuras de grafo ha dejado de ser un tema de laboratorio y ha aterrizado en productos reales. El empuje vino en parte con la publicación de GraphRAG por Microsoft Research a mediados de 2024, pero el patrón ha ido evolucionando mucho más allá: hoy hay variantes ligeras (LightRAG, HippoRAG), implementaciones abiertas que corren sobre Neo4j o Memgraph, y plantillas listas para probarlo en un fin de semana. En marzo de 2025 el mercado está lo bastante maduro para empezar a preguntar cuándo compensa y cuándo no.
Este post resume lo que he visto funcionar al aplicar RAG con grafos a productos concretos, y los problemas típicos que aparecen al pasar de la demo al uso diario. No entra en la teoría detallada; sí entra en decisiones prácticas de arquitectura.
Por qué el grafo aporta sobre el RAG vectorial
El RAG clásico indexa fragmentos de texto como vectores y los recupera por similitud. Funciona muy bien cuando la pregunta del usuario se responde con una o dos piezas concretas de texto: «¿cuál es la política de devoluciones?», «¿qué dice el manual sobre el error 503?». El problema aparece cuando la pregunta exige entender relaciones entre entidades dispersas: «dame las decisiones que tomó Ana sobre el proyecto Apolo el trimestre pasado y quién más estuvo involucrado».
Ahí los vectores pierden pie. Cada fragmento relevante está disperso en documentos distintos, y la similitud pura no captura la relación entre personas, proyectos, decisiones y fechas. El grafo permite modelar esa red explícitamente: nodos para personas, proyectos, artefactos, decisiones; aristas para los vínculos entre ellos, extraídas de los textos. Cuando la pregunta llega, el sistema puede recorrer el grafo, traer los nodos pertinentes, y solo entonces pasar al LLM el subconjunto relevante.
El segundo aporte del grafo es el razonamiento multi-hop. Una pregunta del tipo «¿qué clientes han tenido incidencias relacionadas con la librería X?» exige conectar incidencias → componentes → librerías. Eso se hace muy mal con vectores y muy bien con una consulta de grafos. El LLM no tiene que hacer ese salto; se lo sirves ya hecho.
Cuándo compensa y cuándo no
La decisión de meter un grafo no se toma porque el concepto esté de moda. Compensa en dos escenarios claros.
El primero es cuando el dominio tiene entidades bien definidas y relaciones que los usuarios preguntan. Soporte técnico con clientes, productos, versiones, incidencias. Research interno con proyectos, personas, decisiones, artefactos. Compliance con políticas, procesos, controles, auditorías. En todos estos casos el grafo refleja cómo la gente piensa el dominio, no una abstracción impuesta.
El segundo es cuando el corpus es estable. Un grafo sobre documentos que cambian todos los días requiere un pipeline robusto de actualización, y ese pipeline se come una parte importante del coste. Si los documentos se actualizan semanal o mensualmente, el grafo es más manejable.
No compensa cuando el corpus es pequeño (menos de unos pocos miles de documentos), porque el RAG vectorial con buen reranking ya resuelve. Tampoco cuando las preguntas son monolíticas («¿qué dice el contrato en la cláusula X?») y no hay necesidad real de saltar entre entidades. Y mucho menos cuando el equipo no tiene experiencia con modelado de grafos; el coste de aprendizaje sobre la marcha es alto y los fallos iniciales hunden el proyecto.
Cómo se monta sin sobre-ingeniería
El flujo habitual tiene cuatro piezas.
Primero, la extracción de entidades y relaciones. Un LLM potente (Claude 3.7 Sonnet, GPT-4o, Gemini 2.0) procesa el corpus en lotes y devuelve tripletas (sujeto-relación-objeto) con metadatos. Esto suena caro y no lo es tanto: para un corpus típico de decenas de miles de documentos, la factura de API en 2025 está muy por debajo de lo que mucha gente imagina, si se hace en batch y con prompts bien pensados. La calidad del prompt determina la calidad del grafo, así que vale la pena iterar aquí antes de escalar.
Segundo, la consolidación. El LLM saca muchas entidades que en realidad son la misma persona o el mismo proyecto escrito de forma distinta. Consolidar requiere un paso de similitud de embeddings más reglas específicas del dominio. Sin consolidación, el grafo se convierte en un bosque de nodos casi duplicados que no navega bien.
Tercero, el almacenamiento. Neo4j sigue siendo la opción por defecto para grafos de propiedad, pero hay alternativas más ligeras (Memgraph, KuzuDB) y también implementaciones sobre PostgreSQL con extensiones. Mi consejo, a menos que se necesite escala muy grande, es empezar por el que el equipo ya tenga instalado. Para proyectos en Docker, KuzuDB es sorprendentemente capaz y permite evitar una pieza más en el stack.
Cuarto, la consulta en tiempo de pregunta. Aquí hay variantes. Microsoft GraphRAG genera comunidades de nodos previamente y las usa como resumen jerárquico. LightRAG adopta un enfoque más sobrio, sin precomputar comunidades. HippoRAG pone énfasis en la estructura de conocimiento inspirada en el hipocampo. En la práctica, para un primer proyecto, empezar con el patrón LightRAG suele ser más rápido de poner en pie y suficiente para validar la hipótesis.
Los problemas que aparecen cuando sale a producción
Hay cosas que no se ven en la demo y que golpean a las dos semanas de uso real.
La primera es la actualización de documentos. Un documento que cambia no puede simplemente re-extraerse; hay que invalidar las tripletas que venían de él y regenerar las nuevas, manteniendo consistencia con las entidades que ya había. Sin un pipeline con identificadores estables por documento, el grafo se corrompe lentamente.
El segundo problema es la verificación. Las tripletas extraídas por LLM son probabilísticas: a veces la relación no existe en el texto, o se malinterpreta una negación. Un sistema en producción necesita al menos un muestreo humano para medir la tasa de error, y a veces un segundo paso de verificación automática con un modelo que revise las tripletas dudosas.
El tercer problema, muchas veces subestimado, es la latencia. Una consulta completa (recuperación de subgrafo + expansión + generación) puede pasar fácilmente del segundo. Cuando el producto tiene UX de chat síncrono, eso es perceptible. Hay que optimizar la consulta del grafo con índices específicos y cachear los subgrafos de preguntas frecuentes.
El cuarto es el coste operativo. Extraer un grafo es un gasto único alto, pero mantenerlo fresco es un gasto recurrente. Si el corpus recibe 1000 documentos nuevos a la semana, la pipeline de extracción tiene que correr sin romperse y sin ahogar la cuota de API. Esto lo he visto romperse varias veces en producciones que no lo habían dimensionado.
Una pista sobre evaluación
Evaluar RAG con grafos es más difícil que evaluar RAG vectorial. No basta con medir relevancia de fragmentos recuperados porque la unidad recuperada es un subgrafo. Me ha funcionado definir un conjunto de preguntas sintéticas del dominio con respuesta esperada, medir si el subgrafo recuperado contiene los nodos y relaciones necesarios para responder, y luego medir la calidad de la respuesta generada. Son dos métricas, no una, y ambas importan.
La comparación con un baseline de RAG vectorial puro debe hacerse siempre. A veces el grafo mejora mucho en preguntas multi-hop pero empeora en preguntas simples por el coste extra de recuperación. Medir ambos tipos por separado es la única forma honesta de decidir si el grafo vale la pena para el producto concreto.
Cuándo compensa
El balance, viendo proyectos que han llegado a producción y otros que no, es que RAG con grafos es valioso cuando el dominio es inherentemente relacional, el corpus es estable, y el equipo tiene experiencia suficiente para sostener la pipeline de extracción. En esos casos el salto en calidad sobre preguntas complejas es real y los usuarios lo notan.
Fuera de esos escenarios, el sobrecoste de mantenimiento no se compensa. Un buen RAG vectorial con reranking y citación explícita de fuentes sigue siendo la opción correcta para la mayoría de productos que he visto. Añadir grafo sin necesidad real es uno de los vicios clásicos de la ingeniería de IA en 2024-2025: se hace porque suena bien en la charla con el cliente, no porque resuelva un problema que el usuario tenga.
Mi consejo práctico es dedicar una semana a montar un prototipo, evaluarlo contra el baseline vectorial con preguntas reales del producto, y decidir con números. Si la mejora es marginal, queda como carta para más adelante; si es clara, se construye la pipeline con cuidado y se lleva a producción. Nunca lo he visto funcionar bien como decisión a priori, sin experimentar.
