La mémoire des agents IA n'est pas le RAG : comment séparer la mémoire, la récupération, l'état et le contexte

La mémoire des agents IA, la génération augmentée de récupération (RAG), l'état d'exécution et le contexte du modèle sont souvent abordés comme s'ils étaient interchangeables. Ils ne le sont pas. Les réduire à un seul concept rend les systèmes d'agents plus difficiles à appréhender, plus complexes à déboguer et plus susceptibles de devenir obsolètes ou non fiables.

L'erreur de catégorie : traiter tout élément d'apparence persistante comme de la mémoire

Une base de données vectorielle peut stocker des fragments de conversation. Un objet de session peut conserver les échanges récents. Une ligne de base de données peut enregistrer le statut actuel d'un flux de travail. Un outil de résumé peut compresser des étapes antérieures. Un moteur de recherche peut récupérer d'anciens éléments de preuve. Tous ces éléments peuvent donner l'impression qu'un agent « se souvient », mais ils ne partagent pas la même sémantique.

Cette distinction est essentielle, car les règles d'exactitude requises sont différentes. L'état actuel doit être faisant autorité et à jour. La mémoire nécessite des règles de cycle de vie pour l'écriture, la révision, l'oubli et la gestion des conflits. La récupération requiert une pertinence et une qualité de sélection des preuves. Le contexte exige une gestion rigoureuse du budget de jetons ainsi qu'une protection contre les éléments non pertinents ou contradictoires.

Une architecture à quatre couches : état, mémoire, récupération, contexte

1. État : ce qui est vrai actuellement

L'état appartient au système en cours d'exécution, et non aux souvenirs du modèle. Si une commande est annulée, un déploiement mis en pause, un droit d'accès révoqué ou une tâche passant de « en cours » à « approuvée », la valeur faisant autorité doit provenir du système qui détient cette information.

Une conception risquée consiste à laisser un résumé de conversation obsolète se substituer à l'état actuel. L'agent peut parfaitement se souvenir que la commande était active hier tout en étant dans l'erreur aujourd'hui. L'état nécessite donc une responsabilité clairement définie, un contrôle de version ou des horodatages le cas échéant, ainsi qu'un moyen de relire la source de vérité avant d'exécuter des actions critiques.

2. Mémoire : ce qui doit être conservé du passé

La mémoire ne se résume pas à « tout ce que nous pouvons stocker ». Une couche de mémoire utile détermine ce qui mérite d'être conservé, sous quelle forme, pour quelle durée, avec quelle provenance et sous quelles conditions ces informations doivent être révisées ou supprimées.

La recherche récente sur la mémoire des agents considère de plus en plus que le stockage brut des historiques de transcription est insuffisant. Les travaux de Microsoft sur PlugMem se concentrent sur la transformation des historiques d'interaction bruts en connaissances structurées et réutilisables. Memora dissocie le contenu stocké riche des abstractions plus légères et des indices de récupération, évitant ainsi aux systèmes à long terme d'avoir à trancher entre le niveau de détail et un accès évolutif.

3. Récupération : ce qui doit être sélectionné maintenant

La récupération est un mécanisme de sélection. Elle peut interroger des documents externes, des bases de connaissances internes, des mémoires stockées, des journaux, des graphes, des bases de données ou des sources composites. C'est généralement là qu'intervient le RAG : récupérer des éléments de preuve, intégrer les éléments sélectionnés dans l'entrée de travail du modèle, puis générer une réponse.

Ce mécanisme ne devient pas pour autant de la mémoire au seul motif que le corpus interrogé contient des interactions passées. Le même système de récupération peut chercher des documents de politique que l'agent n'a jamais expérimentés, des données produit issues d'un autre système ou des décisions antérieures d'un utilisateur. La récupération décrit la manière dont les informations sont sélectionnées ; la mémoire décrit la raison pour laquelle certaines informations persistent dans le temps et la façon dont cette persistance est encadrée.

4. Contexte : ce que le modèle peut réellement utiliser à l'instant présent

Le contexte est la couche orientée vers le modèle. Anthropic décrit l'ingénierie de contexte comme le fait de déterminer quelle configuration de contexte est la plus susceptible de produire le comportement souhaité, le contexte étant les jetons mis à la disposition du modèle pendant la génération. Les recommandations d'OpenAI concernant la mémoire de session traitent de manière similaire l'élagage et la compression comme des techniques de gestion de contexte pour les interactions d'agents de longue durée.

C'est pourquoi un système peut disposer d'une excellente mémoire et pourtant échouer. La mémoire pertinente peut exister sans être récupérée. Elle peut être récupérée mais insérée dans le contexte aux côtés d'un texte contradictoire plus influent. Elle peut être compressée au point où le détail décisif disparaît. Ou le modèle peut recevoir une telle quantité d'éléments que les preuves utiles se trouvent diluées dans le bruit.

Comment interagissent les couches

Pourquoi le RAG n'est pas de la mémoire

Le test le plus simple est le suivant : un système RAG peut récupérer des informations que l'agent n'a jamais vues auparavant. Cela démontre à lui seul que la récupération et la mémoire sont des abstractions distinctes.

Le RAG répond à la question : « Quels éléments de preuve dois-je récupérer ? » Un système de mémoire doit en outre répondre à des questions telles que : « Cet événement doit-il devenir une connaissance durable ? », « Cette nouvelle information remplace-t-elle un souvenir antérieur ? », « Peut-on encore se fier à ce souvenir ? », « Qui a l'autorisation de le lire ? » et « Quand doit-il être oublié ? »

Le test de séparation à quatre couches

Lorsqu'une fonctionnalité est qualifiée de « mémoire », posez-vous les quatre questions suivantes. Les réponses indiquent généralement quelle couche est réellement concernée.

Un même composant peut participer à plusieurs couches. Une base de données peut stocker à la fois l'état et la mémoire. Un index vectoriel peut récupérer à la fois des connaissances externes et des souvenirs. La séparation est d'ordre sémantique, et pas nécessairement physique.

Modes de défaillance causés par la fusion des couches

Que doit-on mémoriser, récupérer, recalculer ou relire ?

Un système de mémoire a besoin d'une politique d'écriture, pas seulement d'une politique de récupération

Les discussions sur l'architecture RAG se concentrent souvent sur la qualité de la récupération : découpage (chunking), plongements (embeddings), réordonnancement (reranking), recherche hybride et ancrage (grounding). La mémoire à long terme introduit un autre aspect du problème : qu'est-ce qui est autorisé à entrer dans le stockage persistant en premier lieu ?

Pour une mémoire d'agent durable, une politique d'écriture pratique doit classifier la mémoire candidate, préserver la provenance, détecter les conflits avec les entrées existantes, distinguer l'observation de l'inférence, définir la sensibilité et la portée d'accès, et décider si l'information doit expirer, être révisée ou nécessiter une confirmation de l'utilisateur.

La provenance est le pont entre la mémoire et les preuves fiables

Une entrée de mémoire devrait idéalement conserver suffisamment de provenance pour répondre à ces questions : d'où cela vient-il, quand cela a-t-il été observé, qui ou quoi l'a affirmé, cela a-t-il été fourni par l'utilisateur ou déduit par le modèle, quelle source l'a étayé, et quelque chose l'a-t-il remplacé ?

Sans provenance, une mémoire compressée peut devenir plus autoritaire que la preuve qui l'a créée. Cela est particulièrement risqué pour les agents à longue durée de vie où les résumés et les abstractions sont réutilisés à plusieurs reprises. Le système peut préserver la conclusion tout en perdant les conditions dans lesquelles cette conclusion était valide.

Plus de mémoire ne signifie pas plus de contexte

Un agent à longue durée de vie peut accumuler des gigaoctets d'état, d'historique, de documents et d'informations apprises. Le modèle n'a pas besoin — et ne devrait généralement pas recevoir — de la totalité de ces éléments à chaque étape. Le but de la récupération, du résumé, du compactage et de la mémoire structurée est de convertir un vaste espace d'informations persistantes en un contexte de travail restreint et pertinent.

C'est aussi pourquoi des fenêtres de contexte plus larges n'éliminent pas l'architecture de mémoire. La capacité réduit une partie de la pression, mais elle ne résout pas la fraîcheur, l'autorité, les preuves contradictoires, le périmètre de confidentialité, la qualité d'écriture, la révision ou la décision de ce qui mérite de l'attention.

Liste de contrôle pour la conception en production

• Définir quels systèmes détiennent l'état d'exécution faisant autorité.
• Définir quelles informations sont éligibles pour devenir une mémoire durable.
• Garder distincts les faits fournis par l'utilisateur, les preuves externes et les inférences du modèle.
• Associer des horodatages, la provenance, la portée et la sémantique de révision aux mémoires importantes.
• Considérer la pertinence de la récupération comme différente de l'autorité factuelle.
• Construire le contexte de manière intentionnelle au lieu d'injecter tous les éléments récupérés.
• Relire les faits volatils au lieu de faire confiance aux anciennes mémoires.
• Recalculer les valeurs dérivées peu coûteuses lorsque l'obsolescence serait pénalisante.
• Tester les écritures en mémoire aussi soigneusement que les lectures.
• Mesurer les échecs séparément : erreur d'état, erreur de mémoire, erreur de récupération, erreur de construction de contexte, erreur de raisonnement et erreur d'action.

Qu'est-ce qui changerait cette réponse ?

La frontière entre ces couches peut évoluer à mesure que les plateformes d'agents se développent. Un fournisseur peut proposer un service de mémoire géré qui effectue en interne le stockage, la révision, la récupération, le résumé et la construction de contexte. Cela peut simplifier les composants d'implémentation, mais cela n'élimine pas les questions architecturales. Vous devez toujours savoir si un élément renvoyé est un état actuel, une mémoire persistante, une preuve récupérée ou simplement du texte placé dans le contexte.

La recommandation changerait également pour les systèmes sans continuité inter-sessions, les systèmes où chaque tâche démarre à partir d'un corpus immuable propre, ou les flux de travail étroitement délimités où tout l'état pertinent tient en toute sécurité dans un seul appel. Dans ces cas, une couche de mémoire à long terme dédiée peut ajouter de la complexité sans apporter suffisamment de valeur.

Limites

La terminologie des systèmes d'agents évolue encore rapidement. Certains frameworks qualifient l'historique de conversation de « mémoire », d'autres utilisent « session », « point de contrôle », « magasin », « contexte » ou « état ». Les systèmes de recherche définissent également la mémoire à différents niveaux, de la recherche persistante à l'adaptation interne apprise. Le modèle présenté dans cet article sépare délibérément les responsabilités opérationnelles plutôt que de tenter d'imposer un vocabulaire universel.

Conclusion

La question pertinente n'est pas « Cet agent a-t-il de la mémoire ? » Elle est plutôt : Qu'est-ce que l'état, qu'est-ce qui persiste de l'expérience, comment les informations pertinentes sont-elles récupérées, et qu'est-ce qui parvient finalement au modèle sous forme de contexte ?

Une fois ces responsabilités séparées, les choix de conception deviennent plus faciles à tester. Les faits obsolètes peuvent être attribués à la propriété de l'état. Un mauvais rappel peut être imputé au cycle de vie de la mémoire ou à la récupération. Les invites surchargées peuvent être reliées à la construction du contexte. Les hallucinations persistantes peuvent être tracées jusqu'à la politique d'écriture et la provenance. Le RAG demeure un outil important, mais il ne constitue qu'un élément parmi d'autres d'une architecture d'agent fiable et durable.

FAQ

Glossaire

Sources primaires et lectures complémentaires