Fenêtres de contexte : taille et conséquences

La fenêtre de contexte correspond au nombre maximal de jetons qu'un LLM peut traiter lors d'un seul appel d'API. Elle comprend tout : l'invite système, tous les tours de conversation précédents, les documents que vous injectez pour le RAG et l'espace réservé à la réponse du modèle. Si le total dépasse la fenêtre de contexte, l'API renvoie une erreur.

Considérez la fenêtre de contexte comme la mémoire de travail du modèle. Contrairement à un humain, qui peut se souvenir de conversations passées d'une session à l'autre, un LLM ne possède aucune mémoire persistante : il ne peut « connaître » que ce qui est présent dans la fenêtre de contexte actuelle. Lorsqu'une conversation dépasse cette fenêtre, le contenu le plus ancien doit être supprimé, ce qui peut faire perdre au modèle le fil d'un contexte important présenté plus tôt.

Les fenêtres de contexte ont considérablement augmenté. En 2020, GPT-3 proposait 4 096 jetons. En 2025, les modèles de pointe proposent :

• GPT-4o et GPT-4o-mini : 128 000 jetons (environ 100 000 mots)
• Claude 3.5 Sonnet / Opus : 200 000 jetons
• Gemini 1.5 Pro : 1 000 000 de jetons (un million)
• Gemini 1.5 Flash : 1 000 000 de jetons

Une fenêtre de contexte de 128 000 jetons peut contenir environ 300 pages de texte, un roman complet ou l'intégralité d'une base de code de taille moyenne. Malgré cela, le contexte infini n'est pas un problème résolu : le coût de l'attention augmente de façon quadratique avec la longueur de la séquence, ce qui rend les contextes très longs coûteux et parfois moins précis que des contextes plus courts et ciblés.

Les recherches ont montré que les LLM ne portent pas la même attention à toutes les parties de la fenêtre de contexte. Ils ont tendance à accorder le plus d'attention au contenu situé au tout début (effet de primauté) et à la toute fin (effet de récence) du contexte, tandis que le contenu central est traité de manière moins fiable.

On appelle cela le problème du contenu perdu au milieu. Cela a des conséquences pratiques pour les systèmes RAG : si vous concaténez 10 documents récupérés et que le plus pertinent se retrouve au milieu, le modèle risque de ne pas l'utiliser efficacement. La meilleure pratique consiste à placer le contexte le plus important au début ou à la fin des documents injectés, et non au milieu.

Dans une application de discussion, l'historique complet de la conversation est inclus dans chaque appel d'API. À mesure qu'une conversation s'allonge, le nombre de jetons augmente également. Une conversation de 50 messages contenant en moyenne 100 jetons chacun utilise déjà 5 000 jetons rien que pour l'historique. Ajoutez une invite système de 2 000 jetons et 10 000 jetons de contexte RAG, et vous atteignez 17 000 jetons avant même que l'utilisateur ne pose sa prochaine question.

Disposer d'une grande fenêtre de contexte ne signifie pas que vous devez la remplir entièrement. Les recherches montrent systématiquement que la précision du modèle diminue à mesure que le contexte se remplit, en particulier pour les tâches qui exigent de retrouver précisément des faits spécifiques dans un contexte long. Un contexte ciblé et pertinent de 5 000 jetons produit souvent de meilleures réponses qu'un contexte de 50 000 jetons sans objectif précis.

C'est l'argument principal en faveur du RAG plutôt que de l'insertion brute de tous vos documents dans le contexte : un système RAG ne récupère que les 2 à 5 fragments les plus pertinents, ce qui permet de garder un contexte ciblé et de concentrer l'attention du modèle sur ce qui compte. Imaginez que vous consultiez l'index d'un livre plutôt que le lisiez en entier pour répondre à une seule question.

Les longues fenêtres de contexte permettent des processus de traitement des documents puissants qui étaient auparavant impossibles. Vous pouvez désormais envoyer un PDF de 50 pages complet à GPT-4o et lui poser des questions à son sujet, demander au modèle de résumer et de comparer simultanément plusieurs contrats, ou analyser une base de code entière à la recherche de schémas et d'anti-modèles.

Toutefois, à environ 0,15 $ par million de jetons d'entrée, le traitement d'un document de 100 000 jetons par requête coûte environ 0,015 $ par requête. Avec 10 000 requêtes par jour sur un document qui change rarement, vous payez 150 $ par jour pour un traitement redondant. C'est pourquoi les stratégies de mise en cache et de prétraitement sont extrêmement importantes dans les systèmes de production d'analyse de documents.

Le paramètre max_tokens de l'API limite la longueur de la sortie, et non celle du contexte total. La fenêtre de contexte totale correspond à la somme des jetons d'entrée et des jetons de sortie. Si votre fenêtre de contexte contient 128 000 jetons et que votre entrée en utilise 120 000, il ne vous reste que 8 000 jetons pour la réponse, quelle que soit la valeur définie pour max_tokens.

Prévoyez toujours un budget de sortie suffisant. Pour un assistant conversationnel, réserver 2 000 à 4 000 jetons pour la sortie suffit généralement. Pour la génération de code ou les contenus longs, vous pouvez avoir besoin de 8 000 à 16 000 jetons. Intégrez le calcul de votre budget de jetons à votre logique d'assemblage du contexte.

La taille de la fenêtre de contexte doit être l'un de vos principaux critères lors du choix d'un modèle. Faites correspondre la fenêtre de contexte du modèle à votre cas d'utilisation réel :

• Assistants de discussion avec des sessions courtes : 8 000 à 16 000 jetons suffisent généralement ; utilisez gpt-4o-mini pour réduire les coûts
• Questions-réponses sur des documents de taille moyenne : 32 000 à 128 000 jetons ; gpt-4o offre un bon équilibre entre qualité et coût
• Analyse juridique ou analyse de contrats de plusieurs centaines de pages : 128 000 à 200 000 jetons ; envisagez Claude pour ses performances avec les longs contextes
• Analyse d'une base de code ou d'un livre complet : 500 000 à 1 million de jetons ; Gemini 1.5 Pro est actuellement le leader

Payer pour une fenêtre de contexte de 1 million de jetons alors que vous n'en avez besoin que de 8 000 est un excès coûteux. Dimensionnez votre modèle en fonction de vos besoins réels en contexte.

Lorsque vous interrogez à plusieurs reprises le même document volumineux ou la même invite système dans de nombreuses requêtes, vous payez la tokenisation et le traitement du même contenu à chaque fois. Le mise en cache des invites d'OpenAI applique automatiquement une remise de 50 % sur le prix des jetons d'entrée pour les préfixes d'invite répétés lorsque le même préfixe dépasse 1 024 jetons.

Pour maximiser les accès au cache, structurez vos messages de sorte que le contenu stable apparaisse en premier : l'invite système, puis le document volumineux ou le contexte, puis la question variable de l'utilisateur. Ainsi, le long préfixe stable est mis en cache et seule la petite requête variable est traitée au tarif normal à chaque appel.

Avec une grande fenêtre de contexte, vous disposez de deux stratégies pour gérer les conversations qui s'allongent ou les documents volumineux : étendre (tout conserver dans le contexte) ou résumer (compresser l'ancien contenu pour économiser des jetons). Le bon choix dépend de votre cas d'utilisation.

Choisissez l'extension lorsque vous devez retrouver des faits précis plus tôt dans la conversation, lorsque vous analysez un document qui exige de citer des sections précises ou lorsque le résumé ferait perdre des nuances essentielles. Choisissez le résumé lorsque les thèmes généraux de la conversation précédente comptent davantage que la formulation exacte, lorsque vous approchez de la limite de contexte ou lorsque le même contexte sera réutilisé de nombreuses fois, ce qui transforme le résumé en coût unique.

En production, suivez la longueur du contexte pour chaque requête comme indicateur clé. Des hausses soudaines de la longueur moyenne du contexte peuvent révéler un bug dans votre code d'assemblage du contexte, des utilisateurs qui collent des entrées très longues ou une boucle de rétroaction dans laquelle les longues réponses du modèle sont réinjectées dans le contexte. Configurez des alertes lorsque la longueur du contexte dépasse 80 % du maximum du modèle.

Suivez également les événements de tronquage, c'est-à-dire les situations où vous devez raccourcir le contexte pour qu'il tienne dans la fenêtre. Des tronquages fréquents signifient que vous avez besoin d'une meilleure stratégie de gestion du contexte, d'un modèle avec une fenêtre plus grande ou d'une approche fondée sur le RAG afin de récupérer uniquement le contenu pertinent plutôt que de tout envoyer.

Vérifiez votre compréhension des concepts d'ingénierie de l'IA présentés dans cette leçon.

Dans cette leçon, vous avez appris que : la fenêtre de contexte correspond au budget total de jetons pour l'entrée et la sortie lors d'un seul appel d'API, le problème du contenu perdu au milieu signifie que le contenu au début et à la fin du contexte est traité de manière plus fiable, et un petit contexte ciblé surpasse souvent un grand contexte sans objectif précis, ce qui rend le RAG préférable à l'insertion de tous les documents. Nous allons maintenant voir comment calculer et prévoir les coûts d'API avant d'envoyer des requêtes.