[RAG (retrieval-augmented Generation)](https://en.wikipedia.org/wiki/Retrieval-augmented_Generation) augmente un LLM en récupérant les passages pertinents d'un corpus externe, souvent via des intégrations et une recherche de similarité, puis en les alimentant en tant que contexte afin que le modèle puisse répondre à partir de données à jour ou spécifiques au domaine.

Cela fonctionne bien pour la recherche de documents. Pour la mémoire des agents, elle s’effondre.

Un nouvel article, « Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation » (Hu et al., février 2026 ; [voir article](https://arxiv.org/abs/2602.02007)), du King's College de Londres et de l'Alan Turing Institute, explique pourquoi et suggère une meilleure approche.

## Pourquoi RAG n'est pas à la hauteur de la mémoire de l'agent

Le RAG standard suppose un corpus volumineux et mixte : intégrer le texte, récupérer [top-k](https://en.wikipedia.org/wiki/Nearest_neighbor_search) par similarité, concaténer en tant que contexte.

La mémoire de l'agent est à l'opposé : un flux limité et cohérent où le même fait apparaît dans de nombreuses formulations. L'application de RAG ici crée trois problèmes :

1. **Top-k redondant.** Vous demandez « Quand ai-je vu le dentiste pour la dernière fois ? » Dans un corpus de documents, top-k peut renvoyer quelques paragraphes pertinents provenant de différentes sources. Dans la mémoire de l'agent, de nombreux morceaux disent presque la même chose (« Dentiste prévu le 15 mars », « Rendez-vous chez le dentiste le 15 mars », « Dentiste réservé pour le 15 mars »). Top-k se remplit de répétition. Le journal appelle cela « l’effondrement en une seule région dense ». La similarité ne parvient pas à séparer ce qui est *nécessaire* de ce qui est simplement *similaire*.
2. **L'élagage brise les chaînes de preuves.** Vous demandez « Avons-nous résolu le litige concernant la facture ? » La réponse dépend d'une chaîne : « La facture n°123 a été contestée », puis « Nous avons accepté un remboursement partiel », puis « Payé le montant convenu ». L'élagage post-hoc peut conserver la "facture payée n° 123" et supprimer les tours précédents. Le modèle répond alors « Oui, résolu » sans savoir qu’il y a eu un litige. L’élagage fragmente les preuves liées dans le temps et produit de fausses réponses.
3. **La similarité ignore la structure.** Vous demandez « Quel est l'état du voyage à Barcelone ? » Vous avez besoin du projet, de la tâche (par exemple réserver des vols) et du résultat. La similarité renvoie des morceaux qui mentionnent « Barcelone » ou « voyage » : peut-être une mention aléatoire, un voyage passé, une tâche d'un projet différent. Il vous fallait un parcours structurel (ce projet, ces tâches, ces résultats). La similarité ne code pas cela. La structure oui.

## Structure plutôt que similarité

Une meilleure approche consiste à utiliser la structure pour déterminer ce qui est chargé, et non la similitude. Saisissez des entités (tâches, contacts, transactions, événements) et récupérez par schéma, ID d'entité, relations et chronologies. Conserver les observations et les résultats dérivés sous forme d'unités entières ; n'élaguez pas l'intérieur des blocs de preuves. La même entrée et le même schéma donnent la même sortie. Pas de LLM dans le chemin critique.

## Ce que montre le journal

Le système du document (xMemory) construit une hiérarchie à quatre niveaux (messages aux épisodes, sémantique aux thèmes) avec des intégrations et des résumés LLM. Il bat cinq autres systèmes (Naive RAG[^1], A-Mem[^2], MemoryOS[^3], LightMem[^4], Nemori[^5]) sur LoCoMo et PerLTQA, les ensembles de données de référence pour la mémoire de conversation à long terme et la réponse personnelle aux questions à long terme. Le document ne nécessite pas d'intégrations ou de LLM ; cela nécessite une structure. Vous pouvez y parvenir avec une hiérarchie apprise (xMemory) ou avec une conception déterministe axée sur le schéma. L'article documente également la fragilité de la structure générée par LLM (A-Mem, MemoryOS) : écarts de formatage, mises à jour échouées. La structure déterministe, axée sur le schéma, constitue une base plus fiable.

## xMemory contre Néotome

Neotoma est la [couche de mémoire structurée](/posts/truth-layer-agent-memory) que je construis : le schéma d'abord, déterministe, construit pour la provenance et la relecture. Les deux systèmes vont au-delà de RAG ; ils diffèrent dans la façon dont ils construisent la structure.

**xMemory** construit une hiérarchie à quatre niveaux (messages aux épisodes, sémantique aux thèmes) avec des intégrations et des résumés LLM. Les épisodes sont des blocs contigus ; la sémantique est des faits réutilisables ; sémantique des groupes de thèmes pour un accès de haut niveau. Un objectif de parcimonie-sémantique équilibre la taille du thème. Une taille trop grande entraîne une récupération redondante ; des fragments de preuves trop petits. La récupération s'effectue de haut en bas : sélectionnez un ensemble compact de thèmes et de sémantiques, puis étendez-vous aux épisodes intacts (et éventuellement aux messages) uniquement lorsque cela réduit l'incertitude du modèle de lecteur. Pas d'élagage à l'intérieur des unités. Sur ces critères, il bat les cinq références en matière de qualité et d’utilisation des jetons. L'article note que la structure générée par LLM (par exemple dans A-Mem, MemoryOS) est fragile : écarts de formatage, mises à jour échouées. Parce que xMemory construit sa hiérarchie avec des résumés LLM, il adopte la même fragilité.

**Neotoma** construit une structure sans LLM dans le chemin critique. Les entités sont typées ; les relations et les délais sont explicites ; la récupération utilise un schéma, des ID d'entité, des relations et des plages de temps. La même entrée et le même schéma donnent la même sortie. Les schémas évoluent encore. Les champs inconnus atterrissent dans une couche de préservation. Un pipeline déterministe peut promouvoir des champs de confiance élevée dans le schéma. Un LLM peut suggérer de nouveaux champs ou types en tant que recommandations en attente, appliquées uniquement via des outils ou une approbation humaine. L'inférence reste consultative : les modifications de schéma passent par des outils ou par l'approbation humaine ; l'extraction et la réduction restent déterministes ; le schéma reste source de vérité. La critique de l'article s'applique lorsque le modèle *pilote* la structure, et non lorsqu'il suggère que des humains ou des outils s'appliquent. L’ingestion pour récupérer reste déterministe.

### Comparaison

| | xMémoire | Néotome |
|--|--------|--------|
| Source de la structure | Embeddings + résumés LLM (épisodes, sémantique, thèmes) | Extraction et réducteurs déterministes basés sur le schéma |
| Hiérarchie | Quatre niveaux (messages, épisodes, sémantique, thèmes), guidés par un objectif de parcimonie-sémantique | Entités typées, relations, chronologies (pas de « niveaux » fixes) |
| Récupération | De haut en bas : sélection représentative sur le graphique, puis expansion en fonction de l'incertitude vers des épisodes/messages intacts | Par schéma, ID d'entité, relations, chronologies |
| Contrôle de redondance | Sélection représentative + expansion uniquement lorsque l'incertitude diminue | Les requêtes structurelles renvoient ce que vous demandez ; aucune similarité ne s'effondre |
| Unités intactes | Oui (pas d'élagage dans les épisodes/messages) | Oui (observations et entités conservées entières) |
| Déterminisme | Non (la structure générée par LLM varie) | Oui (même entrée, même schéma, même sortie) |
| Fragilité | Un article cite des écarts de formatage LLM et des échecs de mises à jour dans des systèmes similaires | Le schéma et le code sont explicites ; pas de LLM dans le chemin critique |

### Avantages relatifs

**xMemory** excelle lorsque l'entrée est un flux de conversation et que vous souhaitez une structure sans définir de schémas. Exemple : une conversation de longue durée avec un assistant au cours de laquelle vous demandez « qu'avons-nous décidé concernant le voyage ? » ou "quand ai-je mentionné le budget pour la dernière fois ?" xMemory crée des épisodes, une sémantique et des thèmes ; la récupération est efficace en termes de jetons. Il s'adapte également aux prototypes rapides (tickets d'assistance, notes de réunion) pour lesquels vous ne souhaitez pas encore créer de schémas. Vous acceptez la dérive hiérarchique et n’avez pas besoin d’auditabilité ou de requête de premier ordre par entité.

**Neotoma** excelle lorsque vous avez besoin de traçabilité ou que vos données sont déjà structurées. Exemple : décisions vérifiables (paiements, accords, résultats des tâches) où les mêmes entrées et schémas doivent produire le même instantané. Les modifications du schéma sont versionnées et appliquées de manière déterministe ; pas de LLM dans le parcours. C'est également la solution idéale pour les entités typées (tâches, contacts, transactions, événements) avec des relations et des délais. Requête par type d'entité, ID, relation ou plage de temps. Neotoma les traite comme des autochtones ; xMemory nécessiterait une sérialisation en texte et perdrait un accès de première classe.

## Structuration itérative dans la conversation

Une structure émerge souvent dans le dialogue : « ajoutez une tâche pour cela », « notez que nous avons accepté de payer 500 » et l'agent agit. Les deux systèmes gèrent cela différemment.

**xMemory :** La conversation est l'objet principal. Ce que fait l'agent (par exemple « J'ai créé une tâche pour le dentiste ») reste dans le flux de messages et se décline en épisodes, sémantique et thèmes. Vous obtenez une hiérarchie mieux apprise, mais pas de graphique d'entité distinct et interrogeable. La structure vit à l’intérieur de la hiérarchie.

**Néotome :** La conversation est une source d'observations. Lorsque l'agent crée ou met à jour une tâche, un contact ou une transaction, ces opérations produisent des observations et des instantanés d'entité. Les nouveaux champs du dialogue peuvent atterrir dans une couche de préservation et être promus dans le schéma lorsque la confiance est élevée. Le dialogue et le graphique structuré restent synchronisés car tous deux écrivent dans le même magasin.

**Récupération différente.** xMemory prend en charge la récupération sémantique sur la hiérarchie. Les questions en langage naturel (« Qu'avons-nous décidé à propos du dentiste ? ») renvoient des thèmes, une sémantique ou des épisodes intacts. Il ne prend pas en charge la récupération structurelle (pas de types d'entités avec ID et relations). Cela conduit à des échecs attendus dans trois types de cas :

- **Preuves réparties d'un tour à l'autre.** "Avons-nous résolu le litige concernant la facture ?" Le différend, la négociation et le paiement peuvent vivre dans différents épisodes ou thèmes ; la récupération peut en faire apparaître un ou deux et manquer le reste, de sorte que le modèle répond de manière incorrecte ou incomplète.
- **Définir des requêtes.** "Quelles tâches sont dues avant vendredi ?" ou "Afficher tous les paiements pour contacter X." Il n’y a aucune entité de tâche ou de transaction à filtrer ; vous obtenez des correspondances sémantiques (messages mentionnant « tâche » et « vendredi » ou « contact X »), pas une liste définitive, donc les résultats sont partiels ou bruyants.
- **Traversée de relations.** "Quelles tâches du projet Y sont encore en attente ?" Sans graphique projet-tâche, la récupération renvoie des extraits de conversation qui peuvent omettre certaines tâches ou projets ; vous ne pouvez pas énumérer de manière fiable par relation.

Neotoma prend en charge les deux. Vous pouvez poser des questions de style sémantique lorsque les données se trouvent dans le magasin. Vous bénéficiez également d'une récupération structurelle par type d'entité, ID, relation et fenêtre temporelle, de sorte que les requêtes définies et le parcours de relation renvoient des résultats complets et de première classe. Le compromis est que vous avez besoin de schémas et d'un magasin qui acceptent ces observations.

## La structure plutôt que la similarité, le schéma d'abord plutôt que la fragilité

Pour la mémoire de l'agent, la similarité sur le texte brut échoue. La récupération doit être guidée par la structure : la manière dont vous décomposez et organisez le flux, et non le nombre de fragments correspondant à une requête. L'article montre qu'une hiérarchie apprise (xMemory) bat le RAG naïf et que la structure générée par LLM est fragile.

Cependant, une voie déterministe axée sur le schéma vous offre le même avantage structurel sans cette fragilité. Je construis [Neotoma](https://github.com/markmhendrickson/neotoma) sur ce dernier afin que l'ingestion et la récupération restent reproductibles et que le schéma reste source de vérité.

[^1] : **Naive RAG :** intègre des mémoires, récupère le top-k fixe par similarité, pas de hiérarchie. Pas de projet distinct ; référence définie dans le [article](https://arxiv.org/abs/2602.02007).
[^2] : **A-Mem :** mémoire agent pour les agents LLM ; Liens de style Zettelkasten et mises à jour pilotées par agent vers un réseau de mémoire. [Projet](https://github.com/agiresearch/A-mem).
[^3] : **MemoryOS :** stockage hiérarchique court/moyen/long terme avec modules de mise à jour, de récupération et de génération pour les agents personnalisés. [Projet](https://github.com/BAI-LAB/MemoryOS).
[^4] : **LightMem :** mémoire légère inspirée des étapes Atkinson-Shiffrin ; consolidation thématique et mises à jour hors ligne à long terme. [Projet](https://github.com/zjunlp/LightMem).
[^5] : **Nemori :** mémoire épisodique auto-organisée avec segmentation des événements et pré-calibrage pour des connaissances adaptatives. [Projet](https://github.com/nemori-ai/nemori).