RAG expliqué simplement : donner de la mémoire à une IA

Un grand modèle de langage sait beaucoup de choses, mais il ne sait rien de vos choses. Il ignore le contenu de vos contrats, le manuel technique de votre produit, les comptes rendus de vos réunions ou la dernière version de votre politique interne. Pire : lorsqu'on l'interroge sur un sujet précis qu'il ne connaît pas, il a tendance à répondre quand même, en inventant une réponse plausible mais fausse. C'est exactement le problème que la génération augmentée par récupération — Retrieval-Augmented Generation, ou RAG — vient résoudre. L'idée tient en une phrase : avant de laisser le modèle répondre, on va d'abord chercher les bons documents et on les lui glisse sous les yeux. On donne, en somme, une mémoire externe à une intelligence qui n'en avait pas.

Cet article propose une explication accessible et complète du RAG, sans jargon inutile mais sans simplifier à l'excès. Nous allons voir d'où vient cette technique, comment elle fonctionne étape par étape, quelles sont ses briques essentielles — le découpage, les embeddings, la base vectorielle, la récupération, la génération — et surtout où se cachent les pièges qui font échouer tant de projets. À la fin, vous saurez non seulement ce qu'est un système RAG, mais aussi quand il constitue le bon choix et quand une autre approche serait préférable. Que vous soyez développeur, chef de projet ou simple curieux désireux de comprendre ce qui se trame derrière les assistants documentaires, cette lecture vous donnera une vision claire du sujet.

Un mot de méthode d'abord. Le RAG est souvent présenté comme une recette magique qui supprime toutes les erreurs d'un modèle de langage. Ce n'est pas le cas, et nous le verrons sans détour. Le RAG améliore considérablement la fiabilité factuelle d'un système, mais uniquement s'il est bien conçu. Un mauvais RAG peut se révéler plus trompeur qu'un modèle seul, car il donne une impression de rigueur — « regardez, il cite des sources ! » — tout en s'appuyant sur des extraits mal choisis. Comprendre les mécanismes, c'est justement se donner les moyens d'éviter ce piège.

D'où vient le RAG : une idée née en 2020

Le terme « Retrieval-Augmented Generation » n'est pas un mot-valise marketing récent. Il apparaît dans un article scientifique précis, publié en 2020 par une équipe de chercheurs menée par Patrick Lewis, alors chez Facebook AI Research (FAIR, devenu Meta AI en 2021), en collaboration avec l'University College London et l'Université de New York. L'article, intitulé « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », a été présenté à la conférence NeurIPS 2020. C'est lui qui a donné son nom à toute une famille de méthodes.

Pour comprendre l'intuition des auteurs, il faut saisir une distinction qu'ils posent d'emblée : celle entre mémoire paramétrique et mémoire non paramétrique. La mémoire paramétrique, c'est tout ce qu'un modèle a appris pendant son entraînement et qu'il a « rangé » dans ses paramètres, ces milliards de nombres qui constituent le réseau. Cette connaissance est puissante mais figée : elle date de le terme de l’entraînement, elle est diffuse, et on ne peut pas la mettre à jour sans réentraîner le modèle. La mémoire non paramétrique, elle, est externe : c'est une base de documents que l'on peut consulter à la demande, modifier, enrichir, corriger, sans jamais toucher au modèle lui-même.

La proposition de Lewis et ses collègues consistait à coupler ces deux formes de mémoire. Concrètement, leur système associait un modèle génératif de type séquence-à-séquence à un index dense de l'ensemble de Wikipédia. Face à une question, le système allait d'abord récupérer les passages pertinents dans cet index, puis générait une réponse en s'appuyant sur ces passages. Les résultats étaient probants : sur les tâches dites « à forte intensité de connaissances » — les questions-réponses factuelles, notamment — le modèle RAG produisait des réponses plus précises et mieux ancrées dans les faits que les modèles ne s'appuyant que sur leur mémoire paramétrique.

L'apport fondateur du RAG tient en une phrase : combiner une mémoire paramétrique, apprise et généraliste, avec une mémoire non paramétrique, externe et modifiable à volonté.

Ce qui rend cette idée si durable, c'est qu'elle répond à une contrainte structurelle des modèles de langage. Réentraîner un grand modèle coûte cher et prend du temps ; on ne le fait pas chaque semaine pour intégrer les dernières informations. Le RAG contourne élégamment cet obstacle : au lieu de graver la connaissance dans le modèle, on la garde à l'extérieur, dans une base que l'on met à jour librement. Le modèle, lui, ne change pas — il apprend simplement à bien utiliser ce qu'on lui présente. C'est cette séparation entre le « raisonneur » et la « bibliothèque » qui a fait le succès de l'approche et qui explique sa présence dans une grande partie des applications documentaires d'aujourd'hui.

Le problème que le RAG résout vraiment

Avant de plonger dans la mécanique, arrêtons-nous sur les maux concrets qu'adresse le RAG. Ils sont au nombre de trois, et chacun mérite d'être compris pour saisir la valeur de la technique.

La date de coupure de connaissances

Un modèle de langage est entraîné sur des données arrêtées à une certaine date. Passé ce point, il ignore tout : les événements récents, les nouveaux produits, les décisions prises hier. On appelle cela la « date de coupure de connaissances ». Interrogé sur un fait postérieur à son entraînement, le modèle répondra soit qu'il l'ignore, soit — plus gênant — par une supposition présentée avec assurance. Le RAG résout ce problème en branchant le modèle sur une base documentaire tenue à jour : peu importe la date de coupure, si l'information est dans la base, elle sera récupérée et transmise.

La connaissance privée et spécialisée

Aucun modèle généraliste n'a été entraîné sur vos documents internes, pour une raison évidente : ils ne sont pas publics. Vos procédures, vos contrats, votre documentation produit, votre historique de tickets — tout cela lui est étranger. Le RAG permet précisément d'injecter cette connaissance privée sans avoir à la « fondre » dans le modèle par un réentraînement coûteux et risqué pour la confidentialité. Les documents restent dans votre base ; le modèle les consulte à la volée.

Les hallucinations factuelles

C'est sans doute le point le plus important. Livré à lui-même sur un sujet qu'il maîtrise mal, un modèle de langage a tendance à « halluciner » : il produit une réponse fluide, grammaticalement irréprochable et… inexacte. Le RAG réduit sensiblement ce phénomène en ancrant la réponse dans des passages réels récupérés au préalable. Le modèle ne répond plus dans le vide : il dispose d'un matériau documentaire sur lequel s'appuyer, ce qui le contraint à rester au plus près des faits fournis. La documentation technique de la communauté est unanime sur ce point : fournir un contexte externe pertinent est l'un des leviers les plus efficaces pour améliorer la fiabilité factuelle d'un système.

Une précision honnête s'impose toutefois : le RAG réduit les hallucinations, il ne les supprime pas. Si la récupération ramène des extraits hors sujet, ou si le modèle interprète mal des passages corrects, l'erreur reste possible. Nous y reviendrons dans la section consacrée aux pièges, car c'est là que se joue la différence entre un système RAG fiable et un système décevant.

Comment ça marche : le pipeline étape par étape

Un système RAG fonctionne en deux temps bien distincts. Il y a d'abord une phase préparatoire, réalisée une fois pour toutes (et répétée à chaque mise à jour documentaire) : c'est l'indexation. Vient ensuite la phase vivante, déclenchée à chaque question posée : c'est la récupération suivie de la génération. La documentation technique décrit couramment ce parcours comme un pipeline en cinq à sept étapes. Détaillons-le.

Étape 1 — L'ingestion des documents

Tout commence par la collecte des sources. On rassemble les documents qui constitueront la base de connaissances : fichiers PDF, pages web, notes internes, base d'articles, transcriptions, etc. Cette étape, apparemment banale, est en réalité déterminante. Un document mal extrait — un PDF dont les tableaux sont désordonnés, une mise en page qui mélange colonnes et notes de bas de page — produira un texte de mauvaise qualité qui plombera tout le reste. On dit parfois, avec justesse, que la qualité d'un RAG se décide dès l'ingestion.

Étape 2 — Le découpage en morceaux (chunking)

On ne peut pas traiter un document de cent pages comme un bloc unique. On le découpe donc en portions plus petites et cohérentes, appelées « chunks » (morceaux). Chaque chunk représente une unité de sens : un paragraphe, une section, parfois quelques phrases. La taille de ces morceaux — mesurée en tokens ou en mots — est un paramètre crucial. Trop petits, les chunks perdent leur contexte et deviennent difficiles à interpréter isolément ; trop gros, ils diluent l'information pertinente au milieu de texte hors sujet, ce qui brouille la récupération.

Le découpage naïf, dit « à taille fixe » (par exemple 512 tokens avec un chevauchement de 50 tokens entre morceaux consécutifs), est simple à mettre en œuvre mais coupe souvent au milieu d'une phrase ou d'une idée, ce qui dégrade la qualité. Des approches plus fines existent : le découpage sémantique, qui respecte les frontières naturelles du texte (paragraphes, sections), ou le découpage hiérarchique, qui conserve à la fois des morceaux « parents » (une section entière) et des morceaux « enfants » (une phrase), récupérant au niveau fin pour la précision tout en fournissant le parent comme contexte au modèle. Le choix de la stratégie de découpage n'est pas un détail technique : il conditionne directement ce que le système saura, ou non, retrouver.

Étape 3 — Le calcul des embeddings

Chaque chunk est ensuite transformé en un embedding : un vecteur, c'est-à-dire une liste de nombres, qui capture le sens sémantique du texte. C'est l'étape la plus contre-intuitive pour un néophyte, alors prenons le temps de l'expliquer. Un modèle d'embedding a appris à représenter chaque texte par un point dans un espace à plusieurs centaines, voire milliers, de dimensions. La propriété remarquable de cet espace est que les textes de sens proche se retrouvent proches les uns des autres. Les mots « montagne » et « colline » produiront des vecteurs voisins, bien qu'ils partagent peu de lettres, tandis que « montagne » et « facture » seront éloignés. On transforme ainsi le sens en géométrie : la proximité de sens devient une proximité mesurable dans l'espace.

Cette bascule du sens vers les nombres est le cœur battant du RAG moderne. Sans elle, on en serait réduit à chercher des mots-clés exacts, comme dans un moteur de recherche rudimentaire. Avec elle, on peut retrouver un passage qui répond à la question sans employer les mêmes mots que la question — ce qui correspond bien mieux à la façon dont le langage humain fonctionne.

Étape 4 — Le stockage dans une base vectorielle

Tous ces vecteurs sont rangés dans une base de données vectorielle, une catégorie de base de données spécialisée dans le stockage et la recherche rapide de vecteurs. Contrairement à une base relationnelle classique, qui recherche des correspondances exactes, une base vectorielle trouve les documents dont le sens est le plus proche d'une requête donnée, en calculant une distance entre vecteurs. La mesure la plus répandue est la similarité cosinus, qui compare l'orientation des vecteurs plutôt que leur longueur.

À grande échelle, comparer une requête à des millions de vecteurs un par un serait trop lent. Les bases vectorielles emploient donc des algorithmes de recherche approximative de plus proches voisins, qui sacrifient une infime part de précision contre un gain de vitesse considérable. C'est ce compromis qui rend la recherche sémantique praticable sur d'immenses corpus. On retrouve ici une logique familière en ingénierie : accepter une approximation contrôlée pour obtenir une performance qui, autrement, resterait hors de portée.

Étape 5 — La récupération

Voici où tout se rejoint. Quand un utilisateur pose une question, cette question est d'abord transformée en embedding, avec exactement le même modèle que celui utilisé pour indexer les documents — ce point est essentiel, car deux modèles différents produiraient des vecteurs incomparables. La base vectorielle recherche alors les chunks dont le vecteur est le plus proche de celui de la question, et renvoie les plus pertinents, souvent les trois à dix meilleurs. C'est l'étape de récupération proprement dite : on est allé chercher, dans la bibliothèque, les quelques pages qui traitent du sujet.

Étape 6 — L'augmentation et la génération

Les chunks récupérés sont enfin insérés dans le prompt envoyé au modèle de langage, aux côtés de la question de l'utilisateur. C'est l'augmentation : on enrichit la demande avec le contexte pertinent. Le modèle produit alors sa réponse en s'appuyant sur ces extraits, idéalement en citant ses sources. Le prompt ressemble, dans son esprit, à une consigne du type : « Voici des extraits de documents. En te fondant uniquement sur eux, réponds à la question suivante. Si l'information n'y figure pas, dis-le. »

Cette dernière instruction — « si l'information n'y figure pas, dis-le » — n'est pas anodine. Elle autorise le modèle à reconnaître son ignorance plutôt qu'à combler un vide par une invention. Bien formulée, elle constitue l'un des garde-fous les plus simples et les plus efficaces contre l'hallucination.

Le RAG relie deux mondes : une bibliothèque que l'on met à jour librement et un modèle qui sait lire, raisonner et rédiger. La qualité du résultat dépend autant de la bibliothèque que du lecteur.

Les briques essentielles, décryptées

Le pipeline que nous venons de parcourir repose sur quelques composants dont il vaut la peine d'approfondir le rôle, car c'est en les comprenant que l'on saisit les leviers d'amélioration d'un système.

Le modèle d'embedding : le traducteur du sens

Le modèle d'embedding est le pivot silencieux du RAG. C'est lui qui décide de ce que « proche de sens » veut dire. Deux systèmes RAG identiques en tout point, mais équipés de modèles d'embedding différents, ne récupéreront pas les mêmes passages face à la même question. Le choix de ce modèle dépend de plusieurs facteurs : la langue (un modèle entraîné surtout sur l'anglais servira mal des documents en français), le domaine (un vocabulaire juridique ou médical très spécialisé peut nécessiter un modèle adapté), et la taille des vecteurs (plus ils sont grands, plus ils sont expressifs, mais plus ils coûtent en stockage et en calcul). Il n'existe pas de « meilleur » modèle d'embedding dans l'absolu ; il existe le modèle le mieux adapté à votre corpus et à vos requêtes.

La base vectorielle : plus qu'un simple entrepôt

On réduit parfois la base vectorielle à un lieu de stockage. C'est oublier qu'elle porte aussi la logique de recherche, le filtrage par métadonnées et, souvent, les mécanismes de mise à jour. Une bonne base permet, par exemple, de restreindre la recherche à un sous-ensemble de documents — ne consulter que les contrats signés après une certaine date, ou que les pages d'une langue donnée — grâce à des métadonnées attachées à chaque chunk. Cette capacité de filtrage est fréquemment sous-estimée alors qu'elle change radicalement la pertinence des résultats. Chercher dans le bon rayon de la bibliothèque vaut mieux que fouiller toute la bibliothèque.

Le générateur : un lecteur, pas un oracle

Le modèle de langage qui rédige la réponse finale doit être vu comme un lecteur diligent plutôt que comme un oracle. Sa mission n'est pas de « connaître » la réponse, mais de synthétiser fidèlement les extraits qu'on lui fournit. Cette nuance a des conséquences pratiques : un modèle plus petit, moins « savant » mais bon en synthèse, peut suffire dans un système RAG bien conçu, parce que la connaissance vient de la base et non du modèle. On économise ainsi sur le générateur ce que l'on a investi dans la qualité de la récupération. C'est une redistribution des rôles qui a du sens, tant sur le plan de la performance que sur celui du coût.

Les pièges courants qui font échouer un RAG

Passons maintenant à la partie la plus utile, celle que les présentations enthousiastes escamotent trop souvent. Monter un RAG de démonstration est facile ; monter un RAG fiable en production est un métier. Voici les écueils qui reviennent le plus fréquemment, et les façons de les contourner.

Le mauvais découpage, ce tueur silencieux

La qualité de la recherche vectorielle est extrêmement sensible à la manière dont on découpe les documents avant de les vectoriser, et c'est fréquemment là qu'un pipeline échoue « en silence » — sans erreur apparente, mais avec des réponses médiocres. Un découpage à taille fixe qui tranche au milieu d'une idée produit des embeddings confus : le vecteur d'un demi-paragraphe ne représente bien ni la première ni la seconde moitié. La parade consiste à adopter un découpage respectueux du sens (sémantique ou hiérarchique) et à tester plusieurs tailles de morceaux sur des questions réelles. Il n'y a pas de valeur universelle : la bonne taille dépend de la nature des documents et des questions.

La récupération qui rate sa cible

L'échec de récupération est le mode d'erreur dominant des systèmes RAG. Selon les études et les configurations, il représente une part très substantielle des questions mal traitées. Autrement dit, dans une grande proportion des cas où un RAG donne une mauvaise réponse, la cause n'est pas le modèle générateur mais le fait que les bons extraits n'ont jamais été récupérés. On ne peut pas synthétiser correctement à partir de documents que l'on n'a pas ramenés. Ce constat est capital, car il déplace l'attention : pour améliorer un RAG, il faut d'abord regarder la récupération, pas la génération.

Recherche sémantique contre recherche par mots-clés

La recherche vectorielle est puissante pour le sens, mais son rappel n'est pas garanti : elle peut passer à côté d'une correspondance exacte. Prenons un code produit, une référence réglementaire précise, un nom propre rare — autant de cas où la vieille recherche par mots-clés, incarnée par l'algorithme BM25, se révèle imbattable. Un pipeline qui ne repose que sur la recherche vectorielle a donc des angles morts systématiques sur les requêtes techniques et les termes exacts.

La solution reconnue est la recherche hybride : combiner la recherche dense (vectorielle, pour le sens) et la recherche creuse (par mots-clés, pour l'exactitude), puis fusionner les résultats. Chaque méthode rattrape les faiblesses de l'autre. La recherche sémantique retrouve les reformulations ; la recherche par mots-clés garantit les correspondances exactes. Ensemble, elles couvrent un éventail de requêtes bien plus large que l'une ou l'autre isolément.

Le reclassement, pour affiner le tri

Une fois une première liste de candidats récupérée, on peut appliquer une seconde passe de tri, appelée reclassement (reranking). Un modèle spécialisé compare alors chaque chunk candidat directement à la question et lui attribue un score de pertinence plus fin que la simple distance vectorielle. Les études montrent qu'une architecture en deux étapes — récupération hybride puis reclassement neuronal — surpasse nettement les méthodes à une seule étape, réduisant les échecs de récupération de façon marquée. Le principe est intuitif : on rate large pour ne rien manquer, puis on affine pour ne garder que le meilleur.

Les citations hallucinées

Un piège plus subtil concerne la fidélité des citations. Un système peut produire une réponse qui semble citer les extraits récupérés, mais qui en réalité s'en écarte ou invente des références. Lorsque le prompt ne précise pas clairement comment combiner les sources, le modèle a tendance à mélanger les fragments en une réponse fluide dont la traçabilité est faible. La bonne pratique consiste à mesurer explicitement la fidélité des citations — la réponse cite-t-elle réellement les chunks fournis ? — et à pénaliser toute référence hallucinée. Un RAG qui cite est rassurant ; un RAG dont on a vérifié que les citations sont exactes est fiable. La nuance mérite qu'on s'y attarde.

Évaluer un système RAG sans se raconter d'histoires

Comment sait-on qu'un RAG fonctionne bien ? La question paraît triviale ; elle ne l'est pas. Juger « à l'œil » quelques réponses donne une fausse assurance. La communauté a donc développé des cadres d'évaluation systématiques, dont le plus connu décompose la performance en quatre métriques complémentaires. Deux d'entre elles jugent la récupération, deux jugent la génération.

• La précision du contexte mesure la proportion des extraits récupérés qui sont réellement pertinents. Une valeur élevée signifie que l'on ramène peu de bruit.
• Le rappel du contexte mesure si l'on a bien récupéré toute l'information nécessaire pour répondre. On peut être précis mais incomplet, ou complet mais bruité : les deux métriques se complètent.
• La fidélité vérifie que la réponse générée s'appuie effectivement sur le contexte fourni, sans y ajouter d'affirmations non étayées. On la calcule comme la part des affirmations de la réponse qui sont soutenues par les extraits.
• La pertinence de la réponse évalue si la réponse traite bien la question posée, sans digression ni hors-sujet.

Décomposer ainsi la performance a une vertu diagnostique majeure : quand un système déçoit, ces métriques indiquent où se situe le problème. Un mauvais rappel du contexte pointe vers la récupération ou le découpage ; une mauvaise fidélité pointe vers le prompt ou le générateur. Sans cette décomposition, on tâtonne à l'aveugle, modifiant un paramètre au hasard en espérant une amélioration. Avec elle, on cible l'effort là où il compte. C'est la différence entre bricoler et travailler.

RAG ou fenêtre de contexte longue : quand choisir quoi

Une question revient sans cesse : puisque les modèles récents acceptent des fenêtres de contexte de plus en plus vastes, pourquoi ne pas simplement leur donner tous les documents d'un coup, au lieu de bâtir un système de récupération ? La réponse mérite d'être nuancée, car les deux approches ont chacune leur domaine de pertinence.

Charger l'intégralité des documents dans une fenêtre de contexte longue présente un attrait réel : le modèle voit tout, il peut raisonner sur l'ensemble, croiser des passages éloignés. Cette voie est préférable lorsque l'on raisonne sur un ou quelques documents entiers — un livre, un long rapport — et que l'information pertinente est répartie de façon diffuse. Mais elle a un coût, et pas seulement au sens figuré : le mécanisme d'attention des modèles croît de façon quadratique avec la longueur du contexte, si bien que traiter des centaines de milliers de tokens à chaque requête devient rapidement onéreux et lent.

Le RAG, à l'inverse, resserre agressivement le contexte sur les seuls passages les plus pertinents. Il traite bien moins de tokens, pour un coût et une latence moindres, tout en atteignant souvent une qualité de réponse comparable. Il brille lorsque la base est vaste — bien trop grande pour tenir dans une fenêtre de contexte — lorsqu'elle change fréquemment, ou lorsque l'information à jour et privée est déterminante. Il évite en outre l'écueil de la date de coupure, puisque la base peut être actualisée à tout moment sans réentraînement.

Voici un repère synthétique pour orienter le choix.

Critère	Plutôt RAG	Plutôt contexte long
Taille de la base	Vaste, croissante	Un ou quelques documents
Fraîcheur de l'information	Change souvent	Stable
Répartition de la preuve	Éparse, localisée	Diffuse sur tout le texte
Coût par requête	Maîtrisé	Élevé sur longs contextes
Confidentialité	Documents hors du modèle	Tout dans le prompt

La vérité pragmatique est que ces deux voies ne s'excluent pas. De nombreux systèmes matures combinent une récupération précise, pour cibler les bons documents, et une capacité de raisonnement sur des contextes assez longs, pour croiser plusieurs sources. La question « RAG ou contexte long ? » gagne souvent à être reformulée en « quelle part de récupération et quelle part de contexte pour mon usage ? ». C'est une affaire de dosage, pas de camp.

Mettre en place un RAG : la démarche saine

Supposons que vous soyez convaincu de la pertinence d'un RAG pour votre besoin. Comment s'y prendre sans reproduire les erreurs classiques ? Quelques principes de bon sens balisent le chemin.

D'abord, soigner l'ingestion avant tout le reste. Un corpus propre, bien extrait, dépourvu de scories, vaut mieux que le plus sophistiqué des modèles d'embedding appliqué à un texte de mauvaise qualité. Investir du temps sur la préparation des documents est le placement le plus rentable d'un projet RAG.

Ensuite, traiter le découpage comme un paramètre à régler, pas comme une constante. Testez plusieurs tailles et stratégies de chunks sur un jeu de questions représentatives, et mesurez. On est souvent surpris de constater qu'une taille de morceau différente change tout, à modèle constant.

Puis, ne pas se contenter de la recherche vectorielle. Ajoutez une composante par mots-clés pour couvrir les termes exacts, et envisagez une passe de reclassement si la précision compte. Ces deux ajouts, éprouvés, réduisent nettement les échecs de récupération.

Enfin, mesurer, toujours. Constituez un jeu d'évaluation avec des questions et leurs réponses attendues, et suivez les métriques de précision, de rappel, de fidélité et de pertinence. Sans mesure, chaque modification devient un pari. Avec elle, l'amélioration devient un processus rationnel. C'est cette discipline, plus que le choix de tel ou tel composant à la mode, qui distingue un système fiable d'un prototype flatteur.

La question utile n'est pas « ai-je le meilleur modèle ? » mais « mon système récupère-t-il vraiment les bons passages, et mon générateur y reste-t-il fidèle ? » — tout le reste en découle.

Ce que le RAG ne fait pas

Par honnêteté, terminons sur les limites, car les comprendre évite bien des désillusions. Le RAG n'apprend rien de nouveau au modèle : il ne modifie pas son style, sa façon de raisonner ni ses compétences de fond. Pour cela, d'autres techniques d'adaptation existent, et le RAG n'entre pas en concurrence directe avec elles — il répond à un besoin différent, celui de l'accès à la connaissance factuelle et actuelle.

Le RAG ne compense pas non plus une base documentaire lacunaire. Si la réponse n'est nulle part dans vos documents, aucune récupération, si fine soit-elle, ne la fera apparaître. Le système est aussi bon que sa bibliothèque. De même, un RAG ne dispense pas d'un travail sur les prompts et sur la façon de présenter les sources : le générateur a besoin de consignes claires pour rester fidèle et signaler les cas où l'information manque.

Enfin, le RAG ajoute de la complexité opérationnelle. Il faut maintenir une base à jour, surveiller la qualité de la récupération, gérer les métadonnées, réévaluer périodiquement. Ce n'est pas un obstacle rédhibitoire — c'est le prix d'un système qui reste ancré dans les faits et actualisable. Mais il vaut mieux le savoir d'emblée que de le découvrir en production.

Donner une mémoire à l'IA, avec méthode

Récapitulons l'essentiel. Le RAG répond à une limite structurelle des modèles de langage : leur connaissance est figée, généraliste et parfois faillible. En couplant une mémoire paramétrique apprise à une mémoire non paramétrique externe, il permet à un modèle de s'appuyer sur des documents réels, à jour et privés, réduisant nettement les hallucinations et supprimant la contrainte de la date de coupure. Le principe, formalisé dès 2020, est resté d'une remarquable stabilité, précisément parce qu'il répond à un besoin fondamental.

Le pipeline — ingestion, découpage, embeddings, base vectorielle, récupération, augmentation, génération — est conceptuellement simple, mais sa mise en œuvre fiable exige de la rigueur. Les vrais gains ne viennent pas du choix d'un composant miracle, mais du soin apporté à chaque maillon : un découpage respectueux du sens, une récupération hybride qui marie sens et exactitude, un reclassement pour affiner, des prompts qui exigent la fidélité, et surtout une évaluation systématique qui transforme le tâtonnement en démarche maîtrisée.

Pour qui aborde le sujet, la bonne posture n'est donc ni l'émerveillement — « le RAG résout tout » — ni le scepticisme — « ce n'est qu'un moteur de recherche déguisé ». C'est la compréhension des mécanismes, qui seule permet de juger si le RAG est le bon outil pour un besoin donné, de le construire correctement et de l'améliorer méthodiquement. Donner une mémoire à une intelligence artificielle n'a rien de magique : c'est une affaire d'ingénierie soignée, où chaque décision se mesure et se justifie. Et c'est bien là toute la beauté de la chose.

Sources

Cet article s'appuie sur des sources publiques et vérifiables :

• Patrick Lewis et al., « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks » (NeurIPS 2020) — arXiv 2005.11401 (article fondateur, mémoire paramétrique et non paramétrique).
• Wikipedia, « Retrieval-augmented generation » — en.wikipedia.org (origine du terme, vue d'ensemble).
• Databricks, « End-to-End RAG Workflow: How Retrieval Augmented Generation Works » — databricks.com (pipeline ingestion, embedding, récupération, génération).
• Unstructured, « Common Challenges in RAG and How to Solve Them in Production » — unstructured.io (pièges du découpage et de la récupération).
• StackAI, « RAG Best Practices: Chunking, Embeddings, Reranking, and Hybrid Search » — stackai.com (recherche hybride BM25, reclassement).
• Ragas, « List of available metrics » — docs.ragas.io (fidélité, pertinence, précision et rappel du contexte).
• Meilisearch, « RAG vs. long-context LLMs: A side-by-side comparison » — meilisearch.com (choix entre RAG et contexte long, coûts).