Pourquoi le RAG — RAG : de la théorie à la production

Table des matières

Pourquoi ce chapitre est le point de départ

Avant d'assembler un pipeline de retrieval, avant de choisir une base vectorielle ou une stratégie de découpage, il faut comprendre précisément le problème que le RAG résout. Ce n'est pas un détail académique : la moitié des projets RAG mal conçus le sont parce que personne ne s'est demandé, en amont, si l'architecture était justifiée pour le cas d'usage visé.

Un modèle de langage n'est pas une base de données consultable. C'est une fonction statistique entraînée une fois, figée, qui produit du texte à partir de régularités apprises sur un corpus arrêté à une date donnée. Toute connaissance qui n'était pas dans ce corpus — ou qui a changé depuis — lui est structurellement inaccessible, sauf si on la lui fournit explicitly au moment de la requête. Le RAG est une des réponses à ce problème. Ce chapitre explique pourquoi il en existe d'autres, et dans quels cas chacune s'impose.

La fenêtre de contexte : une ressource finie, pas un tiroir sans fond

Chaque appel à un modèle de langage s'accompagne d'une limite : le nombre de tokens que le modèle peut lire et produire en une seule fois, la fenêtre de contexte. Les modèles récents affichent des fenêtres impressionnantes — 128k, 200k, parfois plus d'un million de tokens chez certains fournisseurs. Cela a fait naître une idée séduisante mais trompeuse : puisque la fenêtre est immense, pourquoi ne pas simplement y coller toute la documentation de l'entreprise ?

Trois raisons rendent cette approche intenable au-delà d'un certain volume.

Le coût. Chaque token du contexte est facturé, à chaque requête, même si 95 % du contenu collé n'est jamais utilisé pour répondre. Réinjecter 50 000 tokens de documentation à chaque question alors que la réponse tient dans trois paragraphes est un gaspillage qui se chiffre vite en budget mensuel significatif.
La latence. Plus le contexte est long, plus le modèle met de temps à le traiter avant de commencer à générer une réponse. Sur une interface utilisateur, cela se traduit par un délai perceptible, incompatible avec un usage conversationnel fluide.
La dégradation de l'attention. Un modèle ne traite pas un contexte long avec une attention uniforme. Les études sur le phénomène dit du « perdu au milieu » (lost in the middle) montrent que l'information placée au centre d'un contexte très long est retrouvée moins fiablement que celle placée en début ou en fin de prompt. Un document noyé dans 100 000 tokens de texte n'a pas la même probabilité d'être correctement exploité qu'un document isolé dans un prompt court.

Une fenêtre de contexte large n'est pas une mémoire persistante. Elle est réinitialisée à chaque nouvelle conversation, et rien n'est appris ni retenu d'un appel à l'autre. Confondre « le modèle peut lire beaucoup de texte » avec « le modèle sait beaucoup de choses » est l'erreur de conception la plus fréquente chez les équipes qui découvrent ces outils.

Il existe donc un plafond pratique bien en deçà du plafond technique. Un corpus d'entreprise de plusieurs milliers de pages ne rentre de toute façon jamais dans une fenêtre de contexte, aussi large soit-elle — et même s'il y rentrait, le coût et la dégradation de qualité rendraient l'exercice contre-productif.

Connaissances privées, connaissances datées

Un modèle de langage généraliste est entraîné sur un corpus public, arrêté à une date de coupure (cutoff). Deux catégories d'information lui échappent alors nécessairement :

Les connaissances privées. Les procédures internes d'une entreprise, sa base de contrats, son wiki technique, ses tickets de support historiques — rien de tout cela n'a pu figurer dans le corpus d'entraînement, pour la simple raison qu'il n'est pas public. Interroger un modèle standard sur « la politique de remboursement de notre produit X » ne peut aboutir qu'à une réponse générique, ou pire, à une réponse inventée avec la même assurance qu'un fait vérifié.
Les connaissances postérieures à la coupure. Une évolution réglementaire publiée le mois dernier, un changement de tarif, une nouvelle version d'une API : tout événement survenu après la date d'entraînement est absent des poids du modèle, quelle que soit sa notoriété publique.

Un modèle de langage ne « sait » que ce qui était statistiquement présent dans son corpus d'entraînement. Il n'a aucun accès en temps réel à une base de données externe, sauf si l'application qui l'entoure le lui fournit explicitement. Cette distinction entre connaissances paramétriques (encodées dans les poids) et connaissances fournies au moment de la requête est la clé de voûte de tout ce chapitre.

Face à cette double limite, demander au modèle de « faire de son mieux » sans lui donner l'information produit un risque connu : l'hallucination par comblement. Le modèle ne dispose d'aucun signal interne lui permettant de distinguer un souvenir fiable d'une extrapolation plausible — il produit dans les deux cas la suite de texte la plus probable compte tenu du contexte disponible.

Trois façons de combler le manque de connaissances

Il existe schématiquement trois stratégies pour donner à un modèle accès à des connaissances qu'il ne possède pas nativement. Elles ne sont pas interchangeables : chacune répond à un profil de besoin différent.

Approche	Principe	Fraîcheur	Traçabilité	Coût dominant
Bourrage de contexte	Coller les documents pertinents directement dans le prompt	Immédiate	Bonne si le prompt reste lisible	Coût par requête (tokens)
Fine-tuning	Ré-entraîner (ou ajuster) le modèle sur un corpus spécifique	Figée à la date du réentraînement	Nulle — le savoir est diffus dans les poids	Coût amont (calcul, données)
RAG	Rechercher les documents pertinents à la demande, puis les injecter dans le prompt	Celle de l'index, mise à jour en continu	Élevée — chaque réponse cite ses sources	Coût mixte (indexation + requête)

Une équipe support veut que son assistant connaisse la documentation produit, qui compte 40 000 pages réparties sur plusieurs wikis. Premier réflexe : tout coller dans le prompt système. Résultat : dépassement de la fenêtre de contexte, coût prohibitif dès les premiers tests, et réponses qui ignorent une partie du contenu à cause de l'effet « perdu au milieu ». Le bon réflexe est d'indexer ce corpus et de n'en récupérer, à chaque question, que les quelques passages réellement pertinents — c'est exactement ce que fait un pipeline RAG.

Le fine-tuning, de son côté, est souvent mal employé. Il est excellent pour transmettre un style, un format de réponse, ou un comportement (répondre toujours en respectant un gabarit JSON, adopter un ton spécifique). Il est en revanche un mauvais outil pour transmettre des faits volumineux et changeants : chaque mise à jour du corpus impose un nouveau cycle de réentraînement, et le modèle final ne peut pas justifier ses réponses en citant une source précise, puisque l'information est diluée dans des millions de paramètres.

Le RAG en pratique : principe général

Le RAG (Retrieval Augmented Generation, génération augmentée par récupération) répond à ce problème par un principe simple : ne pas demander au modèle de « savoir », mais lui donner, à chaque requête, exactement les documents dont il a besoin pour répondre — ni plus, ni moins.

Le déroulé typique d'une requête RAG suit quatre étapes.

Indexation préalable. Le corpus (documents, pages wiki, tickets, contrats) est découpé en fragments (chunks), puis chaque fragment est converti en vecteur numérique (embedding) qui capture son sens. Ces vecteurs sont stockés dans une base vectorielle.
Recherche (retrieval). Quand un utilisateur pose une question, celle-ci est elle aussi transformée en vecteur, puis comparée à l'ensemble des fragments indexés pour identifier les plus proches sémantiquement.
Augmentation du prompt. Les fragments retrouvés sont insérés dans le prompt envoyé au modèle, généralement accompagnés d'une consigne du type « réponds uniquement à partir des extraits suivants ».
Génération. Le modèle produit une réponse en s'appuyant sur ces extraits, et peut citer leur origine — ce qui rend la réponse vérifiable.

La question déclenche une recherche dans la base vectorielle ; les fragments retrouvés augmentent le prompt avant génération de la réponse.

Un pipeline RAG mal réglé — mauvais découpage, mauvais embeddings, recherche trop large ou trop étroite — produira des réponses médiocres même avec le meilleur modèle de génération disponible. À l'inverse, un retrieval précis compense en grande partie les limites d'un modèle plus modeste. Les chapitres suivants de cette formation consacrent une large part au réglage de cette étape, précisément parce qu'elle conditionne la qualité de tout le reste.

Ce principe paraît simple énoncé ainsi. Sa mise en œuvre soulève en réalité une série de décisions techniques non triviales — comment découper les documents, quel modèle d'embedding choisir, comment gérer les mises à jour du corpus, comment limiter les faux positifs de recherche — qui feront l'objet des chapitres suivants.

Quand le RAG n'est pas la bonne réponse

Le RAG n'est pas une solution universelle. Il ajoute de la complexité opérationnelle (indexation, maintenance de la base vectorielle, supervision de la qualité du retrieval) qui ne se justifie pas dans tous les contextes.

Corpus petit et stable. Si l'ensemble des documents pertinents tient confortablement dans une fenêtre de contexte et change rarement, le bourrage de prompt reste plus simple à opérer et à déboguer qu'un pipeline RAG complet.
Besoin de raisonnement plutôt que de rappel factuel. Le RAG excelle à retrouver de l'information existante. Il n'améliore pas la capacité du modèle à raisonner sur des problèmes nouveaux, à faire des calculs complexes ou à planifier des actions — ce sont d'autres familles de techniques qui répondent à ces besoins.
Style ou comportement à transmettre. Si l'objectif est d'obtenir systématiquement un format de sortie précis ou un ton particulier plutôt que d'accéder à des faits, le fine-tuning (ou un prompt système bien conçu) est souvent plus adapté et moins coûteux à maintenir.
Contrainte de latence extrême. L'étape de recherche ajoute un aller-retour supplémentaire avant la génération. Pour des cas d'usage exigeant une latence minimale et où le corpus est réduit, l'injection directe reste préférable.

Choisir le RAG parce que « c'est ce que tout le monde fait » est une mauvaise raison. La bonne question est : mon corpus est-il trop volumineux pour la fenêtre de contexte, change-t-il assez souvent pour rendre le fine-tuning impraticable, et ai-je besoin de traçabilité des sources ? Si les trois réponses sont non, une architecture plus simple suffit probablement.

Checklist avant de se lancer

Avant d'entamer la construction d'un pipeline RAG, il est utile de répondre honnêtement aux questions suivantes :

Le corpus dépasse-t-il, ou dépassera-t-il rapidement, ce qu'on peut raisonnablement coller dans un prompt ?
Le corpus évolue-t-il assez fréquemment pour rendre un réentraînement périodique coûteux ou impraticable ?
Le besoin métier exige-t-il de pouvoir justifier une réponse par une source précise (obligation réglementaire, support client, contexte juridique) ?
L'équipe dispose-t-elle des ressources pour maintenir une base vectorielle à jour dans la durée — et pas seulement pour la construire une fois ?
Le gain de précision attendu justifie-t-il la latence et le coût supplémentaires par rapport à une solution plus simple ?

Si la majorité de ces réponses sont positives, le RAG est probablement le bon choix architectural. Les chapitres suivants détaillent, brique par brique, comment le construire correctement : découpage des documents, choix des embeddings, stratégies de recherche, évaluation de la qualité, et mise en production.

Ce qu'il faut retenir

La fenêtre de contexte d'un modèle est une ressource finie et coûteuse, pas une mémoire persistante.
Un modèle de langage ne connaît que ce qui figurait dans son corpus d'entraînement, à l'exclusion de toute donnée privée ou postérieure à sa date de coupure.
Trois stratégies existent pour combler ce manque : le bourrage de prompt, le fine-tuning, et le RAG — chacune adaptée à un profil de besoin différent, aucune universellement supérieure.
Le RAG associe une étape de recherche documentaire à la génération, ce qui permet un accès à jour à un corpus volumineux, avec traçabilité des sources.
Le RAG ajoute de la complexité opérationnelle réelle : il ne se justifie que lorsque le volume, la fraîcheur ou la traçabilité l'exigent.

L'essentiel à retenir

Ce chapitre pose le problème que le RAG résout : un modèle de langage ne connaît que ce qui a été vu à l'entraînement, dans les limites d'une fenêtre de contexte finie et coûteuse. Il détaille pourquoi le bourrage de prompt et le fine-tuning échouent chacun à leur manière face à un corpus privé, volumineux ou évolutif. Il introduit le principe général du RAG — retrouver puis injecter les documents pertinents au moment de la requête — et fixe les critères permettant de décider si cette architecture est justifiée pour un cas d'usage donné. La suite de la formation développera chaque brique technique évoquée ici.

Questions fréquentes

Le RAG rend-il un modèle de langage plus intelligent ?

Non, le RAG ne modifie ni n'améliore les capacités de raisonnement du modèle. Il élargit uniquement l'accès à des informations factuelles externes, à jour et vérifiables, que le modèle n'aurait pas pu connaître autrement. Le raisonnement, le calcul ou la planification restent limités par les capacités propres du modèle de génération utilisé.

Peut-on combiner RAG et fine-tuning ?

Oui, et c'est même une pratique courante en production. Le fine-tuning peut servir à ajuster le comportement du modèle (format de réponse, ton, respect de consignes précises), tandis que le RAG fournit les faits à jour au moment de la requête. Les deux approches répondent à des besoins différents et ne sont pas mutuellement exclusives.

À partir de quelle taille de corpus faut-il envisager le RAG plutôt que le bourrage de prompt ?

Il n'existe pas de seuil universel, mais dès que le corpus dépasse ce qui peut être injecté à chaque requête sans coût ni latence excessifs, ou dès qu'il change plus vite qu'on ne peut le réécrire dans un prompt statique, le RAG devient pertinent. Un corpus de quelques pages stables ne justifie généralement pas la complexité d'un pipeline RAG.

Le RAG élimine-t-il complètement le risque d'hallucination ?

Non, il le réduit fortement sans l'éliminer. Si le retrieval renvoie des fragments non pertinents ou incomplets, le modèle peut encore produire une réponse erronée, ou combler les manques par extrapolation. La qualité du retrieval et une consigne stricte de ne répondre qu'à partir des extraits fournis sont essentielles pour limiter ce risque.

Une fenêtre de contexte très large (plusieurs centaines de milliers de tokens) rend-elle le RAG obsolète ?

Non. Même avec une fenêtre très large, le coût par requête, la latence et la dégradation de l'attention sur les contenus centraux subsistent. Le RAG reste préférable dès que le corpus est volumineux ou évolutif, car il ne transmet que les fragments réellement pertinents plutôt que l'intégralité d'une base documentaire à chaque appel.

Quelle est la différence entre connaissances privées et connaissances datées ?

Les connaissances privées sont des informations qui n'ont jamais pu figurer dans le corpus d'entraînement public d'un modèle, comme la documentation interne d'une entreprise. Les connaissances datées, elles, existaient publiquement mais sont apparues après la date de coupure de l'entraînement du modèle. Les deux cas produisent le même symptôme : le modèle ne peut pas y accéder sans qu'on les lui fournisse.

Le RAG est-il uniquement utile pour des chatbots documentaires ?

Non, ses usages dépassent largement le chatbot de support. On le retrouve dans la recherche juridique, l'assistance au diagnostic technique, la synthèse de veille réglementaire, ou encore les assistants de code qui doivent référencer une base interne. Le point commun de ces usages est le besoin d'accéder à un corpus volumineux, évolutif et vérifiable.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

Vos projets IA sont-ils sécurisés ? Audit LLM, conformité AI Act, red teaming — devis sous 48h.

Devis gratuit