Pourquoi les LLM oublient -- et comment y remédier
Tu as probablement déjà vécu ça. Il est 2h du matin, tu bosses sur un projet complexe avec Claude ou GPT-4. Ça fait trois heures que tu itères, le contexte est riche, les décisions s'accumulent. Et là, le modèle te sort : « Comme tu l'as mentionné, on utilise PostgreSQL » --- sauf que tu lui as dit cinq fois que c'était MongoDB. Le LLM vient d'oublier une décision fondamentale, noyée au milieu de 50 000 tokens de conversation.
Ce n'est pas un bug. Ce n'est pas un modèle « bête ». C'est un problème fondamental d'architecture --- et comprendre pourquoi ça arrive change complètement la façon dont tu construis tes applications.
La physique de l'oubli : pourquoi 100 % des modèles dégradent
Commençons par les faits bruts. L'étude Chroma (2025) a testé 18 modèles frontière --- GPT-4o, Claude 3.5, Gemini 1.5, Llama 3.1 --- sur des tâches de récupération d'information à différentes longueurs de contexte. Le résultat est sans appel : 100 % des modèles dégradent à chaque incrément de longueur, et ce bien avant d'atteindre la limite théorique de leur fenêtre de contexte.
Autrement dit, quand OpenAI annonce « 128K tokens de contexte », ça ne veut pas dire que le modèle utilise efficacement 128K tokens. Ça veut dire qu'il accepte 128K tokens en entrée. La nuance est énorme.
Trois mécanismes expliquent cette dégradation :
Le Lost-in-the-Middle. Le modèle retient bien le début de la conversation (l'amorce, le system prompt) et la fin (les derniers échanges). Mais le milieu ? C'est le trou noir. Les études montrent une perte de précision de 30 % ou plus sur les informations positionnées au centre du contexte. En pratique, tes décisions des tours 5 à 15 dans une conversation de 20 tours sont les premières à disparaître.
La dilution de l'attention. Le mécanisme d'attention du Transformer calcule des relations entre toutes les paires de tokens. À 100K tokens, ça représente 10 milliards de relations à pondérer. L'attention se dilue mécaniquement --- chaque token reçoit une fraction infinitésimale du « budget attentionnel ». Les détails fins se noient dans le bruit.
L'interférence des distracteurs. C'est le plus vicieux. Quand le contexte contient du texte sémantiquement similaire mais non pertinent, le modèle se trompe de cible. Par exemple, si tu discutes d'une architecture microservices et que la conversation contient aussi un passage sur une architecture monolithique « pour comparaison », le modèle peut contaminer sa réponse avec des éléments du monolithe.
Les chiffres qui font peur : NoLiMa et la réalité des benchmarks
L'étude NoLiMa (Adobe Research, présentée à ICML 2025) a porté le coup de grâce aux illusions. Contrairement aux benchmarks classiques type « needle in a haystack » --- qui testent la récupération d'un fait unique et isolé --- NoLiMa mesure les associations latentes : la capacité à relier deux informations distantes dans le contexte.
Les résultats :
- •GPT-4o passe de 99,3 % à 69,7 % de précision à seulement 32K tokens
- •11 modèles sur 13 passent sous la barre des 50 % à 32K tokens
- •Les modèles open-source (Llama, Qwen) dégradent encore plus vite
Et voilà le piège : les benchmarks marketing montrent des performances sur « needle in a haystack » (retrouver UN fait dans un long texte), ce qui est trivial. La réalité des applications --- relier des décisions, maintenir des contraintes, synthétiser des dépendances --- est infiniment plus complexe. C'est la différence entre retrouver une aiguille dans une botte de foin et comprendre comment les brins de foin sont organisés.
Les solutions hardware : quand le silicium vient à la rescousse
La première ligne de défense est au niveau du matériel et du runtime d'inférence. Pas très sexy, mais redoutablement efficace.
La quantification du KV-cache. Le KV-cache (Key-Value cache) stocke les états intermédiaires de l'attention pour éviter de tout recalculer à chaque token généré. Il grossit linéairement avec la longueur du contexte et devient le premier goulot d'étranglement mémoire. Des techniques comme TurboQuant permettent de compresser ce cache de 4 à 8 fois avec une perte de qualité négligeable. En pratique, ça permet de doubler ou tripler la longueur de contexte effective sur le même GPU.
Flash Attention. Développée par Tri Dao (Stanford), Flash Attention réorganise le calcul de l'attention pour maximiser l'utilisation du bandwidth mémoire du GPU. Résultat : jusqu'à 85 % d'utilisation GPU contre 40-50 % avec l'implémentation naïve. Plus rapide et plus économe en mémoire.
PagedAttention (vLLM). Inspirée de la pagination mémoire des systèmes d'exploitation, cette technique alloue la mémoire du KV-cache par blocs plutôt qu'en continu. Résultat : moins de 4 % de gaspillage mémoire, contre 60-80 % avec l'allocation classique. C'est ce qui permet à vLLM de servir des requêtes à contexte long en production.
Les solutions applicatives : le contexte intelligent
Le vrai changement de paradigme vient de la couche application. L'idée centrale : ne pas envoyer tout le contexte, mais le bon contexte au bon moment.
L'observation masking (JetBrains AI). Plutôt que d'envoyer toute l'historique des fichiers observés à l'agent, JetBrains masque les observations non pertinentes. Résultat : -7 % de coût API et +2,6 % de résolution de tâches. Moins de contexte = meilleure performance. Contre-intuitif, mais logique une fois qu'on comprend la dilution de l'attention.
La compression restaurable (Manus AI). Manus compresse les contextes longs en résumés structurés, mais conserve la capacité de « restaurer » les détails à la demande. Le modèle travaille sur un contexte compact et ne décompresse que les sections nécessaires. C'est l'équivalent de la mémoire virtuelle pour les LLM.
Le JIT Context Discovery. Comme le compilateur JIT qui optimise le code au runtime, le JIT Context Discovery découvre et injecte le contexte pertinent au moment où le modèle en a besoin, pas avant. Ça évite de pré-charger des milliers de tokens « au cas où ».
Les architectures mémoire : au-delà de la fenêtre de contexte
C'est ici que les choses deviennent vraiment intéressantes. Plutôt que d'essayer d'étendre la fenêtre de contexte (une course aux armements vouée à l'échec), on peut construire une mémoire externe que le LLM consulte à la demande.
Mem0 propose une mémoire persistante sous forme de graphe. Chaque interaction est indexée, et le système récupère les souvenirs pertinents par similarité sémantique. Résultat : 91 % de réduction de latence par rapport à l'envoi de tout l'historique dans le contexte.
Hindsight (Tsinghua University) atteint 91,4 % sur LongMemEval --- le benchmark de référence pour la mémoire longue. Son approche : transformer les conversations passées en « expériences » structurées qui peuvent être requêtées comme une base de données.
MemGPT/Letta pousse le concept le plus loin en traitant le LLM comme un système d'exploitation. Le modèle a une « mémoire de travail » (la fenêtre de contexte) et une « mémoire archivale » (une base externe). Il peut explicitement décider de sauvegarder une information importante ou de récupérer un souvenir ancien. C'est l'analogie « LLM as OS » --- le modèle gère sa propre mémoire.
La thèse du livre : la mémoire est un problème d'architecture
Voilà pourquoi j'ai écrit un livre entier sur ce sujet. La mémoire des LLM n'est pas un problème qu'on résout en ajoutant des tokens à la fenêtre de contexte. C'est un problème d'architecture --- un problème de conception de systèmes.
Le livre couvre l'ensemble du spectre : des mécanismes internes de l'attention (pourquoi le Transformer oublie) aux architectures de production (comment construire un système qui se souvient). Chaque chapitre est construit autour de données empiriques --- pas de théorie abstraite, mais des benchmarks, du code, des mesures de performance.
Quelques questions que le livre explore en profondeur :
- •Pourquoi RAG seul ne suffit pas (et ce qu'il faut ajouter)
- •Comment concevoir un système de mémoire à plusieurs niveaux (épisodique, sémantique, procédurale, prospective)
- •Les trade-offs entre latence, coût et fidélité de la mémoire
- •Comment les agents de production (Devin, Manus, Windsurf) gèrent leur contexte
La prochaine fois que ton LLM « oublie » quelque chose, tu sauras que ce n'est pas de la négligence. C'est de la physique. Et comme toute contrainte physique, on peut la contourner --- à condition de comprendre les mécanismes en jeu.
Si le sujet t'intéresse, le livre va bien plus loin que cet article. Il couvre 47 papiers de recherche, 12 architectures de production, et suffisamment de code pour que tu puisses implémenter ta propre couche mémoire.
