Un agent dépourvu de persistance entre les sessions recommence chaque fois à partir du contexte qui lui est fourni. La persistance peut réduire les mises en contexte répétées, mais elle crée aussi des obligations en matière de confidentialité, d’exactitude, d’isolation et de suppression.
C’est le problème de la mémoire. Les fenêtres de contexte gèrent la conversation actuelle. La mémoire à long terme — entre les sessions, sur plusieurs jours, sur plusieurs mois — nécessite sa propre architecture. Et c’est plus difficile qu’il n’y paraît.
Cet article présente une conception de référence à tester, et non une implémentation certifiée. Les équipes produit doivent vérifier les contrôles d’accès, la correction, la conservation, la suppression, la reprise et la qualité de la récupération dans leur propre pile technique.
Ce que signifie « mémoire »
Une vue simpliste : la mémoire = « le modèle se souvient des choses entre les conversations ». La réalité est plus nuancée. Les sciences cognitives distinguent différents types de mémoire, et la mémoire des agents d’IA bénéficie d’une distinction similaire :
Mémoire de travail. La conversation actuelle. Elle est maintenue dans la fenêtre de contexte. Elle est perdue lorsque la conversation se termine (sauf si elle est persistée).
Mémoire épisodique. Des événements passés spécifiques. « Mardi dernier, nous avons discuté de X. » « Il y a trois mois, vous avez décidé Y. »
Mémoire sémantique. Des faits généraux. « Votre nom est Alice. » « Vous préférez des réponses concises. » « Votre entreprise est à Tallinn. »
Mémoire procédurale. Comment faire les choses. « Lorsque l’utilisateur demande une réunion, utilisez ce modèle. » « Lorsque le client est de niveau X, suivez le processus Y. »
Différents types de mémoire servent différentes fonctions. Utilisez uniquement les couches que votre produit peut justifier et exploiter ; stocker plus n’est pas automatiquement meilleur.
Ce que la mémoire doit accomplir
Avant l’architecture, définissez les objectifs :
Continuité. L’agent reprend là où il s’était arrêté. Pas besoin de se présenter à chaque session.
Personnalisation. L’agent applique vos préférences sans qu’on le lui demande. Il écrit dans votre voix, utilise vos outils et fait référence à votre équipe.
Préservation du contexte. Les décisions des conversations passées éclairent les conversations actuelles. « Nous avons décidé X le mois dernier » doit être mémorisé.
Réutilisation des préférences confirmées. Le système peut réappliquer une préférence explicite ou vérifiée dans les périmètres où elle est valide. La répétition seule ne prouve pas qu’un outil, une langue ou un comportement devrait devenir la norme par défaut.
Confidentialité et oubli. Ce qui est mémorisé, ce qui ne l’est pas, ce qui est supprimé. Tant pour la confiance des utilisateurs que pour la conformité légale.
Ces objectifs peuvent entrer en conflit. La continuité peut bénéficier d’une persistance sélectionnée, tandis que la confidentialité et l’exactitude favorisent la minimisation, les limites de finalité, la correction et la suppression. L’architecture doit rendre ces compromis explicites.
L’architecture
Une architecture en couches typique :
┌─────────────────────────────────────┐
│ Mémoire de travail (en contexte) │ Conversation actuelle
├─────────────────────────────────────┤
│ Mémoire de session (récente) │ N dernières conversations
├─────────────────────────────────────┤
│ Mémoire épisodique (long terme) │ Événements passés spécifiques
├─────────────────────────────────────┤
│ Mémoire sémantique (faits) │ Faits stables sur l’utilisateur
├─────────────────────────────────────┤
│ Mémoire procédurale (préférences) │ Comment se comporter pour cet utilisateur
└─────────────────────────────────────┘
Chaque couche nécessite un comportement explicite de stockage, de récupération, d’accès, de provenance, de correction, de conservation et de suppression ; plusieurs couches logiques peuvent partager un magasin physique.
Nous allons passer en revue chacune d’elles.
Couche 1 : Mémoire de travail
Déjà couverte dans L’ingénierie du contexte. Il s’agit de la conversation actuelle dans le contexte. Pour les conversations multi-tours, un contexte hiérarchisé avec les tours récents en texte intégral et les tours plus anciens résumés.
Un transfert vers la mémoire à long terme peut intervenir lors d’un point de contrôle explicite, d’un événement durable ou à la fin d’une session. Comme une session peut se terminer brutalement, ne persistez que les candidats approuvés et rendez l’état d’écriture observable, au lieu de supposer qu’un gestionnaire de fin de session s’exécutera toujours.
Couche 2 : Mémoire de session
Des résumés des sessions récentes peuvent être conservés avec un détail limité lorsque le produit a une finalité justifiée. Tout nombre, tel que les dix dernières conversations, est une entrée de politique illustrative plutôt qu’une valeur par défaut.
Implémentation : un résumé par session, stocké avec l’horodatage et le sujet. Lorsque l’utilisateur revient, l’agent dispose d’une référence rapide sur ce qui s’est passé récemment.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
Lors d’une nouvelle session, un sous-ensemble autorisé de résumés récents peut être chargé après des tests de qualité de récupération, de pertinence, de budget de tokens et de confidentialité. Ne chargez pas automatiquement un nombre fixe dans chaque contexte par défaut.
Il s’agit d’une forme relativement simple de mémoire inter-sessions, mais elle nécessite toujours une isolation, la provenance, la correction, le cycle de vie et des tests de récupération.
Couche 3 : Mémoire épisodique
Des événements passés spécifiques dignes d’être mémorisés à long terme. Décisions, jalons, conversations importantes.
Ceux-ci sont extraits des sessions lorsqu’ils sont notables. Ils sont stockés avec des métadonnées riches.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Récupération : lorsque cela est pertinent pour la conversation actuelle, l’agent récupère les épisodes associés. Par recherche sémantique (calculer le plongement vectoriel de la requête actuelle, trouver les épisodes correspondants), par correspondance de sujet ou par requêtes temporelles (« qu’est-il arrivé le mois dernier ? »).
Le défi consiste à décider ce qui constitue un épisode digne d’être mémorisé. Un schéma candidat consiste à faire proposer par un modèle les décisions, engagements ou jalons à un point de contrôle approuvé, avec les extraits sources et des règles de confirmation. Une étiquette d’importance générée par le modèle n’est pas une autorité pour persister des données personnelles.
Couche 4 : Mémoire sémantique
Des faits stables sur l’utilisateur qui doivent toujours être disponibles. « Alice est la PDG d’Acme. Elle préfère un style de communication concis. Elle travaille dans le fuseau horaire de Tallinn. »
Ceux-ci sont moins volumineux que les épisodes mais plus fréquemment récupérés. Ils forment le « modèle de l’utilisateur » de l’agent.
Implémentation : un profil structuré.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Les mises à jour interviennent lorsque l’agent apprend de nouveaux faits. Après une session, un LLM repère les nouveaux faits stables et les propose ; ils sont soit fusionnés automatiquement, soit placés dans une file d’attente pour examen.
Point important : les faits sémantiques doivent être fiables et stables. Un commentaire anodin dans une conversation (« J’essaierai peut-être Python ») ne devrait pas devenir un fait sémantique (« Alice préfère Python »). La barre est plus haute.
Un flux de travail de confiance purement illustratif, qui nécessite toujours la provenance et l’étalonnage :
- Inféré une fois : candidat uniquement, avec l’extrait source et aucun effet comportemental automatique.
- Explicitement déclaré : candidat pour le périmètre indiqué ; confirmer avant toute réutilisation conséquente.
- Explicitement confirmé : stocké avec la provenance, le périmètre, la date d’examen et les contrôles utilisateur.
Cela empêche l’agent d’apprendre des faits erronés à partir de commentaires anodins.
Couche 5 : Mémoire procédurale
Comment l’agent doit se comporter pour cet utilisateur. Flux de travail, modèles, préférences pour des actions spécifiques.
Exemples :
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Ce sont des schémas de comportement que l’agent suit lorsque des tâches pertinentes se présentent.
Les mises à jour peuvent provenir d’une instruction explicite ou d’un comportement répété. Un comportement récurrent peut déclencher une demande de confirmation, mais ne doit pas créer silencieusement une procédure durable.
Choix de stockage
Où la mémoire réside-t-elle ?
Base de données SQL. Fiable, interrogeable et bien maîtrisée. Chaque type de mémoire correspond à une table ; les jointures servent à la récupération. Elle convient aux schémas d’accès structurés.
Base de données vectorielle. Elle sert à la récupération sémantique des épisodes (« trouver des souvenirs liés à ce sujet »). Les épisodes sont convertis en plongements vectoriels, puis récupérés par similarité.
Combinaison. SQL associé à un index vectoriel est une option lorsque des accès structurés et sémantiques sont nécessaires. La double représentation alourdit les obligations de synchronisation et de suppression ; comparez-la donc à un magasin plus simple.
Outils de mémoire spécialisés. Mem0, Letta (anciennement MemGPT) et Zep sont des couches de mémoire conçues spécialement pour les agents. Elles méritent d’être envisagées si vous recherchez une abstraction de plus haut niveau.
Commencez par le magasin le plus petit qui satisfait l’accès structuré, la récupération sémantique, l’isolation par locataire, la provenance, la correction, la conservation, la suppression, ainsi que les tests de sauvegarde et de restauration. SQL, un index vectoriel, les deux ou une couche spécialisée peuvent convenir ; comparez la charge opérationnelle et de migration plutôt que de supposer un choix par défaut de l’équipe.
Schémas de récupération
Comment l’agent obtient-il la mémoire dans le contexte ?
Schéma 1 : chargement automatique au début de la session
Lorsqu’une nouvelle session commence, chargez automatiquement :
- Le profil sémantique de l’utilisateur.
- Les N résumés de sessions les plus récents.
- Tout engagement ou suivi en cours.
C’est le contexte de base dont dispose l’agent lorsque l’utilisateur se présente.
Schéma 2 : récupération pilotée par la requête
Lorsque le message de l’utilisateur évoque des sujets passés, récupérez les épisodes pertinents.
Exemple : l’utilisateur demande « quelle était la conclusion de notre discussion sur la base de données ? » L’agent recherche « base de données » dans les épisodes et récupère celui qui est pertinent.
Mise en œuvre : générez le plongement vectoriel du message de l’utilisateur, recherchez les épisodes similaires et ajoutez-les au contexte.
Schéma 3 : outils de mémoire explicites
L’agent dispose d’outils pour interroger la mémoire :
search_episodes(query): trouver des événements passés spécifiques.get_user_profile(): extraire le profil sémantique.list_open_items(): engagements en attente.
L’agent décide quand appeler ces outils en fonction de la conversation.
Schéma 4 : enrichissement de la mémoire en arrière-plan
Un processus en arrière-plan examine périodiquement la mémoire et :
- Regroupe les épisodes liés en thèmes.
- Met à jour la confiance sur les faits.
- Fait décroître les anciennes mémoires qui n’ont pas été consultées.
C’est la « maintenance de la mémoire » — maintenir le magasin de mémoire utile au fil du temps.
Écriture de la mémoire
Quand la mémoire est-elle écrite ?
Extraction au point de contrôle ou en fin de session
Une approche par lots, soumise à des tests de livraison durable et d’interruption brutale. Lors d’un point de contrôle approuvé ou à la fin d’une session :
- Un LLM analyse la conversation.
- Extrait :
- Résumé de session.
- Événements notables (pour la mémoire épisodique).
- Nouveaux faits (pour la mémoire sémantique).
- Signaux de préférence (pour la mémoire procédurale).
- Met à jour et stocke.
Le traitement par lots peut réduire le travail effectué pendant la session, mais aussi perdre des mises à jour lorsque celle-ci se termine de façon inattendue et retarder les corrections. Mesurez ces deux comportements et utilisez une tâche durable lorsque la persistance est nécessaire.
Prompt pour l’extraction :
Analysez cette conversation. Produisez un JSON avec :
1. summary : résumé en 2 à 3 phrases de ce qui s’est passé.
2. notable_events : tableau d’événements marquants à retenir (décisions prises, jalons, contexte important).
3. new_facts : tableau de faits stables appris sur l’utilisateur (à inclure uniquement si vous avez une forte confiance).
4. preference_signals : tableau des préférences observées (uniquement si exprimées clairement ou répétées).
5. open_items : tableau d’éléments non résolus que l’utilisateur pourrait souhaiter revisiter.
Soyez prudent. N’incluez que les éléments pour lesquels votre confiance est élevée. Il vaut mieux omettre quelque chose que de halluciner.
Mises à jour en temps réel pour les faits de grande valeur
Pour certains faits, attendre la fin de session est une erreur. Si un utilisateur dit « en fait, je m’appelle Alex, pas Alice » — la correction doit être appliquée immédiatement.
Une approche consiste à demander à l’agent de détecter en temps réel les corrections explicites ou les nouveaux faits importants, puis de mettre directement la mémoire à jour.
Cela nécessite une conception soignée — le LLM pourrait « apprendre » de mauvais faits. Certaines équipes exigent la confirmation utilisateur avant d’appliquer des mises à jour en temps réel.
Mises à jour initiées par l’utilisateur
L’utilisateur peut explicitement dire à l’agent ce qu’il doit retenir :
- « Veuillez vous souvenir que je préfère X. »
- « Oubliez ce que j’ai dit sur Y. »
- « Faites toujours Z. »
Ceux-ci doivent être des contrôles de première classe. Démarrez l’action demandée immédiatement, affichez son périmètre et son état, et expliquez toute conservation légale ou expiration de sauvegarde qui empêche de promettre une suppression instantanée et universelle. Une déclaration explicite est une forte provenance, pas la preuve que chaque périmètre inféré est correct.
Un outil spécifique que l’agent peut proposer :
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
Donner aux utilisateurs ce contrôle renforce la confiance.
Oubli et décroissance
Une mémoire sans limites crée des risques en matière de récupération, de coût, de confidentialité et d’exactitude. Un cycle de vie documenté est essentiel ; la diminution progressive de la priorité au fil du temps est une option, mais ne remplace ni la conservation ni la suppression requises.
Décroissance basée sur le temps
Les mémoires plus anciennes sont moins susceptibles d’être récupérées. Implémentation :
- Calculez le score de récupération avec
relevance * recency_decay. - Les anciennes mémoires disparaissent de fait, sauf référence explicite.
Conservation basée sur l’importance
Les épisodes importants sont conservés plus longtemps ; les triviaux décroissent plus vite.
- Étiquetez les épisodes avec une importance au moment de l’écriture.
- Événements à haute valeur : une période de conservation spécifique à la finalité avec un propriétaire et une date d’examen ; ne définissez pas par défaut une conservation indéfinie.
- Événements routiniers : décroissance sur plusieurs mois.
Oubli initié par l’utilisateur
L’utilisateur peut demander que des mémoires spécifiques soient supprimées.
- Faits spécifiques.
- Périodes de temps spécifiques.
- Sujets spécifiques.
Mise en œuvre : un flux de suppression qui efface l’enregistrement principal ainsi que tous les fragments, plongements vectoriels, résumés, index, caches, exports et tâches en attente qui en dérivent. Un marqueur de suppression peut empêcher la réingestion, mais masquer un enregistrement ne revient pas à le supprimer. Définissez l’expiration des sauvegardes et vérifiez que les données supprimées ne réapparaissent pas après une restauration.
Suppression pilotée par la conformité
Les exigences légales peuvent imposer l’effacement ou la conservation. L’article 17 du RGPD définit un droit à l’effacement avec des exceptions ; les juristes doivent le mettre en correspondance, ainsi que les autres règles applicables, avec le produit, la juridiction et le rôle à l’égard des données.
- Demande de suppression d’un compte utilisateur → lancez le flux de restriction ou de suppression examiné dans tous les magasins concernés et indiquez les exceptions ou le délai d’expiration des sauvegardes.
- Suppression de données sur demande → localisez les enregistrements concernés et leurs dérivés, puis vérifiez le résultat.
- Limites de conservation → faites expirer automatiquement les enregistrements concernés selon le calendrier approuvé.
Ceux-ci doivent être intégrés dès le départ. Les ajouter après coup est douloureux.
Considérations de confidentialité
La mémoire est sensible. Le magasin contient beaucoup sur l’utilisateur. Considérations :
Chiffrement au repos
Données de mémoire chiffrées. Pratique standard.
Contrôles d’accès
Qui peut voir la mémoire d’un utilisateur ? Seulement lui, seulement le système, le personnel de support dans certaines conditions ? Définissez-le clairement. Auditez les accès.
Gestion des PII
Les informations personnelles identifiables (noms réels, adresses, informations financières) doivent être étiquetées et traitées avec soin. Contrôles d’accès spéciaux, procédures de suppression spéciales.
Visibilité utilisateur
Lorsque le produit et les droits applicables l’exigent, permettez aux utilisateurs de consulter, corriger, limiter et supprimer les enregistrements de mémoire. Un tableau de bord consacré à la mémoire est une mise en œuvre possible ; testez sa compréhension et protégez-le comme toute autre interface donnant accès à des données sensibles.
Ce dont l’agent se souvient à votre sujet :
Profil :
- Nom : Alice Tamm
- Rôle : PDG chez Acme Corp
- Style de communication : concis, direct
Sessions récentes :
- 2026-05-14: Projet de proposition rédigé pour Acme
- 2026-05-12: Résultats du premier trimestre examinés
- ...
Préférences :
- Privilégie les réponses concises
- Utilise Notion, Slack et Linear
[Modifier] [Supprimer des éléments spécifiques] [Tout supprimer]
Cette transparence renforce la confiance. Une mémoire opaque, sans visibilité pour l’utilisateur, ne l’inspire pas.
Partage entre contextes
Si l’utilisateur a plusieurs « modes » (agent de travail, agent personnel), il peut vouloir que les mémoires soient séparées. Ne partagez pas automatiquement entre les modes sauf si demandé.
Modes d’échec courants
Quelques schémas récurrents :
Échec 1 : Mémoires hallucinées
L’agent prétend se souvenir de choses qui ne se sont pas produites. « La semaine dernière, nous avons convenu de X » — mais X n’a jamais été discuté.
Cause : le LLM « remplit » des mémoires plausibles lors de l’extraction ou de la récupération.
Correction : ancrez les opérations de mémoire dans les données réelles de la conversation. Le LLM extrait les informations ; la vérification s’effectue par rapport à la transcription réelle. Les faits hallucinés doivent être signalés.
Échec 2 : Mauvais faits appris
L’agent affirme avec confiance des faits erronés. « Vous avez dit que vous préférez Python » alors que vous avez en réalité dit que vous étiez forcé d’utiliser Python au travail.
Cause : mauvaise interprétation lors de l’extraction.
Correction : seuils de confiance. N’apprenez qu’à partir de déclarations explicites, répétées ou confirmées. L’utilisateur peut corriger.
Échec 3 : Fuites de confidentialité
La mémoire d’un utilisateur apparaît dans la conversation d’un autre. Catastrophique.
Cause : erreurs dans la logique de périmètre propre à l’utilisateur.
Correction : imposez le périmètre de chaque utilisateur dans les couches de stockage et de récupération. Auditez ces contrôles. Ne confiez jamais le filtrage au LLM.
Échec 4 : Inflation de la mémoire
Après un an, la mémoire atteint plusieurs mégaoctets par utilisateur. La récupération ralentit. Les coûts augmentent.
Cause : pas de décroissance ou d’élagage.
Correction : décroissance agressive. La plupart des mémoires deviennent inaccessibles (faible priorité de récupération) après plusieurs mois. Compactez périodiquement.
Échec 5 : Faits périmés
L’utilisateur a changé de rôle il y a 6 mois. L’agent fait toujours référence à l’ancien rôle.
Cause : faits non mis à jour lorsqu’ils sont supplantés.
Correction : détectez les contradictions, conservez la provenance et les dates effectives, et demandez confirmation lorsque la valeur faisant autorité est floue. « Le plus récent gagne » est dangereux pour les entrées retardées, citées ou malveillantes.
Échec 6 : Consolidation désorientante
La consolidation de la mémoire en arrière-plan réécrit parfois les mémoires d’une manière qui perd des informations.
Cause : résumé agressif sans préserver les faits clés.
Correction : la consolidation doit explicitement préserver les faits. Testez la consolidation sur des transcriptions de mémoire réelles.
Esquisse d’implémentation : assistant personnel avec mémoire
Une conception de référence illustrative : un assistant IA personnel pour utilisateurs individuels.
Couches de mémoire :
- Travail : conversation actuelle.
- Session : 7 dernières sessions sous forme résumée.
- Épisodique : 100 événements notables les plus récents, avec recherche sémantique.
- Sémantique : profil utilisateur (nom, rôle, préférences, outils).
- Procédural : flux de travail explicites que l’utilisateur a configurés.
Stockage :
- SQL (Postgres) : profil structuré, sessions, épisodes, procédures.
- Base de données vectorielle (pgvector) : recherche sémantique épisodique.
Opérations :
- Début de session : chargement automatique du profil sémantique + 3 dernières sessions + éléments ouverts.
- Mi-session : récupération épisodique déclenchée par la pertinence du sujet.
- Fin de session : extraction basée sur LLM ; l’utilisateur peut examiner ce qui a été appris.
- Arrière-plan : consolidation hebdomadaire (combiner les épisodes liés, faire décroître ceux qui sont périmés).
Contrôles utilisateur :
- Tableau de bord mémoire montrant ce qui est mémorisé.
- Modifier/supprimer des éléments individuels.
- Bouton « Oublier la dernière heure ».
- Flux de suppression complète du compte avec couverture vérifiée, exceptions documentées et comportement d’expiration de sauvegarde.
Preuves requises avant de considérer cela comme réussi :
- achèvement de tâche avec et sans mémoire récupérée sur un ensemble d’évaluation fixe,
- précision des faits stockés et des mémoires récupérées, y compris la gestion des contradictions,
- tests d’isolation inter-locataires et inter-utilisateurs,
- propagation des corrections et des suppressions dans les enregistrements, les plongements vectoriels, les caches, les exports, les tâches et les sauvegardes jusqu’à leur expiration,
- tokens, stockage, latence et coût opérationnel issus de traces réelles,
- test de compréhension utilisateur et de contrôle plutôt que confiance supposée.
Modes d’échec traités :
- Les cas de mémoire hallucinée sont inclus dans les tests d’extraction et de récupération.
- Les scores de confiance sont étalonnés ; ils ne rendent pas un fait vrai par eux-mêmes.
- L’autorisation est imposée avant la récupération et à nouveau avant la présentation.
- Les tâches de conservation et de consolidation disposent de journaux d’audit, d’une gestion des échecs et de tests de suppression.
Ceci est une liste de contrôle de conception, pas une preuve de préparation à la production. Le statut de production nécessite des preuves d’implémentation et un examen de sécurité/confidentialité.
Outils spécialisés
Quelques remarques sur les offres de mémoire en tant que service :
Mem0. Une couche de mémoire open-source. Évaluez sa documentation actuelle et le code par rapport à vos exigences de persistance, d’isolation et de suppression.
Letta (MemGPT). Une conception de mémoire orientée outils. Examinez sa documentation actuelle et ses limites opérationnelles.
Zep. Un service hébergé de mémoire et de contexte. Validez sa documentation actuelle, sa frontière de données et son contrat de suppression.
Cognee. Une option orientée graphe de connaissances. Validez la maturité et l’adéquation à partir de sa documentation et de son dépôt actuels avant de l’adopter.
Ces outils peuvent réduire le travail d’implémentation et ajouter des dépendances en matière de fournisseur, de sécurité, de migration et de cycle de vie des données. Comparez-les avec une conception interne utilisant les mêmes tests d’acceptation.
Déployer uniquement la mémoire minimale justifiée
La mémoire à long terme est ce qui rend les agents continus entre les sessions plutôt qu’amnésiques. C’est aussi l’une des choses les plus difficiles à bien faire.
L’architecture est en couches :
- Mémoire de travail (dans le contexte).
- Mémoire de session (sessions récentes).
- Mémoire épisodique (événements spécifiques).
- Mémoire sémantique (faits stables).
- Mémoire procédurale (préférences et flux de travail).
Chaque couche a sa propre logique de stockage, de récupération et de décroissance. Chacune contribue à rendre l’agent utile au fil du temps.
Les principes qui comptent :
- Extraction prudente (ne pas halluciner de faits).
- Apprentissage basé sur la confiance (ne pas apprendre à partir de commentaires anodins).
- Oubli actif (décroissance et élagage).
- Contrôle utilisateur (transparence et capacité d’édition).
- Application de la confidentialité (à chaque couche).
Lorsqu’elle satisfait aux tests d’évaluation et de cycle de vie, la mémoire peut réduire les mises en contexte répétées et rendre les préférences confirmées disponibles d’une session à l’autre.
Pour les agents qui nécessitent une continuité inter-sessions, la persistance est un choix produit explicite. Construisez la mémoire minimale justifiée, avec provenance, autorisation, contrôle utilisateur et un chemin de fin de vie testé.
