El grafo que le faltaba a tu agente: por qué la memoria vectorial sola no basta — y cómo MillenniumDB cerró la brecha

Pregúntale a tu agente favorito: "¿quién asistió al evento donde se presentó MillenniumDB?" Si solo tiene memoria vectorial, lo más probable es que se quede en blanco — no porque no tenga el dato, sino porque esa pregunta exige cruzar tres relaciones: una persona asiste a un evento, y un proyecto se presenta en ese mismo evento. La memoria vectorial no modela relaciones: modela similitud.

En el capítulo 1 de esta serie vimos por qué tu agente olvida cuando su memoria carece de estructura. En el capítulo 2 evolucionamos nuestra memoria de 3 a 5 capas. Hoy atacamos la capa que casi nadie tiene en producción: la capa relacional — el grafo. Y lo hacemos con datos reales, no con teoría: nuestra implementación con MillenniumDB, la graphDB chilena del IMFD/DCC de la Universidad de Chile.

1. El problema: la memoria vectorial es una nube de puntos sin aristas

La arquitectura dominante de memoria para agentes hoy es el RAG (Retrieval-Augmented Generation) con vector stores: cada fragmento de texto se convierte en un embedding — un vector de cientos de dimensiones — y se guarda en un espacio donde la distancia representa similitud semántica. Cuando preguntas algo, el sistema busca los vectores más cercanos a tu consulta y se los entrega al LLM como contexto.

Esto funciona muy bien para una clase de pregunta: "¿qué dijimos sobre X?", "¿dónde aparece mencionado Y?". Pero tiene un límite estructural: un vector no tiene aristas. En un espacio de 1536 dimensiones no existe el concepto de "se relaciona con", ni de "participa en", ni de "fue decisión sobre". Todo eso vive fuera del modelo vectorial.

No es que el vector store esté mal: es que responde una pregunta distinta. La memoria semántica te dice qué se dijo; la memoria relacional te dice cómo se conecta. Un agente de producción necesita ambas — y la mayoría solo tiene la primera.

2. Por qué una graphDB — y por qué no SQL con JOINs

Un grafo modela el mundo como entidades (personas, proyectos, tecnologías, eventos, decisiones) y relaciones tipadas entre ellas:

(Persona) —asisteA→ (Evento) ←sePresentaEn— (Proyecto)
(Proyecto) —usaTecnologia→ (Tecnologia)
(Persona) —tomaDecision→ (Decisión) —sobreProyecto→ (Proyecto)

Y se consulta con SPARQL, un lenguaje declarativo diseñado exactamente para esto — navegar el grafo, no recorrer tablas:

SELECT DISTINCT ?persona WHERE {
  ?persona a :Persona .
  ?persona :asisteA ?evento .
  ?proyecto :sePresentaEn ?evento .
  ?proyecto :nombre "MillenniumDB" .
}

¿Y por qué no modelar esto en SQL? Porque puedes — pero el costo es real. Cada nuevo tipo de relación exige migraciones de esquema, JOINs que se vuelven ilegibles a los 3 niveles de profundidad, y un modelo mental que nada tiene que ver con cómo piensa un ser humano sobre conexiones. El grafo, en cambio, crece por agregación: agregas un nodo, agregas una arista, y las preguntas nuevas emergen sin rediseñar nada.

3. Por qué MillenniumDB: rendimiento, licencia y soberanía

Cuando decidimos implementar la capa de grafo evaluamos las opciones del mercado. La respuesta corta: MillenniumDB gana en la combinación que importa para una PYME o un agente de producción. La respuesta larga, con datos:

3.1. Rendimiento verificado sobre Wikidata

El repositorio oficial MillenniumDB/benchmark y los papers publicados evalúan el motor sobre consultas reales del knowledge graph de Wikidata (miles de millones de triples), y en esa evaluación supera consistentemente a Blazegraph, Neo4j y Jena — incluidas alternativas enterprise. No es un benchmark inventado por el proyecto: es el estándar de la industria, público y reproducible.

3.2. Origen académico de clase mundial

MillenniumDB nace del IMFD (Instituto Milenio Fundamentos de los Datos) y del DCC de la Universidad de Chile. Sus co-autores incluyen a Aidan Hogan, Domagoj Vrgoc, Marcelo Arenas, Renzo Angles y Gonzalo Navarro — nombres que lideran la investigación mundial en bases de datos. Su paper "MillenniumDB: An Open-Source Graph Database System" (Data Intelligence, MIT Press) documenta la arquitectura con rigor académico.

3.3. GPL-2.0: libre, sin costos de licencia, en tu propio hardware

Para una empresa en LATAM, la licencia importa tanto como el rendimiento. MillenniumDB es GPL-2.0: lo corres en tu VPS, en tu on-premise, sin pagar licencias, sin enviar tus datos de relaciones a la nube de nadie. En un contexto de Ley 21.719 y soberanía de datos, eso no es un detalle: es la diferencia entre tener tus relaciones bajo tu control o depender de un tercero.

4. La demostración real: la query que ningún vector store responde

Hablemos con números de nuestra implementación, no de slides. Nuestro grafo de producción corre en graph.wsolutionsai.com (Docker + Traefik + TLS + autenticación) sobre MillenniumDB, modelando el ecosistema real de Wagner Solutions. Al día de hoy:

Ahora, la pregunta estrella de la saga — la que disparó todo en el seminario LCRS 2026 (Leiden ↔ Chile):

La query SPARQL real, la que corre en nuestro grafo:

SELECT DISTINCT ?persona WHERE {
  ?persona a :Persona .
  ?persona :asisteA ?evento .
  ?proyecto :sePresentaEn ?evento .
  ?proyecto :nombre "MillenniumDB" .
}

El resultado, en milisegundos:

Fíjate en lo que pasó: el agente no "adivinó" la respuesta buscando texto parecido. Navegó el grafo: de MillenniumDB al evento donde se presentó, y de ahí a cada persona que asistió. Es un razonamiento de 3 saltos que un vector store simplemente no puede hacer — no importa cuánto contexto le des.

Y esto no vive en un paper: es la misma capa que usa Shiva (nuestro agente) cuando le preguntas por relaciones entre proyectos, personas y decisiones del ecosistema. El módulo Python graph_memory.py expone métodos como conexiones(), multi_hop() y stack_completo() que el agente invoca en producción.

5. Honestidad anti-hype: lo que MillenniumDB NO hace (aún)

En esta serie tenemos una regla de oro: no sobrevender. Así que seamos claros sobre los límites reales de nuestra implementación y del motor:

• Tamaño modesto: nuestro grafo tiene ~164 entidades, no millones. Es la capa relacional de un agente de una PYME, no una réplica de Wikidata. La arquitectura escala, pero el dato honesto es ese.
• Transacciones y updates: el motor está optimizado para lectura intensiva; la escritura transaccional aún es un área en desarrollo. Hoy nuestro pipeline de ingestión es semi-manual (generar TTL → re-importar), no automático.
• Licencia GPL-2.0: perfecta para uso interno y para contribuir aguas arriba, pero si algún día distribuyes un producto que lo embeba, GPL obliga a compartir el código. Para nuestro caso es un win: retribuimos con contribuciones.
• Herramientas: la UI de exploración gráfica (graph-ui) aún tiene fixes pendientes; la interfaz primaria es SPARQL vía API, que es lo que usamos en producción.

Dicho esto, el ecosistema está vivo y creciendo: en agosto contribuimos con 5 PRs al proyecto (fix SIGILL, web port, setup script, start-server, import de Wikidata) — y cada semana el motor suma capacidades. La dirección es correcta.

6. Lo que viene en la saga

Este capítulo cerró el qué y el por qué. Los próximos abren la caja:

• Capítulo 4: De 0 a grafo en producción — esquema, Docker, SPARQL e integración paso a paso.
• Capítulo 5: Multi-hop en acción — más queries reales que solo el grafo responde.
• Capítulo 6: Vector vs Grafo vs Híbrido — nuestro benchmark honesto con números.
• Capítulo 7: MillenniumDB vs otras graphDB para agentes — con datos.

Conclusión: la frontera de la memoria agéntica no vive solo en Silicon Valley

Hay una narrativa cómoda que dice que la inteligencia artificial de frontera se inventa en California y el resto del mundo la consume. La capa de grafo de la memoria agéntica demuestra lo contrario: la pieza que le faltaba a los agentes — la memoria relacional — se implementa de forma soberana con una graphDB chilena de clase mundial, desarrollada por investigadores del IMFD y la Universidad de Chile, con rendimiento verificado sobre Wikidata.

La memoria vectorial te dice qué pasó. El grafo te dice cómo se conecta. Y un agente que no puede conectar puntos — literalmente — no es un agente: es un buscador con buena redacción.