Des faits obsolètes dans la mémoire de l'agent font chuter la précision de Qwen2.5 de 100% à 44,6%

Plus de contexte récupéré ne garantit pas une meilleure réponse. Des chercheurs du groupe d'Oleeviya Babu Poikarayil (sept auteurs) le démontrent sur la tâche FactConsolidation du benchmark MemoryAgentBench. Sur un historique de 6K tokens, Qwen2.5-7B-Instruct avec recherche BM25 répond correctement dans 45% des cas lorsqu'on lui fournit 64 tokens d'éléments retrouvés. À 512 tokens, la précision tombe à 32%. Et ce, alors qu'un audit avec annotation « gold » a retrouvé l'énoncé le plus récent dans chaque jeu de résultats, sans exception.

Où la chaîne se rompt : dans la recherche ou dans la lecture

De nombreux benchmarks de mémoire pour agents ne fournissent qu'un score global pour le couple « retrouver et répondre ». Quand ce score baisse, on ne sait pas si la recherche n'a pas ramené la mise à jour, ou si le modèle l'a reçue sans l'exploiter. Les auteurs séparent ces deux étapes. Sur la variante single-hop de FactConsolidation, ils vérifient si la version à jour du fait figure parmi les fragments retrouvés. C'était toujours le cas. Le problème se situe donc dans la manière dont le modèle lit les résultats.

La majorité des erreurs concerne des questions où la version obsolète de l'énoncé accompagnait le nouvel énoncé. Un budget élargi augmente le risque qu'une ancienne entrée sur le même objet se glisse dans le contexte. Le modèle voit deux énoncés contradictoires et choisit souvent le mauvais.

Expérience contrôlée : fait obsolète contre fait neutre

Pour neutraliser l'effet de la longueur, les auteurs ont figé le prompt et la taille des éléments fournis : quatre énoncés. Dans une configuration, l'un d'eux était étranger au sujet. Dans l'autre, il était remplacé par une version obsolète concurrente du fait recherché. Le volume de contexte reste identique ; seule la nature d'un énoncé change.

• Qwen2.5-7B-Instruct : la précision chute de 100% à 44,6%.
• Qwen3-14B : chute de 100% à 87,8%.
• Les 50 basculements appariés néfastes (réponse juste devenue fausse) sont tous classés comme stale, c'est-à-dire que la réponse provient de l'énoncé obsolète.

Conclusion des auteurs : un énoncé obsolète nuit davantage qu'un élément neutre de même taille. Les tokens supplémentaires ne sont pas en cause en eux-mêmes. Le coupable est le contenu contradictoire qui semble pertinent.

Même résultat sur un historique long

Sur un historique de 32K tokens, le constat est le même. BM25 avec un budget de 64 tokens atteint 69%, contre seulement 58% avec 512 tokens. Une sélection étroite devance à nouveau une sélection large. L'étude est acceptée au NeurIPS 2026 Workshop on Personalized, Aligned, Long-Term Memory for AI Systems (PALM) et compte 23 pages, annexes comprises.

Que changer dans les systèmes d'agents

Ces conclusions découlent des résultats de l'article ; il ne s'agit pas de recettes validées par les auteurs eux-mêmes. Mais elles s'imposent.

• Métriques. Il faut mesurer séparément le recall des résultats (le fait à jour est-il présent ?) et la qualité de lecture (est-il utilisé ?). Un indicateur unique de bout en bout masque la cause de la défaillance.
• Budget de contexte. Il doit être calibré sur la tâche concrète. Sur les deux tests, 64 tokens ont donné un meilleur résultat que 512, tout en coûtant moins de tokens à chaque appel. Pour les agents à longue session, cette économie s'accumule.
• Écriture en mémoire. Lorsqu'un nouvel énoncé remplace l'ancien, mieux vaut marquer l'ancien comme remplacé ou le supprimer à l'écriture, plutôt que d'espérer que le modèle s'y retrouve à la lecture. Des horodatages et des numéros de version dans les résultats devraient aussi aider.
• Post-traitement des résultats. Avant de les soumettre au modèle, il est raisonnable de regrouper les énoncés relatifs à un même objet et de ne garder que le plus récent. C'est particulièrement important pour les petits modèles : l'écart entre Qwen2.5-7B et Qwen3-14B montre qu'un modèle plus puissant résiste mieux, mais n'est pas à l'abri.

Pour ceux qui conçoivent des assistants personnels et des agents de code dotés d'une longue mémoire, les utilisateurs modifient sans cesse leurs préférences, leurs adresses et leurs paramètres ; les versions obsolètes s'accumulent donc inévitablement. Élargir la fenêtre de résultats « au cas où » s'avère plus risqué qu'il n'y paraît. Il faut d'abord réfléchir à ce qui entre dans le stockage et à la manière dont il sera nettoyé.