agent-memory-bench: benchmark open source para detectar los fallos reales de la memoria en agentes de IA

Por GitHub (Kausha3/agent-memory-bench) · 27 de junio de 2026.

**El problema que quiere resolver**

Casi todos los agentes de IA modernos incorporan algún módulo de "memoria" para retener información entre turnos o sesiones. Sin embargo, la forma habitual de evaluar esa memoria es superficial: ¿recuperó el chunk relevante? Según el autor de este repositorio, ese criterio oculta los fallos que realmente degradan a los agentes en producción. Un agente no falla porque no encuentre un dato; falla porque recupera un dato obsoleto, confunde dos entidades similares, pierde un hecho enterrado bajo ruido, o devuelve información contradictoria con la que ya creía verdadera. Esos cuatro casos son los que `agent-memory-bench` pone bajo el microscopio.

**Las cuatro categorías de fallo**

El benchmark define con precisión cuatro modos de fallo:

- **Retracción**: un hecho se actualiza; el sistema debe devolver el valor nuevo y no filtrar el antiguo. - **Colisión**: existen dos entidades similares; el sistema debe responder sobre la preguntada sin confundirlas. - **Recuperación (recall)**: un hecho se enunció temprano en la conversación, se necesita tarde, y hay ruido intermedio. Incluye un caso frontera de razonamiento multi-hop que ninguna de las tres líneas base actuales resuelve. - **Conflicto**: un hecho es explícitamente contradicho dentro del propio texto; el sistema debe resolver cuál es el valor vigente.

Las definiciones completas, ejemplos trabajados y la justificación de por qué cada modo es difícil se documentan en `TAXONOMY.md`.

**Arquitectura técnica: offline, sin API key, reproducible**

Uno de los objetivos explícitos del proyecto es la reproducibilidad sin fricciones. El benchmark corre completamente offline, sin dependencias externas y sin necesidad de clave de API. Dos comandos bastan:

``` npm install npm run bench # imprime el leaderboard npm test # suite adversarial sobre el núcleo de scoring y las líneas base ```

Está escrito íntegramente en TypeScript (100% del repositorio). Los escenarios son scripts ordenados de eventos `remember` y `query`. Cada `query` declara la subcadena que debe contener la respuesta correcta **y** las subcadenas obsoletas que no deben aparecer, de modo que devolver un valor desfasado cuenta como fallo, no como acierto parcial.

El harness (`src/harness.ts`) reinicia el sistema, reproduce el escenario y juzga cada consulta de forma aislada. El scoring (`src/score.ts`, `src/report.ts`) agrega tasas por categoría y global y renderiza el leaderboard.

**El leaderboard actual (v0.1)**

El repositorio incluye tres líneas base de referencia sobre 13 escenarios en 4 categorías:

| Sistema | Retracción | Colisión | Recall | Conflicto | Global | |---|---|---|---|---|---| | typed-constraint | 100% | 100% | 75% | 100% | **92%** | | keyword | 0% | 100% | 75% | 0% | **46%** | | recency | 100% | 0% | 0% | 0% | **23%** |

El autor subraya que esto debe leerse como **un mapa de dónde falla cada estrategia**, no como un ranking de productos:

- **keyword** (recuperación por similitud, sin modelo de tiempo) acierta en colisión pero falla totalmente en retracción y conflicto: sin noción de tiempo, devuelve alegremente el valor que el usuario ya cambió. - **recency** (gana el token más reciente) arregla la retracción pero colapsa en colisión y recall: deriva hacia el lookalike más reciente, que suele ser la entidad incorrecta. - **typed-constraint** modela el tiempo (los hechos se retractan) y la identidad (los hechos se vinculan a una entidad), lo que le permite superar tres categorías. Falla en el único escenario multi-hop de recall, un ítem frontera deliberado que ninguna línea base resuelve, lo que garantiza que el benchmark no está saturado.

La conclusión clave: las métricas de calidad de recuperación convencionales puntuarían de forma similar a los tres sistemas, mientras que su corrección real varía del 23% al 92%. Esa brecha es precisamente el punto.

**Cómo añadir un sistema propio**

La interfaz que debe implementar un sistema externo es mínima (`src/types.ts`):

```typescript interface MemorySystem { readonly name: string; reset(): void | Promise<void>; remember(text: string): void | Promise<void>; query(question: string): string | Promise<string>; } ```

Los métodos pueden ser asíncronos, por lo que un embedding store, un producto de memoria alojado o un extractor respaldado por LLM se conecta exactamente igual que las líneas base en código puro. Basta con añadir la clase en `src/systems/` e incluirla en `src/run.ts`.

**Estado y hoja de ruta**

La versión actual es v0.1: 4 categorías, 13 escenarios, 3 líneas base de referencia. El roadmap prevé ampliar cada categoría con más escenarios y distractores más difíciles, añadir categorías de deriva temporal y de preferencias, incorporar un modo de juez LLM para respuestas de formato libre, y publicar una guía de contribución para que sistemas de memoria externos puedan presentarse al leaderboard. El autor señala que las contribuciones más valiosas son nuevos escenarios adversariales que rompan la línea base `typed-constraint`.

**Implicaciones para la IA agéntica**

Este benchmark toca un punto ciego significativo del ecosistema actual. En general, la investigación y los productos de memoria para agentes (desde RAG clásico hasta sistemas como MemGPT, Zep o las memorias propias de OpenAI/Anthropic) se evalúan casi exclusivamente con métricas de recuperación heredadas de la búsqueda de información: precisión, recall a nivel de chunk, MRR, NDCG. Estas métricas no capturan si el agente acabará confundiendo a dos usuarios, devolviendo un número de teléfono antiguo, o afirmando simultáneamente dos hechos contradictorios.

El enfoque de `agent-memory-bench` está más alineado con cómo fallan los agentes en escenarios reales de uso continuado: tareas de asistente personal, CRM conversacional, agentes de soporte, o cualquier aplicación donde el estado del mundo cambia a lo largo del tiempo y el agente debe mantener coherencia. La retracción y el conflicto son especialmente críticos en dominios donde los datos cambian con frecuencia (precios, disponibilidades, preferencias de usuario, estado de proyectos).

**Limitaciones del proyecto en su estado actual**

El repositorio tiene actualmente 0 estrellas, 0 forks y 0 comentarios en la discusión de Hacker News, lo que indica que es un proyecto muy reciente y de un único contribuidor. La suite de 13 escenarios es un punto de partida modesto, aunque deliberado: el autor es consciente de que el benchmark no está saturado precisamente porque incluye un caso frontera irresoluble para las líneas base actuales. La ausencia de escenarios con modelos de lenguaje reales (el modo LLM-judge está en el roadmap, no implementado) limita de momento su aplicabilidad directa a sistemas productivos que usan embeddings o LLMs para la gestión de memoria.

**Contexto del sector**

Como contexto del sector, la evaluación rigurosa de sistemas de memoria para agentes es un área emergente pero con creciente atención. Proyectos como MemoryBench (distintos autores, distinto alcance) o los benchmarks de razonamiento sobre diálogos largos (como LongMemEval) abordan facetas similares, aunque con enfoques diferentes. La propuesta de `agent-memory-bench` se diferencia por su énfasis en los modos de fallo específicos y su ejecución completamente local y reproducible, lo que facilita la integración en pipelines de CI para proyectos que construyen sus propios sistemas de memoria.

**Perspectiva regulatoria**

Desde el punto de vista del EU AI Act, los fallos de memoria que describe este benchmark —especialmente la retracción y el conflicto— tienen implicaciones directas en sistemas de alto riesgo donde la exactitud factual es crítica. Un agente que devuelve información médica, legal o financiera obsoleta porque su memoria no gestiona correctamente las retracciones podría incurrir en responsabilidades bajo los requisitos de exactitud y robustez del Reglamento. Disponer de benchmarks específicos para estos modos de fallo facilita la documentación técnica que exige el Act para los sistemas de IA de alto riesgo.