RAG expliqué simplement : comment rendre votre IA plus fiable et mieux informée.

Apprenez le RAG pas à pas : une méthode claire pour rendre votre IA plus fiable

Introduction et objectifs du cours

Le RAG, pour Retrieval-Augmented Generation, est une façon de transformer une IA aux connaissances limitées par son entrainement en un assistant savant et fiable qui s’appuie sur les bonnes informations. A la manière d'un documentaliste qui va rechercher et consulter tous les documents disponibles en relation avec le sujet à traiter, l'IA va faire une recherche dans les sources pertinentes, repérer et collecter les passages vraiment utiles, puis s’appuiera sur ces éléments pour formuler une réponse claire, fiable et vérifiable. En clair, le RAG combine la recherche d’informations avec la génération de texte afin de produire des réponses appuyées sur des connaissances externes.

Promesse du cours

À la fin de ce cours, vous devrez pouvoir expliquer simplement ce qu’est un RAG, évaluer quand cette approche est utile, et imaginer un premier prototype. Nous n'allons pas décrire dans le détail toute l'architecture d'un système RAG, mais allons parcourir tous les concepts importants pour bien le comprendre et être en mesure de mettre en oeuvre un tel système.

L’analogie du documentaliste

Reprenons le parallèle avec le documentaliste à qui l’on pose une question sur une règlementation technique. S’il répond uniquement de mémoire, il risque d’oublier des détails ou d’utiliser des informations obsolètes. S’il consulte d’abord les notes internes, les dernières publications réglementaires, les notices techniques mises à jour ainsi que les procédures récentes, sa réponse devient plus précise et actualisée. Un système RAG suit cette logique : chercher, sélectionner, puis répondre.

Les limites des LLM seuls

Un modèle de langage traditionnel est très performant pour rédiger des textes en apportant une couche de réflexion, mais il ne connaît pas automatiquement les documents spécifiques à votre entreprise, vos projets, vos règles internes, ni les informations publiées après son entraînement. En pratique, un LLM traditionnel génère ses réponses à partir des informations apprises pendant son entraînement, mais il n'a pas connaissance des données récentes, provées ou internes à votre organisation, ni aux informations très spécialisées.

Définition initiale du RAG

Le RAG a justement été conçu pour répondre à ce problème : pallier la limite des LLM traditionnels lorsque leurs connaissances sont incomplètes ou obsolètes. Au lieu de réentraîner le modèle, on lui ajoute une étape de recherche dans des documents pertinents.

Cette étape s'appelle le Retrieval (Récupération en anglais), et le terme Retrieval Augmented Content (RAG) veut littéralement dire : Génération Augmentée par la Récupération. Comme un schéma est plus parlant que 1000 mots, l'infographie ci dessous illustre le principe du RAG

Bénéfices attendus

Cette approche permet d’obtenir des réponses plus ancrées dans des sources, plus faciles à actualiser et mieux adaptées à un contexte métier. Elle peut aussi améliorer la fiabilité des réponses et réduire certaines hallucinations, même si la qualité dépendra toujours des documents retrouvés et de la manière dont ils sont fournis au modèle.

Prérequis : le vocabulaire minimum

LLM et modèle de langage

Un LLM, pour Large Language Model, est un grand modèle de langage : une IA entraînée à prédire et produire du texte. Il sait reformuler, résumer, comparer ou rédiger, et de par son entraînement sur un corpus de très nombreux documents, sa mémoire renferme énormément de connaissances. Cependant, ce savoir reste limité aux documents qu'il a vus pendant son entraînement, et comme nous l'avons vu plus haut, il ne connait pas les informations spécifiques à votre entreprise, vos projets, vos données personnelles, et ne peut donc s'en servir pour enrichir ses réponses.

Prompt et contexte

Un prompt est l’instruction envoyée au modèle : votre question, vos consignes, le format attendu. Le contexte désigne les informations ajoutées au prompt pour guider la réponse : extrait de document, profil utilisateur, contrainte métier, exemple de réponse.

Hallucination

Une hallucination est une réponse qui semble plausible, bien formulée, mais qui est fausse ou non vérifiée. C’est un risque connu : en raison de leur mode de fonctionnement, les LLM peuvent produire des réponses qui paraissent crédibles tout en étant fausses. En effet, le mécanisme de génération est de prédire à chaque instant le prochain mot (ou plus précisément le prochain token), parmi les plus probables. Et parfois la probabilité ne rencontre pas la réalité factuelle. Une fois lancé sur une fausse piste le modèle peut donc affirmer des faits totalement inventés ou travestir la réalité. D'où l'importance du contexte, qui lui permet de rester sur les rails.

Source documentaire

Une source documentaire est un document identifiable utilisé pour justifier une réponse : page d’aide, contrat, guide produit, article, ticket support, etc. Sans mécanisme dédié, les LLM classiques ne citent pas leurs sources, ce qui complique la vérification des propos qu'ils génèrent.

Donnée interne

Une donnée interne est une information propre à votre organisation : procédures RH, documentation technique, grilles tarifaires, comptes rendus, FAQ privée. Elle est souvent précieuse, évolutive, et puisque c'est une information privée, elle n'a pas été intégrée dans le corpus d'entrainement du modèle d'intelligence artificielle que vous utilisez, et ces informations ne figurent donc pas dans sa mémoire interne.

Leçon 1 — Les fondamentaux du RAG

Objectif : comprendre le RAG comme un réflexe simple : avant de demander au modèle de répondre, on lui fait chercher les bons documents, puis on lui donne ces documents comme contexte.

Pourquoi le RAG change tout pour fiabiliser l’IA

Un modèle de langage peut être très performant, mais il répond d’abord avec sa mémoire interne : ce qu’il a appris pendant son entraînement. Cette mémoire ne contient pas forcément vos procédures internes, vos contrats, votre dernière grille tarifaire, ni les documents publiés hier. Sans aide, le modèle peut donc produire une réponse plausible, mais incomplète, dépassée ou difficile à vérifier.

Le RAG, pour Retrieval-Augmented Generation, ajoute une étape essentielle : la recherche avant la réponse. Il combine recherche d’informations et génération de contenu : le système récupère des informations pertinentes dans une base documentaire ou un corpus externe, puis les utilise pour générer la réponse. Ce corpus peut être une FAQ, un wiki d’entreprise, des PDF, une base support ou tout autre contenu contrôlé.

C’est particulièrement utile quand la question dépend de données actualisées, spécifiques à un domaine ou propres à une organisation. Par exemple : "Quelle est notre politique de remboursement actuelle ?" ou "Que dit le guide produit sur cette fonctionnalité ?". Le modèle n’a pas besoin d’avoir appris ces documents à l’avance : on les lui apporte au moment utile.

Le second intérêt est la vérifiabilité. Le RAG aide le modèle à synthétiser une réponse à partir de faits fournis, plutôt qu’à répondre uniquement depuis sa connaissance générale. Cela ne supprime pas tous les risques, mais cela rend la réponse plus ancrée dans des sources identifiables, et plus facile à contrôler.

De la question à la réponse fiable : le parcours du RAG

Le trajet d’un RAG de base tient en quatre moments simples : une question arrive, le système cherche les passages utiles dans une base documentaire externe, ces passages sont ajoutés au prompt, puis le modèle rédige une réponse à partir de ce contexte.

1. Question utilisateur : l’utilisateur pose une demande en langage naturel.
2. Documents pertinents : le système interroge une base, un moteur de recherche ou un corpus externe pour trouver les passages utiles.
3. Contexte ajouté : les passages sélectionnés sont injectés dans le prompt avec la question.
4. Réponse finale : le modèle formule une réponse claire, appuyée sur le contexte fourni.

En résumé :

• le RAG ne remplace pas le modèle, il l'enrichit avec de bons documents
• la réponse vient après la recherche, pas avant
• la base documentaire reste externe au modèle et peut évoluer
• le modèle répond à partir du contexte transmis
• on peut obtenir des réponses plus fraîches grâce à des données mises à jour sans réentraîner le modèle.

Leçon 2 — Ce qui se passe sous le capot

Objectif : comprendre comment un RAG transforme des documents ordinaires en éléments recherchables par le sens, puis comment il retrouve les passages les plus utiles pour répondre à une question.

La préparation des documents

Avant qu’un RAG puisse répondre, il prépare sa matière première : vos documents. Cette étape doit se faire avant de pouvoir utiliser le RAG et répondre aux questions utilisateurs. On parle d'ingestion et d’indexation : le système rassemble les contenus disponibles, les rend exploitables, puis les range dans un format adapté à la recherche.

La première opération est la collecte documentaire. Il peut s’agir de pages d’aide, de PDF, de fiches produit, de tickets support, de comptes rendus ou d’une FAQ interne. Ensuite vient le nettoyage du corpus : enlever les doublons, les menus inutiles, les en-têtes répétitifs, les caractères parasites ou les passages sans valeur. L’objectif est simple : éviter que le système récupère du bruit au lieu d’informations fiables.

Le système découpe ensuite les documents en chunks, c’est-à-dire en morceaux plus petits (extraits), traitant idéalement d'un sujet ou d'une idée identifiable. Un chunk peut être une phrase, un paragraphe, une ligne de données ou même un tour de conversation, leur taille dépend du jeu de données et du cas d’usage. Ce découpage est important : un document complet est souvent trop long ou trop vague, tandis qu’un bon morceau contient juste assez de contexte pour être utile.

Chaque chunk est ensuite converti en embedding. Un embedding est une représentation numérique du sens : au lieu de garder seulement des mots, le système produit une liste de nombres (en réalité, des vecteurs au sens mathématique du terme) qui résume l’idée portée par le texte.

Si l'on utilisait des vecteurs à 2 dimensions, on pourrait imaginer cela comme une carte où les idées proches sont rangées à proximité les unes des autres : "résilier un abonnement" sera plus proche de "annuler mon contrat" que de "changer mon mot de passe".

En réalité, pour tenir compte de la complexité et des nuances du sens porté par toutes les idées présentes dans vos sources, le système d'embedding va utiliser des vecteurs avec un très grand nombre de dimensions (plusieurs centaines). Ainsi, deux idées peuvent être proches sur certaines dimensions, et plus éloignées sur d'autres : "annuler mon abonnement internet" et "résilier mon contrat de travail" se rapprochent sur un certain angle (mettre fin à un contrat), mais sont très éloignées quant au domaine concerné (télécommunications / travail). Certaines dimensions des embeddings de ces idées seront donc potentiellement assez proches, mais d'autres plus distantes pour qu'elles ressortent de manière pertinente en fonction du domaine concerné. Par exemple, "Résilier Free" fera ressortir "annuler mon abonnement internet", démissionner aura un embedding plus proche de "résilier mon contrat de travail" : le terme exact dans le texte importe moins que l'idée qu'il porte.

Enfin, ces chunks et leurs vecteurs sont stockés dans une base vectorielle. C'est une base de données spécifique dédiée au stockage de contenus associés à des vecteurs multi dimensionnels. Ce type de base de données permet la récupération de tous les contenus dont l'embedding (vecteur) est proche de celui d'une requête donnée.

Il existe de nombreuses bases de données vectorielles : Qdrant, Redis, PGVector, Milvus, Pinecone... Toutes sont optimisées pour une récupération très rapide des documents dans le cadre d'un RAG, et chacune s'adapte plus ou moins à certains cas d'usages. Cependant si vous souhaitez expérimenter votre premier projet RAG, nous vous conseillons QDrant, qui est une base de travail très performante et polyvalente, et très facile à mettre en oeuvre via Docker.

À ce stade, une architecture RAG simple réunit déjà ses briques principales : un modèle d’embedding, une base vectorielle et un modèle de génération ou chatbot.

En pratique, la phase d’indexation consiste à découper les documents en chunks, calculer des embeddings, puis stocker ces représentations dans une base vectorielle.

La recherche par sens

Lorsqu’un utilisateur pose une question, le RAG ne cherche pas seulement les mêmes mots. Il cherche les passages qui ont le sens le plus proche. Pour cela, la requête utilisateur est transformée elle aussi en vecteur numérique afin d’être comparée aux vecteurs des documents ou chunks stockés dans la base vectorielle.

Le système compare alors ce vecteur avec les vecteurs déjà présents dans la base. Cette comparaison mesure une proximité sémantique : deux textes peuvent être proches même s’ils n’utilisent pas exactement les mêmes mots. C’est ce qui rend le RAG plus souple qu’une simple recherche par mots-clés.

Une méthode courante pour mesurer cette proximité est la similarité cosinus. Sans entrer dans les mathématiques, elle évalue si deux vecteurs "pointent" dans une direction similaire sur la carte des idées. Plus ils vont dans la même direction, plus les textes sont considérés comme proches. Ainsi, la similarité cosinus peut servir à comparer l’embedding d’une requête aux vecteurs stockés afin de retrouver les chunks les plus pertinents.

Le Retrieval sélectionne alors les chunks les plus proches : ce sont les passages qui semblent contenir la meilleure information pour répondre. Ces morceaux seront ensuite transmis au modèle de langage : dans un RAG, les documents ou chunks récupérés sont injectés dans le prompt fourni au modèle. La qualité de la réponse dépend donc fortement de cette récupération : si les bons chunks remontent, le modèle a de bonnes chances de répondre correctement ; sinon, il risque de répondre à côté ou de manière incomplète.

À retenir :

• Les documents sont collectés, nettoyés et découpés en chunks.
• Chaque chunk devient un embedding, une représentation numérique du sens.
• Les embeddings sont stockés dans une base vectorielle.
• La question de l’utilisateur est transformée en vecteur à son tour.
• Le RAG compare les vecteurs pour retrouver les chunks les plus proches sémantiquement.

Leçon 3 — Construire un mini-RAG avec un cas concret

Le cas fil rouge

Objectif : construire mentalement un mini-RAG capable de répondre comme un chatbot de support client, non pas avec une mémoire générale, mais à partir de documents d’entreprise précis et récents.

Imaginons une entreprise qui vend un logiciel SaaS. Son équipe support reçoit souvent les mêmes questions : " Comment réinitialiser mon mot de passe ? ", " Puis-je être remboursé ? ", " Où trouver la nouvelle option d’export ? ". Un chatbot classique pourrait répondre de façon fluide, mais il risquerait d’inventer si les règles internes ou les nouveautés produit ne sont pas dans sa mémoire.

Le mini-RAG joue donc le rôle d’un assistant qui consulte les bons documents avant de répondre. C’est un cas typique : pour des données internes d’entreprise, le RAG permet de créer des chatbots, assistants ou outils de recherche qui répondent à partir de FAQ, guides produits, wikis, runbooks ou documents internes. Plus précisément, on peut l’utiliser pour un chatbot de service client capable de répondre à partir des bases documentaires de l’entreprise, comme les FAQ, conditions générales et guides produits.

Pour notre prototype, on part avec trois familles de documents :

• FAQ produit : questions fréquentes, procédures simples, erreurs connues.
• Conditions de remboursement : délais, exceptions, cas particuliers, preuves demandées.
• Documentation récente : guides produits mis à jour, notes de version, tutoriels internes.

Ce dernier point est essentiel : le support client a souvent besoin de réponses basées sur la documentation produit la plus récente afin de fournir des réponses précises. Si la politique de remboursement change en 2025, par exemple, on ne veut pas que le chatbot applique une ancienne règle. Comme dans l’exemple d’une politique de remboursement mise à jour, le RAG permet au modèle de consulter des documents d’entreprise récents pour produire une réponse plus précise et vérifiable qu’un LLM classique.

La promesse est donc simple : garder le modèle tel quel, mais lui donner les extraits utiles au moment de la question, sans réentraîner le modèle.

Le pseudo-code du pipeline

Un pipeline minimal tient en quatre mouvements : indexer les documents, rechercher les meilleurs passages, construire un prompt enrichi, puis générer la réponse. Le principe consiste à récupérer des informations dans une base de connaissances externe, puis à injecter les documents ou informations récupérés dans le prompt.

// 1. Indexation des documents
documents = charger(["faq_produit.pdf", "remboursement.md", "guide_v2.html"])
morceaux = decouper_en_passages(documents)
vecteurs = creer_embeddings(morceaux)
base_vectorielle.ajouter(vecteurs, morceaux)

// 2. Recherche des meilleurs résultats
question = "Puis-je être remboursé après 20 jours ?"
vecteur_question = creer_embedding(question)
passages = base_vectorielle.rechercher(vecteur_question, top_k=3)

// 3. Construction du prompt enrichi
prompt = "Tu es un assistant support. Réponds uniquement avec le contexte fourni.\n"
prompt += "Contexte :" + passages
prompt += "Question client :" + question
prompt += "Si l'information manque, dis-le clairement."

// 4. Génération de la réponse
reponse = modele.generer(prompt)
afficher(reponse)

Le prompt enrichi est la partie visible du RAG côté modèle. Au lieu de poser seulement la question, on ajoute les passages retrouvés : un extrait de FAQ, un paragraphe des conditions de remboursement ou une note de documentation récente. Le modèle ne devine plus dans le vide ; il formule une réponse à partir du contexte fourni.

Exemple de réponse attendue : "D’après les conditions de remboursement, un remboursement est possible jusqu’à 30 jours après l’achat, sauf pour les offres promotionnelles non remboursables. Si votre achat date de 20 jours, vous pouvez donc faire une demande avec votre numéro de commande."

En pratique, la qualité finale dépend surtout des documents et de la recherche : la fiabilité d’un assistant RAG dépend fortement de la qualité de sa base documentaire.

• Indexer : préparer FAQ, conditions et guides en petits passages recherchables.
• Retrouver : sélectionner les extraits les plus proches de la question.
• Enrichir le prompt : donner ces extraits au modèle avec une consigne claire.
• Répondre : produire une réponse utile, idéalement sourcée et limitée au contexte.

Leçon 4 — Cas avancés, réglages et limites

Les réglages qui changent tout

Objectif : comprendre que la qualité d’un RAG ne dépend pas seulement du modèle génératif, mais surtout des choix faits avant la réponse : découpage, recherche, sélection et contrôle des documents fournis.

Premier réglage : la taille des chunks. Un chunk trop court peut perdre le contexte ; un chunk trop long peut mélanger plusieurs idées et rendre la recherche moins précise. Il faut donc tester selon vos documents : FAQ, procédures, contrats, tickets support ou documentation technique.

Deuxième réglage : le nombre de chunks transmis au modèle, souvent appelé top-K. À chaque question, le système peut retourner les N ou top-K chunks les plus pertinents : trop peu, l’information utile peut manquer ; trop, le modèle reçoit du bruit documentaire.

Troisième réglage : le modèle d’embedding. C’est lui qui transforme le sens des textes en nombres comparables. S’il comprend mal la langue ou le domaine, la recherche échoue même avec un bon corpus. Pour un RAG en français, mieux vaut choisir un modèle d’embedding multilingue ou adapté à votre secteur.

Enfin, on peut ajouter du reranking. L’idée est simple : après une première recherche, un second modèle relit les passages trouvés et les remet dans un meilleur ordre. Cette étape peut améliorer la pertinence des chunks récupérés, surtout quand plusieurs extraits semblent proches.

Les limites à anticiper

Un RAG ajoute une étape de recherche avant la génération. Cela crée une latence liée à la recherche d’information : acceptable pour un assistant interne, parfois gênante pour une interface très rapide.

Il ajoute aussi de la complexité technique : ingestion des documents, découpage, embeddings, base vectorielle, droits d’accès, évaluation des réponses. Le RAG reste simple à comprendre, mais moins simple à maintenir en production.

La qualité du corpus est déterminante : la qualité des réponses d’un système RAG dépend fortement de la qualité et de la pertinence du corpus. Des fichiers obsolètes, contradictoires ou mal structurés produiront des réponses incertaines. Le RAG n’est pas une machine à vérité : il amplifie souvent la qualité, ou les défauts, de votre base documentaire.

Il faut aussi gérer les données sensibles. Un RAG peut récupérer des informations confidentielles et les exposer si les permissions sont mal conçues. Le recours au RAG soulève donc des enjeux éthiques et de confidentialité, en particulier pour les données RH, juridiques, médicales ou clients.

Les variantes avancées

La recherche hybride combine recherche sémantique et recherche par mots-clés. C’est utile en documentation technique : la recherche vectorielle seule peut rater des codes d’erreur, identifiants ou noms de fonctions, tandis que la recherche hybride améliore nettement les résultats.

Les options les plus avancées à ce jour sont le Graph RAG, qui organise la connaissance en nœuds et relations, et le Modular RAG, qui découpe le système en composants spécialisés. Elles peuvent donner des résultats plus performants selon les cas d'usage, mais sont plus complexes à mettre en oeuvre.

Graph RAG

Graph RAG enrichit le RAG avec un graphe de connaissances : les informations sont reliées sous forme de nœuds et de relations. Il aide l’IA à comprendre les liens entre personnes, produits, procédures ou événements, au lieu de récupérer seulement des passages isolés. C’est utile pour des questions complexes : dépendances, causes, impacts, historique client. Il demande plus de préparation qu’un RAG simple, mais offre des réponses plus structurées, traçables et cohérentes.

Modular RAG

Modular RAG découpe le système RAG en modules spécialisés : recherche, filtrage, reranking, génération, vérification, citation des sources. Chaque brique peut être améliorée, remplacée ou testée séparément. Cette approche convient aux projets plus sérieux, où l’on veut contrôler la qualité, la sécurité et les performances. Elle rend le système plus flexible qu’un pipeline unique, mais ajoute de la complexité technique. À retenir : plus de contrôle, plus d’adaptabilité, mais une maintenance plus exigeante.

À retenir :

• Le bon nombre de chunks équilibre information utile et bruit.
• Un corpus propre vaut mieux qu’un gros corpus désordonné.
• La recherche hybride aide quand les mots exacts comptent.
• La confidentialité doit être pensée dès le départ.
• Un RAG performant se règle, se teste et se surveille.

Ressources complémentaires

Tutoriels débutants

Commencez par ce tutoriel qui montre plusieurs manières simples de mettre en place un RAG de bout en bout : préparer quelques documents, poser une question, puis vérifier quelles sources ont été utilisées. Cela vous permettra de comprendre et d'expérimenter le mode de fonctionnement d'un système de Retreival Augmented Generation.

Bases vectorielles

Pour bien comprendre le mode de fonctionnement des bases de données vectorielle, et explorer les différentes options pour mettre en oeuvre ce qui constitue le coeur du RAG, vous pouvez débuter par ce cours très complet sur les BDD vectorielles par IBM. Vous pourrez ensuite découvrir les types de bases de données utilisables pour le RAG, notamment FAISS, Weaviate, Pinecone, Milvus, Qdrant et pgvector.

Cours Hugging Face

Ce cours Hugging Face sur l'agentique, contenant une section spécifique pour le RAG, est utile pour relier théorie et pratique : modèles d’embedding, modèles de langage, formats de modèles et exemples reproductibles. Un exemple de RAG y utilise un modèle d’embedding bge-base et un Llama 3.2 1B Instruct, ce qui donne un bon point de départ expérimental.

Implémentations Python

Si vous codez déjà un peu, vous pouvez expérimenter cette implémentation Python minimale : chargement de fichiers, découpage, embeddings, stockage vectoriel, recherche, puis appel au modèle.

Outils open source

Privilégiez les outils open source pour apprendre : ils rendent visibles les choix techniques et facilitent les tests locaux. Vous pourrez ensuite passer à des services managés si le prototype doit devenir un produit.
Il en existe des dizaines, mais certains sortent du lot par leur maturité, leur popularité ou l'activité de leur communauté. Parmi ceux-ci : Langchain, RagFlow ou llamaIndex

Conclusion et prochaines étapes

Le RAG tient en une idée simple : ne pas demander au modèle de tout savoir, mais lui apporter les bons extraits au moment de répondre. On indexe d’abord les documents, on récupère ensuite les passages les plus proches de la question, puis le modèle génère une réponse en s’appuyant sur ce contexte.

• Il convient surtout aux besoins qui exigent des données actualisées, spécifiques à un domaine ou propres à une organisation : support client, recherche dans une base interne, assistant documentaire, aide aux équipes métier.
• Un bon RAG doit permettre de vérifier ce qu’il affirme. Certaines implémentations peuvent citer les sources et remonter au document d’origine, ce qui facilite le contrôle et la confiance.
• La limite principale n’est pas magique : si les documents sont incomplets, obsolètes ou mal découpés, la réponse le sera aussi. La qualité du corpus ou de la base documentaire reste déterminante.
• Avant un déploiement sérieux, testez petit : la recherche et l’intégration des informations peuvent ajouter de la complexité et parfois rallonger légèrement le temps de réponse.

Checklist pour lancer un mini-RAG : choisir 5 à 20 documents fiables ; les découper en passages courts ; créer les embeddings et l’index ; poser 10 questions réalistes ; vérifier les réponses et les sources ; améliorer les documents avant d’ajouter de la technique.