Mémoire des agents IA : que garder, compresser et jeter
Dans un appel de modèle, il n'y a pas de mémoire. Chaque tour est une requête neuve, et le modèle ne sait que ce que vous avez assemblé cette fois-ci. Tout ce que l'on décrit comme un agent qui oublie, ou qui se dégrade sur une longue exécution, est une décision prise par votre code sur ce qu'il transporte.
Une fois cela accepté, la conception de la mémoire devient un problème d'ingénierie familier : qu'est-ce qui est toujours pertinent, récemment pertinent, résumable, et qu'est-ce qu'il vaut mieux aller rechercher que stocker.
Les quatre couches#
| Couche | Contenu | Élaguée ? | Taille typique |
|---|---|---|---|
| Épinglée | Objectif, contraintes, identité, politique | Jamais | 200–500 tokens |
| Récente | Derniers tours mot à mot, avec résultats | Fenêtre glissante | 2–5 tours |
| Compressée | Tours anciens en notes factuelles | Réécrite quand elle grossit | Moins de 500 tokens |
| Récupérée | Documents ramenés pour cette étape | Jetée après usage | Par étape |
Compressez des faits, pas de la prose#
L'erreur habituelle est de résumer les tours anciens sous forme de récit : la cliente a demandé sa commande et l'agent a vérifié. Cela se lit bien et n'aide à rien. Compressez vers les faits dont une étape ultérieure pourrait avoir besoin : commande 4471, statut expédié, remboursement demandé, politique 30 jours, rien de remboursé. Structuré, vérifiable et dix fois plus petit.
Compressez à un seuil, pas à chaque tour. Résumer des résumés fait disparaître les détails en silence.
Récupérer n'est pas mémoriser#
Les documents tirés d'une base de connaissances appartiennent à l'étape qui en avait besoin. Les garder ensuite dans le contexte est le plus court chemin vers une exécution gonflée, chère et distraite. Ramener, utiliser, citer, jeter — et si une étape ultérieure a besoin du même fait, le ramener à nouveau. Récupérer coûte peu ; un contexte plein de vieux documents non.
Mémoire persistante entre sessions#
Les agents de longue vie accumulent des faits utiles sur une personne ou un compte : préférences, décisions passées, contraintes stables. Stockez-les volontairement, dans un petit enregistrement structuré avec une étape d'écriture explicite, plutôt que de laisser l'historique enfler. Trois règles gardent cela sain : n'écrire que des faits sur lesquels une exécution future agirait, toujours consigner l'origine, et donner à chaque fait une échéance.
- Écrire volontairement : un appel d'outil, pas un effet de bord.
- Stocker la source et la date à côté de chaque fait.
- Plafonner la taille et faire expirer l'inutilisé.
- Laisser la personne voir et corriger ce qui est stocké sur elle.
Symptômes et causes#
| Symptôme | Cause habituelle |
|---|---|
| Oublie une contrainte du début | Non épinglée, élaguée avec l'historique |
| La qualité baisse après quelques étapes | Contexte dilué par de vieilles sorties |
| Répète une étape déjà faite | Résultat compressé sans marqueur d'achèvement |
| Le coût monte avec la longueur | Les documents récupérés s'accumulent |
| Affirme du périmé avec assurance | Mémoire persistante sans échéance ni origine |
Questions fréquentes
Quelle part d'historique garder mot à mot ?
Trois à cinq tours couvrent l'essentiel du raisonnement sans dominer le contexte. Gardez les résultats attachés à leur appel et compressez le plus ancien en faits structurés plutôt que de le supprimer en silence.
Faut-il une base vectorielle pour la mémoire ?
Pour récupérer des documents, souvent oui. Pour l'état d'une exécution, non : c'est un petit objet structuré dans votre stockage. Confondre les deux donne une machine à états floue et un index sans focus.
Comment éviter une mémoire persistante périmée ?
Donnez à chaque fait une source, une date et une échéance, et faites préférer le frais. Montrez l'enregistrement à la personne pour que les erreurs soient corrigées au lieu d'être répétées.
mémoire des agents iagestion du contexterésumé de conversationmémoire persistantefenêtre de contexte llm
