Mémoire des agents IA : promesses, architecture et mesure en production

Les points essentiels

• Dans la grille de cet article, la mémoire peut désigner le contexte courant, un historique, une base documentaire ou des faits persistants : ces mécanismes seront évalués séparément.
• Ajouter tout l’historique n’améliore pas automatiquement la réponse et peut diluer les informations utiles.^[5][6][7]
• Une mémoire persistante nécessite des règles d’écriture, de correction, d’oubli, de portée et de permission.^[2][4]
• Dans ce guide, le RAG désigne la recherche de sources et la mémoire la conservation d’un état ou d’une expérience ; les deux peuvent se compléter.
• Le gain doit être mesuré sur la tâche, après coût de récupération, erreurs et maintenance.

Une seule expression pour plusieurs mécanismes

Dire qu’un agent “se souvient” peut signifier qu’il relit la conversation, retrouve un document ou conserve une préférence entre deux sessions. Ces comportements possèdent des risques et des tests différents.

Une architecture utile nomme chaque mémoire, sa source, sa durée, ses utilisateurs et la manière dont une information peut être corrigée ou supprimée.

Grille Contexte Lab : mémoire de travail, persistante et procédurale

RAG ou mémoire persistante : deux fonctions différentes

Dans le vocabulaire de ce guide, la recherche augmentée récupère des passages dans un corpus afin d’éclairer une réponse, tandis qu’une mémoire persistante conserve un élément issu d’une interaction ou d’une tâche pour le réutiliser plus tard.

Le RAG ne doit pas devenir une mémoire personnelle par accident, et la mémoire ne doit pas remplacer les documents de référence. Un fait métier officiel reste mieux géré dans son système source.^[2][4]

• Utiliser le RAG pour retrouver une politique ou une fiche produit.
• Utiliser un état de tâche pour suivre les étapes d’un dossier.
• Conserver une préférence seulement avec finalité et portée définies.
• Stocker les faits officiels dans le système de référence.
• Citer et dater ce qui provient d’un document.
• Prévoir l’absence de résultat plutôt que remplir le vide.

Décider ce qui mérite d’être mémorisé

N’enregistrez pas automatiquement chaque message. Définissez une règle d’écriture pour contrôler la catégorie, la source, la confiance, la durée et la personne ou l’organisation concernée.

Pour les éléments importants, une confirmation ou une synchronisation avec le système de référence est préférable à une déduction silencieuse du modèle.

Corriger, expirer et oublier

• Associer une durée à chaque catégorie de mémoire.^[2][4]
• Permettre la consultation et la correction par les personnes habilitées.^[2][4]
• Appliquer l’effacement aux index et caches selon le cadre, les exceptions et les cycles de sauvegarde documentés.^[2][4]
• Éviter qu’un résumé ancien supplante une source plus récente.^[2][4]
• Isoler utilisateurs, clients et environnements.^[2][4]
• Journaliser les écritures et lectures sensibles.^[2][4]

Les défaillances à tester en production

L’expression “context rot” décrit une dégradation observée dans certains modèles ou tests lorsque le contexte grossit ou se contredit. Ne la supposez pas universelle : mesurez le comportement du modèle et de la tâche, puis testez sélection, hiérarchie et fraîcheur.^[5][6][7]

• Préférence attribuée à la mauvaise personne.
• Résumé ancien réutilisé malgré une correction.
• Document accessible par un utilisateur non autorisé.
• Instruction hostile enregistrée puis répétée.^[3]
• Réponse ralentie par une récupération trop large.
• Absence de trace sur l’origine d’un souvenir.

Passer du prototype à une mémoire gouvernée

• Définir les catégories et leur finalité.
• Choisir les systèmes de référence.
• Créer des règles d’écriture, lecture, correction et expiration.
• Tester confusion, contradiction, suppression et accès croisé.
• Déployer d’abord une mémoire limitée et visible.
• Réévaluer le bénéfice avant d’ajouter une nouvelle catégorie.

Vérifier les gains sans métrique décorative

• Réussite de la tâche avec et sans mémoire.
• Pertinence et fraîcheur des éléments retrouvés.
• Erreurs causées par un souvenir inexact.
• Temps économisé moins temps de correction.
• Latence et coût de stockage et récupération.
• Demandes de correction, suppression et incidents d’accès.

Séparer une démonstration convaincante d’un gain en production

Définir un schéma explicite pour chaque souvenir

• Sujet ou entité concernée.
• Fait, préférence, état ou procédure.
• Source et moment de collecte.
• Niveau de confiance et validation éventuelle.
• Portée utilisateur, équipe ou organisation.
• Durée, date d’expiration et motif.
• Lien vers correction, suppression et journal.

Résoudre les conflits sans laisser le modèle choisir silencieusement

Exercer la suppression de bout en bout

Créez un souvenir de test, vérifiez ses copies dans index, cache, export et journal, demandez sa suppression puis contrôlez qu’il n’est plus récupéré. Documentez les éléments qui doivent rester pour sécurité ou preuve, leur accès et leur durée distincte.^[2][4]

Questions fréquentes