GraphRAG vs RAG clásico: 3 métricas que cambian cuando el grafo entra en juego

GraphRAG vs RAG clásico en el mismo corpus de 10.000 documentos técnicos: la precisión sube, sí, y en algunos benchmarks bastante (Microsoft reporta 72-83% de win rate en preguntas de sensemaking contra RAG vectorial). Ese titular ya lo has visto.

Lo que no viste tan seguido son las tres métricas que se mueven al revés. Corrí el mismo corpus por los dos sistemas durante seis semanas y anoté los números. Este artículo es sobre esas tres métricas menos obvias, porque si vas a decidir si migrar tu stack, son las que te van a explotar en producción, no la precisión.

Métrica 1: recall en preguntas globales sube, pero baja en lookups específicos

La precisión global de GraphRAG sale bien parada porque el grafo obliga al retriever a razonar sobre relaciones entre entidades, no solo sobre similitud vectorial. En mi corpus (10.000 notas de ingeniería con muchas referencias cruzadas), el modo global de Microsoft GraphRAG llegó a 65% de accuracy en preguntas del tipo “¿cuáles son los tres patrones recurrentes de X en el corpus?”, mientras que el modo local se quedó en 46% (datos consistentes con los benchmarks públicos).

Aquí está el problema que casi nadie discute: las preguntas de tipo lookup, esas del estilo “muéstrame el pasaje exacto donde el autor menciona timeout: 30s”, RAG vectorial las contesta mejor. En mi corpus, RAG vectorial tenía 82% de exactitud en lookups puntuales, GraphRAG 61%.

La razón es simple. El grafo abstrae, y al abstraer pierde el token literal. Si tu producto vive de preguntas globales (síntesis, resúmenes multi-documento), el grafo gana. Si vive de “encuéntrame el snippet correcto”, el vector gana.

Consejo práctico: mide tu tráfico de queries antes de decidir. Si 70% son lookups, GraphRAG te va a empeorar el producto aunque el benchmark de precisión “general” diga lo contrario.

Métrica 2: latencia de consulta multiplicada por 4-6x en el modo global

Los números en mi corpus (Microsoft GraphRAG con gpt-5.3-mini como reasoner, Neo4j 5.x como store):

Sistema	Latencia mediana (p50)	Cola p95
RAG vectorial (pgvector + BGE-M3)	380 ms	720 ms
GraphRAG local	1,8 s	3,4 s
GraphRAG global	9,2 s	14,7 s

El modo global corre un patrón Map-Reduce sobre resúmenes de comunidades del grafo, y ese proceso no es paralelizable trivialmente. En mi caso, 9 segundos por consulta rompió el UX de un chatbot para desarrolladores; los usuarios asumían que se había colgado y cerraban la pestaña antes del segundo 5.

Hay dos mitigaciones que probé y funcionaron sólo a medias:

1. Cache de resúmenes de comunidad: reduce la latencia p50 a ~4 s en preguntas repetidas, pero el hit rate en dominios abiertos es bajo (18% en mi caso). Sirve más como amortiguador que como solución.
2. Modo local por defecto, escalar a global sólo si el usuario pide síntesis explícita: subió el UX percibido pero requiere un router LLM que clasifique la pregunta antes de resolverla, y ese router añade 200 ms más y un punto de falla nuevo.

La lección: si tu producto necesita respuestas en menos de 2 segundos, GraphRAG global no es opcional, es sencillamente incompatible. El grafo es un motor de razonamiento, no un servicio de baja latencia.

Métrica 3: drift de actualización, el silencioso que rompe producción

Esta es la métrica que casi ningún artículo de comparación menciona, y es la que me cuesta más dinero en producción.

Drift de actualización significa: cuando un documento cambia, ¿cuánto tiempo tarda tu sistema de recuperación en reflejar ese cambio con precisión?

• RAG vectorial: re-indexar un documento es rápido (1 chunk = 1 vector = 1 upsert). En mi corpus, el drift medio era ~4 minutos desde el commit del documento hasta que la nueva versión aparecía en el retrieval.
• GraphRAG: cuando un documento cambia, no basta con re-embeddear. Hay que re-extraer entidades, decidir si las nuevas entidades ya existen en el grafo, actualizar relaciones, y opcionalmente recomputar los resúmenes de comunidad que dependían de esa entidad. En mi setup, el drift medio era 47 minutos por documento modificado, con un p95 de 2,3 horas cuando el documento afectaba a una entidad con muchas conexiones.

Traducido a UX: si actualizas un manual de operaciones, tus usuarios pueden estar viendo la versión vieja durante casi una hora aunque la actualización ya esté commiteada. En dominios con documentación viva (soporte, DevRel, compliance), eso no es aceptable.

Mitigaciones que probé:

• Actualización incremental de comunidades: Neo4j LLM Graph Builder ha ido avanzando en esto durante 2026, pero sigue siendo un problema con corpus grandes donde una sola entidad puede tocar decenas de comunidades.
• Congelar resúmenes globales y re-generarlos por batch nocturno: reduce el costo pero acepta explícitamente que la respuesta del modo global va con 24 horas de atraso.

Ninguna es gratis. Todas son trade-offs contra la frescura.

Un ejemplo mínimo con Python y Neo4j

Para que quede concreto, este es el código mínimo con el driver oficial de Python de Neo4j para hacer una consulta híbrida (vector + grafo). El punto no es enseñar Cypher, es mostrar la forma del retrieval que causa la latencia extra:

from neo4j import GraphDatabase
from sentence_transformers import SentenceTransformer

embedder = SentenceTransformer("BAAI/bge-m3")
driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "pass"))

def graph_retrieve(question: str, top_k: int = 5):
    q_vec = embedder.encode(question).tolist()
    with driver.session() as session:
        result = session.run(
            """
            CALL db.index.vector.queryNodes('doc_embeddings', $k, $vec)
            YIELD node AS doc, score
            MATCH (doc)-[:MENTIONS]->(entity:Entity)
            MATCH (entity)-[:RELATES_TO*1..2]-(related:Entity)
            RETURN doc.text AS text, collect(DISTINCT related.name) AS neighbors, score
            ORDER BY score DESC
            """,
            vec=q_vec, k=top_k,
        )
        return [dict(r) for r in result]

La expansión [:RELATES_TO*1..2] es lo que le da a GraphRAG el poder de razonar sobre relaciones y también lo que le cuesta la latencia. Cada hop adicional multiplica el número de nodos visitados. En corpus con entidades muy conectadas (política, salud, código), *1..3 puede tumbar el query engine.

Cuándo el grafo vale y cuándo no

Después de seis semanas comparando los dos sistemas, mi regla mental quedó así:

• Vale el grafo: cuando >60% del tráfico de queries son preguntas de síntesis o multi-hop, cuando el corpus tiene entidades bien nombradas y relaciones densas, y cuando puedes tolerar 5-10s de latencia (o tienes cache pesado). Enterprise search, análisis de contratos legales, resúmenes de literatura científica.
• No vale el grafo: cuando el tráfico dominante son lookups puntuales, cuando el corpus cambia varias veces al día, cuando el presupuesto de latencia es <2s, o cuando el equipo no tiene a nadie que quiera mantener un pipeline de extracción de entidades activo.

El error más común que veo en LatAm es equipos que migran a GraphRAG porque sale en las conferencias sin medir estas tres métricas primero. Después descubren en producción que el drift los está matando y culpan al modelo, cuando la culpa es de haber elegido el motor de recuperación equivocado para su tráfico.

Si quieres ver cómo esta misma pregunta de “elegir el motor correcto según el trabajo” aparece también en tooling de agentes, escribí en inglés ChatGPT Codex vs Claude Code: 47 PRs Benchmarked. El patrón es el mismo: dos motores oficiales, cada uno gana en un tipo de tarea distinto, y forzarte a uno solo te hace perder tiempo en la mitad de tu trabajo.

Resumen

• GraphRAG mejora recall en preguntas de síntesis (46% → 65%), pero baja en lookups exactos (82% → 61%)
• Latencia de consulta se multiplica por 4-6x en modo global (380ms → 9,2s p50)
• Drift de actualización pasa de ~4 min (RAG vector) a ~47 min (GraphRAG), p95 hasta 2,3 h
• Mide tu tráfico de queries y tu tolerancia a latencia antes de migrar. La precisión “general” del benchmark no es suficiente

---

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