GraphRAG vs RAG tradicional: cuándo el costo extra vale (y cuándo no)
La pregunta que llega en el segundo mes de un proyecto RAG en producción casi siempre es la misma: “¿por qué no responde bien las preguntas que abarcan toda la base?”
Pasé por esa pregunta cinco veces distintas antes de aceptar la respuesta corta: el RAG tradicional, el que casi todos montamos con embeddings y búsqueda vectorial, no está diseñado para eso. GraphRAG sí. Pero GraphRAG cuesta entre 10 y 40 veces más de indexar. La pregunta real, entonces, es “¿cuándo vale el costo extra?”.
Este artículo es la comparación que hice cuando tuve que decidir para un cliente. 10.000 documentos internos, presupuesto acotado, y la típica frase del comité: “queremos algo que responda como ChatGPT sobre nuestra base”.
Lo que el RAG tradicional hace bien (y lo que no)
El RAG tradicional funciona con una arquitectura simple: partes los documentos en fragmentos, generas embedding de cada uno, buscas por similitud coseno cuando llega la pregunta y le pasas los top-k al LLM como contexto.
Es rápido de montar. Con text-embedding-3-small de OpenAI a 0,02 USD por millón de tokens, indexar 10.000 documentos de tamaño mediano (digamos 2.000 tokens cada uno = 20 millones de tokens) sale unos 0,40 USD de una sola vez. Latencia por consulta: 200-400ms. Ese es el número que hace que casi todos empiecen por aquí, y está bien.
El problema aparece cuando el usuario pregunta cosas como:
- “¿Cuál es el hilo común entre el proyecto A y el proyecto B?”
- “¿Qué temas atraviesan toda nuestra documentación?”
- “¿Qué contratos mencionan cláusulas similares a esta?”
Preguntas que no tienen respuesta en un solo fragmento. Requieren entender relaciones entre documentos, no encontrar el documento más parecido a la pregunta. Y la búsqueda vectorial es literalmente eso último: encuentra puntos cercanos en el espacio, no infiere puentes entre puntos lejanos.
Cuando la mitad de las preguntas del usuario final son de este tipo, el RAG tradicional entrega respuestas técnicamente correctas pero sensación de “no leyó todo”. Y esa sensación destruye la confianza más rápido que un error explícito.
Lo que GraphRAG hace distinto
GraphRAG, propuesto por Microsoft Research en 2024 (arXiv 2404.16130), invierte la lógica: en vez de guardar fragmentos y buscar por similitud, usa un LLM para construir un knowledge graph durante la indexación, y consulta ese grafo en tiempo de query.
El pipeline tiene cuatro etapas:
- Extracción de entidades y relaciones: el LLM lee cada documento, identifica entidades (persona, organización, concepto, tecnología) y las relaciones entre ellas.
- Clustering Leiden: agrupa nodos densamente conectados en comunidades. Es un algoritmo que descubre la estructura jerárquica sin que le digas cuántos temas hay.
- Resúmenes de comunidad: el LLM genera un resumen para cada comunidad, y esos resúmenes se indexan.
- Consulta expandida por grafo: la pregunta del usuario se resuelve recorriendo resúmenes de comunidad relevantes en lugar de fragmentos aislados.
El resultado es que las preguntas globales dejan de ser un problema. Las evaluaciones del equipo de Microsoft sobre el conjunto VIINA mostraron mejoras grandes en exhaustividad y diversidad, justo las dimensiones donde el RAG tradicional falla.
Ahora la parte incómoda: el costo.
El número que casi nadie muestra
La comparación de costo entre RAG tradicional y GraphRAG no aparece en muchos blogs porque, francamente, es un jarro de agua fría. Los números para 10.000 documentos de 2.000 tokens cada uno (20 millones de tokens totales), con GPT-4o-mini para la extracción de entidades:
| Etapa | RAG tradicional | GraphRAG |
|---|---|---|
| Embeddings de fragmentos | 0,40 USD | 0,40 USD |
| Extracción entidad/relación (LLM) | — | ~50 USD |
| Generación de resúmenes de comunidad | — | ~15 USD |
| Total indexación inicial | ~0,40 USD | ~65 USD |
| Latencia por consulta | 200-400ms | 800-2500ms |
| Reindexación (delta 10%) | ~0,04 USD | ~6,5 USD |
Los números de GraphRAG salen de proyecciones basadas en el paper original y en el análisis que publicó Medium — GraphRAG vs PageIndex para escenarios similares. Si usas GPT-4o completo en vez de mini, multiplica el costo por 6-10.
GraphRAG cuesta ~160 veces más de indexar que RAG tradicional en este escenario. Y no una sola vez: cada reindexación (cuando cambian documentos) cuesta proporcionalmente más.
Cuándo el extra vale
Con esos números encima de la mesa, la decisión se vuelve más honesta. GraphRAG vale la pena cuando el valor de responder preguntas globales supera 160 veces el costo de indexación anual. Esa frase suena rara escrita así, pero es la cuenta que hay que hacer.
En los proyectos que hice después, encontré tres patrones donde el cálculo da positivo:
1. Soporte técnico interno con tickets similares. El caso que reportó LinkedIn (KG + RAG en soporte al cliente) redujo el tiempo mediano de resolución de tickets un 28,6% y mejoró el MRR un 77,6%. Si tienes un equipo de soporte de 20 personas cobrando 30 USD/hora, recortar el 20% del tiempo mediano paga la indexación de 10k tickets en dos semanas.
2. Análisis de contratos legales. El caso NTT Data (evaluación automática de riesgo contractual) explota justo la ventaja: comparar cláusulas nuevas contra un cuerpo histórico pide recorrer relaciones entre documentos; buscar el contrato más parecido no basta. Un abogado corporativo cuesta 150-300 USD/hora; automatizar una revisión inicial paga GraphRAG antes del primer contrato del mes.
3. Base de conocimiento interna de empresa grande (>500 empleados) con alta rotación. Cuando “la persona que sabía se fue hace seis meses” es un problema recurrente, GraphRAG reconstruye el mapa de relaciones que se pierde con la rotación. RAG tradicional solo encuentra el documento que la persona dejó; no el contexto de por qué existía.
Cuándo el extra no vale
Los tres patrones donde vi a equipos gastar dinero en GraphRAG sin retorno:
Base de conocimiento pequeña (< 500 documentos). El sobrecosto de construir el grafo no se amortiza. RAG tradicional con reranker (Cohere, por ejemplo) llega al 90% de la calidad a 1/100 del costo.
Preguntas mayoritariamente factuales. “¿Cuál es el horario de atención?” no necesita conocimiento de grafo. Si tu telemetría muestra que el 80% de las preguntas son de este tipo, GraphRAG resuelve el 20% restante a un costo que no se justifica.
Documentos que cambian todos los días. La reindexación de GraphRAG es cara y lenta. Si tu corpus muta constantemente (chat interno, tickets en tiempo real), el costo se dispara por reindexación frecuente. Alternativa razonable: RAG tradicional en la capa caliente + GraphRAG mensual sobre snapshot congelado.
El híbrido que casi todos terminan usando
Después de tres proyectos, dejé de recomendar “GraphRAG o RAG tradicional” como decisión binaria. El patrón que sobrevive en producción es híbrido:
- Capa 1 (RAG tradicional): responde el 70-80% de las consultas, latencia baja, costo mínimo.
- Capa 2 (GraphRAG sobre snapshot mensual): entra cuando la capa 1 devuelve confianza baja, o cuando la pregunta contiene marcadores de “consulta global” (qué temas, cuáles proyectos, hilo común, similar a).
El costo total termina siendo 3-5 veces el de RAG tradicional puro, muy por debajo del factor 160. Y la percepción del usuario mejora porque las preguntas “difíciles” ya no se quedan sin respuesta útil.
Es una arquitectura poco elegante pero honesta, la que sale cuando miras los números en vez de la promesa de marketing de cada lado.
La pregunta que hay que hacerse antes de decidir
Antes de escribir una sola línea de código de GraphRAG, hay una pregunta que resuelve el 90% de los casos: ¿qué porcentaje de las consultas reales del usuario final requiere entender relaciones entre documentos?
Si no tienes esa telemetría, mídela primero. Un mes de logs de RAG tradicional en producción, categorizados a mano en factuales vs relacionales, cuesta menos que un día de indexación GraphRAG. Y el número que salga de ese ejercicio va a decidir la arquitectura mucho mejor que cualquier benchmark académico.
El resto (Neo4j vs Neptune, LangChain vs implementación personalizada, GPT-4o vs mini) son detalles técnicos que se resuelven después. La decisión que importa es la primera: entender qué tipo de preguntas te van a hacer.
Yo llegué tarde a esa pregunta en el primer proyecto y pagué 60 USD extra de indexación para descubrir que el 85% de las consultas eran factuales. Nunca más.
Referencias adicionales: arXiv 2404.16130 — GraphRAG paper original, Comparación GraphRAG vs PageIndex.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev
Libro relacionado Convirtiendo LLMs de Mentirosos en Expertos Ingeniería de Contexto desde cero — RAG, MCP, CLAUDE.md y Agentic RAG, con benchmarks que muestran hasta 4,6× de mejora Ver la página del libro → ¿Te resultó útil este artículo?