RAG ou fenêtre géante : le calcul que personne ne fait

Depuis que les fenêtres de contexte ont atteint le million de tokens, une idée circule : le RAG serait mort. Puisque le modèle peut tout lire, à quoi bon sélectionner ?

L'argument paraît imparable. Il repose pourtant sur une confusion, et sur un calcul que personne ne fait.

La confusion : une fenêtre d'un million de tokens ne signifie pas que le modèle lit un million de tokens. Elle signifie qu'il les accepte. Ce n'est pas la même chose, et la recherche a documenté l'écart avec précision.

Le calcul : envoyer un corpus entier à chaque requête a un prix. Nous l'avons chiffré à partir des tarifs officiels, et le résultat déplace la question — pas dans le sens qu'on attend.

Le RAG en trois phrases

Pour les lecteurs qui découvrent le terme.

Le RAG — retrieval-augmented generation, génération augmentée par la recherche — consiste à ne pas tout envoyer au modèle. On découpe d'abord la base documentaire en fragments, on les indexe, puis à chaque question on ne récupère que les fragments pertinents pour les joindre à la requête.

Le modèle ne voit donc jamais l'ensemble du corpus : il voit la question et les quelques pages qui s'y rapportent.

L'alternative, permise par les grandes fenêtres, consiste à tout envoyer et à laisser le modèle trouver lui-même ce qui compte. C'est l'approche que nous appellerons « fenêtre géante ».

Ce qu'une grande fenêtre ne garantit pas

Voici le point que la recherche établit et que le marketing escamote : la précision d'un modèle n'est pas uniforme sur toute sa fenêtre.

Deux phénomènes distincts ont été identifiés. On les confond en permanence, alors qu'ils n'ont ni les mêmes causes ni les mêmes remèdes.

La dégradation positionnelle

Le premier est connu sous le nom de lost in the middle — « perdu au milieu ».

Des travaux de référence ont mesuré la précision d'un modèle selon l'endroit où se trouve l'information utile dans le contexte. Le résultat dessine une courbe en U : la précision est élevée quand l'information se situe au début, élevée quand elle se situe à la fin, et chute de plus de 30 % quand elle se trouve au milieu.

Ce résultat a été répliqué sur six familles de modèles différentes. Ce n'est pas une particularité d'un éditeur, c'est une propriété de l'architecture.

Conséquence directe et rarement tirée : l'ordre dans lequel vous placez vos documents change la qualité de la réponse. Un document décisif enfoui au milieu d'un long contexte a statistiquement moins de chances d'être exploité que le même document placé en tête.

La dégradation par la longueur

Le second phénomène est plus insidieux, et bien plus gênant.

Il ne concerne pas où se trouve l'information, mais combien de texte l'entoure. La précision décline à mesure que l'entrée s'allonge — même lorsque l'information utile est correctement placée et n'a pas bougé.

Autrement dit, vous ne pouvez pas résoudre le problème en soignant l'ordre de vos documents. Le simple fait d'en ajouter dégrade le traitement de ceux qui étaient déjà là.

La cause est architecturale et connue. Les mécanismes qui encodent la position des tokens font décroître la similarité entre éléments éloignés, ce qui réduit mécaniquement l'attention portée aux informations situées loin dans le contexte. La normalisation qui suit amplifie l'effet en concentrant l'attention sur les éléments les mieux notés.

Le point qui devrait faire réfléchir tous ceux qui remplissent des fenêtres : cette dégradation ne commence pas à des centaines de milliers de tokens. Des mesures contrôlées l'observent dès quelques milliers — c'est-à-dire quelques pages.

Le calcul que personne ne fait

Passons à l'argument économique, qui est le plus souvent invoqué et le plus rarement chiffré.

Prenons un cas concret : un assistant documentaire interne. Le corpus fait 500 000 tokens — l'équivalent d'un gros manuel technique. L'outil traite 1 000 questions par jour.

Nous utilisons les tarifs officiels relevés le 7 août 2026, avec un modèle haut de gamme à 5 dollars le million de tokens en entrée.

Approche fenêtre géante, sans mise en cache. Chaque question envoie l'intégralité du corpus : 500 000 tokens, soit 2,50 dollars. Multiplié par mille questions : 2 500 dollars par jour, soit environ 50 000 dollars par mois.

Ce chiffre suffit généralement à clore le débat. Mais il est incomplet.

Approche fenêtre géante, avec mise en cache. Le corpus est stable : il ne change pas d'une question à l'autre. Il peut donc être mis en cache, et les relectures se facturent une fraction du tarif d'entrée. La question tombe alors autour de 0,25 dollar, soit environ 250 dollars par jour.

La mise en cache divise la facture par dix. C'est elle, et non la taille de la fenêtre, qui a rendu l'approche envisageable.

Approche RAG. On ne récupère que les fragments pertinents, disons 8 000 tokens par question. Coût : 0,04 dollar, soit 40 dollars par jour — auxquels il faut ajouter l'infrastructure d'indexation et de recherche, ainsi que le travail de mise en place.

Ce que ce calcul révèle vraiment

Approche	Coût quotidien	Rapport
Fenêtre géante sans cache	2 500 $	×62
Fenêtre géante avec cache	250 $	×6
RAG	40 $	référence

Le résultat intéressant n'est pas que le RAG soit moins cher — on s'en doutait. C'est que la mise en cache réduit l'écart d'un facteur soixante à un facteur six.

Et un facteur six, ce n'est plus un argument décisif : c'est un arbitrage. Six fois plus cher pour une architecture beaucoup plus simple à construire et à maintenir peut être un excellent marché, surtout au démarrage.

Attention toutefois à la condition qui rend ce calcul valable : la mise en cache ne fonctionne que si le contexte est identique d'une requête à l'autre. Un corpus partagé par tous les utilisateurs se met en cache. Un corpus propre à chaque client, ou qui change plusieurs fois par jour, ne se met pas en cache — et l'on retombe sur le facteur soixante.

C'est ce critère, et non la taille du corpus, qui devrait guider la décision. Personne ne le mentionne.

Quand la fenêtre géante gagne

Elle gagne plus souvent qu'on ne le dit, et pour des raisons qui ne sont pas toujours économiques.

Quand le corpus est petit et stable. En dessous de quelques dizaines de milliers de tokens, construire une chaîne de recherche est une complication gratuite. Envoyez tout, mettez en cache, passez à autre chose.

Quand le raisonnement porte sur l'ensemble du document. C'est la limite structurelle du RAG, et elle est sévère. Une question du type « ce contrat se contredit-il quelque part ? » ou « quelle est la cohérence d'ensemble de ce rapport ? » ne se résout pas en récupérant trois fragments : elle exige de tout voir. Un système de recherche qui sélectionne cinq passages pertinents passera structurellement à côté.

Quand vous prototypez. Le RAG demande de découper, d'indexer, de choisir une méthode de recherche, de régler le nombre de fragments récupérés, d'évaluer la pertinence. C'est un projet. La fenêtre géante fonctionne en une après-midi. Commencez par elle pour valider l'idée, optimisez ensuite si le volume le justifie.

Quand la fraîcheur prime sur le coût. Aucun index à reconstruire, aucun décalage entre le document et sa version indexée. Vous envoyez l'état actuel, point.

Quand le RAG gagne

Il gagne dans quatre situations, et sa domination y est nette.

Quand le corpus dépasse la fenêtre. Cas trivial mais fréquent : une base documentaire d'entreprise se compte en dizaines de millions de tokens. Aucune fenêtre ne l'avale.

Quand le contexte diffère à chaque requête. Chaque utilisateur a ses propres documents, chaque client son propre dossier. La mise en cache devient inopérante, et le facteur soixante revient. C'est le cas le plus courant en production, et le plus coûteux à découvrir tardivement.

Quand la précision compte plus que l'exhaustivité. C'est le point contre-intuitif que la recherche éclaire. Envoyer moins de texte, mais le bon, produit souvent de meilleures réponses qu'envoyer tout — précisément à cause des deux dégradations décrites plus haut. Le RAG n'est pas seulement une optimisation de coût : c'est parfois une optimisation de qualité.

Quand vous devez tracer les sources. Un système de recherche sait dire d'où vient chaque élément. Un modèle qui a tout lu produit une réponse dont l'origine est difficile à établir. Pour un usage réglementé, documentaire ou journalistique, cette traçabilité n'est pas un supplément mais une exigence.

L'architecture qui s'impose : l'hybride

La question « RAG ou fenêtre géante » est mal posée, et la pratique de 2026 l'a tranchée en refusant de choisir.

L'architecture qui s'est imposée procède en deux temps. On récupère largement — non plus trois fragments, mais une sélection substantielle, de quelques dizaines à quelques centaines de milliers de tokens. Puis on laisse le modèle raisonner sur cet ensemble, en exploitant sa capacité de contexte long.

C'est le meilleur des deux approches, et cela répond aux faiblesses de chacune. Le RAG pur, avec sa poignée de fragments, échoue sur le raisonnement d'ensemble. La fenêtre géante pure se dégrade avec la longueur. La sélection large suivie d'un raisonnement long évite les deux écueils.

Ce que cela change dans la conception : la recherche ne sert plus à trouver la réponse, elle sert à écarter le hors-sujet. Son objectif n'est plus une précision chirurgicale mais une bonne élimination du bruit. C'est un cahier des charges beaucoup plus facile à atteindre — et c'est pourquoi cette architecture est plus robuste que le RAG classique.

Le découpage, l'étape que tout le monde bâcle

Si vous partez sur du RAG ou sur de l'hybride, une décision pèse plus lourd que toutes les autres et reçoit habituellement le moins d'attention : comment découper vos documents.

Le réflexe consiste à couper tous les mille caractères. C'est rapide, c'est le réglage par défaut de la plupart des bibliothèques, et c'est la principale cause de mauvais résultats.

Un découpage mécanique produit des fragments qui commencent au milieu d'une phrase, séparent un tableau de son titre, ou détachent une réponse de la question qu'elle traite. Récupéré isolément, un tel fragment est inexploitable — et le modèle, à qui l'on demande de répondre à partir de ça, produira une réponse médiocre dont on accusera le modèle.

Trois principes valent mieux qu'un réglage.

Découpez sur la structure, pas sur la longueur. Un document a des sections, des titres, des paragraphes. Ces frontières existent parce qu'elles séparent des unités de sens. Utilisez-les. Un fragment doit correspondre à une idée complète, quelle que soit sa longueur.

Faites se chevaucher les fragments. Un recouvrement de dix à vingt pour cent entre fragments consécutifs évite qu'une information à cheval sur une frontière ne devienne introuvable. Le coût en stockage est négligeable ; le gain en taux de récupération ne l'est pas.

Ajoutez le contexte à chaque fragment. C'est le conseil qui produit le plus grand écart de qualité, et le moins appliqué. Un fragment qui dit « le taux passe alors à 3,5 % » est inutile hors contexte. Le même fragment précédé de « Document : Conditions tarifaires 2026 — Section : Pénalités de retard » devient exploitable. Préfixez chaque fragment du titre du document et du chemin de sa section.

Vérifiez avant de construire

Un test simple, à faire avant d'investir dans quoi que ce soit : prenez au hasard dix fragments produits par votre découpage et lisez-les seuls, sans le document d'origine.

Si vous ne comprenez pas de quoi ils parlent, le modèle ne le comprendra pas davantage. Retravaillez le découpage avant d'aller plus loin — c'est l'heure de travail la plus rentable de tout le projet.

Les erreurs des deux camps

Du côté fenêtre géante. Croire que remplir la fenêtre améliore la réponse — la recherche dit l'inverse au-delà d'un certain point. Négliger la mise en cache, qui fait toute la différence économique. Ne pas soigner l'ordre des documents alors que la position influence mesurablement le résultat. Et découvrir en production que le contexte varie par utilisateur, donc que rien ne se met en cache.

Du côté RAG. Récupérer trop peu de fragments par réflexe d'économie, alors que les tarifs actuels et les grandes fenêtres permettent d'être généreux. Découper les documents mécaniquement, sans respecter leur structure, et produire des fragments incompréhensibles hors contexte. Ne jamais évaluer la qualité de la recherche elle-même — si le bon passage n'est pas récupéré, aucun modèle ne le devinera. Et maintenir une chaîne d'indexation complexe pour un corpus qui tiendrait dans une fenêtre.

Comment décider

Quatre questions, dans cet ordre. La première qui reçoit une réponse tranchée décide.

Votre corpus dépasse-t-il la fenêtre du modèle ? Si oui, RAG ou hybride, sans discussion possible.

Le contexte est-il identique pour toutes les requêtes ? Si oui, la mise en cache change l'économie et la fenêtre géante redevient compétitive. Si non — un corpus par utilisateur, par client, par dossier —, le RAG reprend un avantage décisif.

Vos questions portent-elles sur l'ensemble du document ou sur des passages ? Cohérence globale, contradictions, synthèse transversale : fenêtre géante. Recherche d'information ponctuelle : RAG.

Devez-vous justifier vos réponses par des sources ? Si oui, le RAG apporte une traçabilité que la fenêtre géante ne donne pas.

Et un conseil qui vaut pour tous les cas : commencez par la fenêtre géante. Elle se met en place en quelques heures, elle valide votre idée, et elle vous donne une base de comparaison. Vous saurez alors si le RAG en vaut la peine — et vous aurez des mesures pour l'affirmer, au lieu d'une conviction.

Questions fréquentes

Le RAG est-il mort ?

Non. Ce qui est mort, c'est le RAG naïf appliqué à de petits corpus : découper, chercher par similarité, envoyer trois fragments. Pour un corpus qui tient dans une fenêtre, cette architecture était surdimensionnée. La recherche reste indispensable dès que le corpus est grand, variable par utilisateur, ou que la traçabilité est requise.

Combien de fragments faut-il récupérer ?

Beaucoup plus qu'on ne le croyait. La logique du RAG classique — trois à cinq fragments, pour économiser — datait d'une époque où les fenêtres étaient étroites et les tarifs élevés. Aujourd'hui, récupérer largement puis laisser le modèle trier donne de meilleurs résultats. Mesurez sur vos propres questions.

La mise en cache fonctionne-t-elle vraiment ?

Oui, à une condition impérative : le contenu mis en cache doit être strictement identique d'une requête à l'autre, et placé en tête. Une date, un identifiant de session ou un nom d'utilisateur glissé avant le corpus suffit à invalider tout le cache — sans le moindre message d'erreur. Vérifiez les compteurs de lecture de cache exposés par votre fournisseur.

Les modèles vont-ils régler le problème de dégradation ?

Ils progressent, mais le phénomène est lié à des propriétés architecturales des mécanismes d'attention et ne disparaîtra pas par simple augmentation de la fenêtre. Concevoir en supposant que la précision est uniforme sur un million de tokens reste imprudent.

Faut-il un moteur de recherche vectoriel ?

Pas nécessairement. Pour beaucoup de corpus, une recherche par mots-clés bien réglée fonctionne aussi bien, coûte moins cher et se débogue infiniment plus facilement. Les meilleures configurations combinent souvent les deux. Ne montez pas une infrastructure vectorielle avant d'avoir mesuré ce qu'une recherche classique donne.

Comment savoir si ma recherche est bonne ?

En la mesurant séparément du modèle. Prenez cinquante questions réelles, notez pour chacune le passage qui contient la réponse, et vérifiez si votre système le récupère. Ce taux de récupération est votre plafond : aucune qualité de modèle ne compensera un passage jamais retrouvé. C'est la mesure que presque personne ne fait, et c'est la plus utile.

Ce qu'il faut retenir

Une fenêtre d'un million de tokens n'est pas une promesse de lecture attentive d'un million de tokens. La recherche documente deux dégradations distinctes : l'une liée à la position de l'information, l'autre à la simple longueur de l'entrée — et cette seconde s'observe bien plus tôt qu'on ne l'imagine.

Économiquement, le débat ne se joue pas où on le croit. Ce n'est pas la taille de la fenêtre qui décide, c'est la stabilité du contexte : un corpus identique pour tous se met en cache et rend la fenêtre géante compétitive ; un corpus propre à chaque utilisateur ne se met pas en cache et redonne au RAG un avantage d'un facteur soixante.

Et la bonne architecture, en 2026, ne choisit pas : elle récupère largement, puis raisonne longuement. La recherche n'y sert plus à trouver la réponse, mais à écarter le bruit — un objectif bien plus facile à atteindre, et bien plus robuste.

---

Note de méthode

Le phénomène de dégradation positionnelle (lost in the middle) et la chute de précision supérieure à 30 % pour une information placée en milieu de contexte proviennent des travaux de référence référencés ci-dessous, dont les résultats ont été répliqués sur plusieurs familles de modèles.

Le phénomène de dégradation par la longueur (context rot) est documenté par les travaux cités, distincts des précédents. Nous décrivons le mécanisme et son ordre de grandeur sans reprendre de valeur chiffrée précise : les mesures publiées portent sur des protocoles expérimentaux différents et ne sont pas directement transposables à un usage donné.

Les calculs de coût utilisent les tarifs officiels relevés le 7 août 2026 et des hypothèses explicites — corpus de 500 000 tokens, 1 000 requêtes quotidiennes, 8 000 tokens récupérés par requête en RAG. Ce sont des ordres de grandeur destinés à être recalculés avec vos propres valeurs, non des factures. Le coût d'infrastructure du RAG (indexation, recherche, stockage) n'est pas chiffré, faute de pouvoir le faire sans hypothèses arbitraires : il est signalé comme un terme à ajouter.

Nous ne publions aucun score de benchmark comparant les deux approches. Les résultats disponibles dépendent trop du corpus, des questions et du réglage pour être transposables.

Sources

• Lost in the Middle: How Language Models Use Long Contexts — Liu et al., Stanford
• When Retrieval Succeeds and Fails: Rethinking Retrieval-Augmented Generation for LLMs — arXiv 2510.09106
• Diagnosing and Mitigating Context Rot in Long-horizon Search — arXiv 2606.29718
• Classifier Context Rot: Monitor Performance Degrades with Context Length — arXiv 2605.12366
• Lost in the Middle, and In-Between: Enhancing Language Models' Ability to Reason Over Long Contexts — arXiv 2412.10079