Le problème de la métrique
Un score symétrique récompense la mémoire qui répond à tout — y compris aux questions que son store ne peut pas soutenir. VeriBench note la mémoire comme un déploiement la paie : NET(λ) = (correctes − λ·fausses) / n, où λ est le coût déclaré d'une réponse fausse par rapport à un silence. Le juridique et le médical tournent à λ élevé ; le brainstorming à λ bas. Un seul nombre, balayé sur λ ∈ {1, 2, 5, 10} — fixé avant toute exécution.
✓ Pas de juge LLM, pas de réseau, pas de théâtre de classement — une commande, les JSON bruts commités dans le repo.
Les benchmarks de mémoire mesurent combien revient. Aucun ne met un prix sur ce qui revient faux.
Sur la moitié répondable d'un corpus, une mémoire à gate et un vector store brut récupèrent quasi à l'identique — recall@k ne voit aucune différence. La différence apparaît sur les questions auxquelles le store ne peut pas répondre : une mémoire sans plancher d'abstention renvoie quand même son plus proche voisin, en toute confiance. En production c'est une réponse fabriquée ; dans un benchmark symétrique c'est invisible.
NET(λ) la rend visible par construction : une réponse correcte rapporte +1, une fausse coûte λ, le silence ne coûte rien. L'exactitude d'équilibre est λ/(1+λ) — le même seuil auquel le bouton SLA de Verimem règle le store. Le benchmark mesure le store exactement au nombre avec lequel l'opérateur le règle.
Hypothèse, métrique, balayage de λ et conditions de réfutation sont commités dans PREREGISTRATION.md avant toute exécution. Le scoring et le mapping des issues ont été écrits et testés d'abord — un résultat favorable ne peut pas être fabriqué en choisissant la métrique après coup.
Des jeux de données réels que nous n'avons pas écrits : HaluEval QA et SQuAD v2 (partitions répondables + sans-réponse, disjointes). La correction est un retrieval id-décidable — aucun juge LLM dans toute la boucle.
Un store mélangé doit plonger en négatif (il plonge : NET(1) = −0.94) et le même retrieval plancher coupé doit fabriquer sur les sans-réponse (il le fait : 100 réponses fausses). Si un contrôle passe, le benchmark est cassé — c'est tout l'intérêt de l'avoir.
Les head-to-head utilisent l'embedder identique (multilingual-e5-base) sur les deux moteurs, hors-ligne, mem0 en mode raw-store (son LLM n'est jamais appelé — cet axe est hors périmètre par déclaration, pas par omission).
| Système | ✓ | ✗ | ∅ | coverage | NET(1) | NET(2) | NET(5) | NET(10) | négatif à partir de λ |
|---|---|---|---|---|---|---|---|---|---|
| Verimem · plancher τ=0.8 (défaut produit) | 182 | 4 | 114 | 0.62 | +0.593 | +0.580 | +0.540 | +0.473 | 45.5 |
| mem0 2.0.11 · tel que livré (sans plancher) | 200 | 100 | 0 | 1.00 | +0.333 | 0.000 | −1.000 | −2.667 | 2.0 |
| mem0 + plancher boulonné 0.75 (réglé sur l'éval) | 166 | 0 | 134 | 0.55 | +0.553 | +0.553 | +0.553 | +0.553 | jamais |
| Même store, plancher OFF (contrôle τ=0) | 192 | 100 | 8 | 0.97 | +0.307 | −0.027 | −1.027 | −2.693 | 1.9 |
| Contrôle mélangé (sanité : doit échouer) | 5 | 287 | 8 | 0.97 | −0.940 | −1.897 | −4.767 | −9.550 | 0.02 |
Lisez-la honnêtement, dans les deux sens : tel que livré, mem0 passe en négatif au-delà de λ=2 — 100 réponses fabriquées sur la moitié sans-réponse ; le défaut produit de Verimem reste positif jusqu'à λ≈45. Mais un plancher peut se boulonner sur n'importe quel moteur : avec un seuil réglé sur cette éval, mem0 atteint un +0.553 plat — qui bat notre défaut à λ≥5 sur ce corpus. Les différences qui restent : le moteur ne livre aucun plancher, le seuil boulonné a été choisi sur le test set, et la ligne plate signifie qu'il ne répond à rien dont il n'est pas sûr — coverage 0.55 contre notre 0.62, avec 182 contre 166 correctes à λ=1.
| Système | ✓ | ✗ | ∅ | coverage | NET(1) | NET(2) | NET(5) | NET(10) | négatif à partir de λ |
|---|---|---|---|---|---|---|---|---|---|
| Verimem · plancher τ=0.8 (défaut produit) | 163 | 49 | 88 | 0.71 | +0.380 | +0.217 | −0.273 | −1.090 | 3.3 |
| Verimem · meilleur plancher 0.85 (réglé sur l'éval) | 98 | 7 | 195 | 0.35 | +0.303 | +0.280 | +0.210 | +0.093 | 14.0 |
| mem0 2.0.11 · tel que livré (sans plancher) | 200 | 100 | 0 | 1.00 | +0.333 | 0.000 | −1.000 | −2.667 | 2.0 |
| mem0 + plancher boulonné 0.80 (réglé sur l'éval) | 44 | 0 | 256 | 0.15 | +0.147 | +0.147 | +0.147 | +0.147 | jamais |
Les passages distracteurs de SQuAD compressent la bande de scores, et ça se voit : au défaut produit le crossover tombe à λ≈3.3, et tenir NET positif à λ=10 coûte une coverage de 0.35. L'abstention est un bouton, pas de la magie — c'est le corpus qui décide combien coûte l'honnêteté. La mauvaise décision serait de cacher ce tableau.
Les tableaux ci-dessus : données externes, répondables + sans-réponse, plancher on vs off vs concurrent, contrôle mélangé. L'axe où la fabrication devient un événement facturé.
Un store qui a fidèlement corroboré une corrélation fallacieuse répond aux questions do(X) avec une assurance erronée — et finit en négatif même à λ=1. La provenance n'est pas la causalité ; un benchmark qui ne les distingue pas récompensera la confusion.
Collusion (N identités, un seul flux) plus un sleeper de confiance. Seule une politique de confiance à deux canaux — corroboration indépendante et retour d'issue — reste en positif ; chaque canal seul cède à exactement l'une des deux attaques. L'axe derrière le source-trust à deux canaux de Verimem.
tous les axes, déterministe, zéro clé API
git clone https://github.com/aureliocpr-ctrl/verimem && cd verimem
pip install -e .
python -m benchmark.veribench.run_all # every axis, one reproducible entrypointLa spec, la pré-registration et chaque JSON brut de résultat vivent dans le repo sous benchmark/veribench/ et benchmark/results/. Les concurrents sont invités — l'adapter mem0 est in-tree comme exemple fonctionnel ; proposez en PR l'adapter officiel de votre moteur et nous l'exécutons sur le même terrain.