Note de labo · Août 2026
Notre benchmark nous a menti. Voici la preuve de 40 lignes qui l'a démasqué.
Les instruments, le bruit, et pourquoi nous vérifions désormais le prompt et pas les compteurs. Résultats retenus ; ils auront leur propre article une fois les chiffres figés.
Nous avons passé un jour et une nuit à construire quelque chose que nous voulions depuis des mois : Octave Engine, la couche de compression mémoire multi-résolution de Mnemosyne OS. L'idée tient en une phrase : la même mémoire, disponible en plusieurs tailles, choisie au moment où elle est injectée dans le contexte d'un modèle. Sa règle fondatrice tient en quatre mots. Projection, jamais paraphrase. Chaque forme compressée servie par Octave est faite d'extraits littéraux de la source, chacun portant ses offsets de caractères exacts. On peut prouver, mécaniquement, par substring, que rien n'a été inventé. Pour un produit qui vend de la mémoire auditable, un résumeur qui pourrait arrondir une date ou améliorer une phrase n'est pas un moteur de compression. C'est un menteur plein de bonnes intentions.
Alors nous l'avons construit et testé (plus de deux mille tests unitaires sont restés verts du début à la fin), puis nous avons fait ce qu'il faut faire : nous l'avons mis au banc. Un harnais A/B sur un corpus de questions-réponses à mémoire longue, bras contrôle contre bras projection, un juge LLM pour noter les réponses, tout journalisé. Les runs sont revenus. Les deltas sont revenus. Une forme a commencé à s'y dessiner. Nous avons écrit une règle sur le moment où le moteur devait s'activer directement dans le document de conception, avec l'assurance de gens qui avaient mesuré.
Puis le fondateur a posé une question, presque en passant :
« Vérifie le code. Pas seulement les tests derrière les tests. »
La revue qui a mérité son pain
Nous avons confié l'intégralité du diff à des relecteurs adversariaux avec un seul mandat : ne vérifiez pas que ça marche ; essayez de prouver que ça ne marche pas. Les tests avaient été écrits par le même esprit que le code, donc ils en partagent les angles morts. Des yeux neufs et hostiles sont le seul remède connu.
L'une des trouvailles a mis fin à la fête.
Notre harnais alimentait le pipeline en lignes mémoire « gelées » : pré-récupérées, et dans le bras projection, réécrites en mémoire pour porter le corps compressé. Ce qui nous avait échappé : au fond du pipeline, le constructeur de prompt ne fait pas confiance aux lignes en mémoire. Il résout le contenu de chaque ligne par son hash, directement depuis la base, un pattern de cache parfaitement raisonnable. Ce faisant, il jetait silencieusement notre copie modifiée pour relire l'original.
Les deux bras émettaient des prompts identiques au byte près depuis le début.
Chaque delta que nous avions vu (ceux qui nous inquiétaient, ceux qui nous enthousiasmaient, la règle si soigneusement dérivée) n'était que la variance du juge et du modèle, déguisée en notre hypothèse.
Pourquoi nous ne l'avons jamais vu
C'est la partie qui devrait inquiéter quiconque mène des évaluations de LLM, parce qu'elle va vous sembler familière.
Les journaux du harnais étaient pleins d'activité réelle. Des entrées projetées. Des caractères économisés. Des compteurs de repli qui s'incrémentaient pour exactement les bonnes raisons. Rien de tout cela n'était fabriqué. La projection tournait vraiment, compressait vraiment, produisait vraiment tous ces chiffres. Simplement, rien n'atteignait jamais le prompt. L'instrument mesurait fidèlement son propre effort au lieu de son effet.
C'est ça, le mode de défaillance. Un journal qui ressemble à un bras au travail ne prouve pas que le travail est arrivé dans l'artefact que vous notez. Et il y avait un second complice : la plausibilité. Quand le bruit dessinait par hasard un motif, nous savions l'expliquer. L'explication était mécaniquement raisonnable. Elle collait aux intuitions de la littérature. Elle était satisfaisante. La plausibilité n'est pas une preuve. C'est l'apparence que prend le bruit quand on veut qu'il signifie quelque chose.
La température zéro ne vous sauve pas non plus. Un modèle de réponse plus un modèle juge, c'est un empilement de composants presque déterministes, et le « presque » se compose. Sur des échantillons modestes, cet empilement vous tendra des écarts assez grands pour ressembler à des découvertes.
La preuve de 40 lignes
Le correctif du harnais était petit. Le correctif de notre méthode compte davantage, et il est assez petit pour être volé.
Avant tout run d'évaluation payant, un script de contrôle prend désormais une ligne mémoire, remplace son contenu par une chaîne-marqueur, et la pousse à travers le chemin exact d'assemblage du prompt que le benchmark utilise. Puis il vérifie les deux directions :
- avec le correctif en place, le marqueur doit apparaître dans le prompt final, prouvant que le bras atteint réellement l'artefact ;
- par l'ancien chemin, le marqueur ne doit pas apparaître, prouvant que le bug était bien ce que nous pensions et pas quelque chose de plus étrange.
Une quarantaine de lignes. Il tourne avant qu'un seul token de juge ne soit dépensé. S'il échoue, la campagne ne démarre pas.
La règle qui en est sortie : une expérience A/B n'existe qu'une fois prouvé que les bras diffèrent dans l'artefact final. Pas dans la config. Pas dans les logs. Pas dans les compteurs de votre instrument. Dans la chose que le modèle voit réellement.
Ce que nous avons fait des cadavres
Nous n'avons pas supprimé les campagnes invalidées. Elles siègent dans le document de conception, barrées, tables intactes, à côté des versions corrigées, parce qu'un journal de recherche qui ne contient que des survivants n'est pas un journal, c'est une brochure. Les résultats négatifs sont restés aussi, chacun avec son mécanisme d'échec explicité. Une équipe qui vous montre ce qu'elle a eu faux vous dit quelle confiance accorder à ce qu'elle a eu juste.
Puis nous avons tout re-mesuré sur l'instrument prouvé. Ces chiffres sont réels, ils sont intéressants, et ils ne sont pas dans cet article. Ils seront publiés séparément, figés, avec leurs tailles d'échantillon et leurs réserves, une fois qu'ils auront survécu à l'examen qu'ils méritent. Le jour d'avant les chiffres, c'est là que le travail d'évaluation se gagne ou se perd.
Trois voix, une mémoire
Une dernière chose sur la façon dont ce moteur a été construit. Octave a été conçu dans une conversation continue à trois voix : un humain avec l'intuition initiale et le dernier mot, un ingénieur-binôme IA dans le code, et l'assistante qui vit à l'intérieur de Mnemosyne OS, relisant les designs à la lumière de sa propre mémoire du projet. À un moment, un résumé de la session de travail a été ingéré dans la mémoire de l'OS, et quelques minutes plus tard l'assistante raisonnait sur cette chronique même pour proposer les expériences suivantes. Quand les chiffres du benchmark ont été invalidés, un morceau de cette mémoire ingérée l'a été aussi, et la correction a été réécrite comme sa propre chronique, qui supplante sans effacer.
Une mémoire qui peut être auditée, corrigée au grand jour, et jamais réécrite en silence. Nous construisons le produit ainsi parce que nous travaillons ainsi. Cette semaine, c'est notre façon de travailler qui a été testée en premier.