OpenRankfor.AI
research

MemPalace obtient 96,6 % sur LongMemEval. Nous avons lancé le même benchmark. L'extraction structurée a obtenu un meilleur score.

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

L'affirmation virale : le stockage brut, mot pour mot, surpasse tout le reste pour la mémoire de l'IA. Nous avons reproduit le benchmark et trouvé une autre réponse. Le goulot d'étranglement, c'est la troncature de l'embedding, pas la perte liée à l'extraction. Voici les données.


Pourquoi nous avons lancé ce benchmark

MemPalace (github.com/milla-jovovich/mempalace) a été lancé le 5 avril 2026 et a atteint 14 500 étoiles GitHub en 48 heures. La thèse centrale : stockez chaque conversation mot pour mot dans ChromaDB, sautez entièrement l'extraction par LLM, et vous obtenez 96,6 % de rappel sur le benchmark de référence pour la mémoire de l'IA (LongMemEval).

Ce que cela implique pour le domaine : tout système qui utilise un LLM pour extraire ou résumer des souvenirs sur-conçoit le problème. Le texte brut avec de bons embeddings l'emporte.

Nous construisons des systèmes de gestion des connaissances fondés sur le modèle SECI (Nonaka & Takeuchi, 1995), où l'extraction structurée est une opération centrale. Si le stockage brut surpasse réellement l'extraction, notre architecture est erronée. Nous l'avons donc testée.


Ce que nous avons testé

Benchmark : LongMemEval_S (Wu et al., ICLR 2025). 500 questions qui évaluent cinq capacités de mémoire à long terme : extraction d'informations, raisonnement multi-sessions, mises à jour de connaissances, raisonnement temporel et abstention. Chaque question comprend environ 48 sessions de conversation « meule de foin », dont 1 à 3 contiennent la réponse.

Quatre approches de récupération, même modèle d'embedding (all-MiniLM-L6-v2), mêmes données :

#ApprocheDescription
1Brut, tous les toursStocker le texte complet de la session (utilisateur + assistant), embedder tel quel
2Brut, utilisateur uniquementLa méthode de MemPalace : stocker uniquement les tours de l'utilisateur, embedder tel quel
3Extraction SECICondenser chaque session en environ 500 caractères de faits structurés
4SECI hybride + mots-clésFusionner les scores brut + extrait par fusion de rangs réciproques, ajouter un bonus de chevauchement de mots-clés

Toutes les approches utilisent ChromaDB avec une recherche par similarité cosinus. Aucun LLM n'intervient dans la récupération. La seule différence tient à ce qui est indexé.


Résultats

LongMemEval_S : récupération au niveau de la session (500 questions, les 6 types)

ApprocheR@5R@10NDCG@5NDCG@10
Brut, tous les tours85,9 %92,8 %80,3 %83,0 %
Brut, utilisateur uniquement (méthode MemPalace)92,1 %96,3 %86,8 %88,5 %
Extraction SECI93,7 %96,7 %89,1 %90,3 %
SECI hybride + mots-clés93,9 %96,6 %89,7 %90,8 %

Résultats du benchmark de mémoire IA : extraction SECI vs stockage brut sur LongMemEval_S

Le SECI hybride a battu le stockage brut de type MemPalace de 1,8 point de pourcentage sur le R@5.

Détail par type de question

ApprocheMaj. connaissances (n=72)Multi-sessions (n=121)SS-Utilisateur (n=64)Temporel (n=127)
Brut, utilisateur uniquement (MemPalace)98,6 %90,6 %92,2 %86,9 %
Extraction SECI95,8 %93,2 %96,9 %88,8 %
SECI hybride+mc96,5 %93,7 %96,9 %88,4 %

L'extraction SECI est en tête sur 4 des 6 types de questions. La méthode MemPalace l'emporte sur les mises à jour de connaissances (+2,1 pp), où la formulation d'origine des faits modifiés compte. L'avantage du SECI est le plus marqué sur les questions à session unique côté utilisateur (+4,7 pp), là où la réponse est enfouie au fond d'une longue conversation.


Pourquoi l'extraction l'emporte : le problème de la troncature à 256 tokens

Le résultat nous a surpris. La thèse de MemPalace est intuitive : l'extraction perd de l'information, le brut préserve tout. En théorie, le brut devrait l'emporter.

L'écart est plus serré que ne le laissait penser notre premier échantillon de 100 questions (+4,9 pp ramenés à +1,8 pp à pleine échelle sur 500 questions). Les questions de raisonnement temporel et de mise à jour de connaissances ont resserré l'écart. C'est précisément pour cela qu'on lance le benchmark complet.

La réalité : le modèle d'embedding ne peut pas lire le document en entier.

all-MiniLM-L6-v2 (le modèle par défaut de ChromaDB, utilisé à la fois par MemPalace et par notre benchmark) a une longueur de séquence maximale de 256 tokens. Cela représente environ 1 000 caractères.

Les sessions de LongMemEval font en moyenne 10 000 caractères. Certaines dépassent 30 000.

Quand vous stockez une session brute et que vous l'embeddez, le modèle lit les 1 000 premiers caractères environ et ignore le reste. 90 % du contenu est invisible pour la récupération.

Notre extraction SECI condense la session entière en environ 500 caractères de faits clés structurés. Chaque fait extrait tient dans la fenêtre de 256 tokens. Rien n'est tronqué.

La thèse « le brut l'emporte toujours » ne tient que lorsque votre modèle d'embedding peut réellement lire le document en entier. À 256 tokens, il ne le peut pas.

Session brute (10 000 caractères) :
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
 ↑ embeddé (1 000 caractères)   ↑ tronqué (9 000 caractères) ← invisible à la recherche

Extraction SECI (500 caractères) :
[████████████████████]
 ↑ contenu entier embeddé ← rien de perdu

Un modèle d'embedding à contexte plus long changerait-il le résultat ?

Probablement oui. Des modèles comme bge-large-en-v1.5 (512 tokens) ou nomic-embed-text-v1.5 (8192 tokens) permettraient au stockage brut d'embedder une plus grande partie de chaque session. Les 96,6 % publiés par MemPalace utilisent peut-être des optimisations au-delà du modèle par défaut. Nous testons ensuite des embeddings à contexte plus long.

Le constat tient : la qualité de votre récupération est bornée par votre fenêtre d'embedding, et la plupart des développeurs ne le vérifient pas.


Ce que MemPalace a réussi

Rendons à César ce qui lui appartient :

  1. L'indexation côté utilisateur uniquement. Retirer les tours de l'assistant a fait passer la récupération brute de 85,9 % à 92,1 %, un bond de 6,2 points. Les réponses de l'assistant ajoutent du bruit (génériques, verbeuses) qui dilue l'embedding. Un choix de conception intelligent.

  2. La performance sur les mises à jour de connaissances. Le brut côté utilisateur obtient 98,6 % sur les questions de mise à jour de connaissances, contre 96,5 % pour nous. Quand les faits évoluent dans le temps, disposer de la formulation d'origine aide. L'extraction peut atténuer le signal de mise à jour.

  3. Une culture du benchmark. Publier des résultats LongMemEval reproductibles avec les scripts, être transparent sur le mode (brut vs AAAK vs rooms) qui produit tel ou tel score, et émettre des corrections honnêtes dans les 48 heures suivant le lancement. C'est ainsi que l'open source doit fonctionner.

  4. L'idée centrale est en partie juste. À grande échelle et avec le bon modèle d'embedding, le stockage brut est une référence solide. Le domaine sur-conçoit l'extraction avec des appels LLM coûteux là où des approches plus simples suffisent. La nuance : « plus simple » doit tenir compte de la fenêtre d'embedding.


Le modèle SECI pour la mémoire de l'IA

Notre approche d'extraction s'appuie sur le modèle de gestion des connaissances SECI (Nonaka & Takeuchi, 1995), adapté à la mémoire des agents IA :

PhaseFlux de connaissancesMise en œuvre
SocialisationTacite → TaciteLa session se déroule, le contexte est vécu
ExternalisationTacite → Explicite/distill extrait les faits structurés en markdown
CombinaisonExplicite → Explicite/consolidate fusionne, déduplique, détecte l'obsolescence
InternalisationExplicite → Tacite/remember charge le contexte pertinent dans la session suivante

Le système stocke les connaissances extraites sous forme de fichiers markdown plats répartis en 10 espaces de noms (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Chaque fichier est lisible par un humain et versionné.

Pour ce benchmark, nous avons ajouté ChromaDB sous les fichiers markdown : une double indexation du texte brut et des résumés extraits, avec une fusion de rangs réciproques au moment de la requête.


Méthodologie

Jeu de données : LongMemEval_S (Wu et al., « LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory », ICLR 2025). 500 questions, environ 48 sessions « meule de foin » par question, longueur moyenne de session de 10 042 caractères.

Modèle d'embedding : all-MiniLM-L6-v2 (384 dimensions, longueur de séquence maximale de 256 tokens). Modèle par défaut de ChromaDB.

Récupération : granularité au niveau de la session. Récupération du top 10. Métriques : Recall@5, Recall@10, NDCG@5, NDCG@10.

Méthode d'extraction : condensation à base de règles (sans LLM). Extrait le sujet à partir du premier message de l'utilisateur, la relance à partir du dernier message de l'utilisateur, la résolution à partir du dernier message de l'assistant. Environ 500 caractères par session. Cela reproduit la structure de sortie de notre commande /distill.

Fusion hybride : fusion de rangs réciproques (k=60) des scores de récupération brut et extrait, plus un bonus de chevauchement de mots-clés (jusqu'à 30 % pour les correspondances exactes de termes).

Échantillon : 500 questions (470 évaluées, 30 abstentions écartées). Les 6 types de questions : single-session-user, single-session-assistant, single-session-preference, multi-session, temporal-reasoning, knowledge-update.

Code : seci_vs_mempalace.py

Réserves

  • Récupération du top 10. MemPalace fait ses benchmarks avec une récupération du top 50 (n_results=50) et évalue le R@5 à partir de ce vivier. Notre top 10 est plus contraint. Une comparaison équitable avec des paramètres alignés est à venir.
  • Extraction à base de règles. Notre extraction utilise une condensation par regex/heuristiques, pas un résumé par LLM. Une extraction par LLM améliorerait probablement la qualité, au prix d'un surcoût et d'une latence supplémentaires.
  • Un seul modèle d'embedding. Les résultats sont spécifiques à all-MiniLM-L6-v2 (256 tokens). Des modèles à contexte plus long réduiraient l'écart entre les approches brute et extraite.
  • La mise à jour de connaissances est un point faible. La méthode MemPalace obtient 98,6 % contre 96,5 % pour nous sur les questions où les faits évoluent dans le temps. L'extraction peut atténuer le signal de mise à jour.

Ce que cela signifie pour ceux qui construisent

Si vous construisez un système de mémoire pour l'IA :

  1. Vérifiez votre fenêtre d'embedding. Si votre modèle d'embedding tronque à 256 ou 512 tokens et que vos documents sont plus longs, vous perdez de l'information à la couche d'embedding, quelle que soit votre stratégie de stockage.

  2. L'extraction n'entraîne pas toujours une perte. Quand l'extraction condense un long document en une représentation qui tient dans la fenêtre d'embedding, elle préserve davantage d'information récupérable que le stockage brut qui se retrouve tronqué.

  3. L'indexation côté utilisateur uniquement aide. Retirer les tours de l'assistant de la mémoire de conversation réduit le bruit. Une amélioration de 6,2 points, gratuitement.

  4. La récupération hybride améliore la qualité du classement. Fusionner les scores brut et extrait par RRF n'améliore pas le rappel par rapport à l'extraction seule, mais améliore le NDCG (qualité du classement). Les bons documents remontent quand vous combinez les deux signaux.

  5. Faites le benchmark de votre système. LongMemEval est gratuit, bien conçu et reproductible. Le lancer prend quelques heures. Les résultats pourraient vous surprendre.


Reproduire ces résultats

# Installer les dépendances
pip install chromadb sentence-transformers

# Télécharger les données 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 ..

# Lancer le benchmark
python seci_vs_mempalace.py --dataset s --mode retrieval

Code complet : github.com/rankfor/ai-memory-benchmark


Ce que nous testons ensuite

  1. Des modèles d'embedding à contexte plus long (bge-large, nomic-embed-text) pour voir si le stockage brut rattrape son retard une fois la troncature levée.
  2. Une extraction par LLM (Gemini Flash pour le résumé de session) face à notre extraction à base de règles.
  3. Un renforcement temporel pour une récupération sensible aux dates sur la catégorie des questions de raisonnement temporel.
  4. Une récupération du top 50 pour reproduire exactement la configuration de MemPalace et permettre une comparaison équitable.

Le code est ouvert. Les reproductions sont les bienvenues.


Dmitrij Żatuchin, Rankfor.AI. Avril 2026.

Cette recherche est indépendante. Nous n'avons aucun lien avec MemPalace, LongMemEval ou ChromaDB. Le code du benchmark et les résultats sont ouverts à la reproduction.

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.

Nous utilisons des cookies

Nous utilisons des cookies essentiels pour faire fonctionner notre site. Avec votre consentement, nous pouvons également utiliser des cookies analytiques pour comprendre comment vous utilisez nos outils (comme le Dice Roller) afin de les améliorer. En savoir plus