Une fenêtre de contexte n’est pas une mémoire : comment les LLM traitent les longs documents et les conversations

Ce que contient une fenêtre de contexte

La requête visible de l’utilisateur ne constitue qu’une partie de l’entrée. Une application de clavardage ou un agent peut aussi inclure une instruction système, des règles, l’historique de la conversation, des exemples, des extraits de documents, des définitions d’outils et les résultats d’outils précédents. Ces éléments sont convertis en jetons et transmis au modèle lorsqu’il génère sa prochaine réponse.

Anthropic décrit l’ingénierie du contexte comme la sélection et le maintien de l’ensemble de jetons le plus utile à l’inférence. Cette façon de voir les choses est pertinente : la fenêtre de contexte est un budget d’attention, pas un classeur. Chaque page non pertinente, instruction répétée ou résultat d’outil inutilement détaillé entre en concurrence avec de l’information potentiellement plus importante.

Le contexte, la mémoire, le RAG et les poids sont quatre couches différentes

Ces couches peuvent fonctionner ensemble. Une application pourrait récupérer une politique destinée à la clientèle, rappeler une préférence approuvée par l’utilisateur, puis placer les deux dans le contexte. Le modèle génère ensuite une réponse à partir de ses poids entraînés et de l’information fournie. Qualifier ces quatre couches de « mémoire » masque l’endroit où les données sont stockées, la manière de les corriger et l’entité qui contrôle leur conservation.

Pourquoi une longue fenêtre de contexte est utile

Une fenêtre plus grande peut contenir davantage de code, une plus longue portion d’une conversation ou plus de documents sources dans une même requête. Elle peut réduire la nécessité de diviser un document en plusieurs appels distincts. Pour certaines tâches, le fait de garder ensemble les éléments connexes donne au modèle l’information dont il a besoin pour résoudre les références et produire un résultat cohérent.

La capacité maximale ne garantit pas une utilisation fiable de chaque jeton. Le résultat dépend toujours du modèle, de la structure de la requête, de l’emplacement des faits pertinents, de la qualité de la recherche et de la tâche d’évaluation. Une affirmation comme « prend en charge un très long contexte » décrit une capacité. Elle ne prouve ni un rappel exact sur toute cette longueur ni l’adéquation du modèle à un contrat, à une base de code ou à des archives en particulier.

Un contexte plus long consomme plus de ressources

Les modèles autorégressifs prédisent un jeton à la fois. Pendant la génération, les calculs de clés et de valeurs associés aux jetons précédents peuvent être conservés dans un cache KV afin d’éviter de les recalculer depuis le début à chaque étape. Hugging Face indique qu’un cache dynamique croît à mesure que la génération avance. Les modèles à fenêtre glissante ou à attention par blocs peuvent limiter la croissance du cache dans les couches qui utilisent ces mécanismes.

En pratique, la longueur du contexte influe donc sur la pression exercée sur la mémoire et sur la latence, en plus de la taille des fichiers de poids. Plusieurs requêtes simultanées ont chacune besoin de leur propre état actif. Une estimation fondée uniquement sur la taille des poids peut ainsi sous-évaluer la mémoire nécessaire en production. La quantification des poids ne réduit pas automatiquement toutes les autres allocations d’exécution dans la même proportion.

Pour dimensionner un système réel, testez des longueurs d’entrée représentatives, les longueurs de sortie attendues et le nombre d’utilisateurs simultanés. Le calculateur de VRAM pour LLM local de D-Central peut aider à cerner les variables, mais tout engagement de production doit être validé avec le modèle, le moteur et le matériel exacts.

Pourquoi l’historique de clavardage n’est pas une mémoire persistante

Une interface de clavardage renvoie souvent les messages précédents afin que le modèle puisse répondre de façon cohérente. Lorsque les messages les plus anciens ne tiennent plus dans la fenêtre, l’application peut les tronquer, les résumer ou n’en sélectionner qu’une partie. Le modèle n’a pas secrètement mémorisé l’échange omis : l’application a décidé quoi transmettre.

Une fonction de mémoire persistante stocke plutôt l’information sélectionnée ailleurs. Cela soulève des questions de gouvernance : quelles données sont conservées, qui peut les consulter, comment leur pertinence est-elle déterminée, comment une personne peut-elle les corriger, quand sont-elles supprimées et franchissent-elles la frontière d’un service externe? Une mémoire accrue peut améliorer la convivialité tout en augmentant les risques liés à la conservation et à l’accès.

Le contexte est aussi une frontière de sécurité

Les instructions et le contenu récupéré partagent l’espace d’entrée du modèle. Un document malveillant ou non fiable peut contenir du texte visant à détourner un agent, à exposer de l’information ou à déclencher un outil. Un long contexte peut aussi rendre moins évident le passage ou l’instruction qui a influencé une réponse. Les contrôles d’accès aux documents sources demeurent nécessaires, même lorsque la recherche et l’inférence sont locales.

Pour les déploiements sensibles, séparez les permissions d’accès aux données de celles du modèle, limitez ce qui peut être récupéré pour chaque utilisateur, identifiez le contenu non fiable, restreignez les pouvoirs des outils et consignez les sources utilisées. L’exécution locale peut réduire la transmission de données à des tiers, mais elle ne rend pas chaque jeton sûr ni chaque réponse fiable.

Quand utiliser le contexte, la recherche ou l’ajustement fin

• Utilisez le contexte direct pour une tâche circonscrite dont les documents sources nécessaires sont connus et tiennent aisément dans la fenêtre.
• Utilisez le RAG lorsque les connaissances pertinentes doivent être sélectionnées dans une collection plus vaste et évolutive.
• Utilisez la mémoire de l’application pour conserver délibérément des préférences ou un état qui doivent persister d’une séance à l’autre.
• Envisagez l’ajustement fin lorsque l’objectif porte sur un comportement, un format ou l’adaptation répétée à une tâche plutôt que sur des faits actuels.

Ces choix ne s’excluent pas mutuellement. Le but est de placer l’information dans une couche où elle peut être contrôlée, mise à jour, évaluée et supprimée de façon appropriée. Notre guide sur le RAG et l’ajustement fin présente la prochaine étape de décision.

Foire aux questions

Une fenêtre d’un million de jetons signifie-t-elle que le modèle se souvient éternellement d’un million de jetons?

Non. Il s’agit d’une capacité d’entrée pour une requête dans des conditions données, et non d’un stockage persistant entre les séances. La qualité utilisable et les besoins matériels doivent être évalués séparément.

Puis-je coller tous les documents de l’entreprise dans une seule requête?

La capacité ne suffit pas à en faire une bonne architecture. Les permissions, la pertinence, la latence, le coût et la capacité du modèle à exploiter le contenu comptent tous. La recherche offre généralement une façon plus contrôlée de sélectionner l’information dans un vaste corpus.

Le cache KV est-il la même chose que la mémoire de l’application?

Non. Un cache KV est un état d’exécution qui accélère l’attention pendant la génération. La mémoire de l’application est de l’information conservée délibérément et susceptible d’être rappelée d’une requête ou d’une séance à l’autre.

Sources principales consultées le 24 août 2026 : Anthropic, Effective context engineering for AI agents; Hugging Face, stratégies de cache; documentation de Hugging Face sur les segmenteurs; Vaswani et coll., Attention Is All You Need.