RAG : qu’est-ce que le Retrieval Augmented Generation ?

Demandez à un LLM combien de jours de télétravail prévoit votre accord d’entreprise. Il ne va pas avouer qu’il ne sait pas. Il va vous répondre avec assurance, dans des phrases bien construites, en inventant les chiffres. On appelle ça une hallucination. Les grands modèles de langage produisent du texte brillant, mais ils restent structurellement incapables de savoir ce qu’ils ignorent.

Le RAG existe pour résoudre ce problème précis. Il ne rend pas le modèle plus intelligent, il lui donne accès à la bonne information au bon moment.

Le RAG, c’est quoi exactement ?

RAG signifie Retrieval Augmented Generation, que l’on traduit par génération augmentée par la recherche. Le principe tient en une phrase : avant de répondre, le système va chercher l’information dans une base de documents, puis le modèle rédige sa réponse en s’appuyant sur ce qu’il a trouvé.

D’un côté, un LLM puise dans sa mémoire d’entraînement, qui est figée, généraliste et parfois fausse. De l’autre, un LLM consulte vos données réelles au moment où vous posez la question. Le modèle ne gagne pas en intelligence, il gagne en information.

Vous croisez le procédé tous les jours. Claude qui interroge le web avant de répondre pratique du RAG. Perplexity qui affiche ses citations à côté de sa réponse en fait autant. NotebookLM qui retrouve le bon passage dans vos documents repose sur le même mécanisme. Les AI Overviews de Google, les GPT personnalisés alimentés par des fichiers et les chatbots d’entreprise qui citent la bonne page du manuel fonctionnent tous sur ce principe.

Comment fonctionne le RAG : indexation, recherche, génération

Le pipeline tient en trois étapes. Elles se comprennent vite et se règlent difficilement.

L’indexation vient en premier. Vos documents sont découpés en morceaux, puis chaque morceau est transformé en vecteur numérique par un modèle d’embeddings. Ces vecteurs rejoignent une base vectorielle qui conserve le lien vers le document d’origine, sans quoi vous ne pourrez jamais citer votre source.

La recherche suit. Votre question est transformée en vecteur à son tour, et le système remonte les morceaux dont le sens est le plus proche. Les bons systèmes croisent cette recherche sémantique avec une recherche par mots-clés, pour des raisons que nous détaillons plus loin.

La génération termine le travail. Les morceaux retenus sont injectés dans le prompt avec votre question. Le modèle rédige sa réponse à partir de ces extraits, et il peut indiquer de quel document ils viennent.

La recherche sémantique explique pourquoi un RAG bien réglé retrouve un passage qui parle d’automobile quand vous demandez une voiture. Le vecteur capture le sens du texte plutôt que ses mots exacts, et c’est tout l’apport du traitement du langage naturel dans ce type de système.

RAG ou contexte long : ce que change la fenêtre d’un million de tokens

Un million de tokens d’entrée est devenu la norme chez les modèles phares. GPT-6 Astra accepte 1 050 000 tokens, Claude Opus 5.5 et Gemini 3.8 Flash un million chacun, ce qui représente plusieurs milliers de pages. La question revient naturellement : pourquoi construire un pipeline de recherche quand on peut verser tout le corpus dans le prompt ? Nous avons exploré cet usage à propos de la fenêtre d’un million de tokens de Qwen. Deux réserves sérieuses subsistent.

Première réserve, les modèles ne lisent pas un million de tokens aussi bien que dix mille. Chroma a testé dix-huit modèles sur trois familles d’épreuves : des variantes du test de l’aiguille dans la botte de foin, le jeu conversationnel LongMemEval et une tâche de répétition. La performance devient de moins en moins fiable à mesure que l’entrée s’allonge. Le phénomène porte un nom chez les praticiens, le context rot, et Anthropic l’emploie dans sa propre documentation d’ingénierie : la capacité du modèle à retrouver une information dans sa fenêtre diminue quand le nombre de tokens augmente.

Cette dégradation ne se voit pas sur une démonstration. Elle apparaît quand la question demande de recouper deux passages éloignés, quand des distracteurs ressemblent à la bonne réponse, ou quand le corpus contient deux versions contradictoires du même chiffre.

Seconde réserve, le contexte long se paie, et pas de façon linéaire. La documentation d’OpenAI pose un seuil explicite pour GPT-6 Astra : au-delà de 272 000 tokens d’entrée, le tarif d’entrée et le tarif de cache doublent et la sortie subit une majoration de 1,5 fois, sur la totalité de la requête. Le tarif d’entrée standard de 10 dollars par million monte à 20 dollars dès que vous franchissez ce seuil.

Le calcul devient parlant sur un exemple. Vous posez une question sur un corpus de 500 000 tokens. En le versant entier dans le prompt, vous payez environ 10 dollars d’entrée par question. Un pipeline de recherche qui remonte huit mille tokens pertinents coûte 8 centimes. L’écart se joue sur deux ordres de grandeur, et il se répète à chaque question posée.

Le cache d’entrée nuance ce résultat. OpenAI facture l’entrée en cache 1 dollar par million, soit 90 % de moins, et Anthropic 0,25 dollar pour Claude Fable 5.1, soit 97,5 % de moins. Si vous interrogez plusieurs fois le même corpus pendant la durée de vie du cache, le contexte long redevient défendable. Notez toutefois que le seuil des 272 000 tokens s’applique aussi au tarif de cache chez OpenAI, ce qui rabote le gain sur les très gros prompts.

Les deux approches ne s’opposent donc pas. Le contexte long convient à un document unique et cohérent que vous voulez faire lire en entier, comme un rapport de trois cents pages ou un dossier juridique. Le RAG convient à un corpus vaste, hétérogène et vivant, dans lequel vous ne cherchez chaque fois qu’une poignée de passages. Beaucoup de systèmes en production utilisent les deux : la recherche sélectionne quinze documents au lieu d’un seul, et la fenêtre large absorbe ce volume sans difficulté.

Découpage, embeddings et re-classement : là où un RAG se gagne ou se perd

Le découpage des documents

Le découpage détermine ce que le système pourra retrouver. Un morceau trop petit perd son contexte, et le modèle reçoit une phrase sans savoir de quel chapitre elle sort. Un morceau trop gros dilue le signal, parce que le vecteur moyenne plusieurs idées et finit par ressembler vaguement à tout.

Anthropic a publié une technique qui traite ce problème de front, sous le nom de recherche contextuelle. Elle consiste à faire écrire par un modèle, pour chaque morceau, une ou deux phrases qui le situent dans son document, puis à indexer le morceau augmenté de ce préambule. Sur le jeu de tests d’Anthropic, le taux d’échec de la recherche tombe de 5,7 % à 3,7 %, soit une réduction de 35 %.

Choisir un modèle d’embeddings

Le modèle d’embeddings fixe la qualité du rappel, et il fixe aussi votre coût de migration. Deux modèles ne partagent pas le même espace vectoriel : en changer oblige à réindexer tout le corpus. Ce choix se fait tôt et se paie tard.

Trois questions comptent plus que le classement d’un banc d’essai. Votre corpus est-il multilingue ? Contient-il des images, des tableaux ou des PDF que vous voulez indexer directement ? Devez-vous garder les données en Europe, ce qui oriente vers Mistral Embed, ou vers Codestral Embed s’il s’agit de code ? Les réponses à ces trois questions éliminent la plupart des candidats.

Les dimensions réductibles méritent un mot. OpenAI et Google permettent de tronquer le vecteur sans réentraîner quoi que ce soit, et Cohere propose quatre tailles. Passer de 3 072 à 768 dimensions divise par quatre le coût de stockage et accélère la recherche, au prix d’une perte de précision que vous devez mesurer sur vos propres données.

La recherche hybride et le re-classement

La recherche sémantique seule laisse passer des cas simples. Elle retrouve mal une référence produit, un numéro d’article ou un nom propre rare, parce que ces chaînes comptent moins par leur sens que par leur exactitude. Une recherche par mots-clés couvre exactement ce terrain. La recherche hybride combine les deux et additionne leurs forces. Azure AI Search la présente comme un moyen d’équilibrer précision et rappel. Anthropic en mesure l’apport sur son jeu de tests, où l’ajout d’un index lexical contextuel fait tomber le taux d’échec de 5,7 % à 2,9 %.

Le re-classement intervient en dernier. Un modèle de reranking reprend les trente ou cinquante candidats remontés par la recherche, les note un par un contre la question posée, et ne garde que les meilleurs. Cohere propose rerank-v4.0-pro et rerank-v4.0-fast, multilingues, avec une longueur de contexte de 32 000 tokens. Dans les mesures d’Anthropic, cette étape supplémentaire ramène le taux d’échec à 1,9 %, soit 67 % de moins que la configuration de départ.

Cette suite de trois chiffres dit l’essentiel sur un projet RAG. Le gain ne vient pas du modèle de génération, il vient de la qualité de ce qu’on lui donne à lire.

Le RAG agentique : le système décide lui-même quoi chercher

Un RAG classique lance une recherche par question. Un RAG agentique en lance plusieurs, et il décide lesquelles.

Microsoft a industrialisé l’idée dans son service Azure AI Search, où elle porte le nom de recherche agentique. Un modèle découpe la question en sous-questions, environ trois par plan d’après la documentation, les exécute en parallèle, re-classe sémantiquement chaque lot de résultats, puis fusionne le tout en un ensemble unique accompagné des références des sources et d’un journal d’activité. Microsoft indique noir sur blanc le prix de cette qualité : la latence augmente par rapport à une recherche en une seule passe.

Anthropic pousse la logique plus loin dans ses recommandations sur le contexte des agents. Plutôt que de tout précharger, l’agent conserve des références légères et charge les données en cours d’exécution avec ses outils, au fur et à mesure de ce qu’il découvre. Cette exploration à la demande coûte du temps par rapport à une recherche précalculée, et Anthropic conseille de combiner les deux approches : une première récupération rapide, puis de l’exploration autonome quand elle apporte quelque chose.

Un protocole ouvert sert de tuyauterie à cette façon de travailler. Publié par Anthropic sous le nom de Model Context Protocol, il standardise la connexion d’un assistant à des sources de données et à des outils. Claude et ChatGPT le prennent en charge, comme les principaux éditeurs de code. Un agent IA qui interroge votre wiki, votre CRM et votre base de tickets dans la même conversation s’appuie sur cette plomberie.

Faire entrer des documents scannés dans un RAG

Une grande partie des documents d’entreprise n’existe que sous forme d’image : contrats signés, plans, factures, dossiers archivés. Un pipeline RAG classique les ignore, puisqu’il n’y trouve aucun texte à découper. Les modèles de reconnaissance de caractères récents ont changé cette situation.

Mistral a publié en mars 2025 un premier modèle d’OCR mesuré à 94,89 % de justesse globale sur son propre banc d’essai, tandis que les six autres systèmes comparés, dont GPT-4o, Azure OCR, Google Document AI et deux versions de Gemini 1.5, se situaient entre 83,42 % et 90,23 %. L’éditeur annonçait alors un débit de 2 000 pages par minute sur un seul serveur et un tarif de mille pages par dollar. Ce modèle est aujourd’hui remplacé par mistral-ocr-4-1, qui ajoute trois éléments utiles à un RAG : des cadres de délimitation au niveau du paragraphe, des étiquettes de blocs structurels et un score de confiance par bloc.

Ces scores de confiance ont un usage direct. Ils vous donnent un filtre : un bloc lu avec une confiance faible ne part pas dans l’index, il part dans une file de relecture humaine. Sans ce filtre, un RAG répond avec aplomb sur un montant mal reconnu, et personne ne s’en aperçoit.

Deux autres approches méritent d’être connues. DeepSeek a publié DeepSeek-OCR en octobre 2025, qui compresse une page entière en quelques centaines de tokens visuels : en dessous d’un facteur dix de compression, les auteurs mesurent 97 % de justesse de décodage, et environ 60 % à un facteur vingt. LlamaParse, du côté de LlamaIndex, s’appuie sur des modèles de vision pour venir à bout des tableaux imbriqués et des graphiques intégrés. Les modèles multimodaux généralistes savent aussi lire un document visuel, un usage que nous avons détaillé à propos de l’analyse visuelle de documents.

RAG : cas d’usage concrets et profils concernés

Le RAG n’a pas d’intérêt pour tout le monde. Si vous utilisez l’IA pour reformuler un email ou chercher des idées, le modèle travaille avec ce que vous lui donnez dans la conversation, et cela suffit largement.

Il devient indispensable quand votre base documentaire dépasse ce qu’un prompt peut contenir, quand vos données changent régulièrement, quand vous devez savoir quel document a produit la réponse, ou quand plusieurs personnes interrogent la même base de connaissances.

Quatre exemples donnent la mesure du besoin. Un chatbot de support s’appuie sur la documentation produit. Un assistant RH répond à partir des accords d’entreprise. Un cabinet d’avocats cherche dans sa propre jurisprudence. Une équipe produit interroge deux cents pages de spécifications. Ces quatre cas partagent les mêmes caractéristiques : des données privées, volumineuses, qui doivent rester à jour.

Mettre en place un RAG : du no-code au sur-mesure

On peut commencer sans écrire une ligne de code. NotebookLM, les GPT personnalisés d’OpenAI et ChatPDF acceptent vos documents, répondent à vos questions et citent leurs sources. Ce niveau suffit à un indépendant, à une petite équipe ou à un corpus de quelques dizaines de fichiers.

Les plateformes visuelles constituent l’étage suivant. Dust connecte des agents d’entreprise à vos sources internes et cherche dans votre documentation avant de répondre. Relevance AI construit des agents par fonction, avec une couche de contexte partagée entre eux, plus d’un millier d’intégrations et une facturation à la tâche. Stack AI occupe le même créneau. Vous choisissez vos sources, votre modèle d’embeddings et votre stratégie de découpage, sans toucher au code.

Les services managés des grands fournisseurs de cloud visent les déploiements sérieux. Azure AI Search réunit recherche vectorielle, recherche hybride, classement sémantique, vectorisation intégrée et découpage dans un même index, avec la recherche agentique en complément. Vous gagnez du temps d’intégration, et vous acceptez en échange une dépendance à un fournisseur.

Pour une application maison, deux cadres logiciels dominent. Leurs éditeurs ont publié LangChain et LangGraph en version stable le 22 octobre 2025, avec un engagement de non-régression jusqu’à la prochaine version majeure et 90 millions de téléchargements mensuels revendiqués. LlamaIndex couvre le même terrain et y ajoute LlamaCloud pour l’analyse des documents difficiles.

Du côté du stockage, Pinecone, Weaviate, Qdrant et Chroma sont des bases vectorielles dédiées. Si vos données vivent déjà dans PostgreSQL, l’extension pgvector évite d’ajouter un serveur : elle gère les index HNSW et IVFFlat, six métriques de distance et des vecteurs jusqu’à 16 000 dimensions, à côté de vos tables existantes. Pour beaucoup de projets, ce choix simple reste le bon.

Une question revient toujours : pourquoi ne pas simplement réentraîner le modèle sur vos données ? Le fine-tuning change le comportement du modèle, son ton et son vocabulaire, alors que le RAG lui donne accès à l’information. Les deux techniques de machine learning se combinent, mais avec un seul budget, commencez par le RAG. Il coûte moins cher, se met en place plus vite, et vos données restent à jour sans réentraînement.

Pourquoi les projets RAG échouent en entreprise

Gartner prévoyait dès juillet 2024 qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept avant la fin 2025, en citant la mauvaise qualité des données, l’insuffisance des contrôles de risque, la dérive des coûts et une valeur métier floue. Rita Sallam, analyste de la firme, chiffrait alors un déploiement entre 5 et 20 millions de dollars. Les projets RAG concentrent ces quatre causes, et les échecs se ressemblent d’une entreprise à l’autre.

• Aucun jeu d’évaluation — l’équipe juge la qualité de façon informelle, sur quelques questions qu’elle a choisies elle-même. Sans une centaine de questions réelles accompagnées de leurs réponses attendues, personne ne sait si le nouveau réglage améliore ou dégrade le système.
• Les droits d’accès oubliés — l’index mélange des documents que tout le monde ne devait pas voir. Un RAG qui ignore les permissions de la source transforme une bonne idée en incident de conformité.
• Des documents sans propriétaire — trois versions du même tarif circulent, aucune n’est datée, et le système remonte la mauvaise. Le problème est organisationnel et aucun réglage technique ne le corrige.
• Un paramétrage figé au premier jour — la taille des morceaux, le modèle d’embeddings et le nombre de passages remontés sont fixés une fois pour toutes, alors que le corpus, lui, continue de changer.
• Pas de boucle de retour — les utilisateurs constatent les mauvaises réponses sans avoir aucun moyen de les signaler. Les questions qui échouent restent invisibles pour l’équipe qui maintient le système.
• Des questions de test trop propres — la démonstration tourne sur des formulations soignées, pendant que les utilisateurs écrivent trois mots avec une faute de frappe.

Ces six échecs ont un point commun qui mérite d’être dit : aucun ne se répare en changeant de modèle de langage. Ils se règlent en amont, dans la documentation et dans la gouvernance des données, un travail que nous détaillons dans notre checklist de préparation des données.

Les limites du RAG — et ce que les vendeurs ne disent pas

Le RAG n’a rien d’une solution magique. Le marché regorge pourtant de produits qui vendent du RAG en un clic sans jamais parler de ce qui fait échouer les projets.

Le vrai problème vient rarement de la technique et souvent de vos documents. Un RAG ne retrouve que ce qui existe dans la base. Des documents mal écrits, mal structurés, contradictoires ou périmés ne s’améliorent pas au passage : le système amplifie le problème au lieu de le résoudre. La première question à se poser avant tout déploiement reste donc celle-ci : ma documentation est-elle en état d’être exploitée par une machine ?

Une recherche défaillante donne une réponse défaillante. Si l’étape de récupération ne remonte pas les bons passages, le modèle rédige une réponse assurée à partir de morceaux hors sujet. Mal configuré, un RAG donne l’illusion de la fiabilité, ce qui le rend plus dangereux qu’un LLM utilisé seul.

Le milieu du contexte se perd. Les modèles exploitent mieux le début et la fin de ce qu’on leur donne, et ils négligent le centre. Plus vous injectez de passages, plus ceux du milieu risquent d’être ignorés. Une étude de Stanford publiée en 2023 a mesuré cet effet de position, et les travaux de Chroma montrent de leur côté que la fiabilité baisse quand l’entrée s’allonge, y compris dans les fenêtres géantes.

Le coût grimpe avec l’échelle. Indexer quelques milliers de documents ne pose aucune difficulté. En indexer des millions avec des mises à jour fréquentes demande une infrastructure sérieuse et le budget qui va avec. Beaucoup de preuves de concept impressionnantes en démonstration s’effondrent en production.

Une bonne partie des solutions RAG revient à un NotebookLM à 500 euros par mois. Voilà l’éléphant dans la pièce. Beaucoup de ces plateformes n’apportent rien de plus qu’un dépôt de documents dans un modèle de langage, avec une interface soignée par-dessus. Avant de payer, vérifiez ce que la plateforme fait réellement de plus que les outils gratuits, et testez avec vos vrais documents plutôt qu’avec la démonstration du vendeur.

Ce que cela change pour vous

Le RAG fait le pont entre les LLM et vos données. Ce pont tient à trois conditions. Il lui faut d’abord des fondations solides, c’est-à-dire des documents propres et à jour. L’architecture doit ensuite fonctionner, avec un découpage, une recherche hybride et un re-classement réglés sur votre corpus. Une évaluation honnête referme la liste, celle qui ne confond pas la démonstration du vendeur avec votre réalité.

Vous demandez déjà à Claude de chercher sur le web et vous déposez des fichiers dans ChatGPT, donc vous pratiquez le principe du RAG. La question utile porte ailleurs : vos besoins dépassent-ils ce que ces outils gratuits font déjà très bien ? Si vos données sont trop volumineuses, changent trop souvent ou exigent de la traçabilité, passez au niveau supérieur et commencez par mesurer. Sinon, ne laissez personne vous vendre un problème que vous n’avez pas. Notre glossaire de l’intelligence artificielle reprend le vocabulaire de ce domaine si un terme vous manque.