RAG vs contexte long : quand bourrer le prompt de documents, quand faire de la recherche
Face à une fenêtre de contexte capable d'avaler un million de tokens, la question se pose légitimement : pourquoi encore découper, indexer et chercher des passages ? Parce que le coût, la latence et la précision ne suivent pas la même courbe selon la taille du corpus et la fréquence des questions. Ce guide compare concrètement le contexte long et le RAG pour choisir sans deviner.
Le contexte long : la promesse des fenêtres géantes
Depuis quelques années, les fournisseurs de modèles de langage rivalisent sur la taille de la fenêtre de contexte : certains modèles acceptent désormais plusieurs centaines de milliers, voire plus d'un million de tokens en entrée. Concrètement, cela permet de coller l'intégralité d'un rapport annuel, d'un code source complet ou de plusieurs dizaines de contrats directement dans le prompt, sans découpage préalable ni moteur de recherche intermédiaire.
L'attrait est évident : pas de pipeline à construire, pas de chunking à régler, pas de risque de rater le bon passage parce que la recherche n'a pas bien fonctionné. Le modèle « voit » tout le document et peut théoriquement répondre à n'importe quelle question, y compris celles qui nécessitent de recouper des informations dispersées dans tout le texte.
Mais cette simplicité apparente a un prix, et il grimpe vite dès que le volume de documents ou le nombre de questions augmente.
Le RAG : ne récupérer que ce qui compte
Le RAG (retrieval-augmented generation, ou génération augmentée par récupération) fonctionne différemment : les documents sont découpés en passages, indexés une fois pour toutes, puis seuls les quelques extraits pertinents pour une question donnée sont injectés dans le prompt au moment de la réponse. Le modèle ne voit jamais l'intégralité du corpus, seulement un échantillon ciblé de quelques centaines à quelques milliers de tokens.
Cette approche repose sur un pari : si la recherche (souvent hybride, combinant mots-clés et similarité sémantique) trouve les bons passages, la qualité de la réponse est équivalente, voire meilleure, qu'avec un contexte complet, pour une fraction du coût et de la latence. Pour comprendre le mécanisme en détail, notre article Comment fonctionne le RAG, étape par étape décrit le trajet complet d'une question, de l'indexation à la réponse sourcée.
Si vous découvrez le sujet, Qu'est-ce que le RAG (génération augmentée par récupération) ? Le guide pratique pose les bases avant d'aller plus loin.
Le vrai coût : tokens, latence, précision
La comparaison la plus parlante porte sur le coût par question lorsque le corpus grossit. Prenons un exemple illustratif : un corpus de 2 000 pages (environ 1 million de tokens) et un modèle facturé, pour fixer les idées, 10 € par million de tokens en entrée. Avec le contexte long, chaque question renvoie l'intégralité du corpus dans le prompt : environ 10 € par question, avant même de compter la sortie. Avec le RAG, seuls 5 à 10 passages pertinents (quelques milliers de tokens) sont envoyés : le coût tombe à quelques centimes par question.
Contexte long vs RAG : comparaison concrète
| Critère | Contexte long | RAG (recherche hybride) |
|---|---|---|
| Coût par question sur un gros corpus | Proportionnel à la taille du corpus, répété à chaque requête | Proportionnel à la taille des passages récupérés, quasi fixe |
| Latence | Augmente avec la taille du prompt envoyé | Reste courte, le prompt final est petit |
| Traçabilité des sources | Difficile à isoler dans un bloc massif | Passages cités, vérifiables un par un |
| Mise à jour des documents | Il faut renvoyer tout le contexte à chaque changement | Seuls les documents modifiés sont réindexés |
| Corpus multi-documents volumineux | Butte vite sur la limite de la fenêtre | S'étend sans limite pratique (des milliers de documents) |
| Questions ponctuelles sur un document unique court | Simple et direct | Overhead inutile pour un besoin aussi ponctuel |
Au-delà du coût brut, il y a un effet moins visible mais tout aussi réel : la dilution de l'attention. Plus le contexte est long, plus le modèle doit « chercher » l'information pertinente au milieu d'un bruit important, ce qui peut dégrader la précision sur des questions très spécifiques, même si techniquement tout le texte est présent dans le prompt. Le RAG, en ne présentant que les passages déjà jugés pertinents par le moteur de recherche, réduit ce bruit et facilite le travail du modèle.
La qualité de la recherche fait toute la différence
Un RAG mal réglé (chunking trop grossier, recherche uniquement sémantique) peut rater le bon passage et donner une réponse moins bonne qu'un contexte long complet. La recherche hybride, qui combine mots-clés exacts et similarité sémantique, limite ce risque : voir Recherche hybride : pourquoi combiner mots-clés et vecteurs bat chaque méthode seule.
Quand le contexte long suffit
Le contexte long est souvent le bon choix dans des situations précises :
- Un usage ponctuel sur un document unique : relire un contrat de 40 pages une seule fois avant signature ne justifie pas de construire un pipeline d'indexation.
- Un besoin de synthèse globale : résumer un rapport entier, détecter des incohérences d'un bout à l'autre du texte, des tâches où la recherche par extraits raterait le fil conducteur.
- Un volume de questions très faible : si vous posez une ou deux questions par jour sur un corpus de taille modérée, le surcoût du contexte long reste négligeable en valeur absolue.
- Un prototypage rapide : pour tester une idée avant d'investir dans une architecture RAG, coller le document dans le prompt est la solution la plus rapide à mettre en œuvre.
Quand le RAG devient nécessaire
À l'inverse, le RAG s'impose dès que l'un de ces facteurs entre en jeu :
- Un corpus qui dépasse largement la fenêtre de contexte : des milliers de pages de documentation, une base de jurisprudence, un historique de tickets support.
- Un volume de questions élevé : un support client qui traite des centaines de requêtes par jour ne peut pas se permettre de repayer l'intégralité du corpus à chaque échange.
- Un besoin de citations vérifiables : dans un contexte réglementé (juridique, finance, santé), pouvoir pointer le passage exact qui justifie une réponse est souvent une exigence, pas un confort. Voir notre article sur la vérification des réponses d'IA à partir de sources.
- Des documents qui changent fréquemment : avec le RAG, seule la partie modifiée est réindexée ; avec le contexte long, il faut reconstituer et renvoyer l'ensemble à chaque mise à jour.
- Un besoin de partager l'accès via une API ou un agent IA : une base indexée une fois peut être interrogée par de multiples clients (site web, API, serveur MCP) sans dupliquer le coût de traitement du corpus à chaque appel.
Les cas d'usage juridiques illustrent bien cette bascule : un cabinet qui doit croiser des textes, de la jurisprudence et des mémos internes gagne à indexer une fois pour toutes plutôt qu'à renvoyer des milliers de pages à chaque question. Notre article RAG pour les cabinets d'avocats détaille ce scénario, tout comme RAG pour le support client pour les équipes qui traitent un volume élevé de tickets.
Combiner les deux approches
Le choix n'est pas toujours binaire. Une architecture courante consiste à utiliser le RAG pour réduire un corpus massif à une poignée de documents candidats, puis à injecter ces documents en quasi-intégralité dans un contexte moyen pour une synthèse fine. C'est particulièrement utile quand la question nécessite de recouper plusieurs passages longs plutôt que des extraits courts et isolés.
Le découpage des documents (chunking) reste la variable la plus déterminante pour la qualité du RAG, qu'il soit utilisé seul ou en complément d'un contexte long : des chunks trop petits perdent le contexte, trop grands diluent la pertinence. Notre guide Stratégies de chunking pour le RAG détaille les arbitrages entre taille, chevauchement et découpage par structure.
Autre option fréquente : garder le contexte long pour les cas d'usage internes et ponctuels, et bâtir une base indexée dès que le même corpus doit être interrogé régulièrement, par plusieurs utilisateurs, ou exposé via une API ou un agent IA. C'est exactement ce que permet Kopik : transformer un ensemble de documents (PDF, Word, texte, Markdown) en base de connaissances indexée pour la recherche hybride, interrogeable depuis le site, via une API REST avec clés, ou via un serveur MCP utilisable depuis Claude, Cursor ou ChatGPT. Le découpage, l'indexation et le calcul des coûts par question sont gérés automatiquement, sans avoir à choisir manuellement entre renvoyer tout le corpus ou construire son propre pipeline de recherche.
Pour les équipes qui veulent exposer ce type de base dans leur propre application, Ajouter une API de base de connaissances à votre application : le guide développeur détaille l'intégration côté code.
Un repère simple pour décider
Avant de trancher, trois questions suffisent généralement à orienter le choix : combien de fois ce corpus sera-t-il interrogé, le corpus tient-il confortablement dans une fenêtre de contexte raisonnable, et avez-vous besoin de citer précisément vos sources ? Un usage ponctuel et un petit document plaident pour le contexte long. Un usage répété, un corpus volumineux ou une exigence de traçabilité plaident pour le RAG.
Tester avant de choisir
Créer une base de connaissances pour comparer est rapide : il suffit d'importer les mêmes documents et de comparer coût, latence et pertinence des réponses face à votre usage actuel en contexte long. Le catalogue /bases permet aussi de voir des exemples de bases déjà publiées pour se faire une idée des usages courants.
Comparez sur vos propres documents
Créez une base de connaissances gratuitement à partir de vos PDF, Word ou fichiers texte, et comparez le coût et la précision face à votre approche actuelle en contexte long.
Si l'hésitation porte sur l'architecture plus large (RAG, fine-tuning, ou les deux), notre article RAG ou fine-tuning : que choisir pour vos documents métier ? complète cette comparaison en ajoutant l'angle de l'entraînement du modèle. Et pour estimer le coût réel d'une base vectorielle si vous envisagez de construire votre propre pipeline RAG, Prix d'une base de données vectorielle : ce que vous payez vraiment détaille les postes de dépense au-delà du simple appel au modèle.
Questions fréquentes
Le contexte long va-t-il remplacer le RAG à terme ?
Peu probable à court terme. Même avec des fenêtres d'un million de tokens, le coût par question reste proportionnel à la taille du contexte envoyé, et ce coût est payé à chaque requête. Le RAG reste la solution la plus économique dès que le corpus est interrogé fréquemment ou dépasse largement la fenêtre disponible.
Le RAG est-il moins précis que le contexte long ?
Pas nécessairement. Un RAG bien réglé, avec un chunking adapté et une recherche hybride (mots-clés et similarité sémantique), récupère les passages pertinents sans le bruit d'un contexte massif, ce qui peut même améliorer la précision sur des questions ciblées. La qualité dépend surtout de la recherche, pas du mécanisme en lui-même.
À partir de quelle taille de corpus faut-il envisager le RAG ?
Il n'y a pas de seuil universel, mais dès que le corpus dépasse quelques centaines de pages et que les questions se répètent régulièrement, le RAG devient généralement plus rentable que de renvoyer l'intégralité du texte à chaque requête.
Peut-on combiner contexte long et RAG dans la même application ?
Oui, c'est une architecture courante : le RAG réduit un corpus massif à quelques documents candidats, puis ces documents sont injectés presque intégralement dans un contexte moyen pour une synthèse fine qui nécessite de recouper plusieurs passages longs.
Le RAG permet-il de citer les sources plus facilement que le contexte long ?
Oui, c'est l'un de ses avantages structurels : les passages récupérés sont identifiés individuellement, ce qui permet de citer précisément l'extrait et le document d'origine. Avec un contexte long, isoler la source exacte d'une affirmation dans un bloc massif de texte est beaucoup plus difficile.
Le contexte long coûte-t-il forcément plus cher que le RAG ?
Pas toujours : pour un usage ponctuel sur un document unique et peu de questions, le contexte long peut être moins coûteux en temps de développement sans pour autant générer une facture élevée. L'écart de coût se creuse surtout quand le volume de questions ou la taille du corpus augmentent.
Recevez la newsletter Kopik
Nouvelles bases de connaissances, guides sur le RAG et nouveautés du produit. Un mail toutes les une à deux semaines, désinscription en un clic.
En vous abonnant, vous acceptez de recevoir notre newsletter. Votre adresse n'est jamais partagée.