Si a un asistente de IA conectado a la documentación de una empresa se le pregunta qué dice la política de devoluciones, acertará. Si se le pregunta qué clientes con contrato marco tienen pedidos abiertos de un artículo que se descataloga el mes que viene, la respuesta sonará igual de segura. Y probablemente será incompleta. La distancia entre esas dos preguntas explica cuándo basta con RAG y cuándo hace falta GraphRAG.

Qué hace realmente un RAG

La mayoría de asistentes corporativos funcionan con lo que se llama RAG: generación aumentada por recuperación.

El mecanismo es sencillo. Los documentos se trocean en fragmentos. Cada fragmento se convierte en un vector, una lista de números que sitúa su significado en un espacio de muchas dimensiones. Cuando alguien pregunta, la pregunta también se convierte en vector, y el sistema recupera los fragmentos más cercanos. El modelo redacta la respuesta a partir de ellos.

Funciona muy bien para un tipo concreto de pregunta: aquella cuya respuesta vive en un párrafo.

  • En atención al cliente: qué plazo de garantía tiene una gama de producto.
  • En administración: cómo se solicita un anticipo de gastos.
  • En comercial: qué condiciones generales se aplican a un distribuidor.

Si la respuesta está escrita en algún sitio, el RAG la encuentra.

Dónde se queda corto

El reto aparece cuando la respuesta no está escrita en ningún sitio. Cuando hay que construirla.

La pregunta del contrato marco es de ese tipo. Nadie ha redactado un documento con esa lista. Para responderla hay que saber qué clientes tienen contrato marco, qué pedidos tienen abiertos, qué artículos llevan esos pedidos y cuáles se descatalogan. Cuatro hechos, repartidos entre el CRM, el ERP y el maestro de artículos, unidos por relaciones.

Un buscador vectorial no recorre relaciones. Encuentra fragmentos que se parecen a la pregunta. Y parecerse no es lo mismo que ser relevante.

La búsqueda vectorial encuentra lo que se parece a tu pregunta. Tu negocio necesita lo que está conectado con ella.

Hay tres situaciones en las que esto se nota enseguida:

  • Preguntas de varios saltos. Las que exigen encadenar hechos: cliente, contrato, pedido, artículo. El RAG trae trozos sueltos de algún eslabón, y el modelo rellena el resto con algo plausible.
  • Preguntas de conjunto. "¿Cuántos?", "¿todos los que...?", "¿cuál es el mayor?". Recuperar los cinco fragmentos más parecidos no permite contar ni comparar el universo completo.
  • Términos ambiguos. En finanzas, "cuenta" puede ser una cuenta contable o un cliente. En compras, una misma referencia puede nombrar dos artículos de dos proveedores. Para el vector son puntos cercanos. Para el negocio, cosas distintas.

El resultado no es un error evidente. Es una respuesta bien redactada, verosímil y parcial.

El error más caro en una empresa es el que nadie revisa porque suena bien.

Comparativa: la búsqueda vectorial recupera fragmentos parecidos y no recorre relaciones ni puede contar el conjunto; GraphRAG recupera entidades y relaciones, encadena hechos de varios sistemas y cada afirmación se puede rastrear

Qué añade GraphRAG

GraphRAG cambia el lugar donde se apoya la recuperación. En lugar de buscar sobre fragmentos de texto, busca sobre un grafo de conocimiento: entidades del negocio unidas por relaciones con significado.

Funciona en tres pasos:

  1. Indexar en un grafo. Un modelo de lenguaje lee documentos y tablas y extrae las entidades y relaciones que importan: clientes, contratos, pedidos, artículos, proveedores. El resultado es una red organizada alrededor de los conceptos de la empresa, no alrededor de los párrafos.
  2. Interpretar la pregunta por conceptos. La pregunta se traduce a esos mismos conceptos. "Contrato marco" deja de ser una cadena de texto y pasa a ser un tipo de entidad con sus relaciones. Los conceptos actúan como índice.
  3. Responder con contexto estructurado. El modelo recibe un fragmento del grafo: los hechos exactos y cómo se conectan. Redacta a partir de ahí, y cada afirmación se puede rastrear hasta su origen.

El modelo sigue haciendo lo que mejor sabe hacer: entender lenguaje y redactar. Lo que cambia es de dónde saca los hechos.

El modelo pone el lenguaje. El grafo pone los hechos y cómo se relacionan.

No es una guerra entre vectores y grafos

Plantearlo como RAG contra GraphRAG es engañoso. Son piezas complementarias.

Los vectores son buenos para lo continuo: parecido, matiz, sinónimos, tono. Los grafos son buenos para lo discreto: identidad, pertenencia, reglas. Una empresa necesita las dos cosas.

De hecho, ya conviven. Los índices vectoriales más rápidos organizan internamente sus vectores como una red de vecinos, precisamente para no tener que compararlo todo con todo. Y en un buen GraphRAG, los conceptos del grafo también tienen su vector, para que una pregunta formulada con otras palabras llegue al concepto correcto.

La diferencia está en la última milla. Cuando un cliente escribe "el pedido de la central", el vector entiende que habla de un pedido. El grafo sabe qué central es, a qué grupo empresarial pertenece y qué pedidos tiene abiertos.

Hay algo más de fondo. Dar nombre a un concepto es comprimir. Cuando la empresa define qué es exactamente un "cliente activo" o un "pedido bloqueado", reduce miles de casos a una categoría manejable. Esa compresión es comprensión. Y es justo lo que un modelo genérico no puede traer de serie, porque cada empresa comprime su realidad a su manera.

Cómo decidir qué necesita cada caso

No todo asistente necesita un grafo. Una escala sencilla ayuda a decidirlo:

  • Basta con RAG cuando las preguntas se responden con un documento: manuales, políticas, fichas técnicas, procedimientos.
  • Conviene un enfoque mixto cuando las preguntas combinan texto y un dato de sistema: el estado de un pedido junto a las condiciones de su contrato.
  • Hace falta GraphRAG cuando las preguntas cruzan entidades y sistemas, exigen contar o comparar, o cuando un error tiene coste económico: la exposición de riesgo de un grupo empresarial en finanzas, el impacto de un cambio de tarifa en la cartera comercial, los clientes afectados por una incidencia logística.
Escala de tres niveles: basta con RAG cuando la respuesta está en un documento, enfoque mixto cuando combina texto y un dato de sistema, y hace falta GraphRAG cuando cruza entidades y sistemas o un error tiene coste económico

Una pista práctica: si para responder a mano una persona tendría que abrir más de un sistema, el RAG vectorial por sí solo no va a llegar.

La complejidad no está en la pregunta. Está en cuántas relaciones hay que recorrer para responderla.

Esta es mi apuesta

Creo que muchas empresas van a descubrir los límites del RAG en el peor momento: cuando un asistente que funcionaba bien en la demo empiece a dar respuestas plausibles e incompletas sobre clientes, contratos o pedidos reales.

La salida no es cambiar de modelo. Es darle al modelo una representación del negocio que pueda recorrer: entidades, relaciones y reglas. Y la propia IA ayuda a construirla, extrayendo esa estructura de los documentos y tablas que la empresa ya tiene.

Ese es el orden que tiene sentido: primero usar la IA para ordenar los datos alrededor de los conceptos de la empresa, y después usar esos datos ordenados para que la IA responda con fundamento.

Un asistente que solo encuentra textos parecidos responde. Uno que recorre el negocio, entiende.