RAG vs Grafo de Conocimiento: Cuál Necesita tu Empresa
RAG fue el primer paso para que un modelo respondiera con información de tu empresa en lugar de con lo que aprendió en internet, y sigue siendo la respuesta correcta para muchos casos. Pero hay preguntas de negocio que un sistema de recuperación por similitud no puede contestar bien, por diseño. Este artículo distingue unas de otras.
Cómo funciona cada uno
RAG parte los documentos en fragmentos, los convierte en vectores y los guarda. Cuando llega una pregunta, la convierte también en vector y trae los fragmentos más parecidos. Esos fragmentos se meten en el contexto del modelo, que redacta la respuesta a partir de ellos. Si quieres el detalle, lo desarrollamos en sistemas RAG y en vectores y embeddings.
Un grafo de conocimiento no guarda fragmentos: guarda entidades y las relaciones entre ellas, cada una con su vigencia. Cuando llega una pregunta, no busca texto parecido — recorre la red y devuelve hechos.
La diferencia de fondo cabe en una frase: RAG te trae el párrafo donde probablemente esté la respuesta; el grafo te trae la respuesta.
Las tres preguntas donde RAG se queda corto
1. Las que dependen de qué está vigente
"¿Cuánto cuesta este servicio?" Si en tus documentos hay una lista de precios de enero, otra de junio y un correo con un ajuste de agosto, los tres fragmentos son igual de "parecidos" a la pregunta. La similitud no distingue lo actual de lo caduco, porque no es lo que mide.
El grafo sí, porque cada hecho lleva su ventana de validez. Es el tema que desarrollamos en grafos temporales.
2. Las que cruzan varios documentos
"¿Qué clientes de esta zona compraron el producto que ahora tiene promoción?" La respuesta no está escrita en ningún párrafo: hay que unir tres cosas que viven en fuentes distintas. RAG recupera fragmentos, no hace uniones.
3. Las que exigen exactitud
Cuando el fragmento recuperado contiene el dato, el modelo todavía tiene que leerlo y transcribirlo — y ahí puede equivocarse, sobre todo con tablas. El grafo devuelve el valor como dato estructurado, no como texto que hay que interpretar.
Comparativa
| Criterio | RAG | Grafo |
|---|---|---|
| Qué devuelve | Fragmentos de texto | Hechos estructurados |
| Vigencia | No la distingue | Nativa |
| Cruzar fuentes | Limitado | Es su función |
| Exactitud numérica | Depende del modelo | Del dato |
| Puesta en marcha | Rápida | Requiere modelar entidades |
| Texto largo y narrativo | Mejor opción | Menos natural |
| Escribir de vuelta lo aprendido | No | Sí |
Cuándo basta con RAG
No todo necesita un grafo. RAG es la opción correcta cuando el conocimiento es narrativo y estable: manuales de procedimiento, documentación técnica, bases de artículos de ayuda, marcos normativos. Ahí la respuesta sí está escrita en un párrafo, y traer ese párrafo es exactamente lo que hace falta.
También es la opción sensata cuando quieres validar rápido si un asistente aporta valor. Montar RAG sobre un repositorio de documentos toma poco y responde la pregunta de negocio antes de invertir en modelar entidades.
Cuándo necesitas el grafo
Si dos o más de estas son ciertas, RAG te va a quedar corto:
- Tus datos incluyen precios, disponibilidad o vigencias que cambian.
- Las preguntas frecuentes requieren cruzar información de sistemas distintos.
- Una respuesta equivocada tiene consecuencia comercial directa.
- Varios agentes deben compartir lo que aprenden de cada cliente.
- Tu información vive en formatos mixtos: hojas de cálculo, PDFs, APIs y conversaciones.
No son excluyentes
En la práctica, la arquitectura que mejor funciona usa los dos: el grafo para los datos duros —precios, inventario, vigencias, relaciones con clientes— y RAG para el conocimiento narrativo, como el manual de procedimientos o las condiciones de garantía.
El criterio para repartir es simple: si el dato es un hecho que puede cambiar y debe ser exacto, va al grafo. Si es una explicación que hay que leer, va a RAG.