SLICE-Mem : la mémoire des agents LLM sans génération réduit la consommation de tokens de 92 à 99%

La mémoire à long terme donne à un agent LLM des airs d'interlocuteur qui se souvient de ce que vous lui avez dit la semaine dernière. Elle coûte toutefois cher : presque chaque étape, de la décision « sauvegarder ou non » à l'extraction des faits puis à leur organisation, exige un appel distinct à un grand modèle. Xiaobin Chen et quatre autres auteurs proposent SLICE-Mem, un framework dont la partie en ligne du pipeline n'utilise aucun LLM génératif. Sur Qwen3-30B, il rattrape presque la baseline générative MemOS en qualité, tout en consommant 92,4% (Memora Weekly) et 99,5% (LongMemEval-S) de tokens en moins.

Un filtre en entrée plutôt qu'un modèle à chaque étape

Dans la plupart des systèmes de mémoire pour agents, le LLM joue les clercs à tout faire. Il lit la réplique, détermine si elle mérite d'être conservée, la réécrit sous forme de fait et la confronte à ce qui a déjà été accumulé. Chacune de ces opérations ajoute de la latence et une facture de tokens, qui croissent avec la longueur du dialogue.

SLICE-Mem répartit le travail en deux circuits. Le circuit en ligne repose sur deux composants légers :

• un classifieur compact évalue la saillance (salience) des répliques de l'utilisateur et ne laisse entrer en mémoire que celles qui valent d'être retenues ;
• un extracteur fondé sur les dépendances sémantiques construit, à partir des répliques acceptées, des entrées brèves en s'appuyant sur le prédicat, c'est-à-dire l'action ou l'état autour duquel s'articule l'énoncé.

Ces deux étapes se passent de toute génération de texte par un grand modèle. Le filtrage écarte le bavardage et les formules de liaison du quotidien, tandis que l'extraction centrée sur le prédicat convertit le reste en unités de mémoire compactes.

La réconciliation des entrées est repoussée à la nuit

Le point le plus délicat de toute mémoire, ce sont les contradictions et les doublons. L'utilisateur a déménagé, changé de travail ou changé d'avis : les nouvelles entrées doivent être correctement reliées aux anciennes. Ici, les auteurs font tout de même appel à un LLM, mais pas en temps réel. L'harmonisation entre les entrées est déportée dans une phase de consolidation hors ligne, lancée indépendamment du dialogue.

Cette séparation déplace le travail coûteux vers un endroit où la latence n'est pas une contrainte stricte. L'utilisateur n'attend pas que le modèle relise toute la mémoire après chaque réplique. Et si la consolidation peut s'exécuter par lots, son coût devient lui aussi maîtrisable.

Ce que montrent les benchmarks

Les auteurs ont évalué le système sur le sous-ensemble hebdomadaire de Memora et sur LongMemEval-S. Pour construire la mémoire et la consolider, ils ont utilisé deux modèles de la famille Qwen : l'un de 8B et l'autre de 30B de paramètres. La comparaison principale porte sur la baseline générative MemOS dans sa configuration Qwen3-30B.

• Memora Weekly, métrique FAMA (Forgetting-Aware Memory Accuracy) : 46,60 pour le pipeline en ligne de SLICE-Mem contre 46,68 pour MemOS, soit un écart de 0,08 point.
• LongMemEval-S, précision : 56,8% contre 59,3%, soit un retard de 2,5 points.
• Consommation totale de tokens LLM : en baisse de 92,4% sur Memora Weekly et de 99,5% sur LongMemEval-S.

Sur Memora, le résultat coïncide pratiquement avec celui de MemOS. Sur LongMemEval-S, on note une légère perte, mais l'économie atteint près de deux ordres de grandeur. Les auteurs concluent qu'il est possible de conserver des éléments utiles pour la mémoire à long terme en s'appuyant nettement moins sur un LLM pour la construire.

À quoi cela peut servir en pratique

Pour les équipes qui développent des assistants personnels, du support ou des agents de code dotés d'une mémoire entre les sessions, cette étude fournit un repère clair. Si la facture de tokens consacrée à la « comptabilité de la mémoire » est comparable à celle des réponses elles-mêmes, il vaut la peine de vérifier si la génération est nécessaire en entrée. Le classifieur de saillance et l'analyse syntaxique sont rapides : on peut les héberger à côté du service plutôt que de les faire transiter par une API externe.

Les limites sont aussi visibles. Les résultats proviennent de deux benchmarks et de modèles Qwen, et la comparaison avec MemOS n'est fournie que pour une seule configuration. L'écart de 2,5 points sur LongMemEval-S signifie que, pour les tâches soumises à de fortes exigences d'exhaustivité de la mémoire, le choix dépend du coût d'une erreur. Mais en tant que pattern d'ingénierie, « un filtre peu coûteux en ligne, une réconciliation intelligente hors ligne » semble opérationnel. Il réduit la latence, rend le coût de la mémoire prévisible et réserve le grand modèle aux endroits où l'on ne peut réellement pas s'en passer.