Frameworks de memoria, leídos con lupa

5.1El problema

Un post de vendor cruza tu timeline. El titular promete: "~26% de mejora sobre la memoria de ChatGPT, 91% menos latencia, más del 90% de ahorro de tokens".

Tu arquitectura artesanal acaba de pasar el kill-test de L4. Notas, store con políticas, supervivencia medida. Y ahora alguien te ofrece todo eso empaquetado, con números que parecen aplastantes. ¿Tiras tu código y adoptas el framework?

La respuesta seria no empieza por el porcentaje. Empieza por tres preguntas: ¿contra qué baseline se midió? ¿quién lo midió? ¿quién lo replicó? Si no las haces, estás tomando una decisión de ingeniería con un material de marketing.

Esta lección te da la lupa. Leerás los benchmarks de los tres linajes como lo que son: claims con un autor y un incentivo. Y decidirás, con criterios, cuándo adoptar uno.

5.2Qué vas a poder hacer

Al terminar serás capaz de:

• Situar los tres linajes de frameworks de memoria (MemGPT/Letta, Mem0, Zep/Graphiti) y su mecanismo central.
• Leer un benchmark de vendor con un checklist: baseline, autor, mejora relativa vs absoluta, réplica.
• Diseccionar la disputa LOCOMO entre Mem0 y Zep, separando lo que se afirma de lo que se puede afirmar.
• Decidir, con tres criterios, si Magallanes debe seguir con memoria artesanal o adoptar un framework.

Necesitas saber antes:

• De L4 (Sobrevivir al reinicio): qué métricas definiste para tu memoria —re-trabajo y trade-off— y contra qué baseline. Lo recuperamos en 5.3.
• De N2·L3 (/cursos/context-engineering/memoria/el-store-externo): tus políticas de write y select sobre el Store. Reaparecen al final.
• La lectura crítica de benchmarks de N0·L1 (/cursos/context-engineering/diagnostico/el-mito-de-la-ventana-infinita): la distancia entre lo anunciado y lo efectivo. La misma lupa sirve hoy.

5.3Recupera

Antes de seguir, responde de memoria. Esto reactiva lo anterior y engancha lo nuevo.

1. En L4 mediste si Magallanes sobrevivía al kill. ¿Qué métrica usaste y contra qué baseline la comparaste?
2. De N0·L1: cuando un benchmark anuncia una ventana de contexto, ¿por qué la longitud efectiva suele ser menor que la anunciada?
3. Tu política de write de L3 decidía qué guardar en el Store. ¿Quién toma esa decisión en tu diseño artesanal: tú o el código del framework?

5.4El concepto

Antes de entrar: esta es la sección más densa del nivel, no por el código, sino por las cifras. Vienen números grandes con asteriscos. La estrategia: lee cada claim con su matiz pegado —nunca el número solo— y desconfía de cualquiera que llegue sin baseline. El matiz no es letra pequeña; es la mitad del claim.

La palanca write, ahora empaquetada

Recuerda la taxonomía de Lance Martin que organiza el curso (corpus B.2). La palanca write —"saving it outside the context window to help an agent perform a task"— es lo que tú implementaste a mano en L2–L4: notas, Store, políticas. · fuente: corpus B.2 (Lance Martin, 23 jun 2025).

Los frameworks de memoria son productos que implementan esa palanca por ti: deciden qué extraer, qué guardar y qué recuperar, con sus propias heurísticas. La analogía: pasar de cocinar con ingredientes a comprar el plato preparado. Dónde falla la analogía: el plato preparado no decide qué comes mañana. El framework sí toma decisiones de política que antes tomabas tú, y quedan fuera de tu vista.

Hay tres linajes. Cada uno con su mecanismo central y su sesgo de medición. Los vemos con la lupa puesta.

MemGPT / Letta — la memoria virtual de un sistema operativo

MemGPT (corpus C.4, arXiv:2310.08560, Packer et al., oct 2023) propone virtual context management: gestionar el contexto del agente como un OS gestiona la memoria virtual, paginando información entre lo que cabe y lo que no. · fuente: corpus C.4. Dónde falla la analogía: un OS pagina indefinidamente sin penalización; el LLM paga latencia y coste de inferencia en cada paginación, y la calidad no se recupera con más disco.

El diseño parte en dos. El main context es lo que entra en la ventana del modelo: system instructions, working context y una cola FIFO de mensajes. El external context es lo de fuera: recall storage guarda los mensajes evictados, buscables, y archival storage indexa por vectores textos arbitrarios. Cuando el main context se llena, el sistema pagina entre ambos, igual que un OS entre RAM y disco. · fuente: corpus C.4.

El número estrella: en el benchmark DMR, GPT-4 Turbo de baseline marca 35,3%; con MemGPT, 93,4%. · fuente: corpus C.4.

Aquí va el primer matiz obligatorio. DMR es un benchmark auto-construido por el propio equipo de MemGPT. Quien diseña su benchmark elige las tareas donde su sistema brilla —no por mala fe, sino por incentivo estructural—. El 93,4% es real; la pregunta es contra qué prueba. · fuente: corpus C.4, matiz.

En septiembre de 2024 MemGPT se convierte en Letta (compañía, código abierto en github.com/letta-ai/letta). · fuente: corpus C.4.

Mem0 — extracción y actualización, con tres cifras y un asterisco

Mem0 (corpus C.5, arXiv:2504.19413, abr 2025) es un vendor. Su arquitectura tiene dos fases: una de extracción —destila qué de la conversación merece ser memoria— y una de update que deduplica y resuelve contradicciones contra lo ya guardado. · fuente: corpus C.5 (vendor).

Sus tres cifras son las del titular de 5.1. El matiz cambia lo que significa cada cifra. Léelas con él pegado:

• ~26% de mejora relativa (juzgada por un LLM) en el benchmark LOCOMO, frente a la memoria de ChatGPT/OpenAI. · fuente: corpus C.5.
• 91% menos latencia p95 (1,44 s vs 17,12 s), frente a full-context. El baseline de full-context es pasar la conversación entera, unos 26K tokens. · fuente: corpus C.5.
• Más del 90% de ahorro de tokens (~1,8K vs 26K), también frente a full-context. · fuente: corpus C.5.

El matiz, en una frase: las tres cifras comparan contra full-context o contra ChatGPT, no contra otros sistemas de memoria. · fuente: corpus C.5, matiz. Que un sistema de memoria gaste menos que volcar la conversación entera es esperable —para eso existe—. El claim no dice que Mem0 supere a Zep ni a tu store artesanal. Dice que supera a no tener memoria.

Zep / Graphiti — el grafo de conocimiento bi-temporal

Zep (corpus C.6, arXiv:2501.13956, ene 2025) es otro vendor. Su motor, Graphiti, es un grafo de conocimiento bi-temporal: cada hecho lleva dos líneas de tiempo. · fuente: corpus C.6 (vendor).

Un grafo bi-temporal distingue cuándo ocurrió un evento de cuándo el sistema se enteró. Mantiene un timeline de eventos y otro transaccional, con cuatro timestamps por hecho. Responde "qué sabíamos el martes", no solo "qué pasó el martes". · fuente: corpus C.6. Límite de la utilidad: esa precisión temporal pesa en complejidad; no todo agente la necesita.

Su número estrella en DMR: 94,8% con gpt-4-turbo, frente al 93,4% de MemGPT. · fuente: corpus C.6.

Matiz obligatorio, y es jugoso: ese 94,8% se midió en DMR, el benchmark del equipo de MemGPT. Un vendor reporta una mejora marginal sobre su rival, en el benchmark del rival. La cifra es defendible por eso: juega en campo ajeno. Pero el margen, 1,4 puntos, es tan estrecho que la metodología pesa más que el resultado. · fuente: corpus C.6, matiz.

Graphiti es código abierto bajo Apache 2.0 y combina búsqueda semántica, BM25 y búsqueda en grafo. · fuente: corpus C.6.

El plato fuerte: la disputa LOCOMO

Aquí está el caso de estudio del nivel. Dos vendors, un benchmark de tercero (LOCOMO), y un desacuerdo público que sigue sin resolverse. Léelo despacio: enseña más sobre benchmarks que cualquier cifra individual.

La secuencia (corpus C.5):

1. Mem0 publica sus resultados de LOCOMO e incluye a Zep. Reporta Zep = 65,99%. · fuente: corpus C.5.
2. Zep responde en un post titulado "Lies, Damn Lies, Statistics". Zep alega errores de implementación. Los señalados: modelo de grafo mal aplicado, timestamps pasados como texto en vez de created_at, y búsquedas secuenciales que inflaban su latencia artificialmente. Con esos errores corregidos, Zep reivindica 75,14%. · fuente: corpus C.5.
3. Mem0 contra-alega (en el repo getzep/zep-papers): que Zep modificó el system prompt, incluyó una categoría adversarial y corrió una sola vez (single-run, sin promediar la varianza). · fuente: corpus C.5.

Dos cifras sobre la mesa para el mismo sistema en el mismo benchmark: 65,99% y 75,14%. Una diferencia de nueve puntos que depende enteramente de quién implementó a quién.

A junio de 2026 no hay réplica independiente. Ningún tercero neutral ha corrido ambos sistemas con la misma metodología. La disputa está abierta. · fuente: corpus C.5.

Y esa es la lección, no un fallo de la lección. Cuando dos partes interesadas reportan números incompatibles y nadie neutral arbitra, lo honesto es decir "no se sabe", no elegir el número que te conviene. Por eso una tercera cifra que circula —un supuesto "corregido"— no se usa en este curso: no es verificable. · fuente: corpus §8, lista ⛔.

El checklist de lectura de benchmark de vendor

Destila los matices anteriores en cinco preguntas. Aplícalas a cualquier número que un vendor te ponga delante:

1. ¿Quién corre el benchmark? (El vendor, un tercero, un rival.)
2. ¿Cuál es el baseline exacto? (Full-context, ChatGPT, otro sistema de memoria, nada.)
3. ¿La mejora es relativa o absoluta? ("26% relativo sobre X" no es "26 puntos".)
4. ¿El benchmark es propio o de un tercero? (Auto-construido sesga la elección de tareas.)
5. ¿Hay réplica independiente? (Sin ella, un claim disputado es una hipótesis, no un hecho.)

El contraejemplo: adoptar no te exime de diseñar

Es tentador pensar que un framework resuelve la memoria y cierras el capítulo. No lo hace. Adoptar Mem0 o Zep NO te exime de la rúbrica C2.

Mem0 y Zep deciden qué y cuándo escribir con SUS heurísticas. Pero las políticas de write y select de L3, la supervivencia de L4 y la auditoría de poisoning siguen siendo tu responsabilidad de diseño. El framework mueve el código; no mueve la responsabilidad. Un store de framework sin tu política de proveniencia se envenena igual que el tuyo.

5.5Míralo funcionar

Vamos a hacer dos cosas con la lupa puesta. Primero, leer la disputa LOCOMO con el checklist, en una tabla. Después, situar cada framework con su superficie mínima de API.

Antes de leer la tabla, una advertencia: la columna que importa es la tercera —"qué puede afirmarse hoy"—, y casi siempre dirá poco. Eso no es un fallo del análisis. Es el resultado honesto.

La disputa LOCOMO, fila a fila

Pasa cada fila por el checklist. Pregunta 1 (¿quién corre?): un vendor mide a su rival —máximo conflicto de interés en las dos primeras filas. Pregunta 5 (¿réplica?): no, en ninguna. El veredicto honesto sobre la cifra exacta: no se puede afirmar casi nada en absoluto. Sobre la metodología, en cambio, se aprende mucho —cómo un timestamp mal pasado o un single-run mueven el resultado nueve puntos.

La superficie mínima de cada framework

Para situarte, así de pequeña es la API que cada framework expone para la palanca write. Mem0 (corpus F.3):

1from mem0 import Memory
2
3m = Memory()
4
5# Escribir: pasas los mensajes; Mem0 decide qué extraer y guardar.
6m.add(messages, user_id="magallanes")
7
8# Recuperar: pasas una query; Mem0 decide qué memorias devolver.
9results = m.search("fuentes fiables sobre rutas", filters={"user_id": "magallanes"})

Zep, por su API de grafo (corpus F.4):

1from zep_cloud.client import Zep
2
3client = Zep(api_key="ZEP_API_KEY")
4
5# Escribir al grafo del usuario.
6client.graph.add(user_id="magallanes", type="text", data="...")
7
8# Buscar en el grafo; scope es obligatorio.
9results = client.graph.search(
10    user_id="magallanes",
11    query="fuentes fiables sobre rutas",
12    scope="edges",
13    limit=5,
14)

Mira m.add(messages, user_id=...). Una línea. Pero esa línea esconde toda tu política de write de L3: qué se extrae, qué se deduplica, qué se descarta. En tu store artesanal, esas decisiones eran código tuyo, visible y auditable. Aquí viven dentro del framework.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿qué decisión de TU política de L3 está tomando m.add por ti, sin que la veas?

5.6Hazlo tú

Andamiaje decreciente: primero aplicas el checklist a un claim concreto, luego decides para Magallanes, luego para tu propio agente.

Ejercicio 1 — el claim de latencia de Mem0, reescrito

Te dan el claim tal cual: "Mem0 logra 91% menos latencia p95" (1,44 s vs 17,12 s). · fuente: corpus C.5.

1. Identifica el baseline exacto con la pregunta 2 del checklist.
2. Reescribe el claim con el matiz pegado, en una frase, de forma que un revisor no pueda malinterpretarlo.

Ejercicio 2 — artesanal vs framework, para Magallanes

Con menos guía. Decide: ¿Magallanes sigue con su memoria artesanal de L2–L4, o adopta un framework? Argumenta con tres criterios:

1. Control de políticas. ¿Necesitas ver y auditar qué se escribe y se recupera (rúbrica C2 dims 2 y 5)?
2. Supervivencia demostrada. ¿Tu arquitectura ya pasó el kill-test de L4 con re-trabajo medido?
3. Coste de integración. ¿Qué cuesta cablear el framework, su backend y su mantenimiento, frente a lo que ya funciona?

Ejercicio 3 — la misma decisión, tu agente

Sin andamiaje. Toma el agente de tu propio trabajo. Aplica los tres criterios y escribe el veredicto en cinco líneas.

Elaborative interrogation — antes de decidir, pregúntate: ¿qué evidencia concreta te haría adoptar un framework pese a tener una memoria artesanal que funciona?

5.7Comprueba

Sin pistas. Gate de maestría: leer cinco claims del corpus y destapar el matiz que falta en cada uno.

Para cada claim, escribe (a) el matiz obligatorio que le falta y (b) la pregunta del checklist que lo destapa.

1. "MemGPT: DMR 35,3% → 93,4%."
2. "Mem0: ~26% de mejora relativa en LOCOMO."
3. "Zep: DMR 94,8%, supera a MemGPT."
4. "Mem0 reportó Zep = 65,99% en LOCOMO."
5. "Zep reivindica 75,14% en LOCOMO."

Cierre: ¿qué evidencia te haría cambiar tu veredicto de adopción para Magallanes?

5.8Conecta

Acabas de afilar una lupa, no de descartar herramientas. La rúbrica C2 no pide un framework: pide políticas justificadas, supervivencia demostrada y riesgo auditado —con Mem0 debajo, con Zep debajo, o sin nada debajo. El framework es una opción de implementación, no un sustituto del diseño.

Cierra el arco que abrimos en 5.1. Tenías un titular: "26%, 91%, 90%". Ahora lo lees entero, con sus tres baselines pegados. Sabes que ninguno dice que el framework supere a tu kill-test de L4. La oferta no se evalúa por el tamaño del número.

Doble eco de N0. Primero: los benchmarks públicos miden modelos o productos, no TU agente —igual que la curva del sweep de N0 medía Magallanes y no un leaderboard. Tu kill-test de L4 vale más para TU decisión que cualquier LOCOMO. Segundo: la lupa con la que leíste la ventana de contexto en N0·L1 es la misma de hoy. La distancia entre lo anunciado y lo efectivo no era exclusiva de las ventanas; vive en todo claim con un autor interesado.

L6 junta todo el nivel en el checkpoint C2: arquitectura con políticas, demo del reinicio sin re-trabajo, trade-off medido y poisoning auditado. La decisión framework-vs-artesanal de hoy es parte de esa defensa. Sabrás justificar por qué tu Magallanes lleva —o no— un framework debajo.

5.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida lo aprendido mejor que releer.

• ¿Qué aprendiste? Resume en una frase por qué un porcentaje de vendor sin baseline no es información accionable.
• ¿Qué sigue sin estar claro? ¿Distingues "benchmark auto-construido" de "benchmark de tercero", y por qué importa para leer DMR? Si no, vuelve a 5.4.
• ¿Qué harías distinto? La próxima vez que un vendor te anuncie un "X% de mejora", ¿qué dos preguntas del checklist harías antes de aceptarlo?

Esto requiere práctica. La intuición de "¿contra qué se midió esto?" llega leyendo claims con el checklist delante, no de una vez. En L6 defenderás tu decisión de memoria —framework o artesanal— ante la rúbrica completa de C2.