Dans un modèle classique, chaque mot traverse tous les « tiroirs » du réseau, même ceux qui n'ont rien à voir avec lui. Et si l'on ajoutait un immense fichier où le modèle n'ouvre que les deux ou trois fiches dont il a besoin ?
Prometteurmise à jour du
I
L'idée, simplement
Un modèle de langage stocke une bonne part de son savoir dans des couches dites feed-forward. Elles fonctionnent comme une mémoire, mais une mémoire dense : chaque mot les traverse en entier, ce qui coûte du calcul à chaque fois.
Une couche mémoire remplace (ou complète) cela par une table géante de paires clé → valeur. Pour chaque mot, le modèle ne lit que quelques valeurs. On ajoute ainsi des milliards de paramètres sans ajouter de calcul, comme une bibliothèque qui grandit sans qu'on lise plus de livres.
II
Comment ça marche
Le problème : pour trouver la meilleure clé parmi un million, il faudrait normalement un million de comparaisons. L'astuce des clés produit (Lample et ses coauteurs, 2019) : couper la requête en deux moitiés, comparer chacune à une liste de 1 000 demi-clés, puis croiser les meilleures. On obtient le bon résultat parmi 1 000 × 1 000 = un million de cases avec 2 000 comparaisons seulement.
Le modèle lit ensuite quelques valeurs (une trentaine, par exemple), en fait une moyenne pondérée, et un « portillon » décide quelle part injecter dans la suite du calcul.
Ici, 8 + 8 comparaisons suffisent pour trouver la meilleure case parmi 64. Avec 1 000 + 1 000 comparaisons, on choisit parmi un million.
Schéma illustratif : il montre l'idée, pas des mesures.
La requête est coupée en deux. Chaque moitié est comparée à une petite liste de « demi-clés ». Les meilleures lignes et les meilleures colonnes se croisent sur quelques cases candidates, et la gagnante livre sa valeur. Le fichier peut grandir énormément sans que le nombre de comparaisons explose.III
Ce que montrent les travaux
Prometteur
Memory Layers at Scale (Meta)
Jusqu'à 128 milliards de paramètres de mémoire, ajoutés à des modèles de base allant jusqu'à 8 milliards, entraînés sur 1 000 milliards de jetons. Les modèles avec mémoire battent des modèles denses qui utilisent plus de deux fois plus de calcul, et des « mélanges d'experts » à calcul et paramètres égaux. Le gain est le plus net sur les questions factuelles.
Une mémoire consultée en temps constant à partir des petites suites de mots du texte. À taille et calcul égaux, le modèle de 27 milliards gagne +3 points en MMLU, +5 en raisonnement (BBH), et passe de 84,2 % à 97 % sur un test de recherche dans un long texte. La table de 100 milliards de paramètres peut vivre dans la mémoire ordinaire de l'ordinateur, pas dans celle, rare et chère, du GPU, pour moins de 3 % de perte de débit. Désactivez-la, et les connaissances factuelles s'effondrent (TriviaQA tombe à 29 % de son niveau) : les faits y sont bien rangés.
Comme chaque fait n'utilise que quelques cases, on peut n'actualiser que celles-là. En apprenant de nouveaux faits, un modèle classique réentraîné en entier perd 89 % de ses performances sur d'autres questions, et 71 % avec la méthode LoRA. Avec la mise à jour ciblée des cases mémoire : 11 % seulement, pour le même apprentissage.
Plus loin : plus rapide, et une mémoire qui apprend en lisant
Deux familles de mémoire se dessinent. Les tables fixes (Memory Layers, UltraMem, Engram), apprises une fois pour toutes. Et des mémoires qui s'écrivent pendant la lecture, comme Titans.
Titans garde ce qui le surprend : c'est exactement l'idée de notre hypothèse H4, où les exceptions sont ce qui vaut la peine d'être retenu. Une machine qui ne mémorise que l'inattendu, c'est une forme de compression « règles + exceptions ».
Les « mélanges d'experts » (MoE) économisent du calcul, mais à l'usage ils doivent aller chercher beaucoup de paramètres en mémoire, ce qui les ralentit. UltraMem (ByteDance, 20 millions de cases mémoire) est jusqu'à 6 fois plus rapide qu'un MoE de même taille et de même calcul, réduit le coût d'usage de 83 % au plus, et tourne presque aussi vite qu'un modèle dense. Ajouter des cases ne le ralentit quasiment pas.
Chez Google, la mémoire de long terme est un petit réseau qui modifie ses propres poids pendant la lecture. Il écrit ce qui le surprend (mesuré par l'ampleur de son erreur) et oublie peu à peu le reste. L'attention classique sert de mémoire courte. Résultat : des contextes de plus de 2 millions de jetons, avec une meilleure recherche d'aiguille dans une botte de foin que des modèles plus gros.
C'est la preuve la plus directe, à ce jour, que l'on peut séparer le savoir du raisonnement à l'intérieur même d'un modèle. Avec Engram, couper la mémoire fait chuter les faits mais pas tout le reste ; et la mémoire libère même les premières couches du réseau pour raisonner.
C'est aussi une piste d'économie : la mémoire peut aller sur de la mémoire vive ordinaire, bon marché, et une mise à jour ne touche que quelques cases au lieu de réentraîner tout le modèle.
VI
Les limites
Lire dans une table géante est rapide en calcul mais exigeant en bande passante mémoire : il a fallu une implémentation dédiée pour que ce soit efficace. Les essais publiés vont jusqu'à 8 milliards de paramètres de base chez Meta et 27 milliards chez DeepSeek. Et cette mémoire reste interne et opaque : contrairement à une base externe, on ne peut pas encore y lire une source ni la citer.
VII
Ce que ça change pour nos hypothèses
Un appui fort à H2 (« apprendre le haut, consulter le bas »), que nous faisons passer de 70 à 75 % de confiance. Avec Engram, la meilleure répartition est d'environ un quart des paramètres en mémoire et trois quarts en calcul : un premier chiffre concret pour la frontière que pose notre question ouverte n° 3.
Un mini-modèle avec couche mémoire : lui apprendre une liste de faits, puis en corriger un seul en ne touchant que ses cases. Vérifier qu'il retient la correction, n'oublie rien d'autre, et voir si les cases d'un même sujet se regroupent : ce serait une hiérarchie qui apparaît d'elle-même.