Skip to main content
Chaque chiffre de cette page provient d’un vrai run payant contre le harnais exact dans eval/ — jamais un proxy, jamais trié sur le volet. Reproductible par vous-même : voir eval/README.md.

​
Où on en est aujourd’hui

70,0 % de précision de réponse — la moyenne de trois échantillons stratifiés indépendants de 300 questions LoCoMo (seeds 42, 1, 2 ; fourchette 66,0-72,0 %), mesurée le 22/08/2026 sous le même protocole figé mem0_calibration que l’entrée ci-dessous, cette fois au budget de contexte réel du produit (2000 tokens) plutôt qu’au budget artificiellement plus strict de 900 tokens utilisé pour la mesure précédente (voir la note sous le tableau de trajectoire). Pour la première fois, cette moyenne est au niveau ou au-dessus du chiffre que le papier d’origine de Mem0 rapporte sur ce même dataset (arXiv:2504.19413, 66,9 %). On rapporte une fourchette plutôt qu’un seul run flatteur parce que c’est ce que trois seeds indépendantes ont réellement montré — sur la plus faible des trois (66,0 %), on est à peu près à parité avec ce chiffre, pas clairement devant. Transparence totale, parce que l’alternative c’est que quelqu’un d’autre le signale avant nous : Mem0 a depuis publié un nouvel algorithme « token-efficient » (juillet 2026) qui rapporte 92,5 % sur LoCoMo et 94,4 % sur LongMemEval — mem0.ai/blog. On n’a pas reproduit ces chiffres sous notre propre harnais, et selon la description de cet article eux-mêmes, ils viennent d’un montage single-pass différent et reflètent la plateforme managée de Mem0, pas son SDK open-source — donc on ne prend position ni pour ni contre. Ce qu’on peut affirmer et défendre, c’est la parité avec le seul protocole Mem0 qu’on a réellement reproduit de bout en bout, baseline full-context publiée incluse, ci-dessous. Ce qu’on a, c’est une trajectoire réellement mesurée sur un protocole figé, et un harnais assez honnête pour montrer ses propres points faibles.

​
La trajectoire

La ligne du 22/08/2026 n’est pas directement comparable à celle du dessus sur le budget : le budget de contexte est passé de 900 tokens (un plancher artificiel gardé uniquement pour rester comparable au protocole Mem0/Zep d’origine) à 2000 tokens (ce que le produit livre réellement depuis v0.2.0). Les chiffres ont bougé pour deux raisons à la fois — neuf correctifs de retrieval et un budget plus large — et ce tableau ne cherche pas à les séparer. On est aussi passés d’un run rapporté à trois (seeds 42, 1, 2) : un seul échantillon de 300 questions variait jusqu’à 6 points d’écart entre seeds sur ce protocole, ce qu’un run unique aurait caché. Une différence de plus : la ligne du 17/08/2026 tournait avec le reranker cross-encoder actif ; celle du 22/08/2026 non (désactivé par défaut — voir « Ce qui est encore cassé » plus bas, sa contribution mesurée n’a pas survécu à un re-test plus rigoureux).
Pour référence, la baseline full-context de ce même protocole — tout l’historique de conversation, aucun système de mémoire, aucune compression, le plafond contre lequel toute cette approche est mesurée — obtient 73,7 % ici, à moins d’un point de la baseline full-context publiée par Mem0 elle-même (72,90 +/- 0,19 %). Cette proximité confirme que le harnais reproduit bien le protocole publié plutôt que de mesurer autre chose sous le même nom. Haki atteint ce plafond à 3,7 points près en utilisant nettement moins de contexte : ~27 300 tokens pour la transcription brute, un vrai comptage de ce que l’appel baseline a facturé.
On publie volontairement PAS de ratio de tokens précis pour le côté Haki de cette comparaison pour l’instant. Le harnais enregistre actuellement la taille du contexte Haki à partir de sa propre estimation budgétaire interne, pas d’un comptage indépendant du prompt littéralement envoyé au modèle — alors que le chiffre baseline ci-dessus vient directement de l’usage facturé par l’API. Ce ne sont pas le même type de mesure, et c’est nous qui avons repéré cet écart en relisant cette page, pas en le mesurant. Un vrai chiffre au tokenizer pour le côté Haki est la prochaine chose qu’on doit à cette page, pas un titre qu’on est à l’aise de publier sur une estimation.
Les deux premiers runs utilisent des tailles d’échantillon différentes (1540 complet vs. un échantillon stratifié de 180 questions respectant les vraies proportions de catégories LoCoMo). Les trois sont de vraies mesures payantes sur des protocoles figés, pas un proxy — mais un échantillon plus petit porte une marge d’erreur plus large que 1540. Considérez la direction et l’ampleur de la trajectoire comme solides ; considérez tout point d’arrivée isolé comme portant un vrai bruit d’échantillonnage jusqu’au prochain run complet.

​
Ce que ça coûte

0,238 enmoyenneautotalpourunrunstratifieˊde300questions(troisseeds:0,235en moyenne au total pour un run stratifié de 300 questions (trois seeds : 0,235, 0,240 ,0,238, 0,238 ) — 0,00067 parreque^te,0,0035par requête, 0,0035 par conversation ingérée. Détail complet, config du run incluse (checksum du dataset figé, prompts, prix des modèles) qui rend ce chiffre reproductible : eval/results/ (gitignored dans le dépôt — généré localement quand vous lancez le harnais).

​
Ce qui est encore cassé

Déclaré comme issues suivies et étiquetées — pas caché, pas corrigé silencieusement entre deux versions :

L'accuracy temporal reste en retrait

49,5 % vs. 81,5 % sur le protocole actuel — le plus grand écart de la même ligne, toutes catégories confondues, et l’endroit le plus clair où regarder ensuite.

L'écart à Mem0 est comblé sur la moyenne, pas sur chaque seed

70,0 % de moyenne contre 66,9 % publié par Mem0 — mais notre seed la plus faible (66,0 %) tombe pile dessus, pas au-dessus.

Open-domain : échantillon encore modeste

n=19 par seed — mieux que le n=11 du run à 180 questions, toujours pas assez pour en tirer une conclusion isolée. (count et les catégories adversariales sont hors périmètre de mem0_calibration par construction, comme dans la méthodologie publiée par Mem0 elle-même.)

Reranker : re-mesuré, et le gain n'a pas survécu

Re-testé le 21/08 après la refonte du ranking : 85,1 % à 86,0 % de preuve-or servie sur 308 questions — McNemar p=0,68, indistinguable du bruit. Le chiffre antérieur, plus élevé, avait été mesuré par-dessus le ranking d’avant le 21 août et n’a pas tenu une fois ce ranking corrigé. Désactivé par défaut ; le coût de ~1,1 s p50 / ~1,4 s p95 CPU est connu et n’est pas la raison pour laquelle il est resté désactivé.

La variance entre seeds est réelle, pas du bruit à ignorer

66,0 % à 72,0 % sur trois seeds du même protocole à 300 questions, porté surtout par le multi-hop (49,1 % à 72,7 %). Lisez tout chiffre Haki-contre-Mem0, le nôtre y compris, comme une fourchette tant que le contraire n’est pas prouvé.
Liste complète, et commentez si vous êtes tombé sur quelque chose de non listé : issues known-limitation.

​
Méthodologie

  • Dataset : LoCoMo, figé par checksum SHA-256 — le même jeu de 1540 questions à chaque run, jamais une cible mouvante.
  • Protocole : mem0_calibration dans eval/configs/ — reproduit l’ordre exact question-puis-contexte de Mem0 et son prompt de jugement, pour que le chiffre obtenu soit comparable à ce que Mem0 et Zep publient dans leurs propres conditions, pas juste cohérent en interne. Le budget de contexte est le défaut réel du produit (2000 tokens) depuis la mesure du 22/08/2026.
  • Modèles : gpt-4o-mini pour le modèle de réponse comme pour le juge, température 0.
  • Ce qui est mesuré au-delà de l’accuracy : taux d’abstention, fuite de contradiction, tokens de contexte par paquet, latence p50/p95, coût par requête et par ingestion — des métriques que le secteur publie rarement à côté d’un chiffre vitrine.
  • Reproduisez-le vous-même : commandes exactes dans eval/README.md. Aucun compte requis — ça tourne contre votre propre instance auto-hébergée. L’historique de migrations de ce dépôt a des trous dans sa numérotation (des sauts comme 0026 à 0027) par rapport à notre dépôt interne : trois migrations pour les organisations/la facturation (Cloud uniquement, jamais partie de ce cœur OSS) sont omises. Aucune des trois ne touche une table que ce harnais lit ou écrit — les chemins de code retrieval et consolidation testés ici ne référencent ni la table organizations ni les tables de facturation — donc l’écart change des numéros de migration, pas la reproductibilité.
Rapport généré le 22/08/2026. Prochaine révision au prochain run complet.