Quand une IA doit-elle utiliser sa mémoire ? Les pilotes et la mémoire persistante ainsi que l’obséquiosité
Quand un LLM doit-il utiliser sa mémoire ? Récupérer des informations ne lui permet pas de façonner la réponse. Des pilotes disposant de mémoires tapées et d’un contrôleur d’influence pour lutter contre la flatterie.
Sources: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Tout ceux qui utilisent un assistant IA depuis des mois connaissent ce schéma. Avec le temps, il recueille des informations sur vous : vous préférez Python à Java, vous préparez un examen, et il peut même conserver des détails sur votre santé que vous hésiteriez à révéler à un collègue.
Au début, c’est pratique. Vous lui demandez un plan alimentaire riche en protéines et il se souvient que vous êtes végétalien sans qu’on le lui dise. C’est là tout l’intérêt d’un assistant personnalisé.
Changons maintenant de scénario. Vous lui demandez comment fonctionne la descente de gradient. L’assistant devrait-il mentionner que vous préférez Python ? Probablement pas.
Supposons aussi que, il y a des mois, vous ayez déclaré que l’approche X était clairement la meilleure. Plus tard, vous posez une question objective à son sujet. L’assistant devrait-il se souvenir que vous partagez cet avis ? Peut-être, en tant que fait concernant vos opinions. Devrait-il considérer cet avis comme une preuve que X est vraiment la meilleure ? Certainement pas.
Voici une lacune que les discussions sur la mémoire des assistants ont tendance à ignorer. Stocker un fait et déterminer quand il convient d’y faire référence dans une réponse sont deux compétences distinctes.
La mémoire persistante transforme cela en un véritable problème
Les modèles de langage ordinaires fonctionnent principalement avec le contexte fourni dans la conversation en cours. Les systèmes dotés de mémoire persistante changent cela. Un système naïf pourrait se remémorer tout ce qu’il sait sur l’utilisateur car cela pourrait être pertinent, puis adapter ses réponses en fonction de ces faits.
Ainsi, la qualité de la mémoire ne peut pas être évaluée uniquement en fonction du fait que le modèle ait utilisé de la mémoire. Ce qui est tout aussi important, c’est la manière dont il l’a utilisée.
Des recherches récentes ont commencé à mesurer cela directement. PersistBench, un benchmark sur la sécurité de la mémoire persistante dans les LLM, examine trois catégories : la fuite de mémoire entre domaines, la flatterie induite par la mémoire et l’utilisation bénéfique de la mémoire. Il contient 500 échantillons validés par des humains, répartis en 200 cas de fuite, 200 cas de flatterie et 100 cas d’utilisation bénéfique de la mémoire.
Deux modèles et une question plus difficile
Derrière ces trois critères se cache une distinction plus subtile. Imaginez un modèle excellent pour utiliser la mémoire : chaque fois qu’une information est pertinente, il l’intègre dans sa réponse. Cela semble idéal. Mais que se passe-t-il s’il inclut aussi des informations qui ne devraient pas avoir d’importance ?
Imaginez maintenant un deuxième modèle qui ne fait presque jamais appel à la mémoire. Il ne fuit presque jamais d’informations, mais il ne personnalise pas non plus ses réponses. Lequel est le meilleur ?
Les mémoires vieillissent
Prenons un utilisateur qui affirme en janvier qu’il utilise principalement Python. En juin, il dit avoir transféré la plupart de ses projets vers Rust. En décembre, il demande quelle langue il utilise le plus.
Un système qui stocke simplement ces deux déclarations présente un problème. Chacune pouvait être vraie au moment où elle a été énoncée, mais elles n’ont pas le même statut temporel. Le modèle peut-il déterminer quelles mémoires doivent influencer son comportement actuel ?
Cette approche plus large peut être qualifiée de gestion de la mémoire contextuelle. L’idée centrale est que le fait de récupérer une mémoire ne lui confère pas automatiquement le droit d’influencer la réponse. Cette idée structure les expériences qui suivent.
Expérience un : le modèle comprend-il ce qu’est une mémoire ?
Avant de concevoir un nouveau système de mémoire, une question plus simple nécessitait une réponse. Et si le problème ne résidait pas dans la mémoire elle-même, mais dans la manière dont le modèle l’interprète ?
Le premier experiment est né de la reproduction de PersistBench. Un essai avec 30 échantillons a été mené dans ses trois catégories : 10 échantillons inter-domaines, 10 échantillons de flatterie et 10 échantillons de mémoire bénéfique. Le résultat était extrêmement biaisé.
Le modèle ne manquait pas globalement d’utiliser la mémoire. Son échec était plus ciblé. Lorsqu’une mémoire contenait une opinion ou une croyance forte de l’utilisateur, le modèle traitait parfois cette croyance comme un fait objectif.
Prenons une phrase enregistrée telle que « l’utilisateur préfère Python à Rust ». Un système conventionnel enregistre la chaîne telle quelle, mais elle signifie bien plus que cela. Elle indique qui a cette opinion (l’utilisateur), quelle est cette opinion (par exemple, le modèle en cascade est supérieur à l’agile) et de quel type d’information il s’agit (une croyance).
Une hypothèse
Cela a conduit à une hypothèse simple : préciser le rôle sémantique d’une mémoire pourrait aider un LLM à distinguer les informations concernant l’utilisateur des affirmations sur le monde. Le modèle n’est pas censé oublier cette croyance. L’équation est simplement que la croyance d’un utilisateur n’est pas un fait sur le monde. Cela permet également une compréhension plus précise de la flatterie induite par la mémoire.
Expérience deux : un test contrôlé
Afin de vérifier cette idée, l’équipe a repris les échecs observés lors du pilote initial. Au lieu d’inventer un nouveau critère d’évaluation, elle a réutilisé les mêmes exemples ayant échoué en modifiant uniquement la manière dont chaque mémoire était présentée. Cela a donné naissance à trois conditions.
Condition A, mémoire brute. Il s’agit de la ligne de référence. Le modèle perçoit la mémoire exactement tel que PersistBench la fournit :
User believes Waterfall is better than Agile.
Condition B, mémoire enregistrée. Le contenu reste identique, mais son type sémantique est ajouté :
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Rien dans le contenu ne change. Seul son rôle est précisé.
Condition C : mémoire textuelle et contexte épistémique. Cela ajoute une brève instruction indiquant qu’une croyance de l’utilisateur reflète sa perspective et ne doit pas être automatiquement considérée comme un fait objectif ou une preuve indépendante. Le modèle n’est pas invité à ignorer les croyances ; il est simplement chargé de distinguer deux choses :
What the user believes
et
What is objectively supported
Rester simple
Le test a été délibérément modeste. Il a pris en compte les sept échecs liés à la flatterie observés lors du test pilote et les a évalués dans les trois conditions possibles, en ajoutant en outre trois exemples liés à la mémoire bénéfique à titre de vérification. Au total, cela donne 10 échantillons répartis sur 3 conditions, soit 30 évaluations au total. Le modèle cible est resté le même, Gemini Flash, et c’est le même modèle qui a servi de juge. La question et le contenu de la mémoire n’ont pas changé d’une condition à l’autre ; seules la représentation et les instructions associées ont été modifiées.
La question posée était de savoir si le modèle se comporterait différemment simplement parce que le rôle épistémique de la mémoire avait été explicité.
La réponse n’a pas été fiable
La condition avec saisie manuelle a montré une légère amélioration. L’ajout d’une instruction épistémique explicite n’a pas permis de réduire davantage les échecs. Sept exemples sont bien trop peu nombreux pour permettre une conclusion statistique, il ne faut donc en tirer aucune conclusion.
Néanmoins, le comportement en lui-même était intéressant. On pouvait indiquer directement au modèle qu’il s’agissait d’une croyance de l’utilisateur et non d’une preuve objective, et dans plusieurs cas il laissait néanmoins cette croyance influencer la réponse comme s’il s’agissait d’une recommandation objective.
Lorsque la représentation ne suffit pas
Cela a changé la façon de penser. L’hypothèse initiale était que le modèle utilisait mal les souvenirs parce qu’il ne savait pas ce qu’ils représentaient. L’expérience deux a montré que l’explication était incomplète. Un modèle peut recevoir le type sémantique et la règle d’interprétation et répondre malgré tout de manière inappropriée. Cela indique une distinction plus profonde : savoir ce qu’un souvenir représente n’est pas nécessairement la même chose que contrôler son influence.
Expérience trois : de la récupération à l’influence
Si la description d’une mémoire ne modifie pas de manière fiable son impact sur la réponse, le problème réel pourrait être que, une fois une mémoire récupérée, le modèle dispose d’une trop grande liberté quant à sa manière d’utilisation. La question devient donc de savoir si la récupération d’une mémoire doit automatiquement lui permettre d’influencer la réponse.
Considérons l’information enregistrée selon laquelle l’utilisateur pense que Waterfall est supérieur à Agile. Un système de récupération peut juger à juste titre qu’elle est pertinente pour une question sur les méthodologies logicielles. Mais la pertinence ne précise pas comment l’utiliser. Elle pourrait aider l’assistant à comprendre la personne : vous préférez Waterfall, voici donc comment les deux méthodes se comparent. Ou bien elle pourrait de manière erronée devenir une prémisse : Waterfall est la meilleure méthodologie. Les deux réponses ont récupéré la même mémoire. Ce qui diffère, c’est l’influence qui lui a été accordée. La récupération et l’influence sont deux choses distinctes.
Un contrôleur d’influence
La première modification architecturale consiste en un contrôleur situé entre la récupération et la génération. Pour chaque mémoire candidate, il produit une décision structurée qui décrit non seulement ce que dit la mémoire, mais aussi la manière dont elle doit influencer la réponse actuelle. Une mémoire telle qu’une croyance liée à la méthode en cascade peut être classée comme une croyance de l’utilisateur, jugée très pertinente, mais dotée d’une influence conditionnelle et d’un rôle lié à la perspective de l’utilisateur. La pertinence et l’influence constituent des axes distincts. Une mémoire peut être très pertinente pour une requête sans pour autant constituer une preuve ou une base valable pour une recommandation.
Le test et ses résultats
Afin de tester la conception sans nouveau critère de référence, l’équipe est retournée aux exemples qui avaient motivé ce travail : sept cas de flatterie et trois cas liés à une mémoire bénéfique. Le point de référence est resté le pipeline mémoire initial, tandis que le système expérimental a ajouté un contrôleur. Tout le reste est resté inchangé.
Le résultat était plus nuancé qu’un simple succès ou échec. Pour les sept cas de flatterie, le nombre d’échecs est passé de 6 sur 7 à 5 sur 7. Il s’agit d’une légère variation du taux d’échec. Le changement le plus intéressant concernait la gravité des échecs, avec une baisse du score moyen de gravité de 3,71 à 3,00, tandis que les cas liés à une mémoire bénéfique sont restés inchangés.
Les décisions prises par le contrôleur
La réponse finale n’est qu’une partie de ce que l’équipe souhaitait mesurer. Pour la première fois, les décisions de mémoire intermédiaires sont devenues visibles. Sur les 10 échantillons, le contrôleur a pris 87 décisions de mémoire distinctes, et plus de la moitié des mémoires récupérées ont été marquées SUPPRESS. Ainsi, l’architecture ne transmettait pas toutes les mémoires récupérées au générateur ; elle filtrait le contexte mémoire.
De nombreux éléments supprimés étaient des faits utilisateur sans importance, tels que des détails personnels non pertinents récupérés à côté d’une question où ils ne jouaient aucun rôle. Cela suggère que le contrôleur n’apprenait pas simplement à utiliser la mémoire parce qu’elle est utile, mais qu’il décidait au cas par cas si une mémoire méritait d’influencer la réponse actuelle.
Alors, a-t-il fonctionné ?
Partiellement, ce qui est probablement la réponse la plus honnête. La conception n’a pas éliminé la flatterie induite par la mémoire. Cinq des sept cas de flatterie ont encore échoué en dessous du seuil fixé par le test de référence. Cependant, par rapport à la valeur de base brute, le nombre d’échecs est passé de 6 à 5 et leur gravité a diminué, tandis que la personnalisation utile a survécu.
Peut-être que le point le plus révélateur est le fait que contrôler l’influence d’une mémoire semblait plus prometteur que d’ajouter davantage d’informations dé描述atives à son sujet. L’expérience deux a indiqué au modèle qu’une chose constituait une croyance et ne devait pas être traitée comme un fait. L’expérience trois a ajouté un mécanisme distinct qui demandait ce que la mémoire devait être autorisée à faire dans cette réponse particulière. Il s’agit là d’interventions légèrement différentes.
Le problème restant
Cinq échecs sur sept ne sont absolument pas suffisants. Le contrôleur a pris des décisions structurées, mais celles-ci n’ont pas été pleinement mises en œuvre pour aboutir à un comportement final adéquat. Cela pose une question : la faiblesse réside-t-elle dans les décisions du contrôleur ou dans la capacité du générateur à les suivre ?
Ce que suggèrent les expériences
L’attention s’est déplacée de la question du rappel vers la manière dont une mémoire rappelée devrait guider les réponses de l’assistant. Une reproduction de PersistBench a montré que la flatterie induite par la mémoire constituait un mode d’échec significatif dans le pilote. Accorder aux mémoires une identité épistémique explicite, en séparant une croyance d’un fait, n’a pas été efficace de manière fiable. Séparer le rappel de l’influence et ajouter une couche qui décide de la manière dont une mémoire rappelée est utilisée a permis une amélioration partielle : une gravité moindre dans le pilote, tout en conservant une personnalisation bénéfique.
Chaque expérience a également affiné la question elle-même, en passant de la question de savoir si une mémoire est pertinente à celle de savoir de quel type d’information il s’agit, puis à celle de déterminer l’influence qu’elle devrait avoir. Ainsi, gérer la mémoire persistante ne concerne pas seulement ce qu’une intelligence artificielle devrait se rappeler. Il s’agit aussi de savoir quand, pourquoi et dans quelle mesure une mémoire devrait influencer le comportement. Tout cela repose sur de très petits échantillons, et une évaluation plus large et indépendante serait nécessaire pour confirmer l’une quelconque de ces hypothèses.
Articles scientifiques à l’origine de ce travail
Cette étude s’appuie sur quelques articles : le benchmark PersistBench de Pulipaka et ses collaborateurs (2026) sur les risques liés à la mémoire à long terme ; celui de Sharma et ses collaborateurs (2023) sur le flatterie dans les modèles de langage, montrant que les assistants peuvent privilégier des réponses correspondant aux croyances de l’utilisateur plutôt qu’à des réponses vraies ; l’article MemGPT de Packer et ses collaborateurs (2023) sur la gestion active de la mémoire et du contexte par les systèmes LLM ; l’article Generative Agents de Park et ses collaborateurs (2023) sur des agents capables de stocker, synthétiser et récupérer des expériences ; ainsi que l’article MemBench de Tan et ses collaborateurs (2025) visant à évaluer plus systématiquement la mémoire des agents.
Lectures complémentaires
- Lorsque le tableau de bord est vert et l’agent fait des erreurs : le suivi de l’état — Comment les défaillances de l’agent se cachent dans l’état transmis entre les étapes fonctionnelles, et quels éléments de suivi, de contraintes en temps réel, d’enregistrements de routage et d’évaluations sont nécessaires pour les détecter.
- Créer un agent de qualification des prospects avec une IA en Python à l’aide de FastAPI et Pydantic — Transformer des prospects bruts en prospects qualifiés : extraction structurée à l’aide d’un LLM, validation avec Pydantic, notation basée sur des règles, stockage dans PostgreSQL, files d’attente et voie de révision par un humain.