Un agent ne devient pas « intelligent » parce qu’il conserve toutes les conversations. Une bonne mémoire est un système de sélection : elle sait quoi garder, où le ranger, quand le relire et quand l’oublier. Sans ces règles, l’agent accumule du bruit, réutilise des informations périmées et peut mélanger les données de plusieurs utilisateurs.
Les quatre notions à ne pas confondre
- L’état d’exécution contient ce dont le workflow a besoin maintenant : étape courante, résultats d’outils, erreurs et décisions intermédiaires.
- La mémoire de session conserve les éléments utiles pendant une conversation : objectif, contraintes et derniers échanges.
- La mémoire long terme garde des faits réutilisables lors de sessions futures : préférences validées, décisions ou connaissances métier.
- La mémoire partagée met certains éléments à disposition de plusieurs agents. Elle exige des droits d’accès et une provenance explicites.
L’historique brut n’est donc pas la mémoire. Il constitue seulement une source possible à partir de laquelle extraire des souvenirs.
Une architecture simple et robuste
Stockez l’état opérationnel dans une base structurée. Placez les textes destinés à une recherche sémantique dans un index vectoriel, mais gardez leurs identifiants, dates, propriétaires et niveaux de confiance dans une base transactionnelle. Avant chaque appel au modèle, un composant de récupération sélectionne quelques souvenirs selon la pertinence, la récence, la portée et le budget de tokens.
À l’écriture, n’enregistrez pas chaque phrase. Une politique peut exiger qu’un fait soit explicite, utile à l’avenir et suffisamment fiable. À la lecture, filtrez d’abord par utilisateur, organisation, agent et durée de validité, puis classez les candidats.
Exemple de cycle de mémoire
Un utilisateur demande : « Pour les prochains rapports, utilise des tableaux courts. » L’agent propose d’en faire une préférence durable. Après validation, il stocke le fait avec sa source, sa date et une règle d’expiration. Lors d’une nouvelle session, cette préférence est récupérée, mais seulement pour cet utilisateur. Si celui-ci la corrige, la nouvelle version remplace l’ancienne au lieu de créer deux souvenirs contradictoires.
Mémoire partagée et sécurité
Un espace commun ne doit jamais devenir un pot de données global. Appliquez une isolation multi-tenant, des autorisations par type de souvenir et un journal des lectures et écritures. Les secrets, données sensibles et contenus injectés par des sources externes doivent être exclus ou chiffrés. Une information issue du Web ne doit pas acquérir le même niveau de confiance qu’une décision humaine validée.
Comment évaluer la mémoire
Mesurez le taux de récupération utile, les souvenirs manqués, les faux souvenirs, la fraîcheur et le coût ajouté au contexte. Créez des scénarios où une préférence change, où deux utilisateurs portent le même nom et où un fait expire. Vérifiez aussi que la réponse reste correcte lorsque la mémoire ne retourne rien.
Checklist
- Séparer état, session, long terme et partage.
- Définir des politiques d’écriture, lecture, correction et suppression.
- Associer provenance, propriétaire, date et confiance à chaque souvenir.
- Limiter le nombre de souvenirs injectés dans le prompt.
- Tester l’isolation des utilisateurs et l’oubli effectif.
FAQ
Faut-il obligatoirement une base vectorielle ?
Non. Une base relationnelle suffit souvent pour des préférences et faits structurés. Le vectoriel devient utile pour retrouver des passages proches sémantiquement.
Peut-on résumer tout l’historique ?
Oui pour compacter une session, mais un résumé peut perdre ou déformer des détails. Conservez la provenance et régénérez-le lorsque les faits importants changent.
Quelle durée de conservation choisir ?
La plus courte compatible avec l’usage. Prévoyez expiration, suppression à la demande et règles distinctes selon la sensibilité des données.