Memori est une couche de mémoire open source et native d'agent de Memori Labs. Il observe les conversations et les traces d'exécution (appels d'outils, étapes de flux de travail, décisions, résultats et échecs), puis convertit les signaux sélectionnés en mémoire structurée et persistante. Plus tard, une application ou un agent peut récupérer un petit ensemble de mémoires au lieu de relire l’intégralité d’une transcription.
Il s'agit d'un travail différent du document RAG. RAG répond généralement « que dit le corpus source ? » La mémoire des agents doit également répondre « qu’est-il arrivé, à qui, dans quel projet, quand, avec quel résultat, et est-ce toujours vrai ? » La valeur de Memori dépend moins du stockage de nombreux faits que de l'écriture sélective, de la séparation des utilisateurs et des projets, de la résolution des corrections, de la préservation du lignage, du rappel au bon moment et de la suppression de manière fiable.
De la trace d'exécution au contexte rappelé
conversation + trace d'agent + résultats de l'outil
|
v
désinfecter / attribuer / normaliser
|
notez ce qui est digne de mémoire
|
.------------+-------------.
v v v
faits événements/résultats décisions/modèles
'------------+-------------'
v
magasin de mémoire structurée
entité / projet / processus / session / source / heure
|
rang : pertinence + récence + signal + dégradation
|
v
le plus petit rappel utile
|
correction / remplacement / suppression
La trace brute est entrée, pas nécessairement l'objet mémoire final. Les explications du produit indiquent que l'ingestion est asynchrone : l'activité de l'outil et la conversation peuvent être normalisées, notées et distillées après une interaction sans retarder le chemin de réponse. Les traces brutes peuvent rester disponibles pour l'audit tandis que les primitives durables transportent des métadonnées telles que l'entité, le projet, la session, la source, le signal, l'horodatage et le résultat.
Qu'est-ce que Memori – et n'est-il pas ?
| Système | Unité primaire | Meilleure question | Échec typique |
|---|---|---|---|
| Historique des conversations | Message | Qu'a-t-on dit récemment ? | Le contexte devient long, coûteux et incohérent en interne |
| Document RAG | Morceau/document | Que dit une source externe ? | Faible gestion de l’état personnel, des résultats et des corrections |
| Base de données de flux de travail | Ligne d'application explicite | Quel est l’état de transaction faisant autorité ? | Oblige les développeurs à modéliser chaque domaine et chaque transition |
| Memori | Mémoire structurée dérivée de la conversation et de la trace | Quel état antérieur aide cet agent à agir maintenant ? | L'extraction ou le classement peuvent favoriser des observations bruyantes, privées ou obsolètes |
N'utilisez pas la mémoire probabiliste comme système d'enregistrement des soldes, des autorisations, des commandes, des faits médicaux ou du statut juridique. Ceux-ci appartiennent aux tableaux d’applications faisant autorité et doivent être récupérés au moment de la décision. Memori est meilleur pour les préférences, les tentatives antérieures, les résultats, les connaissances de flux de travail réutilisables et les signaux contextuels dont la provenance peut être montrée.
Les choix architecturaux qui comptent
L'architecture open source est décrite comme indépendante du LLM, du framework et du magasin de données. L'attribution étend la mémoire à une entité et à un processus ; l'augmentation transforme l'activité brute en mémoire structurée ; le rappel utilise la pertinence sémantique, le classement et la dégradation ; les wrappers peuvent injecter le contexte sélectionné dans les appels de modèle ultérieurs. La conception prend en charge Memori Cloud et un chemin d'accès à votre propre base de données.
| Calque | Responsabilité | Question d'évaluation |
|---|---|---|
| Capturer | Collectez les conversations, les traces, les outils et les résultats | Quels événements sont observés exactement et les outils sensibles peuvent-ils être exclus ? |
| Attribution | Attribuer une entité, un projet, un processus et une session | Les identifiants mal formés peuvent-ils entraîner un rappel entre utilisateurs ou entre locataires ? |
| Augmentation | Extraire, classer, enrichir et consolider la mémoire | Quel modèle s'exécute, où, avec quelle politique de nouvelle tentative et de confiance ? |
| Stockage | Conserver les éléments structurés, les incorporations, le lignage et la trace | Qui contrôle le chiffrement, la sauvegarde, la région, la rétention et la migration des schémas ? |
| Rappel | Filtrer, classer, décomposer et renvoyer un contexte pertinent | Chaque résultat peut-il expliquer la source, la portée et l’actualité ? |
| Observabilité | Afficher les écritures, les rappels, les performances et les quotas | Les opérateurs peuvent-ils détecter les saignements, les rappels périmés et les volumes d’écriture incontrôlables ? |
Pourquoi la mémoire dérivée des traces peut ajouter des informations
Une transcription peut indiquer « Je vais réessayer avec l'analyseur CSV », mais la trace peut révéler quel analyseur a été exécuté, quel fichier a échoué, l'erreur, la solution de secours et si la sortie a réussi la validation. La capture du chemin d'exécution peut préserver les preuves causales qu'un résumé conversationnel perd. Des exemples utiles incluent une commande de déploiement qui échoue à plusieurs reprises dans un environnement spécifique, une source de données qui a renvoyé des lignes obsolètes ou un workflow de support dont l'escalade a résolu le cas.
| Signal de trace | Mémoire durable potentielle | Ne stockez pas à l’aveugle |
|---|---|---|
| Appel d'outil et résultat | Procédure de fonctionnement connue ou condition de défaillance récurrente | Charges utiles brutes, jetons, enregistrements clients ou traces de pile transitoires |
| Décision et justification | Approche choisie avec portée et preuves | Spéculation de modèle non approuvée présentée comme politique d'équipe |
| Résultat | Si un plan antérieur a réussi, échoué ou a été annulé | Résultat déduit avant vérification externe |
| Correction de l'utilisateur | Préférence actuelle plus remplacement de l'ancienne valeur | Attributs sensibles sans consentement ni besoin commercial |
| Motif répété | Aperçu fiable du flux de travail après plusieurs observations | Comportement ponctuel généralisé en règle permanente |
La politique d'écriture doit exiger une durabilité, une utilité et une sensibilité appropriée. « L'utilisateur a choisi le mode sombre » peut être durable. « L'utilisateur est actuellement en colère » est éphémère et potentiellement dangereux. « Transfert terminé » doit être vérifié par rapport au système de transaction, et non déduit de la phrase finale d'un agent.
Rappel intelligent et langage « sans jeton »
Le matériel Memori met l'accent sur le rappel ciblé et contrôlé par l'agent et sur l'évitement des vidages rapides importants. La signification pratique n’est pas que la mémoire n’a littéralement aucun coût en jetons : tout texte finalement inséré dans un contexte LLM consomme des jetons. Au lieu de cela, l'agent peut appeler un outil de rappel uniquement lorsque cela est utile, et la récupération peut renvoyer un résultat compact au lieu d'injecter continuellement l'historique complet. Le stockage, l’enrichissement, l’intégration et les appels d’outils ont toujours un coût informatique et monétaire.
| Contrôle du rappel | Avantage | Échec du test |
|---|---|---|
| Filtres d'entité/projet/session | Empêcher les contextes non pertinents et multi-locataires | Identifiants de portée manquants ou usurpés |
| Pertinence sémantique | Trouve un sens au-delà des mots-clés exacts | Correspondances plausibles mais sans rapport |
| Récence et décadence | Dépriorise les anciennes observations | Des faits anciens mais critiques disparaissent |
| Pondération source/signal | Favorise les résultats vérifiés plutôt que les mentions occasionnelles | Une confiance non calibrée qui devient autorité |
| Rappel contrôlé par l'agent | Évite une injection rapide et constante | L'agent oublie d'appeler l'outil à une étape critique |
| Rappel sommaire | Fournit une orientation compacte | La compression supprime les exceptions et la provenance |
Comment interpréter l’allégation de référence
Memori rapporte une précision de 81,95 % sur LoCoMo avec 1 294 jetons par requête et décrit ce contexte comme environ 5 % d'une approche en contexte complet, ce qui implique jusqu'à 95,03 % d'économies d'inférence dans la configuration testée. LoCoMo évalue les questions de mémoire de conversation longue, il est donc pertinent pour le rappel conversationnel. Le positionnement du produit dérivé de la trace va au-delà de ce que prouve à lui seul cette référence.
Avant d'adopter les chiffres, inspectez le code de référence du référentiel, la version de l'ensemble de données, le juge, le modèle, les lignes de base, le comptage de jetons et le nombre d'exécutions. Séparez la précision de la récupération de la précision de la réponse finale. Les réclamations de coûts doivent inclure l'augmentation, l'intégration, le stockage, les appels de rappel et les tentatives, et pas seulement les jetons dans l'invite de réponse finale. Un benchmark de fournisseur est une preuve reproductible utile, mais il ne s'agit pas d'un SLA ou d'une preuve de performance sur vos schémas et langages.
| Réclamation | Ce qu'il prend en charge | Preuve supplémentaire nécessaire |
|---|---|---|
| LoCoMo précision de la réponse | Performance sur une tâche de conversation publique longue | Vos questions de domaine, utilisateurs, langues et modèles de correction |
| 1 294 jetons/requête | Contexte compact dans la configuration rapportée | Coût total d'écriture + récupération + réponse au volume de production |
| Mémoire dérivée de traces | Des entrées plus riches que la conversation seule | Ablation montrant quels champs de trace améliorent vos tâches |
| Bâtiment asynchrone | Évite potentiellement la latence du chemin de réponse | Retard de fraîcheur, échec de file d'attente et comportement de lecture après écriture |
| Isolement limité | Limites conçues du locataire/du projet | Tests contradictoires d’autorisation et d’identification |
BYODB contre Memori Cloud
| Déploiement | Avantages | Responsabilités / questions |
|---|---|---|
| Open source + propre base de données | Contrôle du stockage, gouvernance existante, portabilité et personnalisation locale | Schéma d'exploitation, modèles, intégrations, migrations, sauvegardes, observabilité et mise à l'échelle |
| BYODB avec fonctionnalités hébergées | Conserver les données primaires dans la base de données choisie lors de l'utilisation d'augmentations/opérations gérées | Cartographier exactement quel contenu/métadonnées quitte la base de données et où le traitement a lieu |
| Memori Nuage | Configuration plus rapide, API géré, tableau de bord, quota et visibilité opérationnelle | Vérifiez les prix en direct, la location, les sous-traitants, la région, la rétention, l'exportation, la suppression et la disponibilité. |
« Apportez votre propre base de données » ne signifie pas nécessairement « tous les traitements restent à l'intérieur de votre réseau ». Obtenez un diagramme de flux de données couvrant les traces brutes, la mémoire extraite, les intégrations, la télémétrie et l'accès au support. Si des données personnelles sont stockées, mappez les demandes d’accès/suppression à chaque copie dérivée, vecteur, cache, sauvegarde et trace exportée.
Modèle de menace pour la sécurité de la mémoire et la confidentialité
| Menace | Exemple | Contrôle requis |
|---|---|---|
| Saignement entre locataires | Une requête de rappel omet la portée du projet et renvoie le fait d'un autre client | Autorisation côté serveur, clés de locataire non facultatives et tests d'isolement |
| Empoisonnement de la mémoire | La sortie d'un document/outil non fiable indique aux futurs agents de révéler des secrets | Étiquettes de confiance source, nettoyage, approbation et séparation des instructions/données |
| Inférence sensible | Les comportements répétés se traduisent en allégations de santé, de finance ou d’identité. | Minimisation des données, classes exclues, consentement et conservation de courte durée |
| Autorité obsolète | Une ancienne adresse ou politique est rappelée après correction | Contrôles de version, d'état canonique, de remplacement et de fraîcheur |
| Écart de suppression | Ligne supprimée mais l'intégration, la trace ou la sauvegarde restent récupérables | Vérification de la suppression de bout en bout et expiration documentée des sauvegardes |
| Divulgation rapide | L'agent répète la mémoire privée à un utilisateur non autorisé | Récupération sensible aux autorisations et politique de sortie ; ne vous fiez jamais uniquement au modèle |
Un contrat mémoire prêt pour la production
Définissez un contrat avant d'activer la capture automatique. Chaque mémoire doit avoir un propriétaire, un locataire/entité, un projet/processus, un type, un pointeur source, une heure de création, une confiance, une sensibilité, une expiration, un statut de cycle de vie et un identifiant de suppression. Le contrat doit indiquer quels types ne sont jamais stockés, lesquels nécessitent le consentement de l'utilisateur, lesquels peuvent être rappelés automatiquement et lesquels doivent être récupérés auprès d'un système faisant autorité.
autorisés : préférences, résultats vérifiés, procédures de tâches réutilisables refusé : informations d'identification, paiement brut/dossiers de santé, invites système cachées autorité : base de données d'application > correction utilisateur vérifiée > résultat de l'outil > inférence de modèle rappel : locataire + projet obligatoire ; source et horodatage renvoyés cycle de vie : proposé -> actif -> remplacé/expiré/supprimé suppression : mémoire + intégration + cache + pointeur de trace + planification de sauvegarde
Un plan d'évaluation de quatre semaines
- Semaine 1 : référence. Recueillez 50 vraies questions sur des faits récents, des faits anciens, des corrections, des résultats de plusieurs sessions et des cas « aucun souvenir n'existe ». Mesurez l’historique complet et les lignes de base vectorielles-RAG simples.
- Semaine 2 : qualité d'écriture. Exécutez des traces représentatives, étiquetez les observations qui doivent devenir mémoire et calculez la précision/le rappel de l'extraction, les fuites de données sensibles et le délai de fraîcheur.
- Semaine 3 : qualité du rappel. Testez les filtres, le classement, la dégradation, les citations, les contradictions, les requêtes multilingues et les identifiants de locataires contradictoires. Enregistrez la précision du contexte pertinent avant de mesurer les réponses finales.
- Semaine 4 : opérations. Testez les écritures/rappels, arrêtez le travailleur d'augmentation, faites pivoter les informations d'identification, restaurez une sauvegarde, exportez les données et exécutez une suppression complète. Évaluez la charge de travail réelle.
| Métrique | Définition | Porte de départ suggérée |
|---|---|---|
| Précision d'écriture | Souvenirs durables utiles et précis / tous créés | ≥90% |
| Écrire un rappel | Observations d'or durables capturées / toutes les observations d'or | ≥85% |
| Rappeler précision@k | Souvenirs retournés pertinents / k | ≥80 % au contexte effectivement injecté |
| Taux de mémoire non pris en charge | Allégations rappelées sans source/rappels valides | <2% |
| Fuite transversale | Éléments de locataire/projet non autorisés retournés | 0 en suite contradictoire |
| Succès de la correction | Requêtes renvoyant le fait canonique actuel après correction | 100 % pour les champs de tests critiques |
| Fin de la suppression | Les surfaces dérivées ne sont plus récupérables dans la fenêtre de stratégie | 100% |
| Coût total/tâche | Écriture, modèles, intégrations, stockage, rappel et réponse | En dessous de la valeur mesurée enregistrée |
Les seuils devraient être renforcés pour les utilisations réglementées ou à fort impact. Mesurez également l’abstention : un bon système doit dire « aucun souvenir fiable trouvé » plutôt que de récupérer une fiction sémantiquement similaire.
Alternatives
| Alternative | Choisissez quand | Comparaison clé |
|---|---|---|
| Mem0 | Vous souhaitez une mémoire générale largement intégrée API et des chemins gérés/ouverts | Comparez le schéma d'extraction, la prise en charge des graphiques, la portée, les tests de référence et le flux de données hébergé |
| Zep / Graphiti | Les graphiques de connaissances temporels et les relations entre entités sont essentiels | Comparez l'invalidation temporelle, les opérations graphiques et l'ingestion de traces |
| Letta | La gestion de la mémoire doit faire partie d'un environnement d'exécution d'agent avec état | Abstraction différente : orchestration d'agents et mémoire hiérarchisée |
| LangGraph persistance | Vous avez besoin de points de contrôle de flux de travail explicites et déclarez que vous vous modélisez | État plus déterministe ; extraction de mémoire sémantique moins automatique |
| Couche personnalisée Postgres/pgvector | Vos exigences en matière de schéma, de sécurité ou de coût justifient la propriété | Contrôle maximal, charge d'évaluation et de maintenance maximale |
| Profils simples/Tableaux ADR | Les besoins en mémoire sont faibles, explicites et à conséquences élevées | Souvent plus sûr et moins cher que l’extraction probabiliste |
FAQ
Memori remplace-t-il une base de données vectorielles ?
Non. Il s’agit d’un cycle de vie de la mémoire et d’une couche d’intégration qui peut utiliser l’infrastructure de stockage et de récupération. Le travail supplémentaire important est l'attribution, la structuration, le classement, la lignée et l'augmentation.
Est-ce qu'il apprend uniquement du chat ?
Non. Son positionnement actuel inclut explicitement la trace de l'exécution des agents, l'activité des outils, les décisions de flux de travail, les résultats et les échecs ainsi que la conversation.
Le rappel est-il vraiment sans jeton ?
Le rappel d'outil à la demande peut éviter de toujours injecter de la mémoire, mais le texte renvoyé utilisé par un LLM consomme des jetons de contexte. Incluez les coûts de récupération et de renforcement de la mémoire dans le total.
Memori peut-il stocker un état commercial faisant autorité ?
Il peut stocker le contexte à ce sujet, mais l'état actuel critique doit rester dans la base de données de l'application faisant autorité et être vérifié au moment de l'action.
Comment doivent fonctionner les corrections ?
Conservez la lignée, marquez la valeur vérifiée la plus récente comme canonique, supprimez l'ancienne valeur du rappel ordinaire et conservez l'historique uniquement dans la mesure où la politique le permet.
Qui devrait adopter Memori en premier ?
Des équipes composées d'agents multi-utilisateurs de longue durée dont les échecs mesurables proviennent d'un contexte d'exécution perdu et qui peuvent gérer un programme sérieux de confidentialité et d'évaluation.
Sources et vérification
- Site officiel des produits Memori
- Dépôt officiel open source
- Documentation officielle de l'architecture BYODB
- Aperçu et démo officiels de l'agent-trace
- Page de référence officielle
- Code de référence et matériaux dans le référentiel officiel
- Memori document technique
- Lancement de Product Hunt et explications du fabricant
- Conseils de sécurité des applications OWASP LLM
Dernière révision le 26 juillet 2026. L'architecture, les plans cloud, les résultats de référence et les intégrations peuvent changer. Vérifiez la documentation, les termes et le code actuels avant toute utilisation en production.
