Grafos de conocimiento vs RAG: diferencias, GraphRAG y cuándo combinarlos

Un grafo de conocimiento y un sistema RAG responden preguntas de forma muy distinta: uno navega relaciones explícitas entre entidades, el otro recupera pasajes de texto relevantes para que un modelo redacte la respuesta a partir de ellos. GraphRAG combina ambos enfoques construyendo un grafo a partir de sus documentos y usándolo como mapa de recuperación. En este artículo verá qué aporta cada técnica, cuándo el grafo compensa su coste de construcción y cómo decidir sin montar una arquitectura que probablemente no necesita.

Dos formas distintas de responder una pregunta

Antes de comparar coste o complejidad conviene entender qué hace cada sistema cuando le llega una pregunta. No son dos variantes de lo mismo: resuelven problemas de recuperación de información con lógicas distintas, y eso explica por qué uno brilla donde el otro se queda corto.

RAG clásico: buscar el pasaje más relevante

Un sistema RAG (Retrieval Augmented Generation) divide sus documentos en fragmentos, los indexa (normalmente con búsqueda híbrida, combinando palabras clave y vectores semánticos) y, cuando llega una pregunta, recupera los fragmentos más parecidos para dárselos a un modelo de lenguaje junto con la pregunta. El modelo redacta la respuesta citando esos pasajes. Puede repasar el mecanismo completo paso a paso en cómo funciona RAG. Este enfoque funciona muy bien cuando la respuesta está contenida en uno o dos pasajes cercanos: una cláusula de un contrato, un procedimiento de un manual, una política de RRHH.

Grafo de conocimiento: entidades, relaciones y recorridos

Un knowledge graph representa la información como nodos (entidades: personas, empresas, productos, conceptos) y aristas (relaciones entre ellas: «trabaja en», «es proveedor de», «sustituye a», «depende de»). En lugar de buscar texto parecido, el sistema recorre el grafo: parte de una entidad y sigue sus relaciones hasta llegar a la respuesta. Esto es exactamente lo que necesita cuando la respuesta no está en un único párrafo, sino que hay que juntar varios hechos dispersos en documentos distintos para construirla.

Qué es GraphRAG exactamente

GraphRAG (el término se popularizó a raíz de investigación de Microsoft Research) es una variante de RAG que, en lugar de indexar solo fragmentos de texto, construye primero un grafo de entidades y relaciones a partir de los documentos (extrayendo entidades, relaciones y, a menudo, agrupándolas en comunidades temáticas) y después usa ese grafo para guiar la recuperación. Cuando llega una pregunta, el sistema no solo busca pasajes parecidos: identifica las entidades relevantes, recorre sus relaciones en el grafo y recupera tanto los pasajes originales como el contexto estructurado que conecta esas entidades. El resultado se pasa al modelo de lenguaje igual que en RAG clásico, pero con un contexto mucho más rico en preguntas que requieren unir varias piezas.

Construir ese grafo tiene un coste real: hace falta un paso de extracción de entidades y relaciones (normalmente con un modelo de lenguaje aplicado a cada fragmento), un proceso de resolución de entidades (decidir que «Banco Santander», «Santander» y «SAN» son la misma entidad) y, en las versiones más completas, un algoritmo de detección de comunidades para generar resúmenes jerárquicos del grafo. Esto no es gratis en tiempo de procesamiento ni en revisión humana, y es la razón por la que GraphRAG no debería ser la opción por defecto para cualquier proyecto.

Cuándo un grafo de conocimiento le va a ahorrar dolores de cabeza

Hay señales bastante claras de que su caso de uso se beneficiará de una capa de grafo, con o sin GraphRAG completo encima:

• Preguntas multi-hop: «¿qué proveedores comparten con el Cliente X los mismos requisitos de certificación que incumplió el Proveedor Y?» exige saltar entre varias entidades, no leer un párrafo.
• Relaciones que cambian con el tiempo y que importa auditar: organigramas, cadenas de propiedad societaria, historiales de versiones de un producto.
• Dominios donde las entidades se repiten en cientos de documentos con nombres distintos (sinónimos, abreviaturas, alias) y necesita unificarlas para razonar bien.
• Necesidad de explicar el razonamiento como un recorrido verificable («llegamos a esta conclusión porque A se relaciona con B y B con C»), más allá de citar un pasaje.
• Consultas analíticas agregadas: «¿cuántos contratos activos tiene el departamento X con proveedores de la región Y?», que ningún pasaje individual contiene.

Sectores típicos donde esto aparece: investigación de fraude, compliance con cadenas de proveedores complejas, bibliotecas jurídicas con remisiones cruzadas entre normas, o grandes bases de I+D donde un concepto aparece citado en decenas de papers con relaciones de dependencia entre ellos.

Cuándo RAG clásico (sin grafo) es la opción correcta

La mayoría de los proyectos de una pyme o un despacho no necesitan un grafo, y montarlo sin necesidad añade coste de infraestructura, mantenimiento y puntos de fallo sin mejorar la respuesta. Si sus preguntas típicas son del tipo «¿qué dice la política de vacaciones sobre los días acumulados?», «¿cuál es el plazo de garantía de este producto?» o «¿qué artículo del convenio regula esto?», la respuesta vive en un pasaje concreto o en dos como mucho. Un sistema RAG con buena búsqueda híbrida y un chunking bien pensado resuelve esto con mucha menos complejidad operativa que un grafo.

Casos concretos donde RAG clásico basta: un asistente de políticas de RRHH que cita el manual del empleado y el convenio, un soporte de atención al cliente que responde con el manual de producto, o una base de conocimiento jurídica centrada en consultar normativa artículo por artículo. En todos estos casos puede montar una base en Kopik subiendo sus PDF o Word, dejar que indexe con búsqueda híbrida y tener respuestas citadas sin tocar una base de datos de grafos.

Arquitecturas híbridas: usar el grafo donde aporta y RAG donde basta

En la práctica, muy pocos sistemas en producción son «100% grafo» o «100% pasajes». Lo habitual es un enfoque por capas:

1. Capa base de RAG con búsqueda híbrida para responder la mayoría de preguntas directas, que suelen ser el 70-80% del volumen real.
2. Capa de grafo ligero (solo entidades y relaciones clave del dominio, no todo el corpus) para las consultas multi-hop o analíticas que RAG clásico falla sistemáticamente.
3. Un paso de clasificación de la pregunta (o un agente que decide la estrategia) que enruta hacia pasajes, hacia el grafo, o hacia ambos y combina los resultados antes de generar la respuesta final.
4. Citas verificables en ambos caminos: si la respuesta viene del grafo, mostrar qué documentos originaron cada relación, no solo el nodo final.

Esta decisión de enrutamiento se parece mucho a la que ya tiene que tomar entre recuperación y meter todo en el contexto del modelo; si no ha leído la comparación correspondiente, le conviene revisar RAG vs modelos de contexto largo porque los criterios de decisión son muy similares: volumen de información, frecuencia de actualización y coste por consulta.

Coste y mantenimiento: la cuenta que nadie le cuenta al principio

El coste de un grafo de conocimiento no es solo la construcción inicial. Cada vez que cambian los documentos fuente hay que re-extraer entidades, re-resolver duplicados y, si usa comunidades jerárquicas, regenerar resúmenes. Esto convierte el mantenimiento en un proceso con pasos adicionales respecto a simplemente re-indexar fragmentos nuevos, que es lo único que exige un RAG clásico cuando sube un documento actualizado.

Antes de invertir en cualquiera de las dos rutas, mida qué porcentaje de sus preguntas reales fallan con RAG clásico y por qué motivo exacto. Si los fallos son de recuperación de un pasaje concreto, el problema suele resolverse ajustando el chunking o la búsqueda híbrida, no añadiendo un grafo. Si los fallos son sistemáticamente de tipo «necesito juntar hechos de tres documentos distintos», ahí sí hay un caso de negocio para el grafo. Este diagnóstico se hace con una evaluación sistemática del sistema RAG, no a ojo.

Cómo decidir en la práctica

Un orden razonable para no sobredimensionar su arquitectura desde el primer día:

1. Suba sus documentos a una base con búsqueda híbrida (por ejemplo en Kopik) y empiece a registrar preguntas reales de usuarios.
2. Clasifique manualmente las primeras 50-100 preguntas en «directas» (un pasaje basta) y «multi-hop» (requieren juntar varios hechos).
3. Si las multi-hop son una fracción pequeña, resuélvalas con mejores prompts de síntesis o recuperando más pasajes por pregunta, sin montar un grafo.
4. Si las multi-hop son una parte relevante y recurrente del volumen, modele un grafo acotado solo a las entidades y relaciones de ese subconjunto de preguntas, no a todo el corpus.
5. Revise los requisitos de protección de datos antes de modelar relaciones entre personas identificables; un grafo que conecta empleados, clientes y proveedores puede calificarse como tratamiento de datos personales más sensible que un simple índice de texto, así que conviene repasar RGPD y RAG en esta fase.

Para consultar cualquiera de estos sistemas desde sus herramientas habituales, tanto una base de pasajes como una capa de grafo pueden exponerse vía API REST o servidor MCP, de forma que un asistente como Claude, Cursor o ChatGPT consulte la base sin que usted tenga que montar infraestructura de integración desde cero.

Qué recordar al elegir entre grafo y RAG

No hay una respuesta universal: la decisión depende del tipo de pregunta que realmente le hacen sus usuarios, no del tipo de pregunta que usted imagina que le harán. RAG clásico con buena búsqueda híbrida resuelve la inmensa mayoría de los casos de documentación empresarial, políticas internas y soporte. Un grafo de conocimiento, puro o combinado en GraphRAG, aporta valor real cuando las respuestas exigen recorrer relaciones explícitas entre entidades dispersas en muchos documentos. Si tiene dudas sobre terminología (entidad, embedding, chunk, triple), el glosario de IA y LLM le puede servir de referencia rápida antes de hablar con su equipo técnico sobre cuál de las dos rutas tomar.