L'asymétrie qui rend la hiérarchisation rentable
Si vous changez une chose dans la façon dont vous concevez la mémoire d'un agent, que ce soit celle-ci : cessez de traiter le coût de stockage et le coût d'attention comme s'il s'agissait de la même chose.
J'ai exploré cela en profondeur sur 19 systèmes, et le constat qui revient sans cesse est que ceux qui gèrent bien la mémoire ne sont pas nécessairement ceux avec la récupération la plus sophistiquée. Ce sont ceux qui ont compris quels souvenirs méritent d'être dans le prompt. C'est un problème différent, avec une solution différente.
Le stockage est bon marché. L'attention est coûteuse. Un modèle avec un contexte de 128k lisant 110k de contexte médiocre n'est pas, empiriquement, un meilleur agent que le même modèle lisant 8k de contexte soigneusement sélectionné. La recherche est cohérente : la qualité de la récupération se dégrade à mesure que le contexte se remplit de bruit, et cette dégradation n'est pas linéaire. Le modèle n'ignore pas simplement le matériel non pertinent. Il le traite, et ce traitement étouffe le signal.
Le stockage n'a pas cette propriété. Un fait stocké dans une base de données ne coûte rien à conserver. Le coût n'arrive que lorsque vous le récupérez et le chargez dans le prompt. Ce qui signifie que la question n'est pas « devrais-je stocker ceci ? » mais « devrais-je récupérer ceci, et si oui, quand ? »
Ce recadrage est l'origine de la hiérarchisation. Différents éléments de mémoire ont différents schémas d'accès. Certaines choses, un agent en a besoin à chaque tour : le nom de l'utilisateur, son projet en cours, ses préférences déclarées. Certaines choses, il en a besoin souvent mais pas toujours : décisions récentes, questions ouvertes, faits épisodiques des dernières sessions. Certaines choses, il doit pouvoir les trouver si nécessaire, mais ne devrait jamais alourdir chaque tour : notes de réunion d'il y a trois mois, tâches terminées, transcriptions brutes, documentation de référence ponctuelle.
Un stockage plat traite les trois catégories de manière identique. Les éléments chauds paient le coût de recherche des éléments froids. Les éléments froids gonflent le prompt avec du bruit. Il n'y a pas de mécanisme pour que les éléments soient promus à mesure qu'ils deviennent plus pertinents, ni de mécanisme pour qu'ils vieillissent et disparaissent à mesure qu'ils deviennent moins pertinents. L'analogie avec les systèmes d'exploitation est exacte : les CPU ont L1, L2, L3, RAM, SSD et disque non pas parce que les octets sont différents, mais parce que la fréquence d'accès varie de plusieurs ordres de grandeur. Sept des 19 systèmes que j'ai examinés avaient déjà construit une hiérarchisation explicite avant que je ne commence à les étudier. Deux d'entre eux méritent d'être compris en détail.
MemoryOS comme implémentation de référence
MemoryOS est l'implémentation la plus claire de mémoire hiérarchisée parmi les 19 systèmes. Trois niveaux, chacun avec une forme de données distincte, un budget de latence distinct et un rôle distinct.
Le niveau court-terme est une deque Python avec une longueur maximale de 10 paires QA. Pas d'embeddings, pas d'index de recherche, pas de suivi de chaleur. C'est du matériel brut conversationnel pur, les dix derniers échanges, disponible avec une latence de l'ordre de la microseconde. Lorsque la deque est pleine, la paire la plus ancienne est drainée vers le niveau moyen-terme.
Le niveau moyen-terme contient jusqu'à 2000 sessions. Chaque session porte un résumé, un embedding, un ensemble de mots-clés et des compteurs de chaleur. Le niveau est indexé avec Faiss et recherché par similarité cosinus. Lorsque le niveau atteint sa capacité, les sessions les plus froides sont évincées. Lorsqu'une session devient suffisamment chaude, elle est promue au niveau long-terme.
Le niveau long-terme est un schéma psychologique et d'alignement à 90 dimensions, deux deques de base de connaissances, une pour les faits utilisateur et une pour les faits assistant, chacune plafonnée à 100 entrées. C'est la couche persistante, celle qui survit aux sessions et porte le modèle durable de l'utilisateur.
La formule de chaleur qui régit la promotion fait douze lignes en Python. Trois signaux : la fréquence des visites (un analogue de LFU), la profondeur d'interaction (une approximation de l'engagement thématique) et la décroissance de la récence (exponentielle avec une demi-vie de 24 heures). Un segment franchit le seuil de promotion à 5,0. Après la promotion, les compteurs de visites et d'interactions sont remis à zéro, et la chaleur retombe approximativement à 1,0.
La décision de conception qui est facile à manquer : la chaleur contrôle la promotion, pas la récupération. Le récupérateur est purement sémantique, similarité cosinus sur les embeddings du moyen-terme. La chaleur est un signal d'arrière-plan qui décide si un segment doit passer au niveau long-terme. Les deux préoccupations sont découplées, et ce découplage est plus important que la formule elle-même.
Ce que MemoryOS laisse de côté mérite d'être nommé. Les coefficients sont codés en dur à 1,0, il n'y a pas de mécanisme pour apprendre les poids à partir des schémas d'utilisation réels. Il n'y a pas de chemins de rétrogradation ; une fois que quelque chose atteint le niveau long-terme, il y reste. Et la formule optimise la fréquence plutôt que l'importance. Un fait critique mais rare (le nom d'un partenaire, une condition médicale, une contrainte forte) peut ne jamais franchir le seuil de promotion s'il n'apparaît qu'une seule fois. Une fois que le niveau moyen-terme évince le segment, le fait est perdu.
Les niveaux dérivés de la théorie chez Hindsight
Hindsight arrive à la même structure à trois niveaux à partir d'un point de départ complètement différent. Là où MemoryOS s'inspire de la théorie des caches des systèmes d'exploitation, Hindsight s'inspire des sciences cognitives.
Les trois niveaux sont Monde, Expérience et Observations. Monde contient des affirmations objectives sur l'univers, des vérités de base, toujours actives, durables. Expérience contient les actions à la première personne du système lui-même, l'enregistrement épisodique. Observations contient des croyances consolidées dérivées de faits de Monde et d'Expérience, avec des ID de mémoire source, un compteur de preuves et un champ d'historique qui suit l'évolution de la croyance.
Les trois niveaux vivent dans la même table de base de données, différenciés par un discriminateur de type de fait. Des index HNSW partiels sont construits par type de fait. Le schéma est unifié ; les schémas d'accès ne le sont pas.
La promotion chez Hindsight n'est pas basée sur des compteurs. C'est une consolidation par lots pilotée par LLM. Lorsqu'un nouveau fait est écrit, il est mis en file d'attente dans une table d'opérations asynchrones. Un worker en arrière-plan récupère les nouveaux faits ainsi que les observations existantes qui se chevauchent, construit un prompt par lots et demande au modèle de créer, mettre à jour et supprimer. Les mémoires source sont estampillées avec un horodatage consolidated-at pour éviter le retraitement. Chaque nouveau fait, indépendamment de sa fréquence d'accès, est considéré pour une promotion vers le niveau Observations.
C'est la différence clé avec MemoryOS. En liant la promotion vers le niveau supérieur à la consolidation plutôt qu'à la chaleur, Hindsight évite l'angle mort pour les faits critiques mais rares. Un seul passage de consolidation considère chaque nouveau fait. La fréquence est sans importance pour décider si quelque chose est promu.
En clair : deux systèmes, des principes fondateurs différents, des langages d'implémentation différents, des cas d'usage cibles différents, et tous deux aboutissent à trois niveaux avec du matériel brut en bas, une couche de travail au milieu, et une couche persistante synthétisée en haut. Tous deux utilisent la promotion asynchrone. Tous deux conservent la provenance vers les niveaux inférieurs. C'est à cela que ressemble l'évolution convergente dans l'architecture logicielle, et c'est le signal le plus fort que je connaisse qu'un modèle est structurellement porteur.
La hiérarchisation par genre de @supermemory
supermemory opère sous la forme d'un déploiement d'API géré, ce qui modifie l'implémentation sans changer l'architecture. Les trois niveaux sont le profil statique, le profil dynamique, et le stockage de documents et de segments.
Le profil statique contient des faits stables à long terme, le niveau chaud. Il est renvoyé sous forme de tableau statique depuis l'endpoint de profil, mis en cache en périphérie, avec un budget de latence d'environ 50 ms. Le profil dynamique contient le contexte récent et épisodique, le niveau tiède. De nombreuses entrées portent un champ forgetAfter qui définit un TTL. Le stockage de documents et de segments est le niveau froid, interrogé via des endpoints de recherche lorsque nécessaire.
L'attribution des niveaux se fait au moment de l'écriture. Un LLM d'extraction classifie chaque mémoire entrante avec un booléen isStatic et éventuellement une valeur forgetAfter. La classification est imposée par un prompt d'extraction fermé, uniforme pour tous les consommateurs.
La forme du déploiement d'API géré permet trois choses qu'un concepteur de processus interne ne peut pas copier directement mais devrait comprendre. Les données du niveau froid peuvent reposer sur du matériel moins cher (stockage d'objets pour les octets bruts, un store relationnel standard pour les métadonnées et les segments), avec le profil chaud mis en cache séparément en périphérie. Le niveau chaud a son propre endpoint avec son propre SLA, séparé du chemin de recherche. Et le prompt d'extraction est centralisé, ce qui signifie que l'attribution des niveaux est cohérente d'une manière que la classification par agent l'est rarement.
Les compromis sont réels. Un niveau chaud distant n'est rapide que si le réseau est rapide. L'agent ne peut pas outrepasser la classification du niveau par le moteur. Le prompt d'extraction est une boîte noire. Mais le modèle architectural (niveau chaud comme son propre endpoint, niveau froid sur du matériel moins cher, attribution des niveaux au moment de l'écriture) vaut la peine d'être copié même si la forme de déploiement ne l'est pas.
Promotion vs. typologie fixe
mem9 est le cas contrasté qui clarifie ce que la hiérarchisation n'est pas.
mem9 a une colonne memory-type avec trois valeurs : pinned, insight et digest. Les mémoires pinned sont attribuées par des chemins d'écriture de contenu explicites, créées manuellement, protégées de la réconciliation par LLM. Les insights sont attribués par chaque écriture extraite par LLM, mutables, versionnables, remplaçables. Les deux participent au même rappel hybride avec le même score RRF. Le champ type est un indicateur de protection en écriture, pas un filtre de récupération ni un signal de niveau.
C'est de la typologie, pas de la hiérarchisation. La distinction est importante car les deux sont faciles à confondre. La typologie décrit la gouvernance : qui peut muter cette mémoire, sous quelles conditions. La hiérarchisation décrit les schémas d'accès : à quelle fréquence cette mémoire est-elle nécessaire, et quelle représentation de stockage sert le mieux cette fréquence. Un système peut avoir les deux. Le isStatic de supermemory est un signal de niveau, tandis qu'un indicateur isInference séparé est plus proche d'une classe de gouvernance. Mais les confondre produit le plus d'ambiguïté en pratique.
Si vous vous retrouvez à ajouter un champ type à vos lignes de mémoire, la question à se poser est de savoir si le champ décrit un schéma d'accès ou une classe de gouvernance. Si c'est un schéma d'accès, vous construisez une hiérarchisation. Si c'est une classe de gouvernance, vous construisez une typologie. Les deux sont utiles. Ce ne sont pas la même chose.
Ce que le plat vous coûte
Quatre choses concrètes découlent de l'utilisation d'un stockage mémoire plat.
Le chemin chaud paie le coût de recherche du chemin froid. Chaque récupération parcourt le même index sur les mêmes éléments. L'agent qui cherche le nom de l'utilisateur paie le même coût de recherche que l'agent qui cherche une note de réunion d'il y a six mois. À petite échelle, c'est invisible. À grande échelle, c'est un problème de latence.
Le chemin froid gonfle le prompt avec du bruit. La récupération renvoie des éléments sémantiquement proches, ce qui inclut le contexte permanent, les faits remplacés, et le matériel qui est factuellement correct mais non pertinent pour le tour en cours. Le modèle traite tout cela. Le rapport signal/bruit dans la fenêtre de contexte se dégrade à mesure que le stockage grandit.
Il n'y a pas de mécanisme pour que les éléments soient promus. La mémoire n'est pas statique. Un fait épisodique éphémère du début d'une relation peut, avec le temps, devenir un signal durable sur les préférences ou les contraintes de l'utilisateur. Un stockage plat n'offre aucun mécanisme pour remarquer cette transition. L'élément reste dans la même représentation que celle dans laquelle il a été écrit, indépendamment de l'évolution de sa pertinence.
Il n'y a pas de mécanisme pour que les éléments vieillissent et disparaissent. La rétrogradation n'est pas une suppression. Un stockage plat qui veut supprimer du matériel obsolète doit le supprimer. Un stockage hiérarchisé peut le déplacer vers une représentation plus froide, toujours trouvable, sans plus alourdir le chemin chaud. Le stockage plat impose un choix binaire que le stockage hiérarchisé n'impose pas.
Le résultat net
18 des 19 systèmes implémentent une hiérarchisation, y font allusion ou ont des recommandations explicites pour cela. L'exception est mem9, qui a une couche de typologie résolvant un problème différent et qui bénéficierait d'une hiérarchisation par-dessus.
Si vous construisez la mémoire d'un agent à partir de zéro, la progression que les 19 systèmes indiquent est la suivante. Identifiez ce dont l'agent a besoin à chaque tour : c'est votre niveau chaud. Identifiez ce dont il a besoin souvent mais pas toujours : c'est votre niveau tiède. Identifiez ce qu'il doit trouver si nécessaire mais ne devrait jamais alourdir chaque tour : c'est votre niveau froid. Choisissez un mécanisme de promotion : basé sur la chaleur comme MemoryOS, le jugement du LLM comme Hindsight, ou la classification au moment de l'extraction comme supermemory. Choisissez un mécanisme de rétrogradation : décroissance temporelle, TTL ou catégories de fraîcheur. Gardez la promotion et le score de récupération séparés au début : le découplage est plus facile à ajouter qu'à défaire. Suivez la provenance des niveaux supérieurs vers les niveaux inférieurs, afin de toujours pouvoir répondre à la question de savoir d'où vient une croyance synthétisée.
Les 19 systèmes ne sont pas unanimes sur grand-chose. Sur ce point, ils le sont : un seul stockage mémoire plat est la mauvaise valeur par défaut pour tout système de mémoire d'agent non trivial.
Le stockage est bon marché. L'attention est coûteuse. Construisez le système qui exploite la différence.
Si vous avez trouvé cet article intéressant, n'hésitez pas à le partager.
