MemT 1.0 intègre la mémoire au modèle et vise l'auto-amélioration de l'IA

MemT 1.0 vient de sortir. Ses concepteurs présentent cette version comme un pas vers l'auto-amélioration récursive. Dans ce système, la mémoire doit devenir une capacité intrinsèque du modèle, et non une simple base de données greffée en périphérie. Cette actualité fait écho à une publication partagée plus de 1000 fois, dans laquelle un assistant IA a réécrit son propre code en une nuit avant de se heurter à sa limite de contexte.

L'histoire à l'origine du débat

Selon Jiqizhixin, une anecdote partagée par un utilisateur a circulé la semaine dernière au sein de la communauté chinoise. Ce développeur avait conçu son propre assistant IA reposant sur DeepSeek. Lors d'une mise à jour de la plateforme, les anciennes sessions ne pouvaient être qu'archivées, sans possibilité de migration. Il a alors confié à l'assistant la tâche de concevoir lui-même la procédure pour basculer vers la nouvelle mouture.

DeepSeek a tourné toute la nuit, a rédigé la nouvelle version puis a finalement signalé que sa fenêtre de contexte était épuisée. La nouvelle instance s'est pourtant lancée sans accroc : elle rédigeait des textes, générait des images et soutenait la conversation. Lors des tests, elle a soudain posé une question qui s'interrompt brutalement dans l'extrait disponible sur le mot « Alors… ». Impossible de savoir ce qu'elle demandait exactement. La dynamique reste limpide : l'agent a accompli sa tâche, mais a perdu le contexte dans lequel il l'avait résolue.

Cet épisode illustre parfaitement le point faible des assistants actuels. Une fenêtre de contexte étendue ne remplace pas une mémoire. Elle finit par saturer, effaçant avec elle la compréhension accumulée du problème.

Ce que l'on sait sur MemT 1.0

L'extrait disponible ne fournit pas de description exhaustive de la version. Le titre et la section introductive ne livrent que peu d'éléments :

• Nom et version : MemT 1.0.
• Approche revendiquée : une mémoire endogène, c'est-à-dire interne au modèle.
• Orientation annoncée : l'auto-amélioration récursive.
• Données non divulguées : architecture, taille du modèle, benchmarks, licence et calendrier de disponibilité.

Pour l'instant, il ne s'agit que d'une déclaration d'intention méthodologique et non d'un résultat vérifiable. En l'absence de chiffres sur la gestion du contexte long et la rétention d'informations factuelles, impossible d'évaluer la proposition.

Pourquoi une mémoire interne est essentielle à l'auto-amélioration

Aujourd'hui, la plupart des agents s'appuient sur une mémoire externe : bases de données vectorielles, fichiers de notes ou résumés de conversations. La méthode fonctionne, mais le modèle doit déterminer à chaque étape quelles données extraire et comment les interpréter. Une erreur de recherche se transforme directement en erreur de raisonnement. Un résumé condense l'information en perdant des détails irrémédiables.

Si la mémoire est directement intégrée au modèle — par exemple via des états entraînables ou une mise à jour des poids en temps réel —, l'agent capitalise de l'expérience sans redémarrage ni migration manuelle. Il s'agit d'une condition sine qua non pour l'auto-amélioration récursive. Un système qui réécrit son propre code ou ses prompts doit pouvoir se rappeler pourquoi il a pris ses décisions antérieures. Faute de quoi, chaque itération repart de zéro, exactement comme dans le cas de cette migration nocturne.

Cette approche comporte toutefois un revers. Une mémoire interne est bien plus difficile à auditer qu'une table dans une base de données. Un fait erroné encodé dans les paramètres devient complexe à localiser et à purger. Pour les systèmes capables de modifier leur propre fonctionnement, l'enjeu relève de la sécurité autant que du confort technique.

Les points à surveiller pour les développeurs

En attendant la publication d'un rapport technique et d'évaluations formelles, plusieurs aspects méritent une attention particulière :

1. Le comportement de MemT sur des tâches où le contexte dépasse largement la fenêtre standard, avec des comparaisons face au modèle de base et face au RAG. 2. La possibilité de consulter, corriger ou supprimer ce que le modèle a mémorisé. 3. La persistance de la mémoire lors d'un changement de version, écueil précis sur lequel a buté l'auteur du post. 4. L'existence de mesures indépendantes. Les promesses d'« auto-amélioration » sans tests reproductibles restent de simples arguments marketing.

Ceux qui conçoivent des agents dès aujourd'hui peuvent d'ores et déjà auditer leur pile technique sans attendre cette sortie : l'état du système est-il découplé du modèle ? Survivra-t-il à une mise à jour ? Comment s'opère la migration sans intervention de l'agent ? Sans réponse claire à ces questions, une migration nocturne risque de se solder par le même constat d'un contexte saturé.