Mémoire d’agent perdue face au RAG naïf dans 90 des 99 tests, selon une étude de l’UIUC

En bref

UIUC a testé 11 systèmes de mémoire d’agents face à une baseline RAG par chunks simple : 90 des 99 cellules de résultats se situent en dessous du RAG.
Les pertes s’accompagnent généralement d’une facture bien plus salée : A-Mem a dépensé 94,4 M de tokens de maintenance et 227 heures de construction hors ligne sur PersonaMem-v2 pour obtenir 48,4 contre 48,7 pour le RAG.
Cette taxe a trois sources : les preuves détruites au moment de l’écriture, les preuves enfouies au moment de la lecture, et la fragilité lorsqu’un autre modèle répond.
Le correctif bon marché n’est pas une meilleure architecture mémoire : récupérer depuis l’historique brut en parallèle du stock mémoire et reranker conjointement a fait passer SimpleMem de 73,6 à 82,8 sur LongMemEval-s.

La baseline que personne n’imprimait

La mémoire d’agents est devenue une catégorie de produit. Mem0, Zep, Letta, MemoryOS, MemOS et une douzaine de dépôts open source promettent tous qu’un agent cessera d’oublier, et le nombre d’articles grimpe trimestre après trimestre depuis 2024. Ce à quoi la plupart de ces articles se comparent, c’est une autre conception de mémoire. Le contrôle évident — récupérer des chunks de la conversation brute et les confier au modèle — est souvent absent ou sous-spécifié. (Source: arXiv — Memory Tax: Dissecting the Net Value of Agent Memory)

Une équipe de l’University of Illinois Urbana-Champaign, avec des co-auteurs de Tsinghua, Renmin, Waterloo et Verdent.ai, a mené ce contrôle. Leur prépublication, Memory Tax: Dissecting the Net Value of Agent Memory, évalue 11 systèmes de mémoire représentatifs sur trois benchmarks et trois backbones, et rapporte un résultat qui devrait être épinglé au-dessus de chaque lancement de « mémoire long terme » : de nombreux systèmes de mémoire dédiés obtiennent des scores inférieurs au RAG naïf. (Source: Memory Tax — project page)

Le décompte phare est sans détour. Sur 99 cellules système–benchmark–backbone, 90 se situent en dessous de la baseline RAG naïve, sur plus de 200 exécutions d’expériences, 20 Md+ de tokens et 10 M+ d’appels LLM. (Source: Memory Tax — project page)

Ce qui a réellement été testé

Le dispositif est la partie à lire avant le classement. Les 11 systèmes se répartissent en quatre familles : les stockages plats (A-Mem, SimpleMem, MemOS), les conceptions hiérarchiques ou par cycle de vie (MemoryOS, LightMem, OpenViking), les conceptions à base de graphes (HippoRAG2, PlugMem, MAGMA) et les politiques entraînées (Mem-T, Memory-R2). Chaque système a tourné sur Qwen3.5-4B, Qwen3.6-27B et GPT-5.6 Luna (low), en partageant un même modèle d’embedding, Qwen3-Embedding-0.6B, et les réponses ont été notées par un juge LLM adossé à Qwen3.6-27B, avec un accord juge–humain rapporté à 95,1 %, 100 % et 97,3 % sur les trois benchmarks. (Source: arXiv HTML — Memory Tax, §3.1 and Appendix A.3)

Les benchmarks sont LongMemEval-s (500 corpus d’environ 115 k tokens, une question chacun), PersonaMem-v2 (40 utilisateurs simulés sur 200, 934 questions à choix multiple à quatre options) et MINT-Eval (60 corpus sur 595, 1 557 questions testant la récupération sous interférence multi-cibles). (Source: arXiv HTML — Memory Tax, Appendix A.1)

Les auteurs ont aussi anticipé l’objection évidente. Comme les unités de mémoire vont d’un simple tour à un résumé de session, ils ont mesuré une « portée de récupération » — la part de tokens de mémoire que le modèle voit réellement — et ont augmenté le top-k de chaque système jusqu’à ce que sa portée soit au moins égale à celle d’un RAG à un tour. Les systèmes de mémoire n’ont pas été privés de contexte pour faire briller le RAG. (Source: arXiv HTML — Memory Tax, Appendix A.4)

Le tableau des scores

Sur LongMemEval-s avec Qwen3.6-27B, le RAG à deux tours obtient 81,4. A-Mem atteint 79,4 (−2,0), Mem-T 75,0 (−6,4), HippoRAG2 78,2 (−3,2), MAGMA 68,2 (−13,2) et OpenViking 58,8 (−22,6). Sur le plus faible Qwen3.5-4B, où la récupération est plus difficile, l’écart se creuse : le RAG se situe à 72,2 tandis qu’OpenViking s’effondre à 31,8, un déficit de 40,4 points. Les systèmes de mémoire gagnent parfois — MemOS gagne 1,0 et 1,5 point sur PersonaMem-v2 à 4B et 27B, Memory-R2 gagne 2,0 à 4B — mais les victoires sont petites et dispersées face à une longue colonne de défaites. (Source: Memory Tax — leaderboard, Table 1)

Les auteurs refusent la lecture paresseuse. La mémoire résout des questions que le RAG manque — c’est le bénéfice mémoire, l’effet attendu de l’organisation des faits, de la distillation des préférences ou du lien entre sessions. Elle perd aussi des questions que le RAG résout déjà — la taxe mémoire, causée par des preuves supprimées, enfouies ou réécrites. La valeur nette est le bénéfice moins la taxe, et dans la plupart de ces cellules, la soustraction devient négative. (Source: arXiv HTML — Memory Tax, §4.1)

La facture qui accompagne la perte

Le coût est le point où la comparaison cesse d’être académique. Sur PersonaMem-v2 avec Qwen3.6-27B, le RAG à un tour répond avec une précision de 46,8 pour 2,77 M de tokens d’inférence, 0,07 heure de travail hors ligne et 58,3 minutes de temps de QA de bout en bout. A-Mem obtient 48,4 mais paie 19,6 M de tokens pour construire, 94,4 M de tokens pour maintenir et 4,18 M pour inférer, avec 227,4 heures de construction hors ligne et 79,0 K d’appels LLM. Mem-T obtient 42,1 — quatre points en dessous du RAG — tout en facturant 161,9 M de tokens de maintenance et 6 807,9 minutes de QA en ligne, soit environ 113 heures contre 58 minutes pour le RAG. (Source: arXiv HTML — Memory Tax, Appendix E.2)

C’est là le problème structurel de la mémoire en tant que produit. Son argument économique repose sur l’amortissement : payer une fois à l’écriture, lire à bas coût pour toujours. Sur des backbones à poids ouverts, où relire un historique de 120 k tokens est une opération courante, l’amortissement n’arrive jamais. La dépense côté écriture est réelle, l’économie côté lecture est faible, et la précision n’est pas là pour justifier la différence. Les auteurs le formulent sans détour : les systèmes de mémoire « paient généralement bien plus cher que le RAG, mais souvent sans gain de précision équivalent ». (Source: Memory Tax — project page)

D’où vient la taxe

L’article dissèque la perte selon trois axes, et chacun correspond à une décision de conception qu’un développeur a déjà prise. (Source: arXiv HTML — Memory Tax, §4.2–4.4)

Fidélité. La compression, le résumé et l’extraction de faits ont lieu avant la récupération, si bien que les preuves perdues à l’écriture ne peuvent être récupérées à la lecture. Les auteurs isolent ce facteur en répondant à chaque question uniquement avec les unités de mémoire construites à partir de ses preuves de référence, retirant ainsi la récupération de l’équation. La perte d’information survit à ce contrôle, avec une gravité variable selon le système.

Accessibilité. Même des preuves intactes doivent être trouvées. En rejouant la récupération tour par tour, les systèmes de mémoire récupèrent moins de questions au premier tour que les chunks bruts ; les preuves sont fragmentées entre les unités, diluées par du contenu sans rapport, ou paraphrasées jusqu’à ne plus correspondre à la requête. MAGMA et LightMem s’approchent de leurs chiffres oracle lorsqu’on leur fournit les bonnes unités et restent bien en dessous en fonctionnement normal, ce qui pointe vers l’accès plutôt que le stockage.

Robustesse. Un agent à longue durée de vie peut écrire sa mémoire avec un modèle et la lire avec un autre. En gardant le stock fixe et en changeant le modèle qui répond, les systèmes de mémoire souffrent plus que le RAG, car les opérations dépendantes du modèle ajoutent de la variance par-dessus l’historique brut.

Des benchmarks qui flattent la récupération

Il y a un constat côté évaluation qui joue dans les deux sens. Sur un ensemble plus large de benchmarks de mémoire long terme, un matcher par mots-clés sans embeddings ni LLM — il prend les deux mots de requête les plus rares et remplit son budget avec les chunks qui les contiennent — passe 50 % sur certains benchmarks, et le RAG hybride atteint environ 70 %. Quand un appariement grossier franchit déjà la moitié des questions, la mémoire lourde a peu de marge pour démontrer sa valeur, et une perte modeste devient le signal visible. (Source: arXiv HTML — Memory Tax, §4.5 Benchmark Headroom)

Les auteurs prennent soin de ne pas qualifier le rappel d’accessoire — beaucoup de questions réelles sont précisément du rappel. Leur recommandation est procédurale, et c’est celle que la plupart des articles sur la mémoire ratent : rapporter le RAG à côté du système de mémoire, pour que les lecteurs voient la marge restante au lieu de la déduire.

Le correctif bon marché : lire aussi la source

Le résultat constructif est modeste et pratique. Comme les écarts par rapport à l’historique brut sont inévitables, il faut les rendre récupérables. La preuve de concept des auteurs, src-aug, récupère depuis l’historique brut en parallèle du stock mémoire et reranke les deux conjointement. Sur Qwen3.6-27B, elle fait passer SimpleMem de 73,6 à 82,8 sur LongMemEval-s tout en réduisant la taxe mémoire de 12,0 à 5,2, MemoryOS de 73,4 à 76,4 (taxe de 11,4 à 7,8) et Mem-T de 75,0 à 80,0 (taxe de 10,8 à 5,2). Les gains sur PersonaMem-v2 sont plus faibles mais positifs : SimpleMem de 46,7 à 49,6, MemoryOS de 48,2 à 53,0. (Source: Memory Tax — project page, Design Implications)

Pas de nouvelle architecture, pas de backbone plus puissant, pas de récupération plus profonde. Un second index sur la source et un reranker conjoint ont récupéré l’essentiel de la taxe sur trois systèmes. C’est un schéma d’index hybride que n’importe quelle équipe peut livrer cette semaine, et il recadre la question de la mémoire : la valeur n’est pas dans la couche d’abstraction, elle est dans le maintien d’un chemin de retour vers ce qui a été réellement dit.

L’article étend aussi le cadre au-delà de la mémoire de chat. En mémoire expérientielle — des agents réutilisant des traces de tâches passées sur ALFWorld, WebShop, Mind2Web, BigCodeBench, AppWorld et τ²-Bench — les workflows distillés battent le RAG naïf sur trajectoires pour les tâches web, tandis que plusieurs méthodes de mémoire restent derrière lui sur l’usage d’outils. En mémoire de modèle du monde pour la vidéo longue durée, la simple récupération d’images passées a battu les mémoires latentes et à base de cache sur les deux métriques. (Source: arXiv HTML — Memory Tax, §5.1–5.2)

Les limites méritent d’être énoncées. L’ensemble de baselines est représentatif, pas exhaustif ; les configurations officielles ont été suivies plutôt que réglées de façon exhaustive ; les benchmarks sont statiques, hors ligne et en anglais ; et PersonaMem-v2 et MINT-Eval ont été évalués sur des sous-ensembles stratifiés en raison du coût des API, sans modèle de pointe plus fort que GPT-5.6 Luna (low). (Source: arXiv HTML — Memory Tax, Limitations)

Ce que les développeurs devraient faire

Lancez la comparaison avant d’acheter l’architecture : gardez une baseline RAG par chunks sur l’historique brut, notez-la sur les mêmes questions, et journalisez les tokens et les appels à côté de la précision. Si la couche mémoire ne bat pas cette baseline, la couche est un coût assorti d’un récit.

Instrumentez ensuite les trois modes de défaillance. Journalisez si la preuve nécessaire à une réponse a jamais été écrite en mémoire, si elle était récupérable au premier tour, et si un changement de modèle dégrade le stock. Gardez une échappatoire vers la source brute pour tout ce qui est important, et considérez par défaut comme une perte d’information toute écriture mémoire qui ne peut être rattachée à un tour source précis. Pour les agents qui lisent et réécrivent leurs propres notes — le schéma derrière la plupart des systèmes ici — cette piste d’audit fait la différence entre un atout et un passif. Couverture TAR associée : la mémoire sémantique LanceDB dans Hermes Agent et la mémoire continue de Komi pour les agents de code.

FAQ

L’étude dit-elle que la mémoire d’agents est inutile ?

Non. La mémoire gagne sur un sous-ensemble de questions où l’organisation ou l’abstraction aide — elle perd simplement plus de questions qu’elle n’en gagne dans 90 des 99 cellules mesurées, généralement à un coût plus élevé.

La baseline RAG est-elle un homme de paille ?

Les auteurs ont aligné la portée de récupération pour que chaque système de mémoire voie au moins autant de son stock qu’un RAG à un tour, et ont validé la baseline par des ablations. C’est un contrôle inhabituellement rigoureux, pas un contrôle faible.

Pourquoi les systèmes de mémoire échouent-ils si les preuves sont préservées ?

À cause de l’accès. Les preuves sont fragmentées entre les unités, diluées par du contenu sans rapport, ou paraphrasées jusqu’à ne plus correspondre à la requête, si bien qu’elles ne sont pas récupérées au premier tour.

Quelle est l’amélioration la moins coûteuse ?

Récupérer depuis l’historique brut en parallèle du stock mémoire et reranker conjointement (src-aug). Cela apporte jusqu’à 9,2 points de précision sur LongMemEval-s dans les expériences de l’article.

Les résultats se transposent-ils au-delà de la mémoire de chat ?

En partie. Les workflows distillés aident sur les tâches web, mais plusieurs méthodes de mémoire restent derrière le RAG sur trajectoires pour l’usage d’outils, et la récupération naïve d’images a battu les mémoires latentes en vidéo longue durée.

Pour aller plus loin

— The Agent Report