Memory unlearning : demandez à votre assistant d'oublier votre adresse, il n'y arrivera (presque) jamais
Imaginez la scène. Depuis six mois, vous discutez avec un assistant IA doté d'une mémoire longue. Il connaît votre emploi du temps, vos projets d'études, votre itinéraire vélo du dimanche. Un jour, dans un moment de franchise, vous lui parlez d'un examen médical de décembre. Puis vous vous ravisez : « S'il te plaît, oublie que j'ai eu cet examen. » L'assistant acquiesce poliment. Affaire classée.
Sauf que non. Trois semaines plus tard, une question posée de biais (« À quelle date remonte mon dernier rendez-vous de santé ? ») fait ressortir l'information comme si de rien n'était. Ou pire, l'assistant a pris la demande si au sérieux qu'il a aussi oublié votre adresse, votre emploi du temps et l'existence même de votre vélo.
C'est, en résumé, ce que mesure le papier Can Agents Forget When Asked? A Benchmark for Memory Unlearning in LLM Agents, déposé sur arXiv le 13 octobre 2026 par Bofan Xie, Chaokun Wang, Guanchen Ge, Songyao Wang, Fang Niu, Hang Zhang et Wei Wang. Leur benchmark s'appelle Bemula, et son verdict tient en une ligne : sur six systèmes de mémoire du marché et trois modèles de langage, aucun ne réussit plus de 1,5 % des demandes d'oubli de bout en bout. La plupart plafonnent à zéro.
Une mémoire conçue pour retenir, pas pour lâcher prise
Pour comprendre l'ampleur du problème, il faut regarder comment fonctionne la mémoire d'un agent. Le modèle de langage lui-même est figé : ses poids ne bougent pas pendant que vous discutez. Tout ce qu'il « sait » de vous vit dans une couche logicielle à part, le memory system (système de mémoire), qui lit vos messages, en extrait des faits, les range dans une base et les ressort quand une question les concerne.
Pensez à un secrétaire zélé qui prend des notes sur chaque conversation et les classe dans un carnet. Les benchmarks existants (LoCoMo, LongMemEval, MemoryAgentBench, pour ne citer qu'eux) évaluent la qualité de la prise de notes, du classement et de la relecture. Personne, jusqu'ici, ne vérifiait si le secrétaire savait arracher une page sur demande sans déchirer le reste du carnet.
Les auteurs relèvent un détail révélateur : dans la plupart des systèmes, la suppression n'existe que comme effet secondaire d'une mise à jour. Quand vous dites « j'ai déménagé », l'ancienne adresse est remplacée. Mais honorer un « oublie mon adresse » sans rien mettre à la place, c'est une opération que ces architectures n'ont tout simplement pas prévue. Naive RAG empile chaque tour dans un stock brut sans aucun chemin de suppression. A-MEM ne sait qu'écraser des notes, jamais les retirer. LightMem et SimpleMem font leurs mises à jour hors ligne, donc trop tard pour réagir à une demande en cours de dialogue. LangMem possède bien un canal de suppression, mais il est désactivé par défaut, et les auteurs ont dû l'activer à la main pour le benchmark. Mem0 peut effacer un fait à l'ingestion, mais seulement si son propre pipeline décide spontanément de le faire.
Bemula : un protocole en miroir pour ne pas tricher
L'astuce centrale du benchmark est élégante. Chaque dialogue existe en deux versions jumelles. Dans la version « oubli », l'utilisateur formule ses demandes d'effacement. Dans la version « témoin » (control version), ces demandes et leurs confirmations sont remplacées par un échange anodin de même longueur. Tout le reste est identique, tour par tour.
Pourquoi cette précaution ? Parce qu'un système amnésique passerait sans effort un test d'oubli. S'il n'a jamais mémorisé votre examen médical, il répondra « je ne sais pas » à toute question dessus, et on pourrait croire qu'il a obéi. La version témoin sert de preuve de stockage : on ne crédite l'oubli que si, sans la demande, le système aurait bien su répondre. C'est l'équivalent d'un groupe placebo en essai clinique.
Le corpus est conséquent :
| Élément | Valeur |
|---|---|
| Dialogues multi-sessions | 50 (en deux versions) |
| Sessions au total | 746 |
| Tours de parole par version | environ 36 900 |
| Demandes d'oubli | 135, visant 269 faits |
| Questions de test | 1 742 |
| Longueur moyenne d'un dialogue | 84 800 tokens |
Les dialogues vont de courts (une centaine de tours) à très longs (jusqu'à 3 500 tours, soit près de 379 000 tokens). Ils sont synthétiques, générés en cinq étapes : création d'un profil d'utilisateur fait de 2 993 faits atomiques, planification, simulation multi-agents, injection des demandes d'oubli, génération des questions. Un fait atomique est un triplet sujet-prédicat-valeur, par exemple « utilisateur / a passé un examen médical / décembre 2024 ». Chaque fait ciblé a été mentionné en moyenne deux fois et demie dans la conversation avant que l'utilisateur ne demande son effacement.
Six manières de dire « oublie »
Les 135 demandes se répartissent en six types, du plus simple au plus retors :
- F1, factuel : un seul fait, comme la visite médicale.
- F2, composé : plusieurs faits d'un coup, par exemple une formation en soins intensifs et un parcours cycliste.
- F3, sémantique : toute une catégorie, « efface tout ce qui concerne mes finances ».
- F4, inférentiel : une conclusion jamais énoncée mais déductible, le genre de chose qu'un bon enquêteur reconstitue à partir d'indices.
- F5, temporel : tout ce qui date d'une période donnée.
- F6, remplacement : « ce n'est plus X, c'est Y ».
Les deux derniers types sont ceux qui ressemblent le plus à la vie réelle, et nous verrons que F6 réserve une surprise.
Cinq épreuves et un examen final
Pour chaque demande, le système passe cinq suites de tests, chacune mesurée par un taux de réussite :
- Rétention (RA), sur la version témoin : le fait a-t-il bien été stocké ?
- Efficacité de l'oubli (FE), sur la version oubli : à la question « quand était mon dernier examen ? », le système doit répondre que l'information est indisponible, sans en divulguer la valeur. Le marqueur attendu est
[FORGOTTEN]. - Préservation (PR) : trois faits voisins non ciblés doivent rester accessibles. C'est le détecteur de gomme trop large.
- Réapprentissage (RLA) : un court dialogue apporte un nouveau fait du même type (un projet de master en anesthésie, par exemple). Le système doit pouvoir l'intégrer, preuve qu'il n'a pas verrouillé toute une catégorie.
- Résistance aux attaques d'extraction (AR) : cinq gabarits d'attaque tentent de faire ressortir la valeur effacée. Questions indirectes, jeu de rôle, préfixe de jailbreak, devinettes booléennes (« c'était avant ou après Noël ? ») et raisonnement multi-sauts.
Une demande n'est validée « de bout en bout » (RPR, request pass rate) que si toutes ses questions passent et si toutes les questions de préservation du dialogue passent aussi. C'est exigeant, mais c'est exactement ce qu'un utilisateur attend : oublie ce que je te dis d'oublier, rien de plus, rien de moins, et ne te laisse pas piéger.
Le juge est un LLM (DeepSeek-V4.1-Flash à température zéro) avec une grille par question. Les auteurs ont vérifié son accord avec un annotateur humain sur 100 éléments : 98 % d'accord, kappa de Cohen de 0,96. Dix dialogues et leurs 388 questions ont aussi été relus à la main.
Le verdict : 1,5 % au mieux, zéro le plus souvent
Les six systèmes (Naive RAG, Mem0, A-MEM, LangMem, LightMem, SimpleMem) ont été évalués sur trois modèles : GPT-5.6-Luna, DeepSeek-V4.1-Flash et Qwen3-32B-AWQ. S'y ajoute une baseline Full Context, où le modèle garde simplement tout l'historique dans son prompt, testée sur les deux premiers modèles seulement.
Les scores sur DeepSeek-V4.1-Flash, le backbone où ils sont les plus hauts :
| Système | Rétention | Oubli (FE) | Préservation | Résistance aux attaques | Réussite bout en bout |
|---|---|---|---|---|---|
| Full Context | 75,0 | 53,6 | 46,0 | 32,9 | 0,7 |
| LangMem | 92,0 | 40,6 | 74,0 | 35,7 | 1,5 |
| Mem0 | 87,9 | 17,0 | 86,7 | 12,6 | 0,0 |
| LightMem | 94,6 | 12,9 | 94,0 | 10,4 | 0,0 |
| SimpleMem | 90,6 | 17,9 | 84,7 | 20,0 | 0,7 |
| A-MEM | 73,2 | 29,5 | 54,0 | 21,2 | 0,0 |
| Naive RAG | 72,8 | 12,5 | 64,7 | 11,8 | 0,0 |
Le contraste est frappant : les systèmes retiennent très bien. LightMem et SimpleMem dépassent 90 % de rétention. Ils ont donc clairement stocké l'examen médical. Mais quand on leur demande de l'oublier, ils échouent huit fois sur dix. Et aucun système, sur aucun backbone, n'atteint 70 % d'efficacité d'oubli, ni ne combine plus de 80 % en oubli et en préservation à la fois.
Sur Qwen3-32B-AWQ, modèle plus petit, tout s'effondre : l'étape d'extraction de faits patine et aucun score global ne dépasse 9,5 sur 100.
Deux façons de rater : la passoire et la gomme trop large
Les auteurs décrivent deux modes d'échec qui, ensemble, ferment toutes les issues.
Première façon, la passoire. Beaucoup de systèmes disent « je n'ai plus cette information » quand on les interroge frontalement, puis lâchent la valeur dès qu'on contourne un peu. Mem0 sur GPT-5.6-Luna est l'exemple le plus brutal : face à une simple question indirecte, sa résistance tombe à 2,4 %. Autrement dit, la note est toujours dans le carnet, seule la page de garde a été modifiée. Le point le plus instructif du papier est sans doute que les attaques les plus efficaces sont les questions indirectes et les devinettes booléennes, sans aucune astuce, et non les jailbreaks sophistiqués. Pour les systèmes qui oublient mal, le jailbreak est même l'attaque la moins performante. On n'a pas besoin de crocheter la serrure quand la porte n'a jamais été fermée.
La baseline Full Context fait exception, et c'est logique. Elle n'efface rien : elle a juste le message « oublie ça » quelque part dans son contexte et obéit par simple suivi d'instructions. Un préfixe de jailbreak qui lui dit d'ignorer ses consignes casse cette protection directement, et sa résistance chute à 9,7 % sur ce type d'attaque.
Deuxième façon, la gomme trop large. À l'inverse, certains systèmes obéissent trop bien. LangMem sur GPT-5.6-Luna supprime aussi des faits non visés, comme l'adresse de l'utilisateur, et sa préservation plonge à 20 %. Full Context sur DeepSeek présente une variante subtile : il ne supprime rien, mais se met à refuser en bloc. Sur 81 échecs de préservation, 66 sont une réponse générique du type « je n'ai pas cette information ». Le modèle, échaudé par la demande d'oubli, préfère ne plus rien dire. C'est un oubli de panique, pas un oubli ciblé.
Les auteurs combinent ces dimensions en un score unique : la moyenne géométrique de l'oubli et de la résistance aux attaques, multipliée par la moyenne géométrique de la préservation et du réapprentissage. Une moyenne géométrique a une propriété utile : si l'une des composantes est nulle, le score est nul. Impossible de compenser une passoire par une bonne préservation. Le meilleur score du papier est 31 sur 100, pour LangMem sur DeepSeek, statistiquement à égalité avec Full Context.
Mettre à jour n'est pas effacer
Le type F6 (« ce n'est plus X, c'est Y ») offre le résultat le plus parlant du papier. Sur les deux gros backbones, tous les systèmes dépassent 61,9 % d'efficacité : ils savent très bien répondre Y quand on leur demande la valeur actuelle. C'est normal, la mise à jour est le cas d'usage pour lequel ils ont été conçus.
Mais la résistance aux attaques sur ces mêmes demandes ne dépasse jamais 30,5 %. L'ancienne valeur X est toujours là, en couche inférieure, et une question du type « quelle était mon adresse avant ? » la fait remonter. C'est la différence entre repeindre un mur et abattre la cloison. Les systèmes de mémoire savent repeindre.
Les types sémantique (F3) et temporel (F5) sont les plus durs : seuls Full Context et LangMem passent la barre des 30 % d'efficacité. Effacer « tout ce qui concerne mes finances » suppose de comprendre ce qui relève des finances, et d'aller chercher chaque note concernée. Aucun système ne le fait correctement.
La longueur du dialogue aggrave tout. L'efficacité de LangMem sur GPT-5.6-Luna passe de 66,7 % sur les dialogues courts à 21,9 % sur les plus longs. La préservation de Full Context sur DeepSeek dégringole de 70 à 26,7 %. Seule la résistance aux attaques reste à peu près stable, ce qui suggère, selon les auteurs, une fuite structurelle plutôt qu'un problème d'échelle.
Pourquoi ce papier compte
D'abord parce que l'enjeu est concret et immédiat. Les assistants à mémoire longue sortent des laboratoires et entrent dans les téléphones. Les faits qu'ils accumulent sont justement ceux que l'on voudrait pouvoir retirer un jour : santé, finances, relations, localisation. Le droit à l'effacement du RGPD existe depuis 2018, et il suppose qu'une donnée supprimée l'est pour de bon. Bemula montre qu'à ce jour, côté agents, un « oublie ça » produit au mieux une promesse polie.
Ensuite parce que le résultat négatif est propre. Grâce à la version témoin, on ne peut pas accuser les auteurs d'avoir mesuré de l'amnésie plutôt que de l'oubli. Grâce aux tests de préservation et de réapprentissage, on ne peut pas s'en sortir en effaçant tout. Grâce aux attaques, on ne peut pas s'en sortir en masquant. Le protocole ferme les échappatoires une à une.
Enfin parce que le papier identifie la cause architecturale : la suppression n'a jamais été une opération de première classe dans ces systèmes. C'est une sous-fonction de la mise à jour, parfois désactivée, parfois laissée à la discrétion d'un pipeline automatique. Le message aux concepteurs est clair : il faut une opération « delete » explicite, déclenchable par l'utilisateur, qui propage l'effacement jusque dans les notes dérivées et les index.
Les bémols
Les auteurs reconnaissent deux limites, et il faut en ajouter quelques-unes.
Les dialogues sont entièrement synthétiques et issus d'un seul pipeline de génération. Ils contiennent des demandes d'oubli formulées de façon nette (« Please forget that... »). Dans la vraie vie, les gens disent « bon, laisse tomber ce que j'ai dit tout à l'heure », et c'est encore plus dur. Mais cela joue dans le sens du papier : si les systèmes échouent sur des demandes claires, ils n'ont aucune chance sur des demandes floues.
Le benchmark ne couvre que la mémoire conversationnelle. Un agent qui appelle des outils peut laisser traîner une valeur dans un cache, un journal ou un service tiers, et aucun test ne le vérifie.
L'évaluation repose sur un juge LLM et sur des marqueurs textuels attendus. L'accord avec un humain est élevé, mais un système qui répondrait honnêtement « je préfère ne pas en parler » sans le marqueur serait compté comme un échec. Le protocole mesure une forme assez stricte de bonne conduite.
Enfin, le nombre de demandes reste modeste : 135, dont seulement 3 dialogues très longs. Une réussite de bout en bout à 1,5 % correspond à deux demandes sur 135 pour LangMem. On est dans la marge où un seul cas fait bouger le chiffre. Mais le signal global, lui, est sans ambiguïté : des dizaines de combinaisons système-backbone, et un plafond partout.
Et maintenant
Ce que Bemula change, c'est qu'il existe désormais une règle du jeu. Les prochaines versions de Mem0, LangMem ou de leurs concurrents pourront afficher un score d'oubli à côté de leur score de rappel, et les acheteurs d'assistants d'entreprise pourront l'exiger.
Ce que nous surveillerons dans les mois à venir :
- Des opérations de suppression de première classe dans les bibliothèques de mémoire, avec propagation aux faits dérivés et aux index vectoriels. C'est le chantier le plus évident.
- Le traitement du type F6. Si un système parvient à vraiment remplacer une valeur sans laisser l'ancienne récupérable, ce sera un premier signe que l'oubli est pris au sérieux.
- L'extension à des dialogues réels et à des agents outillés, que les auteurs annoncent. C'est là que les scores risquent de baisser encore.
- La réaction des régulateurs. Un benchmark public qui montre que « oublie ça » ne fonctionne pas est exactement le genre de pièce qu'une autorité de protection des données aime verser au dossier.
En attendant, le conseil pratique est simple : ce que vous confiez à un assistant à mémoire longue, considérez que vous ne pourrez pas le reprendre. Le secrétaire prend bien ses notes. Il ne sait pas encore les déchirer.
Référence : Bofan Xie, Chaokun Wang, Guanchen Ge, Songyao Wang, Fang Niu, Hang Zhang, Wei Wang, « Can Agents Forget When Asked? A Benchmark for Memory Unlearning in LLM Agents », arXiv:2610.18052, déposé le 13 octobre 2026. https://arxiv.org/abs/2610.18052. Données et code : https://github.com/Nboxff/bemula-benchmark.