research

MemPalace obtiene un 96,6% en LongMemEval. Ejecutamos el mismo benchmark. La extracción estructurada obtuvo una puntuación más alta.

April 8, 2026
10 min read
n=500
Dmitrij Żatuchin
AI MemoryLongMemEvalKnowledge ManagementSECI ModelRetrievalChromaDBEmbeddingsLLM Infrastructure

La afirmación viral: el almacenamiento literal en bruto supera a todo lo demás para la memoria de la IA. Reprodujimos el benchmark y encontramos una respuesta distinta. El cuello de botella es la truncación del embedding, no la pérdida por extracción. Aquí están los datos.


Por qué ejecutamos este benchmark

MemPalace (github.com/milla-jovovich/mempalace) se lanzó el 5 de abril de 2026 y alcanzó 14.500 estrellas en GitHub en 48 horas. La tesis central: guarda cada conversación de forma literal en ChromaDB, omite por completo la extracción con LLM y obtienes un 96,6% de recall en el benchmark estándar de memoria de IA (LongMemEval).

La implicación para el campo: cada sistema que usa un LLM para extraer o resumir memorias está sobredimensionando el problema. El texto en bruto con buenos embeddings gana.

Construimos sistemas de gestión del conocimiento basados en el modelo SECI (Nonaka y Takeuchi, 1995), donde la extracción estructurada es una operación central. Si el almacenamiento en bruto realmente supera a la extracción, nuestra arquitectura está equivocada. Así que lo probamos.


Qué probamos

Benchmark: LongMemEval_S (Wu et al., ICLR 2025). 500 preguntas que evalúan cinco capacidades de memoria a largo plazo: extracción de información, razonamiento multisesión, actualizaciones de conocimiento, razonamiento temporal y abstención. Cada pregunta incluye alrededor de 48 sesiones de conversación tipo "pajar", de las cuales entre 1 y 3 contienen la respuesta.

Cuatro enfoques de recuperación, mismo modelo de embedding (all-MiniLM-L6-v2), mismos datos:

#EnfoqueDescripción
1Bruto todos los turnosGuarda el texto completo de la sesión (usuario + asistente), lo embebe tal cual
2Bruto solo usuarioMétodo de MemPalace: guarda solo los turnos del usuario, los embebe tal cual
3Extracción SECICondensa cada sesión en unos 500 caracteres de hechos estructurados
4SECI híbrido + palabra claveFusiona las puntuaciones bruta + extraída mediante reciprocal rank fusion, añade un impulso por coincidencia de palabras clave

Todos los enfoques usan ChromaDB con búsqueda por similitud del coseno. Ningún LLM interviene en la recuperación. La única diferencia es lo que se indexa.


Resultados

LongMemEval_S: recuperación a nivel de sesión (500 preguntas, los 6 tipos)

EnfoqueR@5R@10NDCG@5NDCG@10
Bruto todos los turnos85,9%92,8%80,3%83,0%
Bruto solo usuario (método MemPalace)92,1%96,3%86,8%88,5%
Extracción SECI93,7%96,7%89,1%90,3%
SECI híbrido + palabra clave93,9%96,6%89,7%90,8%

Resultados del benchmark de memoria de IA: extracción SECI frente a almacenamiento en bruto en LongMemEval_S

El híbrido SECI superó al almacenamiento en bruto estilo MemPalace por 1,8 puntos porcentuales en R@5.

Desglose por tipo de pregunta

EnfoqueActual. Conoc. (n=72)Multisesión (n=121)SS-Usuario (n=64)Temporal (n=127)
Bruto solo usuario (MemPalace)98,6%90,6%92,2%86,9%
Extracción SECI95,8%93,2%96,9%88,8%
SECI híbrido+pc96,5%93,7%96,9%88,4%

La extracción SECI encabeza 4 de los 6 tipos de pregunta. El método MemPalace gana en actualización de conocimiento (+2,1 pp), donde importa la redacción original de los hechos que cambian. La ventaja de SECI es más marcada en las preguntas de una sola sesión de usuario (+4,7 pp), donde la respuesta está enterrada en lo profundo de una conversación larga.


Por qué gana la extracción: el problema de la truncación a 256 tokens

El resultado nos sorprendió. La tesis de MemPalace es intuitiva: la extracción pierde información, el bruto lo conserva todo. En teoría, el bruto debería ganar.

El margen es más ajustado de lo que sugería nuestra muestra inicial de 100 preguntas (+4,9 pp se redujo a +1,8 pp a escala completa de 500 preguntas). Las preguntas de razonamiento temporal y de actualización de conocimiento acercaron la diferencia. Por eso precisamente se ejecuta el benchmark completo.

La realidad: el modelo de embedding no puede leer el documento completo.

all-MiniLM-L6-v2 (el modelo por defecto de ChromaDB, usado tanto por MemPalace como por nuestro benchmark) tiene una longitud máxima de secuencia de 256 tokens. Eso equivale a unos 1.000 caracteres.

Las sesiones de LongMemEval promedian 10.000 caracteres. Algunas superan los 30.000.

Cuando guardas una sesión en bruto y la embebes, el modelo lee los primeros ~1.000 caracteres e ignora el resto. El 90% del contenido es invisible para la recuperación.

Nuestra extracción SECI condensa la sesión entera en unos 500 caracteres de hechos clave estructurados. Cada hecho extraído cabe dentro de la ventana de 256 tokens. Nada se trunca.

La tesis del "el bruto siempre gana" solo se sostiene cuando tu modelo de embedding puede realmente leer el documento completo. Con 256 tokens, no puede.

Sesión en bruto (10.000 caracteres):
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
 ↑ embebido (1.000 caracteres)   ↑ truncado (9.000 caracteres) ← invisible para la búsqueda

Extracción SECI (500 caracteres):
[████████████████████]
 ↑ contenido entero embebido ← nada perdido

¿Cambiaría el resultado un modelo de embedding con contexto más largo?

Probablemente sí. Modelos como bge-large-en-v1.5 (512 tokens) o nomic-embed-text-v1.5 (8192 tokens) permitirían que el almacenamiento en bruto embebiese más de cada sesión. El 96,6% publicado por MemPalace puede usar optimizaciones más allá del modelo por defecto. Estamos probando embeddings de contexto más largo a continuación.

El punto se mantiene: la calidad de tu recuperación está limitada por tu ventana de embedding, y la mayoría de los desarrolladores no comprueban esto.


En qué acertó MemPalace

Hay que reconocer el mérito:

  1. Indexado solo de usuario. Eliminar los turnos del asistente mejoró la recuperación en bruto del 85,9% al 92,1%, un salto de 6,2 puntos. Las respuestas del asistente añaden ruido (genéricas, prolijas) que diluye el embedding. Una decisión de diseño inteligente.

  2. Rendimiento en actualización de conocimiento. El bruto solo usuario obtiene un 98,6% en preguntas de actualización de conocimiento frente a nuestro 96,5%. Cuando los hechos cambian con el tiempo, tener la redacción original ayuda. La extracción puede suavizar la señal de la actualización.

  3. Cultura de benchmarking. Publicar resultados reproducibles de LongMemEval con scripts, ser transparente sobre qué modo (bruto, AAAK o rooms) produce qué puntuación, y emitir correcciones honestas dentro de las 48 horas del lanzamiento. Así debería funcionar el código abierto.

  4. La idea central es parcialmente correcta. A escala y con el modelo de embedding adecuado, el almacenamiento en bruto es una línea base sólida. El campo ha estado sobredimensionando la extracción con costosas llamadas a LLM cuando enfoques más simples funcionan. El matiz: "más simple" debe tener en cuenta la ventana de embedding.


El modelo SECI para la memoria de la IA

Nuestro enfoque de extracción se basa en el modelo de gestión del conocimiento SECI (Nonaka y Takeuchi, 1995), adaptado para la memoria de agentes de IA:

FaseFlujo de conocimientoImplementación
SocializaciónTácito → TácitoLa sesión ocurre, el contexto se experimenta
ExternalizaciónTácito → Explícito/distill extrae hechos estructurados a markdown
CombinaciónExplícito → Explícito/consolidate fusiona, deduplica, detecta obsolescencia
InternalizaciónExplícito → Tácito/remember carga el contexto relevante en la siguiente sesión

El sistema guarda el conocimiento extraído como archivos markdown planos en 10 espacios de nombres (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Cada archivo es legible por humanos y está bajo control de versiones.

Para este benchmark, añadimos ChromaDB por debajo de los archivos markdown: doble indexado tanto del texto en bruto como de los resúmenes extraídos, con reciprocal rank fusion en el momento de la consulta.


Metodología

Conjunto de datos: LongMemEval_S (Wu et al., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory," ICLR 2025). 500 preguntas, ~48 sesiones de pajar por pregunta, longitud media de sesión de 10.042 caracteres.

Modelo de embedding: all-MiniLM-L6-v2 (384 dimensiones, longitud máxima de secuencia de 256 tokens). Por defecto en ChromaDB.

Recuperación: granularidad a nivel de sesión. Recuperación top-10. Métricas: Recall@5, Recall@10, NDCG@5, NDCG@10.

Método de extracción: condensación basada en reglas (sin LLM). Extrae el tema del primer mensaje del usuario, el seguimiento del último mensaje del usuario y la resolución del último mensaje del asistente. Unos 500 caracteres por sesión. Esto simula la estructura de salida de nuestro comando /distill.

Fusión híbrida: Reciprocal Rank Fusion (k=60) de las puntuaciones de recuperación bruta y extraída, más un impulso por coincidencia de palabras clave (hasta un 30% para coincidencias exactas de términos).

Muestra: 500 preguntas (470 evaluadas, 30 de abstención omitidas). Los 6 tipos de pregunta: single-session-user, single-session-assistant, single-session-preference, multi-session, temporal-reasoning, knowledge-update.

Código: seci_vs_mempalace.py

Salvedades

  • Recuperación top-10. MemPalace hace benchmarking con recuperación top-50 (n_results=50) y evalúa R@5 a partir de ese conjunto. Nuestro top-10 está más restringido. Una comparación justa con parámetros equiparados llegará próximamente.
  • Extracción basada en reglas. Nuestra extracción usa condensación por regex y heurísticas, no resumen con LLM. La extracción basada en LLM probablemente mejoraría la calidad, pero añadiría coste y latencia.
  • Un solo modelo de embedding. Los resultados son específicos de all-MiniLM-L6-v2 (256 tokens). Modelos de contexto más largo reducirían la diferencia entre los enfoques bruto y extraído.
  • La actualización de conocimiento es un punto débil. El método MemPalace obtiene un 98,6% frente a nuestro 96,5% en preguntas donde los hechos cambian con el tiempo. La extracción puede suavizar la señal de la actualización.

Qué significa esto para quienes construyen

Si estás construyendo un sistema de memoria de IA:

  1. Comprueba tu ventana de embedding. Si tu modelo de embedding trunca a 256 o 512 tokens y tus documentos son más largos, estás perdiendo información en la capa de embedding sin importar tu estrategia de almacenamiento.

  2. La extracción no siempre pierde información. Cuando la extracción condensa un documento largo en una representación que cabe en la ventana de embedding, conserva más información recuperable que un almacenamiento en bruto que acaba truncado.

  3. El indexado solo de usuario ayuda. Eliminar los turnos del asistente de la memoria conversacional reduce el ruido. Una mejora de 6,2 puntos gratis.

  4. La recuperación híbrida añade calidad de ordenación. Fusionar las puntuaciones bruta y extraída mediante RRF no mejora el recall respecto a la extracción por sí sola, pero mejora el NDCG (calidad de la ordenación). Los documentos correctos quedan mejor posicionados cuando combinas ambas señales.

  5. Haz benchmarking de tu sistema. LongMemEval es gratuito, está bien diseñado y es reproducible. Ejecutarlo lleva unas pocas horas. Los resultados pueden sorprenderte.


Reproducir estos resultados

# Instalar dependencias
pip install chromadb sentence-transformers

# Descargar los datos de LongMemEval
mkdir -p data && cd data
curl -L -o longmemeval_s_cleaned.json \
  https://huggingface.co/datasets/xiaowu0162/longmemeval-cleaned/resolve/main/longmemeval_s_cleaned.json
cd ..

# Ejecutar el benchmark
python seci_vs_mempalace.py --dataset s --mode retrieval

Código completo: github.com/rankfor/ai-memory-benchmark


Qué estamos probando a continuación

  1. Modelos de embedding de contexto más largo (bge-large, nomic-embed-text) para ver si el almacenamiento en bruto alcanza al resto cuando se elimina la truncación.
  2. Extracción basada en LLM (Gemini Flash para resumir sesiones) frente a nuestra extracción basada en reglas.
  3. Impulso temporal para recuperación consciente de fechas en la categoría de preguntas de razonamiento temporal.
  4. Recuperación top-50 para igualar la configuración exacta de MemPalace en una comparación justa.

El código es abierto. Damos la bienvenida a las reproducciones.


Dmitrij Żatuchin, Rankfor.AI. Abril de 2026.

Esta investigación es independiente. No tenemos afiliación con MemPalace, LongMemEval ni ChromaDB. El código y los resultados del benchmark están abiertos para su reproducción.

BeVisible Club

Get research like this before we publish it.

New AI visibility studies, ranking patterns, and source-stack data delivered to your inbox a week before they go public.

Join BeVisible Club

Want to Know How AI Sees Your Brand?

Rankfor.AI measures your brand's AI visibility across all major platforms and provides actionable recommendations.

About the Author

Dmitrij Żatuchin

Founder

Dmitrij Żatuchin is the founder of Rankfor.AI. A computer scientist with a PhD in semantic web technologies, he bridges the gap between how AI reasons about brands and how brands want to be understood. With over two decades of software architecture experience and academic roles at Estonian Business School, Dmitrij builds the measurement infrastructure brands need to transition from optimizing for search engines to becoming visible for reasoning engines.

© 2025-2026 Rankfor.AI™ Todos los derechos reservados.

Ask AI about Rankfor.AI

Rankfor.AI sp. z o.o., Skarbowcow 23B, 53-025 Wroclaw, Poland

KRS: 0001190083 | NIP: 8993033605

Usamos cookies

Utilizamos cookies esenciales para que nuestro sitio funcione. Con su consentimiento, también podemos usar cookies de análisis para comprender cómo utiliza nuestras herramientas (como el Dice Roller) y así poder mejorarlas. Más información