Google apprend aux modèles de langage à « dormir » pour transférer les connaissances de la mémoire vers les poids

Google apprend aux modèles de langage à « dormir » pour transférer les

connaissances de la mémoire vers les poids

Google Research a publié le framework SLEEP — une méthode pour enseigner de nouvelles informations aux modèles de langage sans qu'ils perdent ce qu'ils savaient déjà. L'idée est née de deux problèmes anciens de l'apprentissage continu.

Le premier est l'oubli catastrophique : lorsqu'un modèle est réentraîné sur une nouvelle tâche, les mises à jour de poids effacent ce qui était important pour les tâches précédentes. Le second est que les connaissances issues de la fenêtre de contexte ne deviennent jamais une mémoire permanente. Tant que l'information reste dans le prompt, le modèle l'utilise. Une fois le contexte terminé, elle disparaît. Et maintenir un long contexte coûte cher : il faut le faire traiter à nouveau et le garder en mémoire vive à chaque requête.

Éveil, sommeil et « rêves »

SLEEP divise le fonctionnement du modèle en deux modes.

• Éveil — le modèle reçoit des données d'entrée et stocke les informations dans une mémoire à court terme, comme d'habitude.
• Sommeil — la réception de nouvelles données est suspendue. Le modèle active des blocs de mémoire supplémentaires MoE (mélange d'experts) et transfère les connaissances accumulées vers leurs poids, en cherchant à minimiser l'impact sur ce qui est déjà consolidé. Une fois le transfert effectué, la mémoire temporaire est vidée.

Une phase distincte, dite de « rêve », est décrite séparément : des combinaisons aléatoires d'experts génèrent leurs propres exemples d'entraînement, et le système en sélectionne les plus utiles pour poursuivre l'apprentissage. Le modèle prépare donc en partie lui-même le matériel nécessaire à sa consolidation, sans jeu de données externe à chaque cycle.

Un détail important : le « sommeil » est un cycle de réentraînement contrôlé, suivant des règles définies par les chercheurs, et non une reconfiguration autonome du modèle. L'architecture et le code restent fixes, seuls les poids des blocs MoE désignés évoluent.

Ce que montrent les expériences

L'équipe a testé l'approche sur trois tâches différentes.

• BABILong — un test sur le traitement de contextes très longs. Le modèle a conservé des informations issues de séquences allant jusqu'à 10 millions de tokens, non pas en élargissant la fenêtre de contexte, mais en ancrant les connaissances directement dans les paramètres.
• Entraînement séquentiel en traduction — un test classique de l'oubli. Les langues sont apprises l'une après l'autre, et habituellement, dans ce type de test, la qualité sur les premières langues chute sensiblement après l'apprentissage des nouvelles. Avec SLEEP, la baisse s'est révélée quasiment nulle.
• Mathématiques (AIME) — une précision de 79,2 % sur AIME 2024 et de 69 % sur AIME 2025. L'écart entre les deux années n'a rien de sensationnel : un tel écart s'observe chez beaucoup de modèles sur ces deux jeux de problèmes, et une seule publication ne permet pas encore de tirer de conclusions sur les causes. Ce qui compte davantage, c'est que le transfert des connaissances vers les poids n'a pas détruit la capacité de raisonnement mathématique du modèle.

Ce que cela signifie pour les équipes d'ingénierie

La question centrale est celle du coût. Transférer des connaissances vers les poids exige des cycles de réentraînement supplémentaires, donc du calcul à planifier : pendant le « sommeil », le modèle ne traite pas les requêtes. Il faudra décider à quelle fréquence lancer ce cycle, combien de mémoire accumuler avant de le déclencher, et combien de blocs MoE réserver au stockage — autant de paramètres fixés par des règles que les développeurs devront ajuster eux-mêmes en fonction de leur charge.

Le bénéfice potentiel se situe dans l'économie du contexte. Si une base de connaissances d'entreprise, un long échange ou des documents fréquemment mis à jour sont ancrés dans les poids, il ne sera plus nécessaire de faire traiter des millions de tokens à chaque fois et de payer pour leur retraitement répété. Pour des agents opérant sur de longues historiques, c'est une économie directe en mémoire et en latence de réponse.

Un risque subsiste néanmoins, que la description du framework ne lève pas : une inscription dans les poids est plus difficile à suivre et à annuler qu'un document dans le contexte ou dans une base de données externe. Pour les secteurs réglementés, il faudra réfléchir séparément à la manière de vérifier, et au besoin de supprimer, ce que le modèle a consolidé pendant son « sommeil ». À ce stade, SLEEP doit être perçu comme un résultat de recherche solide et un candidat pour des essais pilotes dans des projets aux données constamment mises à jour, plutôt que comme un composant prêt pour la production.