Qu’est-ce qu’une fenêtre de contexte ? Ce que tout utilisateur de LLM doit savoir

Une fenêtre de contexte correspond à la quantité d’informations qu’un grand modèle de langage (LLM) peut traiter dans une seule requête. Mesurée en tokens, elle peut inclure votre prompt, l’historique de la conversation, les instructions système, les documents récupérés, les résultats d’outils et la réponse générée par le modèle.

Une fenêtre de contexte plus grande permet à un modèle de traiter davantage d’informations dans une seule requête. Par exemple, un agent de programmation qui enquête sur un bug peut examiner simultanément les fichiers sources pertinents, la documentation, les résultats de tests et les modifications récentes du code, plutôt que d’analyser chaque élément séparément et de perdre un contexte utile entre les requêtes.

Toutefois, une fenêtre de contexte plus grande ne garantit pas une mémoire parfaite. Les prompts plus longs nécessitent davantage de calculs, consomment plus de tokens et peuvent compliquer l’identification des détails réellement importants par le modèle. Des recherches sur les modèles à contexte long, dont l’étude Lost in the Middle et le benchmark RULER de NVIDIA, benchmark RULER ont montré à plusieurs reprises que les modèles exploitent moins bien le contexte disponible à mesure qu’il augmente, en particulier lorsque les informations pertinentes sont enfouies parmi des éléments moins utiles.

Cet article explique le fonctionnement et la mesure des fenêtres de contexte, ce qui se passe lorsqu’elles sont saturées, et comment les développeurs peuvent les gérer efficacement.

En résumé

• Une fenêtre de contexte est le budget total de tokens qu’un LLM mobilise pour une requête. Elle couvre le prompt de l’utilisateur, l’historique de conversation, le contenu récupéré et la sortie.
• Des fenêtres de contexte plus grandes permettent de traiter des documents, bases de code et conversations plus longs, sans garantir que le modèle exploite efficacement chaque élément.
• Les modèles récupèrent le moins fiablement les informations situées au milieu de longs prompts, un phénomène documenté par l’étude Lost in the Middle et le benchmark RULER.
• Une gestion efficace du contexte — récupération, synthèse et mise en cache — est généralement préférable à la simple maximisation du nombre de tokens envoyés.
• La meilleure stratégie de contexte est celle qui correspond à votre charge de travail réelle, et non celle qui utilise la plus grande fenêtre de contexte annoncée.

Qu’est-ce qu’une fenêtre de contexte dans un modèle IA ?

Une fenêtre de contexte est l’espace de travail actif d’un modèle, où toutes les informations pertinentes pour la requête en cours sont réunies avant qu’il génère une réponse.

Prenez un agent IA qui résume une conversation de service client et recommande une résolution. Pour y parvenir efficacement, le modèle doit traiter :

• Le prompt système
• Le message du client
• L’historique de la conversation
• Les politiques de l’entreprise
• Les résultats des outils et des API
• La sortie

Tous ces éléments se disputent l’espace au sein de la même fenêtre de contexte, quelle que soit sa taille.

Les fenêtres de contexte n’incluent pas les données d’entraînement. L’entraînement intègre durablement des informations dans les paramètres d’un modèle, ce qui façonne ce qu’il « sait » de manière générale. Une fenêtre de contexte ne contient, elle, que les informations fournies pour la tâche en cours.

Cette distinction est importante en pratique : si une application a besoin qu’un modèle raisonne sur une politique précise, un dossier client ou un document technique, cette information n’est pas disponible simplement parce que le modèle a été entraîné sur des contenus similaires. Elle doit généralement être intégrée directement au contexte de travail du modèle, dans le prompt ou via un système de récupération ou d’outils ; sinon, le modèle raisonnera à partir de connaissances générales plutôt qu’à partir du document dont il dispose.

Tokenisation et fenêtres de contexte : comment les données sont traitées

Avant qu’un LLM traite un texte, un tokenizer le découpe en unités plus petites appelées tokens. Un token peut représenter un mot entier, une partie de mot, un signe de ponctuation ou un autre court fragment de texte.

Pour l’anglais, une règle pratique consiste à considérer qu’un token représente environ quatre caractères, soit environ trois quarts de mot. Selon cette estimation, 100 tokens correspondent à environ 75 mots. Ce n’est toutefois qu’une approximation. Prenons la phrase « Les fenêtres de contexte influencent les performances d’une application. » Un tokenizer ne la représente pas nécessairement sous la forme de sept mots complets : selon le tokenizer, un ou plusieurs mots peuvent être divisés en plusieurs sous-tokens.

La tokenisation varie aussi considérablement selon les langues. Deux phrases de sens et de longueur visuelle similaires peuvent consommer un nombre de tokens très différent selon la langue et le tokenizer. Les recherches sur l’équité des tokenizers ont révélé que, pour certains couples de langues, la longueur tokenisée d’un texte équivalent peut varier jusqu’à un facteur 15, même avec des tokenizers conçus pour la prise en charge multilingue. Les développeurs d’applications multilingues doivent mesurer l’utilisation des tokens avec le tokenizer réel de leur modèle, plutôt que de l’estimer à partir du nombre de mots.

Une fenêtre de contexte de 200 000 tokens peut sembler immense, mais une application qui ajoute continuellement l’historique des conversations, la documentation récupérée, les réponses d’outils et les instructions système peut atteindre cette limite plus vite que prévu. Les applications de production surveillent donc souvent l’utilisation des tokens et recourent à des techniques telles que la synthèse, l’élagage de l’historique, le filtrage de récupération et la compression des prompts pour conserver les informations les plus pertinentes dans le contexte actif.

Comment fonctionne une fenêtre de contexte dans les modèles de langage ?

Une fenêtre de contexte fonctionne grâce au mécanisme d’attention de l’architecture Transformer, qui calcule comment chaque token d’une entrée est lié à tous les autres avant que le modèle ne produise une réponse.

Prenez la phrase « Le client a retourné l’ordinateur portable parce qu’il ne chargeait plus. » Pour l’interpréter correctement, le modèle doit déterminer comment client, ordinateur portable, retourné et chargeait sont liés entre eux. À mesure qu’une séquence s’allonge, le nombre de ces relations augmente rapidement.

Dans l’auto-attention standard, la puissance de calcul requise augmente approximativement avec le carré de la longueur de la séquence. Par exemple, un prompt de 10 000 tokens nécessite environ 100 millions de comparaisons par paires, tandis qu’un prompt de 100 000 tokens en nécessite environ 10 milliards. Les modèles modernes utilisent diverses optimisations d’architecture et d’infrastructure pour réduire ce coût en pratique, mais le problème de mise à l’échelle sous-jacent demeure.

Les longues conversations ajoutent une seconde contrainte : le cache clé-valeur, ou cache KV. Lors de la génération, les modèles conservent les représentations intermédiaires des tokens précédents au lieu de les recalculer pour chaque nouveau token, ce qui accélère considérablement l’inférence. Ce cache occupe toutefois de la mémoire et grandit à mesure que la séquence s’allonge.

Longueur maximale du contexte dans les modèles IA et son importance

La longueur maximale de contexte d’un modèle définit la quantité d’informations qu’il peut accepter et traiter dans une seule requête. Mais la capacité du modèle à exploiter efficacement une grande fenêtre de contexte est une question distincte.

Des fenêtres de contexte plus longues permettent des cas d’usage qui étaient difficiles ou peu pratiques avec les LLM précédents. Les développeurs peuvent fournir à un modèle un dépôt de code entier, un long document juridique, un article de recherche, la transcription d’une réunion ou un historique de conversation conséquent, sans devoir d’abord réduire ces éléments à quelques milliers de tokens.

C’est important, car préserver une plus grande partie du contexte d’origine peut améliorer la capacité du modèle à répondre précisément aux questions, à identifier les relations entre des informations éloignées et à exécuter des tâches qui dépendent du document dans son ensemble. Par exemple, un assistant de programmation peut devoir examiner plusieurs fichiers pour comprendre comment une fonction est appelée, tandis qu’un assistant dédié aux documents juridiques peut devoir comparer des définitions dans une section avec des obligations décrites beaucoup plus loin dans le document.

Toutefois, une fenêtre de contexte plus grande ne produit pas automatiquement de meilleurs résultats. Des entrées très longues peuvent augmenter les coûts et la latence, et les modèles peuvent moins prêter attention aux informations enfouies au milieu d’un contexte volumineux. Les développeurs doivent donc sélectionner les informations pertinentes, structurer clairement les longues entrées et utiliser, lorsque cela est approprié, des techniques telles que la récupération, la synthèse et l’élagage du contexte.

Comparaison des tailles de fenêtres de contexte par modèle

Les fenêtres de contexte varient fortement parmi les principales familles de modèles actuelles, de quelques centaines de milliers de tokens à 10 millions. Voici comment se comparent les modèles phares actuels :

Les limites annoncées évoluent rapidement à mesure que les fournisseurs publient de nouveaux modèles et relèvent leurs plafonds. Considérez donc tout tableau de ce type comme un instantané, non comme un classement permanent. La taille du contexte n’est par ailleurs qu’un critère parmi d’autres pour choisir un modèle. À elle seule, elle ne renseigne ni sur la qualité du raisonnement, ni sur les limites de sortie, la latence ou le coût.

Conséquences d’une fenêtre de contexte petite ou grande

Une petite fenêtre de contexte oblige les développeurs à faire des choix. Les longs documents sont découpés, l’historique de conversation ancien est synthétisé et les connaissances externes ne sont récupérées que lorsqu’elles sont réellement nécessaires.

Une grande fenêtre de contexte supprime certaines de ces contraintes. Vous pouvez fournir davantage d’exemples, conserver un historique de conversation plus long ou analyser un ensemble plus vaste de documents sans devoir d’abord tout scinder.

Toutefois, une fenêtre plus grande introduit un autre problème : la dilution de l’attention. Lorsqu’un prompt contient une grande quantité d’informations, le modèle peut avoir du mal à identifier les détails les plus pertinents pour la requête en cours. Des instructions ou preuves importantes peuvent se retrouver enfouies parmi des contenus moins pertinents, ce qui augmente le risque de réponses incomplètes, incohérentes ou moins précises.

Pourquoi les modèles se perdent au milieu

Les modèles récupèrent généralement mieux les informations situées au début ou à la fin d’un long prompt, et moins bien celles enfouies au milieu. L’influente étude Lost in the Middle a testé ce phénomène directement en plaçant la réponse à une question à différentes positions dans un long prompt et en mesurant la fréquence à laquelle les modèles la trouvaient. La précision était systématiquement la plus élevée au début et à la fin du contexte, et la plus faible au milieu.

Cela signifie qu’un modèle peut techniquement accepter un document sans en exploiter fiablement chaque partie. Envoyez à un LLM 100 documents d’assistance parce que l’un d’eux contient la réponse à la question d’un client : une fenêtre de contexte plus grande permettra peut-être aux 100 documents de tenir. Mais le modèle devra toujours isoler un passage pertinent parmi 99 passages non pertinents, et une fenêtre plus longue ne le garantit pas.

Il est donc utile de distinguer la fenêtre de contexte annoncée d’un modèle de sa fenêtre de contexte effective pour une charge de travail donnée. Des benchmarks comme RULER et LongBench cherchent à mesurer cet écart. RULER a constaté que des modèles obtenant des résultats presque parfaits à de simples tests de récupération se dégradaient tout de même lorsque la longueur du contexte et la complexité des tâches augmentaient. LongBench évalue des tâches plus larges, dont les questions-réponses sur documents, le raisonnement sur plusieurs documents, la synthèse, l’apprentissage few-shot et la complétion de code.

Un contexte long apporte néanmoins une réelle valeur. La capacité et la compréhension sont simplement deux propriétés différentes, toutes deux importantes pour choisir un modèle adapté à une tâche donnée.

Gérer les limites de contexte : bonnes pratiques pour les développeurs

Bien gérer le contexte consiste à contrôler ce qui parvient au modèle : fournir les informations pertinentes pour la tâche au moment où elles le sont, plutôt que de chercher à maximiser le nombre de tokens dans chaque requête. Les pratiques suivantes peuvent aider les développeurs à réduire le contexte inutile, améliorer la qualité des réponses et maîtriser les coûts et la latence.

1. Récupérez les informations pertinentes plutôt que de tout charger

La génération augmentée par récupération, ou RAG, permet à une application d’interroger une base de connaissances externe et de n’insérer que les passages pertinents dans le contexte du modèle. Au lieu d’ajouter un manuel entier de 500 pages à chaque requête d’assistance, l’application récupère les quelques passages les plus proches de la question réelle du client.

Cela réduit l’utilisation de tokens et indique beaucoup plus clairement au modèle ce qui importe. La qualité de la récupération reste essentielle : les systèmes RAG de production améliorent généralement les résultats en découpant soigneusement les documents, en récupérant plusieurs passages candidats, en les réordonnant et en éliminant les éléments non pertinents avant de construire le prompt final. ElevenLabs, par exemple, a reconstruit son pipeline RAG afin d’ajouter la réécriture des requêtes et des appels de modèles parallèles, réduisant de moitié la latence médiane de récupération.

2. Gérez délibérément l’historique des conversations

Les applications conversationnelles accumulent rapidement du contexte. Ajouter indéfiniment chaque message précédent gaspille des tokens et peut introduire des détails non pertinents dans les tours suivants.

Les applications traitent ce problème en conservant les tours les plus récents, en synthétisant les échanges plus anciens, en extrayant les faits durables dans une mémoire structurée et en ne récupérant les détails plus anciens que lorsqu’ils redeviennent pertinents. Cela crée une séparation utile entre le contexte conversationnel à court terme, dont le modèle a immédiatement besoin, et la mémoire applicative à plus long terme, qui peut être réinjectée ultérieurement.

3. Utilisez la mise en cache lorsque le contexte se répète

De nombreuses applications envoient à répétition les mêmes longues instructions ou répondent à des questions sémantiquement similaires à celles qu’elles ont déjà traitées. La mise en cache réduit cette surcharge.

La mise en cache des prompts ou du contexte permet de réutiliser plus efficacement des entrées répétées, et la mise en cache sémantique va plus loin en reconnaissant qu’une nouvelle question signifie sensiblement la même chose qu’une question à laquelle le système a déjà répondu. « Quelle est votre politique de retour ? » et « Combien de temps ai-je pour retourner un article ? » sont deux formulations différentes qu’un cache sémantique peut traiter comme la même question, évitant un appel de génération complet et réduisant à la fois la latence et les coûts en tokens.

4. Mesurez les performances avec des longueurs de contexte réalistes

Ne choisissez pas une stratégie de contexte uniquement sur la limite de tokens annoncée par le fournisseur du modèle. Testez des charges de travail de production représentatives et mesurez la qualité des réponses, la précision de récupération, la latence, l’utilisation des tokens, le coût et les taux d’échec à mesure que la longueur du contexte augmente.

Comparez des stratégies telles que fournir davantage de contexte, récupérer moins de passages, synthétiser l’historique de conversation ou combiner récupération et synthèse. Un modèle doté d’une fenêtre de contexte d’un million de tokens peut prendre en charge votre application sur le plan technique, alors qu’un prompt plus court, soigneusement alimenté par récupération, peut produire des résultats plus rapides et plus précis à moindre coût.

Commencez avec ElevenAgents pour des solutions linguistiques évolutives

La gestion du contexte est particulièrement importante pour les agents conversationnels, qui doivent combiner l’énoncé actuel avec les tours précédents, les instructions métier, les informations client, le contenu de la base de connaissances et les résultats d’outils, tout en répondant assez vite pour que la conversation paraisse naturelle.

ElevenAgents réunit ces éléments sur une plateforme unique pour créer et déployer des agents vocaux IA. Son moteur d’orchestration coordonne la reconnaissance vocale, un LLM et Text to Speech, tandis que les développeurs configurent les prompts, les bases de connaissances, les outils, les workflows et le modèle de langage sous-jacent. La restitution expressive, notamment la façon dont un agent transmet le contexte émotionnel dans la parole, dépend du même contexte qui détermine d’abord ce que l’agent dit.

Pour la gestion des connaissances en particulier, ElevenAgents prend en charge à la fois les documents en contexte intégral et le RAG, configurable directement sur la plateforme. Les petits documents sont directement intégrés au prompt d’un agent, afin que leur contenu reste disponible tout au long de la conversation. Les bases de connaissances plus volumineuses sont plutôt indexées, le RAG récupérant les passages pertinents pour chaque requête au lieu de tout charger simultanément dans la fenêtre de contexte.

Commencez dès aujourd’hui en vous inscrivant à ElevenAgents ou contactez notre équipe pour découvrir vos options de déploiement.

FAQ : qu’est-ce qu’une fenêtre de contexte ?