Context Window (Fenêtre de contexte LLM)

Le context window est une caractéristique du modèle : c'est sa capacité physique de traitement en une requête (4k, 128k, 1M tokens). Le RAG (Retrieval-Augmented Generation) est une architecture applicative qui sélectionne, à la volée, les passages les plus pertinents d'une base documentaire externe pour les injecter dans ce context window. En clair : le context window est le contenant ; le RAG est la logique qui décide quoi y mettre. Un grand context window ne remplace pas un RAG bien conçu, il en facilite l'implémentation (chunks plus grands, retrieval moins agressif, citations contextuelles plus riches), mais le RAG reste indispensable dès que la base documentaire dépasse la fenêtre, ou pour la traçabilité et la fraîcheur des sources.

Oui, sensiblement, dès qu'on injecte effectivement le volume. La tarification API des LLMs est proportionnelle aux tokens consommés (input + output). À titre indicatif fin 2025, sur les modèles frontaliers 1M tokens, une requête qui remplit l'essentiel du contexte coûte beaucoup plus cher qu'une même question résolue par un RAG sur quelques chunks pertinents. Le grand context window devient économiquement intéressant pour les cas d'usage à faible fréquence et forte valeur (audit ponctuel d'un dépôt de code, analyse one-shot d'un corpus contractuel), beaucoup moins pour un copilote interne sollicité des milliers de fois par jour. L'arbitrage TCO se fait cas par cas.

Oui, c'est un phénomène documenté sous le nom de « lost in the middle ». Les modèles ont tendance à mieux exploiter les informations situées en début et en fin de contexte, et à sous-pondérer celles du milieu — d'où l'intérêt des benchmarks long context (HELM Long Context, Needle-in-a-Haystack, RULER) qui mesurent précisément la capacité de récupération sur l'ensemble de la fenêtre. Les modèles 2025-2026 (Claude 4.7 Opus, Gemini 1.5 Pro, Mistral Large 2 MoE) ont fortement réduit cet effet sur les premiers 100k-200k tokens, mais une dégradation reste mesurable à pleine charge 1M. Conclusion pratique : placer les éléments critiques en début et en fin, et garder le RAG ciblé comme architecture de référence pour les usages à fort enjeu de précision.

À mai 2026, le palier 1M+ tokens est atteint par : Claude 4.7 Opus (1M context window, Anthropic), Gemini 1.5 Pro (1M en GA, 2M en preview, Google), et Mistral Large 2 en architecture MoE (128k natif, 1M via configurations spécifiques). GPT-4 Turbo et GPT-4o restent à 128k, GPT-5 introduit des paliers étendus selon variantes. Côté open weights, Llama 3.1 (Meta) plafonne à 128k natif. Le choix ne se fait jamais sur le seul critère du context window : il faut croiser performance sur benchmarks long context (HELM, RULER), coût par token, latence, conformité (RGPD, AI Act, SecNumCloud) et souveraineté de l'hébergement. La méthode Nehos d'évaluation comparée LLM intègre ces dimensions.

Trois règles de calcul à connaître. Un, un token vaut environ 0,75 mot anglais et 0,5 mot français — un texte de 1 000 mots français consomme donc grossièrement 2 000 tokens. Deux, dans une conversation multi-tours, l'historique complet est renvoyé à chaque requête : le coût croît quadratiquement avec la longueur, pas linéairement. Trois, l'output généré est généralement facturé plus cher que l'input sur les API frontalières. Pour cadrer un budget : utiliser les tokenizers officiels (tiktoken pour OpenAI, l'API count_tokens d'Anthropic, le tokenizer Mistral) sur un échantillon représentatif, puis projeter sur le volume mensuel attendu. Les stratégies de mitigation efficaces sont le prompt caching, la compression d'historique, le summarization rolling et le routage modèle (petit modèle sur questions simples, grand modèle uniquement sur cas complexes).