GraphRAG vs RAG clásico: guía práctica para elegir en 5 preguntas

Cada semana alguien suelta en LinkedIn que GraphRAG ha dejado obsoleto al RAG vectorial. Y cada semana otra persona sale al paso: que si cuesta 7 veces más, que si casi nadie lo necesita. Las dos cosas son verdad, lo que pasa es que hablan de proyectos distintos. Mientras tanto el debate se queda flotando en abstracto, y cuando te toca decidir dentro de tu equipo la conversación se resume en “elijo GraphRAG porque es lo último” o “elijo RAG porque es barato”. Ni una cosa ni la otra es un criterio.

Te propongo 5 preguntas concretas que hay que contestar antes de decidir nada. Si sales con “sí” en 4 de 5, GraphRAG probablemente merece la pena. Si el balance es “no” en 3 o más, quédate con RAG vectorial y te ahorras entre 10 y 700 veces en costes de indexación. Y no, no me flipo con el rango: la investigación oficial de Microsoft sobre LazyGraphRAG muestra que GraphRAG tradicional puede costar hasta 700 veces más por consulta global que la variante optimizada.

Antes de las 5 preguntas: por qué la diferencia importa

El RAG vectorial clásico va así. Trozas tus documentos, cada trozo genera un embedding, y los embeddings se guardan en una base vectorial. Cuando entra una pregunta, buscas los trozos con embedding parecido y se los sueltas al LLM como contexto. Simple, rápido, barato. El problema es que solo encuentra “documentos cercanos” al texto de la pregunta; sobre las relaciones entre ellos no razona.

GraphRAG va por otro lado. Aprovecha el LLM en la fase de indexación para extraer entidades y relaciones de todos tus documentos, monta un knowledge graph y luego le pasa por encima el clustering de Leiden para detectar comunidades temáticas. Al recuperar, te devuelve resúmenes de comunidad y caminos del grafo. Con esa capa arriba puede contestar “qué temas tienen en común el proyecto A y el proyecto B”, una pregunta ante la que RAG vectorial se queda con cara de póker.

La letra pequeña: el equipo de Microsoft contó que indexar un corpus legal de 5 GB costaba 33.000 USD en la primera versión de 2024. Para 2026, con LazyGraphRAG y las optimizaciones del camino, ese mismo corpus se queda en 50-200 USD, aunque siga costando entre 10 y 40 veces más que su equivalente en RAG vectorial (que rondaría los 5 USD). El coste ya cabe en un presupuesto normal. Pero el departamento de finanzas te lo va a notar igualmente.

Pregunta 1: ¿tus datos son fundamentalmente relacionales?

La clave está en el peso que tienen las relaciones entre documentos, no en cuánto pese el corpus entero.

Datos relacionales de verdad: informes de investigación que se citan entre sí, expedientes legales que remiten a jurisprudencia previa, historias clínicas en las que diagnóstico y tratamiento cruzan pacientes, documentación de arquitectura donde el componente A depende de B, que a su vez depende de C.

Datos que parecen relacionales sin serlo: artículos de blog que cubren el mismo tema (no se relacionan estructuralmente, solo comparten palabras clave), FAQ de atención al cliente (cada entrada va por su cuenta), documentación tipo how-to en la que cada guía se lee por sí sola.

Si te contestas honestamente “vale, mis documentos van cada uno por su lado”, GraphRAG no te va a dar retorno. RAG vectorial cubre de sobra la búsqueda por similitud temática.

Pregunta 2: ¿tus preguntas requieren razonamiento multi-hop?

Multi-hop quiere decir que la respuesta obliga a conectar información repartida en varios documentos.

Ejemplos multi-hop de verdad: “qué empresas del sector financiero contrataron al mismo abogado que la empresa X entre 2020 y 2024” (te toca cruzar directorio de empresas, contratos y clasificación sectorial). “Qué investigadores han copublicado con alguien del equipo de OpenAI en los últimos 3 años” (te toca montar la red de coautoría).

Ejemplos que parecen multi-hop y no lo son: “resúmeme la política de vacaciones de la empresa” (aunque esté dispersa en 3 documentos, se resuelve concatenando). “Qué dice el manual sobre el reembolso de gastos” (con una búsqueda vectorial en el manual sobra).

La validación de NTT Data que cita Microsoft confirma que GraphRAG le saca al RAG vectorial un 26% en exhaustividad y un 57% en diversidad cuando la pregunta pide una vista global del corpus. La pega: esa ventaja solo cuenta si tus usuarios hacen ese tipo de pregunta. Y en la mayoría de proyectos empresariales, el 80% de las consultas reales son del estilo “dónde pone la política X”. Eso lo cubre RAG vectorial al 0,5% del coste.

Pregunta 3: ¿con qué frecuencia se actualizan tus documentos?

Aquí el equilibrio económico se da la vuelta.

Documentos estables (leyes, textos históricos, corpus académico): pagas la indexación de GraphRAG una vez y la amortizas durante años. Un coste de 50-200 USD desaparece si lo repartes entre 10.000 consultas al año.

Documentos que cambian a diario (base de conocimiento interna, tickets de soporte, documentación de producto viva): cada actualización te obliga a reindexar al menos las secciones afectadas. Si tus documentos rotan al 10% mensual, acabas pagando el coste de indexación 12 veces al año y el retorno se evapora.

Una arquitectura híbrida te saca del apuro: guarda los documentos “estables” en GraphRAG y los “vivos” en RAG vectorial. El agente decide a cuál consultar según el tipo de pregunta.

Pregunta 4: ¿cuánto puede invertir tu equipo en la puesta en marcha?

Aquí no hablo solo de dinero. Hablo de horas de gente y de habilidades.

RAG vectorial: 1 persona senior lo tiene en producción en 2-3 días. Las bibliotecas (LlamaIndex, LangChain) traen tutoriales que salen a la primera. Y cualquier ingeniero backend te lo mantiene después.

GraphRAG: la implementación oficial de Microsoft te pide entender extracción de entidades, ajustar el prompt de extracción, clustering Leiden, jugar con los parámetros de comunidad y evaluar la calidad del grafo generado. La primera versión que arranca lleva entre 2 y 4 semanas, y encima toca iterar. Neo4j o Kuzu como backend de grafo meten un stack extra que alguien tiene que operar aparte.

Si tu equipo nunca ha tocado bases de datos de grafo, o no le puedes reservar 3-4 semanas de arranque, lo pragmático es RAG vectorial ahora y GraphRAG más adelante (o nunca, si la Pregunta 2 sale que no).

Pregunta 5: ¿cuánto vale la respuesta correcta frente a una respuesta aproximada?

Esta es la más importante y la que menos se pregunta la gente.

Sitios donde la respuesta correcta vale mucho: análisis legal (una respuesta incompleta te puede costar el caso), diagnóstico médico asistido (un falso negativo es peligroso), auditoría de código de infraestructura crítica (una dependencia que se te escapa se convierte en un incidente en producción). Ahí ese 26% extra de exhaustividad de GraphRAG justifica el coste.

Sitios donde una respuesta aproximada te vale: chatbot de FAQ, asistente de búsqueda en documentación técnica, resumen de informes internos en los que el usuario puede seguir tirando del hilo. Aquí ese 26% extra te cuesta 40 veces más por consulta y, muy probablemente, ni se nota.

La pregunta traducida a dinero: ¿cuánto perderías si el sistema devuelve una respuesta parcial en el 10% de las consultas? Si es “no mucho”, RAG basta y sobra.

El árbol de decisión resultante

Si has sumado tus respuestas:

• 4 o 5 “sí”: monta GraphRAG. Y empieza por LazyGraphRAG en vez del GraphRAG clásico; cuesta el 0,1% de la versión original con calidad comparable en consultas locales.
• 2 o 3 “sí”: tira por una arquitectura híbrida. RAG vectorial para la base y GraphRAG solo para los documentos que de verdad lo justifican.
• 0 o 1 “sí”: quédate con RAG vectorial. No pierdas el tiempo con GraphRAG hasta que cambien las respuestas.

El árbol funciona porque cada pregunta se apoya en un umbral de dolor operativo real, no en una idea abstracta de “sofisticación”. Muchos proyectos que “necesitan GraphRAG” lo que necesitan en realidad es un mejor chunking en su RAG vectorial. Y algunos que “no lo necesitan” descubren que sí, después de tirarse meses reinventando GraphRAG a mano.

Notas para tu evaluación de la próxima semana

Si tu equipo está eligiendo entre una cosa y la otra, prueba con estas 3 acciones concretas:

• Coge 20 consultas reales de tu sistema actual y clasifica cuántas son “recuperación factual” frente a “razonamiento entre documentos”. Ese porcentaje lo decide todo.
• Lanza el GraphRAG oficial de Microsoft sobre un subconjunto de 100 páginas de tus datos. Calcula el coste real de indexación y multiplícalo por la frecuencia de actualización anual.
• Compara las respuestas de las mismas 20 consultas en RAG vectorial y en GraphRAG. Si la mejora es menor del 15%, GraphRAG no te compensa.

El proceso te lleva una semana. Y te ahorra meses de arquitectura equivocada.

Traduje este blog a 4 idiomas y me encontré con patrones en el tráfico que no me esperaba. Si te pica la curiosidad sobre cómo cada idioma reacciona distinto al mismo contenido, escribí el análisis completo aquí.

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