Une grande fenêtre de contexte est une limite de capacité, pas une stratégie de recherche documentaire. Le fait qu'un modèle accepte plusieurs centaines de milliers de jetons ne signifie pas qu'il les lit avec une attention uniforme, et cela ne signifie certainement pas qu'il faille payer pour les envoyer tous. Chaque benchmark de contexte long qui a pris la peine de mesurer la position et la longueur dit la même chose : la précision chute à mesure que l'entrée grandit, et les preuves enfouies au milieu d'un prompt sont les moins utilisées.

Le recadrage à retenir : la fenêtre de contexte est un budget que l'on dépense, pas une base de données que l'on interroge. Les équipes qui la traitent comme du stockage construisent des systèmes plus lents, plus coûteux et moins précis que le pipeline de recherche documentaire qu'elles ont contourné.

Les deux modes de défaillance sont différents

On les confond souvent, alors qu'ils appellent des correctifs différents.

  • Dégradation positionnelle. L'effet « lost-in-the-middle » décrit par Liu et al. (2023) : la précision est la plus élevée quand le passage pertinent se trouve tout au début ou tout à la fin de l'entrée, et s'affaisse au milieu, produisant une courbe en U. Déplacez le même fait du bord vers le centre et la qualité de la réponse chute, alors que rien d'autre n'a changé.
  • Dégradation liée à la longueur. La précision décline à mesure que l'entrée grandit, même quand la preuve est fixe et bien placée. Des travaux ultérieurs comme RULER (Hsieh et al., 2024) ont testé des modèles à contexte long sur des tâches multi-aiguilles et de raisonnement sur le contexte, et ont constaté que la longueur de contexte effective est systématiquement plus courte que le chiffre annoncé.

La dégradation positionnelle, on peut parfois la contourner par réordonnancement. La dégradation liée à la longueur, non, car le problème est la taille de la botte de foin elle-même. La corriger suppose d'y mettre moins.

Pourquoi le chiffre du benchmark induit en erreur

Le test « needle-in-a-haystack » doit sa popularité au fait qu'il est facile à exécuter et facile à réussir. On cache une phrase hors contexte à différentes profondeurs dans un long document, on demande au modèle de la répéter, et on trace une grille verte. Un modèle peut obtenir un score quasi parfait à cet exercice et échouer quand même sur ce dont vous avez réellement besoin, parce que les vraies questions ne sont pas des recherches lexicales.

Vos utilisateurs posent des questions qui exigent de retrouver quatre faits liés éparpillés dans un corpus, de remarquer que deux d'entre eux se contredisent, et de raisonner sur le reste. C'est la tâche que mesure RULER, et c'est là que la fenêtre annoncée et la fenêtre réellement exploitable divergent. Traitez le rappel à une seule aiguille comme un test de fumée, pas comme une preuve que la fenêtre fonctionne.

Côté coût, ce n'est pas subtil

La dégradation du rappel se discute. La facture, non. Les jetons d'entrée sont facturés par appel, donc une architecture qui bourre 200 000 jetons de contexte dans chaque requête paie les 200 000 à chaque fois, que la réponse en ait eu besoin de douze ou d'aucun.

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

Cela représente un facteur soixante-six sur la ligne d'entrée, avant même de compter la latence. Le délai avant le premier jeton dépend de la quantité que le modèle doit lire, donc le prompt bourré est aussi le plus lent. Vous payez plus cher pour une moins bonne réponse, livrée plus tard. Il n'y a aucun axe sur lequel cela l'emporte.

La mise en cache de prompt complique l'arithmétique dans un cas précis : un préfixe véritablement stable qui se répète d'un appel à l'autre peut être lu avec une forte réduction. C'est réel, et cela vaut la peine d'être utilisé. Mais cela ne sauve que le coût d'un préambule statique, pas le rappel d'une botte de foin surchargée. Un mauvais prompt mis en cache reste un mauvais prompt, juste moins cher.

Que faire à la place

La discipline n'a rien de spectaculaire, et elle fonctionne.

  • Rechercher, puis répondre. Placez une étape de recherche documentaire devant le modèle et ne transmettez qu'une poignée des meilleurs extraits. Une Bedrock Knowledge Base fait cela sans que vous ayez à gérer un index vous-même. Six bons extraits valent mieux que six cents médiocres, à chaque fois.
  • Classer, et le faire sérieusement. Si vous transmettez dix extraits, l'ordre compte parce que la position compte. Placez la preuve la plus forte en haut et la deuxième plus forte en bas, là où l'attention est la meilleure. Remplissez le milieu avec le matériel secondaire, pas avec le fait déterminant.
  • Plafonner ce que chaque étape peut voir. Un plafond strict de jetons par appel force la couche de recherche documentaire à être sélective. Sans plafond, le contexte grandit jusqu'à ce que quelque chose casse, en général au pire moment.
  • Mettre en cache le préfixe stable, pas le corps variable. Le prompt système et les schémas d'outils sont identiques à chaque appel et ont leur place dans le cache. Les preuves récupérées changent à chaque question, et n'y ont pas leur place.
  • Mesurer le rappel sur vos propres questions. Faites tourner vos vraies requêtes sur votre vrai corpus et notez les réponses. Les annonces de longueur de contexte des fournisseurs sont un chiffre marketing ; votre évaluation est la seule qui décrit votre système.

Quand la grande fenêtre est la bonne réponse

Il existe des cas où remplir la fenêtre est la bonne approche, et refuser de le faire par principe est une erreur en soi. Résumer un document unique de bout en bout nécessite le document entier ; il n'y a rien à rechercher parce que tout est pertinent. Un raisonnement qui exige de garder une base de code ou un contrat entier sous les yeux en même temps a réellement besoin de cette envergure. Une analyse ponctuelle où construire un pipeline de recherche documentaire coûte plus cher que les jetons est un bon endroit pour être paresseux exprès.

Le test consiste à se demander si vous pouvez nommer le sous-ensemble qui compte. Si oui, allez le chercher. Si vous en êtes vraiment incapable, parce que la tâche porte sur le corpus entier plutôt que sur une partie, alors la fenêtre fait un travail réel et vous devriez vous en servir.

À retenir

Des fenêtres de contexte plus grandes sont une véritable prouesse d'ingénierie, et elles continuent de grandir. Elles sont aussi le moyen le plus coûteux d'éviter d'écrire une étape de recherche documentaire. Le rappel se dégrade avec la longueur et avec la position, la facture suit chaque jeton envoyé, et la latence suit la taille du prompt. Décidez de ce que le modèle a besoin de voir, envoyez cela, et cessez de confondre capacité et compétence.

À lire ensuite

Pour le volet infrastructure de la recherche documentaire à grande échelle, les notes de terrain cloud et plateforme vivent sur ercan.cloud, et le hub est sur ercanermis.com.