Comparer quatre systèmes de mémoire pour les agents IA

La mémoire d’un agent est un choix de modélisation

Une fenêtre de contexte plus large ne résout pas le problème de mémoire d’un agent IA. Les fenêtres de contexte sont finies, alors que des faits utiles, des documents et des conversations peuvent devoir persister d’une session à l’autre. La génération augmentée par récupération (RAG) peut réinjecter des informations dans le contexte d’un LLM. La mémoire persistante soulève une autre question de conception : que doit retenir le système, et comment ces informations doivent-elles se comporter par la suite ?

La réponse façonne l’architecture. Graphiti, Hindsight, Mem0 et Supermemory étendent tous la mémoire au-delà du contexte immédiat d’un modèle, mais la représentent différemment. Choisir une approche commence par le comportement de mémoire dont l’application a besoin.

Quatre systèmes montrent à quel point la « mémoire » peut être définie différemment

Graphiti place les graphes de connaissances temporels au centre de sa conception. Un graphe de connaissances temporel représente des entités et leurs relations tout en suivant l’évolution de ces relations dans le temps. Graphiti se présente comme « the open-source temporal knowledge graph framework » et est disponible sur GitHub ou comme fondement du service de mémoire d’agent Zep. Graphiti indique qu’il réévalue les informations stockées au fil du temps afin que leur contexte reste correctement cadré.

Ce modèle convient aux applications où les relations et leur évolution comptent. Graphiti prend en charge Anthropic, Azure OpenAI, Google Gemini, Groq, Ollama et les API compatibles OpenAI, ainsi que des connecteurs vers des sources comme GitHub, Gmail, OneDrive et Notion.

Hindsight utilise un modèle différent. Disponible comme service cloud et comme projet pouvant être hébergé localement, Hindsight répartit les informations issues des sessions d’agent en quatre types de mémoire, chacun avec sa propre stratégie de stockage et de récupération. Il expose ces mémoires via trois interfaces programmatiques : retain stocke tout, d’un fait à une conversation complète ; recall récupère le contenu stocké ; et reflect exécute une boucle agentique sur une requête à l’aide de données antérieures.

Par exemple, l’intégration Continue de Hindsight peut ajouter une mémoire à long terme aux interactions avec un LLM hébergé localement dans Visual Studio Code. Un utilisateur peut invoquer la mémoire pertinente avec le mot-clé @hindsight ou configurer des règles d’injection automatique modifiables. La persistance devient alors une composante de la manière dont l’agent récupère les informations antérieures et raisonne à partir d’elles.

Mem0 définit lui aussi quatre types fondamentaux de mémoire, organisés différemment de ceux de Hindsight. Mem0 indique que chaque mémoire ajoutée passe par un processus de distillation puis est orientée vers une vector DB, une graph DB ou une SQL DB selon l’usage prévu. Une base de données vectorielle stocke des représentations numériques du contenu afin de retrouver des éléments similaires par le sens. L’architecture de Mem0 relie la stratégie de stockage à ce que représente une mémoire et à la manière dont l’application prévoit de la récupérer.

Supermemory part de contenus hétérogènes. Il indique ingérer du texte brut, des données structurées, des documents PDF et Microsoft Office, de la vidéo et de l’audio, ainsi que des images, puis utiliser ces éléments pour construire un graphe de contexte pour les conversations d’agent. Supermemory met également en avant l’extraction de contenu comme fonctionnalité. Son modèle fait de l’ingestion à travers plusieurs médias et formats de fichiers une partie du choix architectural.

La « mémoire persistante » peut donc désigner plusieurs modèles concrets : des connaissances en graphe maintenues dans le temps, quatre types de mémoire exposés via retain, recall et reflect, des mémoires distillées réparties entre trois catégories de bases de données, ou un graphe de contexte assemblé à partir de contenus hétérogènes.

Le temps et le partage transforment la persistance en exigence plus précise

La persistance signifie que l’information survit. Une architecture de mémoire doit aussi définir ce qui se passe à mesure que l’information vieillit et que les circonstances changent.

Graphiti indique traiter explicitement le temps comme une composante de son modèle de mémoire. Les informations stockées sont réévaluées au fil du temps pour que leur contexte reste correctement cadré. Mem0 utilise un mécanisme différent : les données plus anciennes sont dépréciées tout en restant disponibles, ce qui préserve un contexte plus large à long terme. Hindsight utilise également la dépréciation.

Cela crée un choix concret concernant l’historique. Un agent confronté à des faits changeants peut avoir besoin que les informations précédentes restent disponibles alors même que leur statut actuel évolue. Le simple rétablissement d’une ancienne session ne définit pas à lui seul ce comportement.

Le périmètre crée une autre exigence. Mem0 inclut un type distinct appelé mémoire organisationnelle, conçu pour des données partagées entre plusieurs agents ou différentes équipes. Dans le modèle de Mem0, la propriété de la mémoire peut dépasser le cadre d’un seul agent pour s’étendre à un périmètre organisationnel partagé.

Les équipes peuvent définir très tôt deux propriétés : la manière dont les informations changeantes doivent se comporter dans le temps, et les personnes qui doivent pouvoir les partager.

Le modèle de mémoire détermine l’infrastructure dont vous héritez

La représentation choisie pour la mémoire détermine aussi ce qu’une équipe doit exploiter.

La conception de Graphiti centrée sur les graphes nécessite une base de données graphe pour un usage local. Graphiti cite Neo4j comme option par défaut et la plus largement prise en charge, tandis qu’Amazon Neptune, FalkorDB et KuzuDB fonctionnent également. Postgres avec pgvector n’est pas indiqué comme option. Choisir le modèle de graphe temporel de Graphiti implique donc l’infrastructure graphe qui l’accompagne.

Mem0 en local a des exigences différentes. Mem0 indique qu’il nécessite une instance Python et une base de données vectorielle. Postgres avec l’extension pgvector est décrit comme un choix courant et simple, et peut être installé dans un venv Python. Mem0 prend en charge Anthropic, Google Gemini, OpenAI et des options auto-hébergées, notamment LangChain, LiteLLM, LM Studio et Ollama.

Supermemory propose un autre modèle de déploiement. Son édition open-source est décrite comme un binaire unique et autonome, sans base de données externe nécessitant un provisionnement séparé.

Supermemory distingue également ses éditions. La version open-source ne comprend pas les services de mise à l’échelle ni les connecteurs vers des services tiers, notamment Gmail, Google Drive et Notion, fournis avec l’édition enterprise. Les équipes doivent évaluer séparément la structure de déploiement et les capacités opérationnelles requises.

Choisir les exigences avant la commodité

Commencez par le comportement dont l’application a besoin. Déterminez si elle nécessite des connaissances temporelles, un stockage et une récupération typés avec réflexion, une mémoire organisationnelle partagée, ou un contexte hétérogène et multimodal.

Définissez ensuite comment l’historique doit être traité et qui peut partager la mémoire. Évaluez l’infrastructure nécessaire pour mettre en œuvre ce modèle. Bases de données graphe, vector stores, bases de données SQL, environnements Python, connecteurs, binaires locaux et services hébergés imposent des exigences opérationnelles différentes.

Cette séquence évite que la commodité de déploiement ne devienne implicitement une décision sur le modèle de mémoire.

Points clés à retenir pour les dirigeants

• Définissez d’abord ce que signifie la mémoire : Graphiti, Hindsight, Mem0 et Supermemory utilisent des modèles différents de mémoire persistante. Choisissez en fonction des comportements requis, comme les relations temporelles, la récupération typée, l’orientation du stockage ou l’ingestion de contenus hétérogènes.
• Anticipez le temps et le partage : La persistance seule ne suffit pas lorsque les faits changent ou que les mémoires doivent franchir les frontières entre agents et équipes. Définissez comment les informations historiques doivent être conservées et qui peut accéder à la mémoire partagée avant de sélectionner un système.
• Tenez compte des exigences d’infrastructure : Les modèles de mémoire s’accompagnent de dépendances opérationnelles différentes, des bases de données graphe de Graphiti aux vector stores de Mem0 et au binaire open-source autonome de Supermemory. Évaluez ces exigences en parallèle des besoins de déploiement et d’intégration.
• Faites passer les exigences avant la commodité : Commencez par les exigences de comportement de mémoire, d’historique et de partage avant de comparer les options de déploiement. Cela évite que la commodité de l’infrastructure ne dicte l’architecture de mémoire à long terme d’une application.