Structurer la mémoire par type réduit le nombre de tokens récupérés d'environ 40 %.

Pourquoi un stockage de mémoire plat finit par échouer

La plupart des tutoriels pour débutants apprennent à un agent LLM à « se souvenir » en ajoutant chaque nouvelle information à une liste unique et en renvoyant cette liste au modèle à chaque tour. Le code ne fait littéralement que trois lignes et produit une démo fonctionnelle. En pratique, la liste s'allonge sans contrôle. Deux symptômes apparaissent :

  • L'agent traite les données obsolètes comme étant toujours vraies, par exemple en fournissant un ETA expiré depuis des heures.
  • La fenêtre de contexte se remplit de détails insignifiants qui n'influencent jamais la réponse, ce qui gonfle les coûts d'API et ralentit les temps de réponse.

Un simple magasin de vecteurs (vector store) ou un cache clé-valeur basique ne peut pas distinguer l'intitulé de poste d'un utilisateur d'un statut de projet temporaire. Lorsqu'un agent effectue une recherche sémantique, l'algorithme de similarité peut faire remonter un vieil ETA simplement parce que la requête contient les mêmes mots, même si la donnée n'est plus pertinente.

Mémoire structurée : quatre catégories, un seul objectif

La solution consiste à ne plus traiter la mémoire comme un monolithe et à commencer à classer chaque entrée dans l'une des quatre catégories suivantes :

  • Faits utilisateur – attributs stables tels que le rôle d'un utilisateur, sa langue préférée ou son niveau d'accréditation. Ceux-ci changent rarement et peuvent être mis en cache pour toute la session.
  • Feedback – règles explicites que l'agent doit respecter, par exemple : « ne jamais révéler les mots de passe de la base de données » ou « éviter l'humour dans les requêtes de conformité ». Comme elles régissent le comportement, elles doivent figurer dans le prompt système plutôt que dans le pool de recherche.
  • État du projet – données à évolution rapide comme les ETA actuels, la progression des tâches ou des tokens temporaires. Ce compartiment nécessite une vérification d'expiration ; une fois qu'un horodatage sort d'une fenêtre définie, l'entrée doit être purgée.
  • Références – pointeurs vers des services externes, des identifiants de documents ou des points de terminaison d'API (endpoints). Il ne s'agit pas de contenu à afficher, mais de routes pour récupérer des données fraîches si nécessaire.

Mem0 permet aux développeurs d'attacher des métadonnées arbitraires à chaque enregistrement de mémoire. En indexant sur le champ « kind », une requête peut d'abord filtrer le compartiment pertinent avant que le LLM ne décide de la manière d'utiliser le résultat.

Récupération en deux étapes avec Mem0

  1. Extraire les mémoires par type – Une courte requête de filtrage demande à Mem0 « tous les feedbacks » ou « les entrées d'état de projet plus récentes qu'un court intervalle ». L'ensemble des résultats est déjà limité à la catégorie appropriée.
  2. Laisser le LLM décider – Les extraits filtrés sont insérés dans le prompt avec la question actuelle de l'utilisateur. Le modèle peut désormais raisonner à leur sujet sans avoir à trier des faits non pertinents.

Une illustration concrète : au lieu d'attendre qu'une correspondance sémantique fasse remonter la règle « ne pas se moquer de la base de données », le développeur injecte cette règle directement dans le prompt système au début de la session et la met en cache pour toute l'interaction. Même si la requête de l'utilisateur ne contient aucune référence explicite aux bases de données, le modèle connaît déjà la contrainte.

Astuces pratiques pour réduire les coûts

  • Mettre en cache les règles de feedback – Stockez l'ensemble des règles une seule fois par session et réutilisez-les plutôt que de relancer une recherche à chaque tour. Cela réduit l'utilisation de tokens à chaque cycle.
  • Ignorer les recherches d'état de projet lorsqu'elles sont non pertinentes – Si l'utilisateur pose une question purement conceptuelle (« Quelle est la différence entre l'apprentissage supervisé et l'apprentissage par renforcement ? »), il n'est pas nécessaire de récupérer des données d'ETA ou de progression des tâches.

En appliquant ces deux habitudes, l'utilisation de tokens peut être réduite d'environ 40 % par rapport à une approche naïve de mémoire plate. Les économies se traduisent directement par des factures d'API moins élevées et des délais d'exécution plus rapides, en particulier pour les agents qui restent actifs pendant de nombreux échanges.

Qui en profite, qui s'inquiète

Gagnants – Les équipes qui construisent des bots de support client, des assistants de flux de travail internes ou toute interface LLM multi-tours. Ils obtiennent des réponses plus fiables, évitent des erreurs embarrassantes causées par des données obsolètes et optimisent davantage leurs budgets.

À retenir

Si vous voulez un agent LLM qui reste performant lors de sessions prolongées, arrêtez d'entasser chaque fait dans une seule fenêtre de contexte. Marquez chaque mémoire comme fait utilisateur, feedback, état de projet ou référence, imposez des expirations si nécessaire, et laissez un outil comme Mem0 faire le gros du travail. Le résultat est une réponse plus fraîche, moins de tokens inutiles et une réduction notable des coûts d'exploitation.