Résumé technique : Mémoire d'agent : Caractérisation et implications systémiques des charges de travail à horizon temporel long et avec état

Énoncé du problème

Les agents basés sur les grands modèles de langage (LLM) sont de plus en plus déployés pour des tâches à horizon temporel long nécessitant un raisonnement soutenu sur des historiques d'interaction étendus, comme des assistants personnels suivant des préférences sur plusieurs semaines ou des agents de codage maintenant le contexte d'un projet à travers des sessions. Alors que les premiers LLM reposaient sur des connaissances paramétriques et la génération augmentée par récupération (RAG) qui découplait les connaissances des paramètres en utilisant des corpus externes statiques, les agents avec état nécessitent un corpus de mémoire mutable produit par le propre flux d'interaction de l'agent.

S'appuyer uniquement sur la fenêtre de contexte du modèle pour la mémoire fait face à trois limites fondamentales :

1. Capacité : Les interactions multi-sessions continues dépassent inévitablement les budgets de contexte fixes.
2. Coût : Les coûts de préremplissage (prefill) augmentent de manière quadratique avec la longueur de l'historique, et la pression sur la mémoire du cache KV devient ingérable à travers les sessions en raison de l'éviction du cache.
3. Fidélité : Le raisonnement et le rappel se dégradent dans les séquences longues, présentant une courbe de performance en « U » où les faits situés dans le milieu du contexte sont perdus.

Par conséquent, les agents nécessitent des systèmes de mémoire externe pour persister, récupérer sélectivement et mettre à jour l'état. Cependant, un écosystème riche de systèmes de mémoire d'agent a émergé avec des conceptions diverses (récupération plate, extraction médiée par LLM, structures basées sur des graphes, flux de contrôle agentiques), pourtant leur comportement au niveau système reste non caractérisé. Les benchmarks existants se concentrent purement sur la précision en aval, ignorant la redistribution asymétrique des coûts computationnels (construction vs récupération) qui impacte de manière critique le déploiement à grande échelle.

Méthodologie

Les auteurs présentent la première caractérisation systémique des algorithmes de mémoire d'agent, couvrant l'ensemble de l'espace de conception.

1. Taxonomie et suite de charges de travail

L'étude introduit une taxonomie orientée système classant dix systèmes de mémoire d'agent représentatifs selon quatre axes : construction, stockage, récupération et mutabilité. Ces systèmes sont catégorisés en quatre paradigmes :

• Paradigme I : Mémoire à long contexte : Utilise le contexte même du modèle (ex: long_context).
• Paradigme II : Mémoire RAG plate : Indexation déterministe (lexicale ou vectorielle) sans construction par LLM (ex: BM25, EmbedRAG).
• Paradigme III : Mémoire RAG augmentée par structure : Utilise un LLM comme extracteur fixe pour dériver des faits, des résumés ou des graphes. Subdivisé en ajout uniquement (ex: GraphRAG, HippoRAG v2) et consolidatrice (ex: Mem0, SimpleMem).
• Paradigme IV : Flux de contrôle agentique : Expose les opérations de mémoire au LLM comme faisant partie de la boucle de décision (ex: A-Mem, Letta, MIRIX).

L'évaluation utilise deux suites de benchmarks :

• MemoryAgentBench (MAB) : Évalue la récupération, l'apprentissage au moment du test, la compréhension à longue portée et l'oubli sélectif. L'étude se concentre sur LongMemEval_S_* (environ 360K tokens d'historique, 60 requêtes par échantillon) pour séparer les coûts de construction des coûts de récupération.
• MemoryArena : Contient des tâches multi-sessions pour exposer les compromis fraîcheur-latence dans les scénarios d'ingestion continue.

2. Harnais de profilage

Les auteurs ont construit un harnais de profilage sensible aux phases (qui sera open-source) qui attribue les coûts à trois phases logiques : construction, récupération et génération.

• Télémétrie API : Instrumente les requêtes de chat-completion et d'embedding pour suivre le volume de tokens, la structure des appels et la latence.
• Télémétrie Matérielle : Échantillonne les compteurs GPU (NVML/DCGM) pour mesurer la puissance, l'utilisation, l'empreinte VRAM et l'énergie.
• Configuration Expérimentale : Les expériences ont été menées dans deux régimes : construction à distance (API OpenAI) et construction locale (NVIDIA H100 avec service Qwen3 via vLLM).

Contributions clés

1. Taxonomie orientée système : Une classification des systèmes de mémoire d'agent selon quatre axes avec des signatures de coût prédites par paradigme.
2. Profilage sensible aux phases : Un harnais suivant les tokens, les appels de modèle, l'utilisation du GPU et la latence à travers la construction, la récupération et la génération.
3. Caractérisation complète : Analyse des formes de coût de construction, des seuils de capacité, des structures d'amortissement, de l'ordonnancement de la fraîcheur, de la croissance de l'empreinte et du comportement de la queue de distribution de la récupération.
4. Dix recommandations de systèmes : Directives exploitables pour l'infrastructure, l'ordonnancement et la sélection de systèmes.

Résultats clés et enseignements

1. La construction domine le cycle de vie

Contraفirement à l'hypothide que le service au moment de la requête est le coût principal, la construction énergétique domine le cycle de vie de l'agent pour les systèmes médiés par LLM.

• Répartition de l'énergie : L'énergie totale par réponse correcte varie de plus de 47× à travers la suite (de ~4,1 kJ pour BM25 à ~185,9 kJ pour Letta).
• Décalage de coût : Les paradigmes III et IV déplacent la majorité de l'énergie de bout en bout vers la phase de construction, qui est invisible pour l'utilisateur au moment de la requête.
• Implication : Les métriques de précision seules sont insuffisantes ; les opérateurs doivent tenir compte de l'énergie du cycle de vie, qui varie d'un ordre de grandeur même pour des systèmes ayant une précision similaire.

2. La construction est dominée par le préremplissage (prefill) et l'embedding

La construction est structurellement une charge de travail de type « lecture longue, écriture courte », dominée par l'embedding et le prefill du LLM, avec un temps de décodage minimal (part de décodage médiane de 4,6 %).

• Modèles de trafic : Les systèmes du paradigme III.a génèrent un trafic d'indexation hors ligne par lots (batch), tandis que les paradigmes III.b et IV génèrent un trafic séquentiel par événement.
• Conflit : Router à la fois la construction (orientée débit) et le QA (sensible à la latence) par le même endpoint provoque un blocage en tête de ligne (head-of-line blocking). Les tâches de construction occupent l'espace disponible du cache KV, bloquant les requêtes sensibles à la latence.

3. Le choix du LLM de construction est contraint par l'algorithme

Les opérateurs peuvent réduire l'échelle du LLM utilisé pour la construction afin de réduire les coûts, mais la plage de sécurité dépend de l'algorithme.

• Dégradation gracieuse : Les systèmes sans contrats de sortie stricts (ex: Mem0, SimpleMem) tolèrent des LLM de construction plus petits avec une dégradation fluide de la précision.
• Seuils de capacité : Les systèmes avec des contrats de sortie stricts (ex: MIRIX exigeant des schémas JSON spécifiques) présentent un seuil critique ; descendre en dessous d'une certaine capacité de modèle (ex: Qwen3-1.7B) corrompt entièrement le magasin de mémoire, le rendant inutilisable.

4. La frontière Construction–Service–Précision

Aucun système n'est optimal sur l'ensemble des trois axes : coût de construction, latence par requête et précision.

• Compromis : BM25 offre une construction rapide et une précision globale élevée mais des temps de requête plus lents. Mem0 offre la latence de requête la plus rapide mais entraîne des coûts de construction massifs et une précision moindre.
• Sélection : Les charges de travail à haut volume de requêtes favorisent les systèmes qui déplacent le travail vers la construction ; les charges de travail à ingestion continue favorisent les systèmes à faible coût de construction.

5. Compromis Fraîcheur–Latence dans les sessions continues

Dans les charges de travail multi-sessions, le temps de construction par session s'étend sur cinq ordres de grandeur (de moins d'une milliseconde pour BM25 à des dizaines de secondes pour Letta).

• Dilemme d'ordonnancement : Si le temps de construction dépasse l'intervalle d'arrivée inter-session, les opérateurs font face à un choix : un ordonnancement synchrone (exposant une latence élevée à l'utilisateur) ou un ordonnancement asynchrone (servant une mémoire obsolète).
• Implication : Pour les dépendances strictes inter-sessions, la construction et la récupération cumulées doivent être traitées comme une contrainte de faisabilité stricte.

6. Divergence de l'empreinte et du coût en tokens

• Stockage : Les empreintes de mémoire par utilisateur varient d'un facteur ~9 à 1M de tokens. Les conceptions multi-vues gonflent le stockage ; les systèmes consolidateurs peuvent le compresser.
• Coût en tokens : Les systèmes agentiques du paradigme IV augmentent de manière super-linéaire en coût de tokens à mesure que les magasins de mémoire croissent, car chaque nouvelle ingestion interroge le magasin en expansion. Cela rend les coûts à long terme des systèmes agentiques disproportionnellement coûteux par rapport à leur empreinte initiale.

7. Structure de latence et comportement de la queue

• Déterministe vs Limité par le LLM : Les systèmes déterministes (paradigme II) ont des queues de latence étroites (p95/p50 ~1,3×). Les systèmes limités par le LLM (paradigmes III/IV) présentent des queues larges (jusqu'à 5,9×) car les décisions de runtime du LLM peuvent introduire un nombre variable d'étapes de raisonnement ou d'utilisation d'outils.
• Recommandation : Les systèmes limités par le LLM nécessitent des plafonds d'itération externes et des délais d'expiration (timeouts) pour borner les coûts de pire cas.

Signification et affirmations

L'article affirme fournir la première caractérisation systémique des charges de travail de mémoire d'agent, révélant que les choix de conception redistribuent les coûts de manière drastique et asymétrique, de façon invisible pour les métriques de précision.

• Décision de niveau système : Les auteurs soutiennent que la sélection d'un système de mémoire d'agent doit être traitée comme une décision de niveau système, et non simplement comme une optimisation de la précision.
• Implications infrastructurelles : Ce travail souligne que la mémoire d'agent impose des besoins système au-delà du service LLM traditionnel, spécifiquement la gestion distincte de la construction (débit en arrière-plan) versus la récupération (latence sensible) et la gestion prudente des compromis fraîcheur-latence.
• Portée modeste : Les auteurs reconnaissent que leur caractérisation est basée sur des scénarios mono-nœud et mono-agent. Ils notent que la cohérence multi-nœuds/multi-agents et la mémoire multimodale sont des frontières émergentes non capturées dans cette étude, mais que la taxonomie et la méthodologie proposées constituent une base pour une caractérisation future.

L'article conclut par dix recommandations spécifiques pour les opérateurs, couvrant l'ordonnancement de la construction, les seuils de capacité, l'amortissement via le volume de requêtes, les compromis fraîcheur-latence et la gestion à l'échelle d'une flotte, visant à guider le déploiement d'agents avec état à grande échelle.