Note de labo · Août 2026
Notre benchmark nous a menti. Un script de 40 lignes l'a prouvé.
Pourquoi nous vérifions le prompt plutôt que les compteurs. Les résultats auront leur propre article, une fois les chiffres figés.
En un jour et une nuit, nous avons construit un projet voulu depuis des mois. Octave Engine est la couche de compression mémoire multi-résolution de Mnemosyne OS. La même mémoire existe en plusieurs tailles. Le moteur choisit la taille quand il injecte la mémoire dans le contexte du modèle.
Sa règle tient en quatre mots : Projection, jamais paraphrase. Chaque forme compressée est faite d'extraits littéraux de la source, avec leurs offsets de caractères exacts. Une recherche de sous-chaîne prouve donc que rien n'a été inventé. Un résumeur peut arrondir une date ou améliorer une phrase. Pour un produit de mémoire auditable, ce serait un menteur plein de bonnes intentions.
Plus de deux mille tests unitaires sont restés verts du début à la fin. Puis nous avons mis le moteur au banc. Un harnais A/B opposait un bras contrôle à un bras projection, sur un corpus de questions-réponses à mémoire longue. Un juge LLM notait les réponses, et tout était journalisé. Les deltas ont dessiné une forme. Nous avons écrit dans le document de conception quand activer le moteur. Nous pensions avoir mesuré.
Puis le fondateur a posé une question, presque en passant :
« Vérifie le code. Pas seulement les tests derrière les tests. »
La relecture adverse du code
Nous avons confié tout le diff à des relecteurs adverses. Leur consigne : ne vérifiez pas que ça marche ; essayez de prouver que ça ne marche pas. Le même esprit avait écrit le code et les tests. Les tests avaient donc les mêmes angles morts. Seuls des yeux neufs et hostiles les trouvent.
Une de leurs trouvailles a tout arrêté.
Notre harnais donnait au pipeline des lignes mémoire « gelées », déjà récupérées. Dans le bras projection, nous réécrivions ces lignes en mémoire avec le texte compressé. Mais le constructeur de prompt ne lit pas les lignes en mémoire. Il relit chaque ligne par son hash, dans la base de données. C'est un cache raisonnable. Il jetait donc en silence notre copie modifiée et relisait l'original.
Les deux bras envoyaient depuis le début des prompts identiques au byte près.
Tous nos deltas venaient de la variance du juge et du modèle. Notre règle si soignée reposait sur ce bruit. Le bruit avait pris l'apparence de notre hypothèse.
Pourquoi nous ne l'avons jamais vu
Si vous évaluez des LLM, cette partie vous semblera familière.
Les journaux du harnais étaient pleins d'activité réelle : entrées projetées, caractères économisés, compteurs de repli. Rien n'était fabriqué. La projection compressait vraiment. Mais rien n'arrivait au prompt. L'instrument mesurait son propre effort, et non son effet.
Un journal plein d'activité ne prouve pas que le travail arrive jusqu'au juge. La plausibilité nous a aussi trompés. Quand le bruit dessinait un motif, nous savions l'expliquer, avec l'appui de la littérature. Une explication plausible ne prouve rien.
La température zéro ne protège pas non plus. Le modèle de réponse et le modèle juge sont presque déterministes, et les deux « presque » s'additionnent. Sur de petits échantillons, ils produisent des écarts qui ressemblent à des découvertes.
La preuve de 40 lignes
Le correctif du harnais était petit. Le correctif de notre méthode compte davantage, et vous pouvez le reprendre.
Avant chaque run d'évaluation payant, un script de contrôle prend une ligne mémoire. Il remplace son contenu par un marqueur. Il la fait passer par le chemin exact qui assemble le prompt du benchmark. Puis il vérifie les deux directions :
- Avec le correctif, le marqueur doit apparaître dans le prompt final. Le bras atteint donc bien l'artefact.
- Par l'ancien chemin, le marqueur ne doit pas apparaître. Le bug était donc bien celui que nous pensions.
Le script fait une quarantaine de lignes. Il tourne avant le premier token de juge. S'il échoue, la campagne ne démarre pas.
Notre règle : une expérience A/B n'existe qu'une fois prouvé que les bras diffèrent dans l'artefact final. La config, les logs et les compteurs ne suffisent pas. Seul compte ce que le modèle voit.
Ce que nous avons fait des campagnes invalidées
Les campagnes invalidées restent dans le document de conception. Elles sont barrées, tables intactes, à côté des versions corrigées. Les résultats négatifs restent aussi, chacun avec la cause de son échec. Un journal de recherche qui ne garde que les réussites devient une brochure.
Nous avons ensuite tout re-mesuré avec l'instrument prouvé. Ces chiffres sont réels. Ils paraîtront à part, figés, avec la taille des échantillons et leurs réserves.
Un moteur conçu à trois voix
Octave est né d'une conversation à trois voix. Un humain avait l'intuition de départ et le dernier mot. Un ingénieur IA travaillait dans le code. L'assistante intégrée à Mnemosyne OS relisait les designs avec sa mémoire du projet.
Un résumé de la séance est entré dans la mémoire de l'OS. Quelques minutes plus tard, l'assistante s'en servait pour proposer les expériences suivantes. Les chiffres invalidés ont aussi invalidé une partie de cette mémoire. La correction est une nouvelle chronique, qui remplace l'ancienne sans l'effacer.
Cette mémoire s'audite et se corrige au grand jour. Nous construisons le produit comme nous travaillons. Cette semaine, notre façon de travailler a été testée en premier.
Mnemosyne OS est une application de bureau pour Windows, macOS et Linux. Télécharger Mnemosyne OS