Una guía para entender grafos, memoria y contexto en la era de la inteligencia artificial.
Hay palabras que últimamente aparecen por todas partes:
RAG. Embeddings. Vector databases. Context window. Agents. MCP. Knowledge Graph. GraphRAG.
Y llega un momento en que uno piensa:
“A ver… ¿qué demonios es un grafo?”
Porque además parece que todo mundo está haciendo uno.
Obsidian tiene su grafo. Neo4j lleva años construyendo tecnología alrededor de ellos. Microsoft tiene GraphRAG. Graphiti utiliza grafos para darle memoria a agentes. Hay proyectos que convierten documentos en grafos. Y otros que convierten directamente un codebase en un grafo.
Entonces…
¿Estamos hablando de lo mismo?
No.
Pero sí hay una idea que conecta a todos:
Representar información no solamente por lo que es, sino por la relación que tiene con otras cosas.
Y eso se vuelve especialmente interesante cuando hablamos de inteligencia artificial.
Empecemos con algo muy sencillo
Imagina que estamos construyendo un agente de IA.
El agente tiene acceso a varias cosas:
AGENTE IA
│
┌────────────┼────────────┐
▼ ▼ ▼
MEMORIA MCP CÓDIGO
│ │ │
▼ ▼ ▼
HECHOS TOOLS PROYECTO
Podríamos almacenar toda esa información como texto.
Por ejemplo:
El proyecto utiliza .NET. La base de datos es SQL Server. El agente puede utilizar herramientas mediante MCP. El proyecto tiene un repositorio en GitHub. El modelo utilizado actualmente es X. El desarrollador decidió utilizar esta arquitectura por determinada razón.
Todo eso está bien.
Pero hay algo que no estamos representando explícitamente:
las relaciones.
Podemos transformar la misma información en algo parecido a esto:
DESARROLLADOR
│
construye
│
▼
PROYECTO
│ │ │
│ │ └──── utiliza ──► SQL SERVER
│ │
│ └───────── utiliza ──► .NET
│
└────────────── tiene ────► GITHUB
Y entonces aparece la idea fundamental.
Un grafo conecta cosas
No solamente almacena:
“A existe.”
También puede representar:
“A está relacionado con B de determinada manera.”
Y esa relación puede tener significado.
Las tres piezas de un grafo
No hace falta ponerse demasiado académico.
Para entender la idea basta con tres conceptos.
1. Nodos
Son las cosas.
Agente
Proyecto
.NET
SQL Server
GitHub
MCP
Claude
DeepSeek
2. Relaciones
Indican cómo están conectadas esas cosas.
utiliza
depende_de
desarrolla
consulta
modifica
pertenece_a
reemplaza
Por ejemplo:
AGENTE ──utiliza──► MCP
o:
PROYECTO ──depende_de──► SQL SERVER
3. Propiedades
Información adicional sobre los nodos o relaciones.
Por ejemplo:
PROYECTO
├── lenguaje: C#
├── framework: .NET
└── estado: producción
Así que, simplificando mucho:
Nodo + relación + propiedades = una estructura de conocimiento mucho más rica que una lista de datos.
¿Y por qué no usamos simplemente una base de datos?
Buena pregunta.
Porque las bases de datos tradicionales son extraordinarias para muchas cosas.
Podríamos tener:
| Proyecto | Tecnología |
|---|---|
| Proyecto A | .NET |
| Proyecto A | SQL Server |
| Proyecto A | GitHub |
Perfecto.
Pero cuando empezamos a preguntar:
¿Qué depende de este servicio?
¿Qué otros componentes utilizan esta biblioteca?
¿Qué proyectos están relacionados con este cliente?
¿Qué decisiones llevaron a esta arquitectura?
¿Qué cambió después de aquella migración?
el problema empieza a ser menos:
“dame este dato”
y más:
“explícame las relaciones entre estos datos”.
Ahí es donde el modelo de grafo resulta especialmente natural.
El ejemplo más fácil: Google Maps
Piensa en un mapa.
Una ciudad es un punto.
Otra ciudad es otro punto.
Pero lo realmente interesante son las conexiones:
MONTERREY
│
│ carretera
▼
SALTILLO
│
│ carretera
▼
SAN LUIS POTOSÍ
La relación:
Monterrey → carretera → Saltillo
es información.
No es simplemente decoración.
Ahora imagina miles de ciudades, carreteras, aeropuertos, vuelos y rutas.
Eso es un grafo.
Y podemos hacer preguntas como:
¿Cómo llego de A a B?
¿Qué ciudades están conectadas?
¿Cuál es la ruta más corta?
¿Qué sucede si cierro esta conexión?
Eso mismo, llevado al mundo de los datos, es una de las razones por las que los grafos son tan poderosos.
Ahora llevémoslo a la inteligencia artificial
Aquí es donde empieza lo divertido.
Durante los últimos años hemos hablado muchísimo de RAG.
La idea básica es bastante sencilla:
USUARIO
│
▼
PREGUNTA
│
▼
BUSCADOR
│
▼
DOCUMENTOS RELEVANTES
│
▼
LLM
│
▼
RESPUESTA
El modelo no necesita conocer toda nuestra información.
Puede buscarla cuando la necesita.
Eso fue un cambio enorme.
Pero aparece una limitación.
A veces la respuesta no está escrita literalmente en un documento.
La respuesta está en las relaciones entre varios documentos.
Un ejemplo
Supongamos que tenemos estos documentos:
Documento 1
Proveedor A trabaja con Producto X.
Documento 2
Producto X es compatible con Equipo Y.
Documento 3
Equipo Y está instalado en Monterrey.
Documento 4
Proveedor A ofrece garantía de 24 meses.
Ahora preguntamos:
¿Qué proveedor ofrece un producto compatible con los equipos instalados en Monterrey y con garantía de 24 meses?
La respuesta probablemente no está en ningún documento.
Está repartida:
Proveedor A
│
▼
Producto X
│
▼
Equipo Y
│
▼
Monterrey
y además:
Proveedor A
│
▼
Garantía
│
▼
24 meses
La información estaba ahí.
Pero la respuesta requería conectar los puntos.
Y ahí aparece GraphRAG.
¿Qué demonios es GraphRAG?
Dicho de manera muy simplificada:
GraphRAG combina recuperación de información con estructuras de conocimiento basadas en grafos.
En lugar de pensar únicamente:
DOCUMENTO
↓
CHUNKS
↓
EMBEDDINGS
↓
BÚSQUEDA
podemos tener:
DOCUMENTOS
│
▼
ENTIDADES
│
▼
RELACIONES
│
▼
GRAFO
│
▼
RECUPERACIÓN
│
▼
LLM
Microsoft desarrolló GraphRAG precisamente para abordar preguntas donde entender la estructura global de un conjunto documental puede aportar información que una búsqueda basada únicamente en fragmentos puede perder.
Y aquí conviene hacer una aclaración:
GraphRAG no es simplemente “RAG + Neo4j”.
Es una estrategia de recuperación y generación que utiliza estructuras de conocimiento y relaciones para mejorar el contexto que recibe el modelo.
Pero entonces aparece otra palabra: memoria
Y aquí es donde, personalmente, creo que el tema se vuelve mucho más interesante.
Porque un RAG puede ayudarte a buscar información.
Pero un agente necesita algo más.
Necesita recordar.
Imagina que le dices a un agente:
“Para este proyecto prefiero .NET porque ya tenemos mucho código desarrollado en C#.”
Meses después:
“¿Por qué seguimos usando .NET?”
Un sistema con memoria podría representar algo así:
USUARIO
│
└── prefiere ──► .NET
│
└── razón ──► código existente
Ahora imagina que el proyecto cambia.
.NET
│
└── reemplazado_por ──► NUEVA ARQUITECTURA
La información anterior no necesariamente desaparece.
Puede convertirse en parte del historial.
Y aquí aparece una idea muy poderosa:
La memoria no solamente consiste en guardar cosas
También consiste en entender cómo están relacionadas y cómo cambian con el tiempo.
La memoria de un agente puede convertirse en un grafo
Imagina algo así:
AGENTE
│
┌────────────┼────────────┐
▼ ▼ ▼
PERSONAS PROYECTOS SISTEMAS
│ │ │
└──────┬─────┴──────┬─────┘
▼ ▼
DECISIONES HECHOS
│ │
└─────┬──────┘
▼
MEMORIA
Ahora el agente puede recordar:
- qué se decidió;
- quién lo decidió;
- por qué;
- qué proyecto estaba involucrado;
- qué tecnología se utilizó;
- qué ocurrió después.
Eso es mucho más rico que simplemente guardar el historial de conversaciones.
Proyectos como Graphiti están construidos alrededor de esta idea de utilizar grafos temporales para representar conocimiento y memoria de agentes, incluyendo hechos, relaciones y el momento en que esa información fue válida.
Y Neo4j también está explorando arquitecturas de memoria de agentes que combinan información estructurada, relaciones y recuperación semántica.
Y aquí viene algo que me encanta
¿Qué pasa si hacemos un grafo del código?
Porque sí.
También podemos convertir un codebase en un grafo.
Supongamos que tenemos:
OrderController
OrderService
OrderRepository
OrdersTable
En archivos quizá veamos:
Controllers/
Services/
Repositories/
Models/
Pero un grafo puede mostrarnos algo más interesante:
OrderController
│
│ llama_a
▼
OrderService
│
│ llama_a
▼
OrderRepository
│
│ consulta
▼
OrdersTable
Ahora podemos hacer preguntas como:
¿Quién llama a este método?
¿Qué depende de esta clase?
¿Qué componentes podrían verse afectados si cambio esto?
¿Qué ruta HTTP termina ejecutando este servicio?
Eso es justamente la idea detrás de herramientas como codebase-memory-mcp: analizar un repositorio y construir una representación estructurada de sus elementos y relaciones para que un agente pueda consultarla mediante MCP.
Y aquí el asunto empieza a ponerse bastante interesante.
Porque tenemos:
GRAFO DEL MUNDO
+
GRAFO DE MEMORIA
+
GRAFO DEL CÓDIGO
¿Y Obsidian?
Aquí probablemente mucha gente ya está pensando:
“¡Pero Obsidian tiene un grafo!”
Sí.
Y es un excelente ejemplo para entender visualmente la idea.
En Obsidian puedes tener:
Nota A
│
├────► Nota B
│
└────► Nota C
│
└────► Nota D
La idea fundamental es que las notas pueden enlazarse.
El Graph View simplemente hace visible esa red.
Pero hay una distinción importante:
Obsidian no es lo mismo que un knowledge graph para agentes.
Obsidian nació como una herramienta de conocimiento personal basada en Markdown y enlaces.
Después podemos agregarle capas de búsqueda semántica, plugins y MCP.
Pero el concepto fundamental es diferente.
Y precisamente por eso resulta tan interesante como ejemplo.
Entonces… ¿qué tipos de grafos estamos encontrando?
Aquí es donde normalmente empiezan las confusiones.
Porque todos tienen nodos y relaciones, pero no necesariamente resuelven el mismo problema.
Knowledge Graph
Representa conocimiento:
PERSONA
│
trabaja_en
▼
EMPRESA
│
vende
▼
PRODUCTO
GraphRAG
Utiliza grafos para mejorar la recuperación de conocimiento:
DOCUMENTOS
↓
ENTIDADES
↓
RELACIONES
↓
GRAFO
↓
RETRIEVAL
↓
LLM
Agent Memory
Representa lo que un agente necesita recordar:
HECHOS
DECISIONES
PREFERENCIAS
EXPERIENCIAS
HISTORIAL
↓
MEMORIA
Code Graph
Representa la estructura de un sistema:
CLASE
↓
MÉTODO
↓
LLAMADA
↓
SERVICIO
↓
BASE DE DATOS
Personal Knowledge Graph
Representa conocimiento humano:
IDEAS
│
├── proyectos
├── personas
├── artículos
├── conceptos
└── referencias
Y ahí puede entrar perfectamente una herramienta como Obsidian.
Entonces… ¿los grafos van a reemplazar a las bases vectoriales?
No.
Y tampoco deberían.
Ese es otro error común.
No necesariamente tenemos que elegir:
Grafo O vector database.
Podemos utilizar ambos.
Por ejemplo:
INFORMACIÓN
│
┌───────────┼───────────┐
▼ ▼ ▼
TEXTO VECTOR GRAFO
│ │ │
└───────────┼───────────┘
▼
CONTEXTO
│
▼
AGENTE
El vector puede ayudar a encontrar información semánticamente parecida.
El grafo puede ayudar a entender relaciones.
El texto puede conservar el contenido original.
Y el agente puede combinar todo eso.
No son necesariamente competidores.
Son piezas diferentes.
Y esto nos lleva a algo todavía más importante
Durante mucho tiempo imaginamos una IA así:
PROMPT
↓
MODELO
↓
RESPUESTA
Después:
PROMPT
↓
RAG
↓
MODELO
↓
RESPUESTA
Ahora estamos empezando a construir algo más parecido a:
AGENTE
│
┌──────────────┼──────────────┐
▼ ▼ ▼
MEMORIA CONOCIMIENTO HERRAMIENTAS
│ │ │
▼ ▼ ▼
GRAFO GRAFO MCP
│ │ │
└──────────────┼──────────────┘
▼
CONTEXTO
│
▼
LLM
Y eso cambia bastante la conversación.
Porque el agente ya no solamente recibe un prompt.
Puede tener:
memoria.
conocimiento.
herramientas.
código.
historial.
relaciones.
Y todo eso puede estar conectado.
¿Significa esto que una IA “entiende” realmente?
Aquí hay que tener cuidado.
Un grafo no convierte mágicamente un modelo de lenguaje en una inteligencia consciente.
Un grafo puede estar equivocado.
Puede contener información vieja.
Puede tener relaciones mal extraídas.
Puede tener entidades duplicadas.
Y si una IA construye el grafo, también puede equivocarse al interpretar la información original.
Por eso empiezan a cobrar importancia conceptos como:
proveniencia.
temporalidad.
confianza.
actualización.
No basta con saber:
“Esto es cierto.”
También queremos saber:
“¿De dónde salió?”
“¿Cuándo era cierto?”
“¿Quién lo dijo?”
“¿Sigue siendo cierto?”
Eso es especialmente importante cuando hablamos de memoria de agentes.
Entonces, ¿por qué estamos hablando tanto de grafos ahora?
Porque los modelos de lenguaje son extraordinariamente buenos trabajando con lenguaje.
Pero el mundo real no está hecho únicamente de texto.
Está hecho de:
personas.
empresas.
productos.
sistemas.
documentos.
decisiones.
eventos.
dependencias.
historial.
Y, sobre todo:
relaciones
Muchas preguntas importantes no son:
“¿Dónde aparece esta información?”
Son:
"¿Cómo está relacionada esta información con todo lo demás?"
Ahí es donde el grafo se vuelve interesante.
Y quizá esta sea la mejor manera de verlo
Un buscador puede decirte:
“Encontré esto.”
Un sistema RAG puede decirte:
“Encontré estos fragmentos relevantes.”
Un grafo puede ayudarte a decir:
“Esto está relacionado con aquello.”
Y un agente con memoria puede llegar a algo todavía más interesante:
“Esto está relacionado con aquello, esto ocurrió antes, esta fue la decisión que tomamos y esto es lo que cambió después.”
Ese salto es importante.
Porque ya no estamos hablando solamente de recuperar información.
Estamos hablando de contexto.
El grafo como una capa de contexto
Quizá esta sea la idea que vale la pena llevarse de todo el artículo.
No pensemos en un grafo solamente como:
“una base de datos con bolitas y líneas”.
Pensemos en él como una forma de representar:
qué cosas existen, cómo se relacionan y qué significado tienen esas relaciones.
Y eso tiene muchísimo sentido para una IA.
Porque cuanto más autónomo queremos que sea un agente, menos basta con darle una ventana de contexto enorme y esperar que mágicamente encuentre todo.
Necesitamos darle estructura.
Necesitamos memoria.
Necesitamos relaciones.
Necesitamos contexto.
Y ahí los grafos están encontrando un nuevo lugar dentro de la arquitectura de la IA.
Y ahora viene la parte divertida…
Ya entendimos qué es un grafo de conocimiento.
Pero cuando uno empieza a investigar aparecen nombres por todas partes:
Neo4j.
Graphiti.
Microsoft GraphRAG.
Cognee.
RAGFlow.
Obsidian.
FalkorDB.
codebase-memory-mcp.
Y aquí descubrimos algo todavía más interesante:
no todos están haciendo lo mismo.
Algunos quieren construir memoria para agentes.
Otros quieren hacer RAG sobre documentos.
Otros quieren representar conocimiento.
Otros quieren convertir un codebase completo en un grafo.
Y otros están más cerca del conocimiento personal.
Así que la siguiente pregunta ya no es:
"¿Qué demonios es un grafo?"
Ahora es:
¿Cuál de todos estos grafos me sirve para qué?
Y esa…
esa sí merece una comparativa.