De 4K à 1 million de tokens : comment la fenêtre de contexte a évolué et pourquoi davantage de contexte ne signifie pas une meilleure mémoire

Le chiffre qui a changé le marché : ce qu’est une fenêtre de contexte et ce qu’elle ne mesure pas

La fenêtre de contexte est le budget de tokens qu’un modèle peut prendre en compte lors d’une invocation. En pratique, elle inclut généralement les instructions, l’historique de conversation, les documents joints ou récupérés, les appels d’outils et leurs résultats réintégrés à l’échange et, selon l’interface, la sortie à générer. Un chiffre de contexte ne doit donc pas être lu automatiquement comme l’espace disponible pour des documents : une partie du budget peut déjà être consommée avant le début de la tâche.

Une spécification de 128K, 200K ou 1 million de tokens décrit avant tout une limite d’admission ou une configuration prise en charge. C’est une propriété importante : elle évite de devoir fragmenter d’emblée un contenu volumineux et peut permettre de conserver éléments probants, instructions et traçabilité dans une seule requête. Elle n’établit toutefois pas, à elle seule, que le système répondra avec la même fidélité quelle que soit la position de l’information, qu’il résoudra des contradictions entre documents ou qu’il transformera un passage pertinent en décision correcte.

Il convient également de distinguer le contexte de la mémoire au sens large. Le contexte est l’information fournie dans l’interaction en cours. Une mémoire persistante exige de stocker, sélectionner, mettre à jour et gouverner l’information entre différentes sessions ou tâches. Un modèle peut recevoir un dossier complet sans disposer pour autant d’un mécanisme fiable pour décider quel fait doit persister, quelle version prévaut ou à quel moment une préférence antérieure n’est plus valide. Cette différence est essentielle lors de la conception d’assistants documentaires et d’agents.

L’extension du contexte représente une capacité d’entrée utile, non une garantie générale de compréhension. La question opérationnelle n’est pas de savoir quel est le chiffre publié le plus élevé, mais si, pour une distribution donnée de documents et de décisions, l’ajout de davantage de contenu améliore une exactitude vérifiable sans dépasser les contraintes de coût et de latence.

Chronologie utile : de l’attention dense à l’extension du contexte

Le Transformer original a placé l’attention au cœur du mécanisme reliant les positions d’une séquence et a utilisé des encodages positionnels pour représenter l’ordre. Sa formulation d’attention complète est puissante, mais la comparaison d’un grand nombre de positions entre elles crée une pression de calcul et de mémoire qui augmente rapidement avec la longueur de la séquence. Dans les premiers usages pratiques des modèles de langage, les fenêtres relativement courtes n’étaient pas seulement un choix produit : elles reflétaient des limites d’entraînement et d’inférence.

L’évolution ultérieure n’a pas suivi une voie unique. D’une part, des améliorations d’implémentation ont réduit les transferts entre mémoire et processeur sans modifier le résultat mathématique de l’attention exacte. FlashAttention est un jalon représentatif de cette voie : il réorganise le calcul en tenant compte de la hiérarchie mémoire. Il ne supprime pas à lui seul la croissance associée à l’attention dense, mais peut rendre praticables des longueurs ou des lots moins réalistes avec des implémentations antérieures.

D’autre part, les représentations positionnelles sont devenues une composante décisive de l’extension. RoPE encode la position par rotations ; des travaux ultérieurs ont proposé d’interpoler les positions afin d’adapter des modèles utilisant RoPE à des fenêtres plus longues avec un réglage fin limité. Ce mécanisme ne revient pas à démontrer une utilisation uniforme de toutes les positions : il modifie la manière dont la distance et l’ordre sont présentés au modèle, tandis que son comportement final dépend aussi des données, de l’entraînement et de la tâche.

Une troisième voie traite le contexte comme un flux plutôt que comme un bloc devant rester intégralement dans le cache. Les mécanismes d’attention en streaming avec des attention sinks proposent de conserver un petit ensemble d’états d’attention avec les tokens récents. Ils sont pertinents pour des interactions prolongées, mais ils déplacent le problème : une politique de rétention décide ce qui reste disponible et ce qui est écarté. Ils ne constituent pas une mémoire sémantique infaillible.

Enfin, des fournisseurs ont exposé des fenêtres d’un million de tokens ou plus pour certaines familles de modèles. La documentation de Gemini présente ces capacités avec des options de cache ainsi que des considérations de coût et de latence. C’est une preuve de disponibilité d’une interface et d’un produit dans des conditions précises ; elle ne doit pas être transformée en démonstration indépendante d’un raisonnement fiable sur n’importe quel million de tokens.

Quatre couches à ne pas confondre

La première couche est l’admission. Un système admet une entrée lorsqu’il la tokenise et l’accepte dans sa limite. La deuxième est le traitement effectif sous un budget opérationnel : cette même entrée peut exiger un prefill prolongé, consommer de la capacité mémoire ou réduire la concurrence disponible. Deux systèmes qui admettent le même volume peuvent se comporter différemment en matière de temps de réponse et de coût par tâche.

La troisième couche est la récupération d’information. La question est alors de savoir si le modèle localise une donnée précise, une clause, une date ou une relation lorsqu’elle est répartie entre plusieurs documents et entourée de contenu plausible mais non pertinent. La recherche sur le phénomène connu sous le nom de perte au milieu a évalué à la fois des questions-réponses multi-documents et une récupération clé-valeur, et a observé une variation des performances selon la position de l’information pertinente. Ces résultats invitent à mesurer les positions, et pas seulement les moyennes.

La quatrième couche est l’usage cohérent des éléments probants. Un modèle peut citer ou extraire un passage correct, puis produire une synthèse qui mélange des versions incompatibles, enfreint une règle de priorité ou exécute une action non justifiée par la source. Cette couche exige des tâches de décision et de production avec des critères explicites, et non uniquement un test de recherche textuelle.

Ces couches permettent aussi d’éviter une erreur fréquente dans les comparaisons : transformer la limite d’entrée d’une API en classement global de capacité. Pour comparer des options dans le parcours de comparaison, il est préférable de consigner séparément l’entrée maximale, la sortie maximale, la modalité, les performances mesurées sur une tâche et les conditions de mesure. Le chiffre nominal est un attribut ; la fiabilité est un résultat empirique.

Ce qui change en inférence : prefill, génération, cache KV et concurrence

L’inférence longue comporte au moins deux phases aux profils distincts. Lors du prefill, le système traite les tokens d’entrée afin de construire les états nécessaires pour poursuivre la génération. Lors de la phase de décodage, il génère de nouveaux tokens de manière incrémentale et réutilise ces états. Une entrée volumineuse peut concentrer une part importante de l’attente initiale, même si la réponse finale est brève ; une sortie longue ajoute ensuite sa propre durée.

Le cache de clés et de valeurs, ou cache KV, évite de recalculer pour chaque token généré les représentations des tokens antérieurs. Il est essentiel à une génération efficace, mais il occupe de la mémoire et sa taille augmente avec la longueur prise en attention, l’architecture, la précision et le nombre de requêtes simultanées. Les travaux sur la quantification asymétrique à deux bits du cache KV identifient ce cache comme un goulet d’étranglement mémoire, en particulier lorsque le contexte et la taille de lot augmentent. La quantification peut atténuer cette pression, mais elle introduit un choix supplémentaire de qualité, de compatibilité et d’évaluation.

Le coût réel n’est pas non plus un tarif uniforme déduit du seul produit du nombre de tokens par un prix. Le prefill, la longueur de sortie, la réutilisation ou la mise en cache du contexte lorsqu’elles existent, les nouvelles tentatives, le nombre de tours, la concurrence et la capacité réservée ont une influence. La documentation de contexte long de Gemini mentionne des considérations spécifiques de latence et de prix ; ces conditions doivent être vérifiées dans la version en vigueur de la documentation et sous la charge propre à l’application.

C’est pourquoi une évaluation doit rapporter une distribution, et non une simple moyenne. La moyenne peut masquer le fait que les cas longs bloquent des ressources ou font augmenter sensiblement le 95e percentile de latence. Elle doit aussi séparer le temps de préparation du contexte, le premier token et la fin de génération, car chaque mesure suggère une mitigation différente.

Pourquoi les tests simples échouent

Une démonstration dans laquelle la réponse se situe au début ou à la fin d’un document propre ne représente pas la majorité des dépôts réels. L’élément pertinent peut se trouver dans une position intermédiaire, dans un tableau, dans une version antérieure remplacée ou être réparti entre des sources utilisant une terminologie différente. Répéter une même question à de nombreux emplacements permet de détecter une dégradation positionnelle qu’un test unique ne révèle pas.

Les distracteurs doivent être plausibles. Ajouter du texte aléatoire mesure surtout la robustesse à un bruit facile ; ajouter des politiques semblables, des chiffres anciens ou des clauses presque identiques mesure la capacité à résoudre l’ambiguïté. Il est également utile d’introduire des contradictions contrôlées et de définir à l’avance la règle de résolution : par exemple, la version approuvée la plus récente prévaut, ou la source désignée comme normative prévaut. Sans règle de référence, un échec ne peut pas être attribué au modèle.

Les agents ajoutent une autre pression : le contexte entre en concurrence avec les descriptions d’outils, les résultats de recherche, les états d’exécution et les messages de sécurité. Une fenêtre plus grande peut réduire le besoin de couper le contenu, mais elle facilite aussi le maintien de l’influence d’informations obsolètes ou non pertinentes. La conception doit limiter les résultats réintégrés et conserver des identifiants de provenance afin d’examiner pourquoi une action a été prise.

Il ne suffit pas de demander au modèle d’affirmer qu’il a utilisé une source. La sortie doit contenir des références internes à des fragments stables du corpus gelé, et un évaluateur doit vérifier qu’elles étayent la réponse. La traçabilité n’élimine ni les hallucinations ni ne garantit que l’inférence est valide, mais elle transforme une affirmation en objet révisable.

Contexte long face au RAG, au résumé et à la mémoire persistante

Le contexte long, la génération augmentée par récupération — RAG —, les résumés et la mémoire persistante sont des patrons complémentaires, et non les degrés d’une même échelle. Le contexte long conserve davantage de matériau littéral dans un appel. Le RAG sélectionne un sous-ensemble depuis un index ou un dépôt. Le résumé compresse l’information, au prix d’une possible perte de détail. La mémoire persistante maintient des données entre les interactions au moyen de politiques d’écriture, de mise à jour, d’expiration et d’accès.

Le RAG convient lorsque le dépôt dépasse la fenêtre, évolue fréquemment ou exige un filtrage par autorisations, date, entité ou juridiction. Il réduit également la quantité de texte à traiter à chaque tour. Ses risques se déplacent vers l’indexation, le rappel, le classement et la perte de relations entre fragments. Un contexte long peut être préférable lorsque la tâche dépend de la comparaison de nombreuses parties d’un ensemble délimité, à condition que les tests démontrent un bénéfice par rapport à une sélection correctement configurée.

Les résumés aident à maintenir la continuité, mais ils ne doivent pas être traités comme une source primaire lorsqu’une tâche exige une précision littérale. Une architecture prudente conserve des liens entre le résumé et les fragments source, permet d’y revenir et distingue les faits extraits, les interprétations et les décisions. La mémoire persistante requiert une gouvernance encore plus stricte : qui peut y écrire, ce qui peut être oublié, comment elle est corrigée et quelles données ne doivent pas persister.

Le choix doit reposer sur ses propres éléments probants. Dans le parcours de découverte, il est possible d’identifier les documents, outils et contraintes qui caractérisent le flux ; dans le parcours d’apprentissage, l’équipe peut fixer les définitions et critères ; et dans le parcours de comparaison, elle peut confronter les résultats sous le même corpus et le même budget. L’architecture par défaut ne devrait pas être décidée selon la longueur annoncée.

Protocole d’évaluation interne : de la démonstration à la décision

Un protocole minimal commence par un corpus gelé et documenté. Il doit inclure des formats et longueurs représentatifs, des versions, les métadonnées autorisées et une séparation nette entre développement et évaluation finale. Pour chaque tâche, on définit une réponse attendue, les éléments probants qui l’étayent, la règle de résolution des conflits et le niveau de risque d’une réponse erronée. Lorsqu’il n’existe pas de réponse unique, le critère doit permettre l’expression d’une incertitude ou une escalade humaine.

Ensuite, répartissez les éléments pertinents sur plusieurs positions : début, zone intermédiaire et fin. Variez la distance entre les éléments qui doivent être combinés et ajoutez des distracteurs sémantiquement proches. Évaluez au minimum l’extraction littérale, la réponse multi-documents, la résolution de contradictions et une décision ou action soumise à des contraintes. Les métriques doivent distinguer la fidélité des citations, l’exactitude de la décision, le taux d’abstention appropriée, le coût par cas correct et les percentiles de latence.

Comparez des configurations qui consomment des budgets comparables : contexte complet, RAG, RAG plus documents voisins, résumé avec retour à la source et, le cas échéant, contexte long avec cache. Maintenez constants le modèle, les instructions et l’évaluateur lorsque l’objectif est d’isoler l’architecture. Lorsqu’un modèle change, signalez-le comme une variable supplémentaire et évitez d’attribuer tout l’effet à la longueur.

Avant d’adopter une solution, fixez des seuils explicites. Par exemple, une amélioration doit dépasser une marge définie pour les décisions correctes et la fidélité des éléments probants, ne pas dégrader le p95 au-delà de la limite de service et rester dans un coût maximal par tâche valide. Les valeurs précises dépendent du cas d’usage ; elles ne peuvent pas être déduites d’une spécification publique de contexte.

Comment lire 128K, 200K ou 1M de tokens sans promettre une compréhension illimitée

Une spécification responsable doit être lue à la lumière de cinq questions : quelle est l’entrée maximale, quelle est la sortie maximale, quelles modalités sont acceptées, quelles conditions de prix et de latence s’appliquent et quel comportement a été mesuré sur la tâche concernée. L’entrée et la sortie ne sont pas interchangeables : réserver une sortie ample peut réduire l’espace disponible pour les documents, et une tâche avec une réponse courte peut tout de même subir une attente importante pendant le prefill.

La date et la version de la documentation sont également importantes. Les limites, modèles, modalités et politiques de cache peuvent évoluer. Dans une fiche interne, il est utile de consigner la date de consultation, l’identifiant exact du modèle ou du service et les conditions pertinentes, au lieu de ne conserver qu’un chiffre susceptible de devenir rapidement obsolète.

La conclusion n’est pas que les longues fenêtres sont inutiles. Elles constituent une extension technique significative et peuvent simplifier des tâches qui nécessitaient auparavant une fragmentation agressive. La conclusion est plus limitée : leur utilité doit être démontrée sur la distribution réelle des documents, avec des éléments probants traçables et dans une enveloppe opérationnelle acceptable. Davantage de tokens disponibles peuvent améliorer une application ; davantage de tokens sans sélection, évaluation ni gouvernance peuvent accroître le coût et la surface d’erreur.

Pour les équipes produit, la décision pratique consiste à traiter le contexte comme un budget mesurable. Envoyez davantage d’information lorsqu’elle améliore de façon démontrable la récupération et la décision ; récupérez, résumez, demandez des précisions ou escaladez lorsqu’une de ces options apporte de meilleurs éléments probants et davantage de contrôle. Une fenêtre d’un million de tokens cesse ainsi d’être une promesse abstraite pour devenir une option technique évaluable.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.