Vous constatez que votre Agent retrouve correctement une procédure, mais oublie les préférences d’un utilisateur ou réutilise une information obsolète ?
Le plus rapide est de séparer les rôles : RAG pour les connaissances externes, Agent Memory pour les utilisateurs, les conversations et l’état des tâches. Pour un Agent durable, choisissez généralement un double circuit avec des règles distinctes d’écriture, de traçabilité et de suppression.
Dernière mise à jour : 10 août 2026. Les éléments concernant TencentDB-Agent-Memory ont été vérifiés dans le dépôt officiel, ses fichiers de configuration et sa dernière version publiée à cette date : dépôt et historique du projet.
Cette analyse s’adresse aux développeurs qui ajoutent une mémoire persistante à un chatbot, un assistant personnel, un Agent de programmation ou un système de tâches en plusieurs étapes. Elle concerne aussi les équipes qui disposent déjà d’un RAG d’entreprise et doivent décider si elles peuvent le réutiliser sans y stocker indistinctement chaque échange.
Le bon découpage des données
La première erreur consiste à traiter « mémoire » comme un simple synonyme de « contexte plus long ». Un RAG et une mémoire d’Agent peuvent tous deux rechercher du contenu, mais ils ne répondent pas à la même question.
Un système RAG part généralement de sources externes : documentation produit, contrats, bases de connaissances, tickets résolus, manuels techniques ou fichiers multimédias. Son objectif est de retrouver des éléments pertinents afin de produire une réponse fondée sur des preuves. Le contenu reste rattaché à une source, une version, un document ou une page. Cette association est importante pour afficher une citation, vérifier une date ou invalider une ancienne version. La documentation de référence sur la récupération de connaissances décrit précisément cette logique de données injectées au moment de la réponse et de génération appuyée sur des sources.
Une mémoire d’Agent conserve plutôt des éléments liés à l’usage :
- une préférence utilisateur, comme un format de livraison ou un style de réponse ;
- un fait stable, comme le langage de programmation préféré ;
- un résumé de scénario, par exemple l’état d’un projet en cours ;
- une décision prise au cours d’une tâche ;
- une relation entre une erreur, sa cause et la correction appliquée ;
- un état opérationnel qui doit être restauré après redémarrage.
Prenons un assistant de montage vidéo. Le manuel de DaVinci Resolve ou la procédure interne de livraison relèvent du RAG. Le fait que votre équipe exige des exports en ProRes, conserve une piste audio séparée et nomme les fichiers selon un modèle précis relève de la mémoire. Dans un Agent de design, le guide de la marque appartient à la base documentaire ; la préférence persistante d’un directeur artistique pour des compositions sobres appartient à la mémoire utilisateur.
Agent Memory et base vectorielle
Une base vectorielle est un composant de stockage et de recherche. Elle peut servir à un RAG, à une mémoire d’Agent ou aux deux. Elle ne définit pas, à elle seule, ce qui doit être mémorisé, combien de temps, avec quelle portée utilisateur ni selon quelle règle de correction.
Cette distinction répond à une question fréquente : Agent Memory et base vectorielle ne sont pas deux produits concurrents. La première décrit une fonction et une politique de gestion de l’information ; la seconde peut être l’un des moteurs utilisés pour retrouver cette information.
Si vous placez les documents, les préférences et les états de tâches dans un index unique, vous créez plusieurs coûts cachés :
- les documents évoluent par version, tandis qu’une préférence peut être remplacée par une nouvelle préférence ;
- une information générale peut être visible par plusieurs utilisateurs, alors qu’une mémoire personnelle doit rester isolée ;
- un résultat documentaire doit souvent afficher sa source, tandis qu’un souvenir doit expliquer quand et dans quel contexte il a été extrait ;
- la suppression d’un document ne suit pas forcément la même propagation que l’effacement d’un profil utilisateur ;
- un ancien état de tâche peut être utile pour l’audit mais dangereux s’il est présenté comme l’état actuel.
Le problème n’est donc pas seulement la précision du classement vectoriel. C’est aussi l’absence de responsable clairement défini pour chaque type de donnée.
Les métriques d’écriture et de mise à jour
Deux pipelines, deux responsabilités
Dans un RAG classique, l’écriture est souvent explicite : vous importez un document, le découpez, ajoutez ses métadonnées, calculez des représentations de recherche, puis l’indexez. Une nouvelle version peut déclencher une réindexation ou une invalidation. Le contrôle se situe avant la mise à disposition du contenu.
Dans une mémoire persistante, l’écriture intervient pendant l’utilisation de l’Agent. Le système doit décider si une phrase mérite d’être conservée, sous quelle forme, avec quelle portée et pour quelle durée. Cette décision peut passer par une extraction de faits, une consolidation de plusieurs échanges et une génération de résumé de scénario.
Le dépôt officiel de TencentDB-Agent-Memory décrit une progression L0 à L3 : conversation brute, faits atomiques, scénarios et persona. Il distingue aussi la mémoire de tâche à court terme, les journaux détaillés et les couches de synthèse lisibles. Cette structure évite de remplacer l’original par un résumé impossible à vérifier : les niveaux supérieurs peuvent redescendre vers les éléments sources à l’aide de références comme node_id ou result_ref. (README officiel et architecture de traçabilité)
Les paramètres documentés dans la version vérifiée donnent trois repères opérationnels utiles :
- la stratégie de rappel par défaut est hybride, combinant recherche par mots-clés et recherche sémantique ;
- le nombre maximal d’éléments retournés par rappel est fixé à 5 par défaut ;
- l’extraction d’une mémoire L1 est déclenchée toutes les 5 conversations par défaut, tandis que la génération de persona intervient toutes les 50 nouvelles mémoires.
Ces valeurs ne sont pas des garanties de qualité. Elles montrent plutôt qu’une mémoire sérieuse possède un calendrier d’extraction, des limites d’injection et des niveaux de consolidation. Vous devez les tester avec vos propres dialogues, car une fréquence trop élevée capture du bruit et une fréquence trop faible retarde la mise à jour.
| Critère | RAG | Agent Memory |
|---|---|---|
| Déclencheur d’écriture | Import, publication ou synchronisation d’une source | Échange, événement, décision ou fin de tâche |
| Unité de stockage | Document, passage, page, fichier | Fait, préférence, scénario, état ou trace |
| Mise à jour | Nouvelle version, suppression ou réindexation | Consolidation, conflit, expiration ou correction |
| Problème typique | Source obsolète encore récupérée | Souvenir faux ou généralisé trop vite |
| Contrôle recommandé | Version, propriétaire, date d’effet | Confiance, portée, provenance, date de dernière validation |
Les conflits et les souvenirs erronés
Un Agent ne doit pas transformer chaque phrase en vérité durable. « Je préfère les exports carrés » peut être une préférence temporaire, une contrainte valable pour un seul client ou une consigne définitive. Le pipeline doit donc distinguer au minimum :
- la phrase originale ;
- l’interprétation extraite ;
- la portée de cette interprétation ;
- sa date ;
- les échanges qui la justifient ;
- son statut après correction.
Lorsqu’un utilisateur dit ensuite « revenez au format paysage », la mémoire précédente ne doit pas être simplement conservée avec un score inférieur. Elle doit être marquée comme remplacée, limitée à un ancien projet ou soumise à confirmation. Sans cette logique, le rappel peut être techniquement pertinent mais opérationnellement faux.
Pour une base documentaire, la correction est différente. Vous devez remplacer ou retirer la source, puis vérifier que les anciennes représentations et les caches ne peuvent plus être utilisées. Pour une mémoire, vous devez aussi réexaminer les résumés de scénario et la persona qui ont pu être construits à partir du souvenir supprimé.
Les métriques de rappel et de preuve
Un index pour répondre, une mémoire pour reprendre
Le RAG optimise une question du type : « Quelle est la procédure actuellement applicable ? » La mémoire optimise plutôt : « Que devons-nous continuer depuis la dernière étape ? » ou « Quel format cet utilisateur utilise-t-il habituellement ? »
Pour un chatbot de support, le RAG doit retrouver la règle correspondant à la version du produit et au contrat du client. La mémoire peut rappeler que ce client préfère recevoir un résumé avant les étapes détaillées. Mélanger les deux peut conduire l’Agent à traiter une préférence comme une règle contractuelle, ou une ancienne réponse comme une procédure officielle.
La qualité doit donc être mesurée avec des jeux de tests différents :
- rappel documentaire : la bonne source est-elle retrouvée et citée ?
- rappel personnel : le bon utilisateur est-il associé au bon souvenir ?
- rappel temporel : l’information la plus récente remplace-t-elle l’ancienne ?
- rappel de tâche : l’Agent restaure-t-il le bon état après interruption ?
- rappel négatif : l’Agent sait-il ne rien rappeler lorsqu’aucune donnée fiable n’existe ?
Le projet TencentDB-Agent-Memory met en avant une recherche hybride, associant mots-clés, vecteurs et fusion de résultats, ainsi que des outils de recherche séparés pour la mémoire et les conversations. Son intérêt principal n’est pas de promettre qu’un souvenir sera toujours exact, mais de rendre l’erreur inspectable. Les artefacts de mémoire sont décrits comme lisibles, avec des chemins permettant de revenir d’une persona vers un scénario, puis vers un fait et la conversation d’origine. (configuration et outils documentés du projet)
| Question d’évaluation | Signal attendu dans un RAG | Signal attendu dans une mémoire |
|---|---|---|
| Pourquoi cette information a-t-elle été utilisée ? | Document, passage, version et métadonnée | Fait, scénario, conversation et identifiant de provenance |
| Est-elle encore valable ? | Version et date d’effet de la source | Date de validation, conflit et statut du souvenir |
| Peut-elle être citée ? | Oui, si la source est conservée | Oui, si la mémoire garde le chemin vers l’évidence |
| Que faire après correction ? | Réindexer ou invalider la source | Corriger le souvenir et ses agrégats dérivés |
| Quel risque principal ? | Réponse appuyée sur une version obsolète | Personnalisation fausse ou fuite entre utilisateurs |
La traçabilité des erreurs
Lorsqu’un rappel de mémoire est incorrect, ne vous contentez pas d’inspecter le score de similarité. Suivez cette chaîne :
- quelle requête l’Agent a-t-il générée ;
- quelle couche a répondu : persona, scénario, fait ou conversation ;
- quelle règle a autorisé l’injection ;
- quelle source originale a produit le souvenir ;
- le souvenir était-il déjà corrigé ou expiré ;
- le filtre d’utilisateur, de projet et de tenant était-il actif ;
- le modèle a-t-il mal interprété une mémoire pourtant correcte ?
Cette méthode est plus longue qu’un simple examen des cinq premiers résultats, mais elle permet de distinguer un problème d’extraction, de classement, de filtrage ou de génération. C’est également pour cette raison qu’il est risqué de supprimer les conversations brutes dès qu’un résumé est créé.
La gouvernance des données
Les règles de confidentialité
Vous ne devez pas appliquer la même politique aux documents partagés et aux souvenirs personnels. Dans un RAG d’entreprise, les droits peuvent dépendre du service, du dossier, du niveau de confidentialité ou du contrat. Dans une mémoire d’Agent, l’isolation peut dépendre de l’utilisateur, du projet, de l’organisation, du rôle ou de la session.
Un déploiement local peut réduire le nombre de chemins d’externalisation, mais il ne constitue pas automatiquement une conformité. Il reste nécessaire de définir les accès administrateurs, les sauvegardes, les journaux, les copies temporaires, les exports et les mécanismes de purge.
La CNIL rappelle le principe de minimisation : ne collecter que les données adéquates, pertinentes et nécessaires à la finalité prévue. Elle recommande également d’associer une durée de conservation à chaque catégorie de données et de journaliser les procédures d’effacement. La fiche sur les durées de conservation précise qu’une donnée personnelle ne doit pas être conservée indéfiniment.
Pour un Agent, cela signifie qu’il faut séparer au moins :
- les journaux techniques nécessaires au diagnostic ;
- les conversations conservées pour un service actif ;
- les mémoires utiles à la personnalisation ;
- les documents réglementaires ou contractuels ;
- les données supprimées mais maintenues temporairement pour une obligation légale ;
- les sauvegardes qui doivent suivre une procédure d’effacement différé.
| Dimension de gouvernance | RAG documentaire | Mémoire d’Agent |
|---|---|---|
| Périmètre d’accès | Document, équipe, contrat, application | Utilisateur, projet, session, tenant |
| Durée | Liée à la validité ou à l’obligation documentaire | Liée à l’utilité, à la correction et au consentement |
| Suppression | Source, fragments, index, cache | Conversation, fait, scénario, persona, sauvegarde |
| Audit | Version et historique de publication | Provenance, extraction, modification et rappel |
| Risque de fuite | Document accessible au mauvais rôle | Souvenir d’un utilisateur injecté dans un autre contexte |
Faut-il conserver tous les échanges ?
Non. Conserver toutes les conversations peut faciliter le diagnostic, mais augmente la surface de risque, le volume d’indexation et la probabilité de capturer des informations sans valeur durable. Une politique plus robuste consiste à distinguer :
- les données éphémères, conservées uniquement pendant la tâche ;
- les traces techniques, conservées selon une durée d’exploitation définie ;
- les faits validés, réutilisables dans plusieurs sessions ;
- les préférences explicitement confirmées ;
- les informations sensibles, exclues par défaut ou soumises à une règle spécifique.
La règle européenne relative à l’effacement prévoit, dans les cas applicables, le droit d’obtenir l’effacement de données personnelles. Dans une architecture à mémoire, cette demande doit atteindre non seulement la table principale, mais aussi les résumés, les index, les caches, les fichiers de travail et les sauvegardes selon la politique retenue.
Le choix selon votre Agent
Les conditions de décision
Utilisez la branche suivante avant de choisir un composant :
- Si les réponses doivent provenir de manuels, de contrats, de tickets ou de fichiers multimédias identifiables, choisissez d’abord un RAG.
- Si l’Agent doit se souvenir d’une préférence, d’une décision ou d’un état après fermeture de la session, ajoutez Agent Memory.
- Si la tâche se déroule sur plusieurs étapes et doit reprendre après une interruption, utilisez une mémoire de tâche distincte du RAG.
- Si les utilisateurs sont isolés par compte ou par organisation, refusez un index commun sans filtre d’autorisation explicite.
- Si chaque réponse doit être auditée, conservez les références vers l’évidence originale, même après extraction d’un résumé.
- Si vous ne disposez que d’un besoin ponctuel de recherche documentaire, n’ajoutez pas une mémoire persistante par défaut.
- Si l’Agent combine support, personnalisation et exécution d’actions, retenez le double circuit : RAG pour les règles, mémoire pour le contexte utilisateur et l’état opérationnel.
| Cas d’usage | Choix conseillé | Pourquoi |
|---|---|---|
| Question unique sur une documentation | RAG seul | Pas de valeur durable à extraire d’une conversation isolée |
| Assistant personnel sur plusieurs semaines | Agent Memory avec RAG si nécessaire | Préférences et contexte évolutif à conserver |
| Agent de programmation sur un projet long | Double circuit | Documentation, code et erreurs d’un côté ; décisions et état du projet de l’autre |
| Support client réglementé | Double circuit cloisonné | Réponses fondées sur les sources, personnalisation limitée et auditable |
| Création audio ou vidéo récurrente | Double circuit léger | Référentiel de formats et de droits dans le RAG ; habitudes créatives dans la mémoire |
| Agent de tri ponctuel | RAG ou contexte de session | La persistance peut créer plus de risques que de bénéfices |
Le rôle de TencentDB-Agent-Memory
TencentDB-Agent-Memory est pertinent lorsque votre difficulté porte sur la continuité entre sessions, la consolidation progressive et l’inspection des souvenirs. La documentation officielle indique un fonctionnement local avec SQLite et sqlite-vec par défaut, une recherche hybride et une organisation en couches. Elle décrit également une intégration sous forme de module pour OpenClaw ainsi qu’un adaptateur Hermes ; vérifiez toutefois les frameworks et paramètres réellement supportés dans la version installée, car le projet évolue. (configuration du dépôt officiel)
Vous ne devez pas le considérer comme un remplacement automatique de votre RAG. Son rôle est plutôt de fournir une couche de mémoire structurée, avec des niveaux de détail et une remontée vers les preuves. Votre base documentaire peut rester responsable des politiques, des manuels et des sources versionnées, tandis que la mémoire conserve les préférences, les scénarios et les états qui doivent survivre à une session.
Pour une première validation, construisez un jeu de dialogues comprenant :
- une préférence explicitement confirmée ;
- une préférence ensuite modifiée ;
- deux utilisateurs ayant des exigences opposées ;
- une tâche interrompue puis reprise ;
- un souvenir volontairement faux ;
- une demande de suppression ;
- un redémarrage complet avant le rappel.
Mesurez séparément l’exactitude, la portée utilisateur, la capacité de correction, la restauration après redémarrage et la preuve permettant d’expliquer chaque rappel. Ne mélangez pas ces résultats avec la précision de votre RAG : ce sont des indicateurs différents.
Mise en production en cinq étapes
- Cartographiez les données. Pour chaque champ, indiquez s’il s’agit d’une source externe, d’un fait utilisateur, d’un état de tâche, d’un journal ou d’une donnée sensible.
- Définissez les événements d’écriture. Décidez ce qui déclenche une extraction : confirmation utilisateur, fin de tâche, changement de statut, erreur résolue ou répétition d’une préférence.
- Conservez la provenance. Chaque mémoire persistante doit pointer vers l’échange, le document ou l’événement qui l’a produite. Sans cette référence, vous ne pourrez pas corriger proprement un rappel.
- Séparez les routes de rappel. Interrogez le RAG pour les connaissances externes et la mémoire pour le contexte personnel ou opérationnel. Ajoutez un routeur lorsque la requête peut relever des deux.
- Testez les incidents avant l’ouverture. Vérifiez l’isolement entre utilisateurs, la suppression complète, les conflits de préférences, la restauration après redémarrage et le comportement lorsque le rappel est vide.
- Définissez l’exploitation. Documentez les sauvegardes, les accès administrateurs, les journaux, la durée de conservation, les migrations et la procédure de retour arrière.
- Réévaluez les règles. Une mémoire qui fonctionne en environnement de test peut accumuler des erreurs en production. Programmez une revue des souvenirs obsolètes et des cas de rappel contestés.
Si votre projet nécessite un environnement isolé pour tester un Agent local, ses journaux et ses mécanismes de récupération, commencez par consulter les informations de location d’un Mac pour un environnement de développement. Pour les équipes qui évaluent plusieurs scénarios d’exécution, la page présentant Kvmzen permet aussi de comprendre le cadre de service avant de comparer les options.
Le choix d’exploitation
Un RAG seul est souvent le choix le plus simple pour une base documentaire et pour une question ponctuelle. Une mémoire seule peut convenir à un assistant qui doit surtout suivre des préférences et des tâches, mais elle ne remplace pas une source officielle lorsque l’exactitude documentaire et la citation sont nécessaires. Pour la plupart des Agents qui accompagnent un utilisateur dans la durée, le double circuit est le meilleur compromis, à condition de ne pas partager les mêmes règles d’écriture, de portée et de suppression.
Votre environnement actuel peut présenter trois limites concrètes : une base vectorielle prévue pour les documents mais mal adaptée aux états évolutifs, des journaux difficiles à purger après une demande d’effacement et une exécution distante qui complique l’isolement des conversations sensibles. Dans ce contexte, louer un environnement Mac auprès de Kvmzen peut servir de terrain de test séparé pour vos pipelines locaux, vos scripts de validation et vos intégrations d’Agent, sans engager immédiatement un achat matériel.
Cette option reste moins pertinente si vous devez maintenir une charge lourde et stable pendant une longue période, connecter des périphériques physiques spécifiques ou conserver durablement les mêmes ressources. En revanche, pour tester une architecture Agent Memory + RAG, reproduire un incident, valider une reprise après redémarrage ou comparer plusieurs versions d’un projet, un environnement loué peut accélérer la décision sans transformer votre prototype en engagement d’infrastructure permanent.