C'est quoi un RAG ? De l'indexation de documents à la génération de réponses fiables

Le problème du vase clos : Pourquoi les LLM manquent de contexte

Un LLM est entraîné une fois, sur un snapshot du web et de diverses sources textuelles, arrêté à une date précise. Passé ce point, sa connaissance est figée. Il ne sait pas ce qui s'est passé la semaine dernière, il ne connaît pas la politique tarifaire de votre entreprise, et il n'a jamais lu votre documentation interne.

Quand on lui pose une question sur un sujet qu'il ne connaît pas vraiment, il ne dit pas forcément "je ne sais pas". Il génère une réponse plausible en s'appuyant sur ce qu'il a vu pendant son entraînement. C'est ce qu'on appelle une hallucination : une réponse confident mais fausse ou inventée. Dans un contexte professionnel, droit, médecine, finance, support technique, ce comportement est inacceptable.

Le problème n'est pas que le modèle est stupide. Il est très capable de raisonner, de synthétiser, d'expliquer. Le problème, c'est qu'il manque de contexte pertinent au bon moment. Le RAG est précisément conçu pour combler ce vide : lui apporter, juste avant qu'il réponde, les informations dont il a besoin pour être fiable.

Le principe du RAG : Injecter la bonne information au bon moment

L'idée centrale du RAG tient en une phrase : avant de demander au modèle de générer une réponse, on va d'abord chercher dans une base de documents les passages les plus pertinents par rapport à la question posée, puis on les glisse dans le prompt envoyé au LLM.

Concrètement, le flux ressemble à ceci : un utilisateur pose une question, un moteur de recherche spécialisé extrait les extraits de documents les plus proches sémantiquement, ces extraits sont assemblés dans une instruction envoyée au LLM, qui génère sa réponse en s'appuyant sur ce contexte fourni plutôt que sur ses seuls paramètres internes.

Ce découpage en deux étapes distinctes, récupérer, puis générer, est ce qui rend le RAG à la fois puissant et modulable. On peut changer la base documentaire sans toucher au modèle. On peut améliorer la recherche indépendamment de la génération. Et surtout, on peut tracer l'origine de chaque réponse jusqu'à un document source, ce qui est précieux pour l'audit et la confiance.

Étape 1 : Préparer et ranger les documents

Avant qu'un RAG puisse fonctionner, il faut préparer la base documentaire. Cette phase dite d'indexation est souvent la plus longue et la plus déterminante : une mauvaise indexation donnera de mauvais résultats, quelle que soit la qualité du modèle en aval.

Chunking : Le découpage du texte en morceaux

Un document de cinquante pages ne peut pas être envoyé en bloc au LLM : la fenêtre de contexte des modèles est limitée, et noyer le modèle dans du texte inutile dilue la pertinence. On découpe donc chaque document en morceaux plus petits, appelés chunks, qui seront indexés et récupérés individuellement.

La taille d'un chunk est un paramètre clé. Trop court (quelques phrases), le chunk perd son contexte : un passage isolé peut devenir incompréhensible sans ce qui précède. Trop long (plusieurs pages), il devient difficile à cibler précisément et encombre le contexte du LLM. En pratique, on vise souvent des chunks de 300 à 800 tokens, avec un léger chevauchement entre les morceaux consécutifs pour ne pas couper une idée en deux. Il existe aussi des stratégies plus avancées, comme le découpage par structure sémantique (paragraphe, section) plutôt que par nombre fixe de tokens.

La vectorisation : Traduire le sens sémantique en coordonnées

Une fois les documents découpés, chaque chunk est transformé en vecteur numérique par un modèle d'embedding, un type de réseau de neurones spécialisé dans la représentation sémantique du texte. L'idée est la suivante : deux textes qui parlent de la même chose, même avec des mots différents, se retrouvent proches dans l'espace vectoriel. "Délai de livraison" et "combien de temps pour recevoir ma commande" produiront des vecteurs voisins.

C'est cette propriété qui rend la recherche par vecteur bien supérieure à la recherche par mots-clés classique pour comprendre l'intention d'une question. Le modèle d'embedding est entraîné séparément du LLM et peut être spécialisé pour un domaine particulier (juridique, médical, technique) pour de meilleures performances.

La base vectorielle : Archiver pour la recherche de proximité

Les vecteurs générés sont stockés dans une base vectorielle (ou vector store), un type de base de données optimisé pour une opération spécifique : trouver rapidement les N vecteurs les plus proches d'un vecteur de requête. Des solutions comme Pinecone, Weaviate, Chroma ou pgvector (une extension PostgreSQL) sont couramment utilisées.

À chaque chunk vectorisé est associée une métadonnée : le nom du document source, le numéro de page, la date, la catégorie… Ces informations permettront ensuite de filtrer les résultats (par exemple, "ne chercher que dans les documents de 2024") ou de citer précisément la source dans la réponse finale. La base vectorielle n'est pas statique : on peut y ajouter, modifier ou supprimer des documents au fil du temps, ce qui est l'un des grands avantages du RAG sur le fine-tuning.

Étape 2 : Trouver les bonnes informations

Lorsqu'un utilisateur pose une question, le système doit identifier rapidement quels chunks de la base sont les plus susceptibles de contenir la réponse. Cette étape de récupération est critique : si les mauvais passages sont sélectionnés, le LLM travaillera avec de mauvaises informations.

La recherche par mots-clés et par sens

Il existe deux grandes familles de recherche, souvent combinées. La recherche lexicale (ou full-text search) fonctionne sur la correspondance exacte ou approchée de termes. Elle est rapide, transparente et efficace pour les requêtes techniques avec des termes précis comme un numéro de référence ou un nom propre.

La recherche vectorielle (ou recherche sémantique) transforme la question de l'utilisateur en vecteur via le même modèle d'embedding, puis calcule la proximité de ce vecteur avec tous les chunks stockés. Elle excelle pour les requêtes formulées en langage naturel et les synonymes, mais peut rater des correspondances exactes importantes. La combinaison des deux approches, appelée recherche hybride, est aujourd'hui la pratique recommandée dans la majorité des systèmes RAG en production.

Reranking : Le tri des morceaux les plus pertinents

La recherche initiale retourne généralement une dizaine de chunks candidats. Mais tous ne sont pas également pertinents : certains partagent des mots en commun avec la question sans réellement y répondre. C'est là qu'intervient le reranker, un modèle secondaire dont le seul rôle est d'évaluer la pertinence de chaque chunk par rapport à la requête et d'en trier le résultat.

Le reranker est plus précis que la simple similarité vectorielle parce qu'il analyse la relation entre la question et le chunk ensemble, et non séparément. En contrepartie, il est plus lent et coûteux à faire tourner sur l'intégralité de la base : d'où l'architecture en deux temps, un premier filtre rapide, puis un classement fin sur les meilleurs candidats. On ne garde ensuite que les 3 à 5 chunks les mieux classés pour composer le contexte envoyé au LLM.

Étape 3 : Rédiger la réponse finale

Une fois les bons passages récupérés et classés, ils sont transmis au LLM avec la question de l'utilisateur. C'est la phase de génération, celle que l'utilisateur voit, mais qui repose entièrement sur la qualité de ce qui l'a précédée.

L'ingénierie du prompt : Contextualiser la requête de l'utilisateur

Le prompt envoyé au LLM ne contient pas seulement la question. Il est structuré pour guider précisément le modèle : on lui fournit les chunks récupérés, on lui indique qu'il doit s'appuyer sur ces extraits pour répondre, et on définit le format attendu (réponse courte, liste, explication détaillée...). C'est ce qu'on appelle l'ingénierie du prompt, ou prompt engineering.

Un bon prompt de RAG explicite clairement la règle du jeu : "Réponds uniquement à partir des passages fournis ci-dessous. Si la réponse ne s'y trouve pas, dis-le." Il peut aussi indiquer au modèle de citer ses sources, de structurer sa réponse en étapes, ou d'adapter son niveau de langage à l'audience. Plus la consigne est précise, plus le comportement du modèle est prévisible et contrôlable.

La consigne anti-hallucination ("Je ne sais pas")

C'est probablement l'instruction la plus importante d'un système RAG bien construit : autoriser, voire obliger, le modèle à dire qu'il ne sait pas. Par défaut, un LLM cherche toujours à produire une réponse cohérente. Si le contexte fourni ne contient pas la réponse, il risque de la combler avec des éléments de son entraînement général, perdant ainsi tout le bénéfice du RAG.

En ajoutant explicitement dans le prompt "Si les documents fournis ne permettent pas de répondre à la question, réponds : "Je ne dispose pas de l'information dans les documents fournis", on force le modèle à rester dans les limites de ce qu'on lui a transmis. C'est une mesure simple mais décisive pour maintenir la fiabilité du système. Dans des contextes critiques, on peut aller plus loin en demandant au modèle de citer systématiquement le passage exact sur lequel il s'appuie pour chaque affirmation.

Comment vérifier que le RAG fonctionne ?

Mettre en place un RAG ne garantit pas qu'il répond correctement. Un système RAG se comporte comme un pipeline : une défaillance à n'importe quelle étape dégrade le résultat final. L'évaluation doit donc couvrir les deux grandes composantes : la recherche d'une part, la génération de l'autre.

L'évaluation de la recherche : Les bons documents ont-ils été trouvés ?

On évalue ici la capacité du système à retrouver les chunks pertinents pour une question donnée. Les métriques classiques sont le rappel (recall), est-ce que tous les passages importants ont été récupérés ?, et la précision, est-ce que les passages récupérés sont bien ceux qu'on attendait, sans bruit inutile ?

Pour mener cette évaluation, on construit généralement un jeu de test : un ensemble de questions pour lesquelles on connaît à l'avance les documents sources attendus. On fait tourner le moteur de recherche et on compare automatiquement les résultats obtenus aux résultats attendus. Cette étape révèle souvent des problèmes de chunking (des passages pertinents coupés au mauvais endroit), de qualité d'embedding (un modèle pas assez spécialisé pour le domaine métier), ou de paramétrage de la recherche hybride.

L'évaluation de la réponse : L'IA a-t-elle inventé ou suivi les documents ?

Cette seconde évaluation porte sur la qualité de la génération elle-même. On cherche à mesurer deux choses : la fidélité (faithfulness), est-ce que la réponse est bien ancrée dans les documents fournis, sans ajout inventé ?, et la pertinence (answer relevance), est-ce que la réponse répond vraiment à ce que l'utilisateur a demandé ?

Des frameworks open-source comme RAGAS (RAG Assessment) automatisent en partie cette évaluation en utilisant un LLM comme juge : on lui fournit la question, les chunks récupérés et la réponse générée, et il note si la réponse est fidèle aux sources. Ce n'est pas parfait, mais c'est un moyen efficace de détecter rapidement les régressions quand on modifie le système. En production, on complète souvent avec des retours humains ciblés sur les cas limites ou les questions à fort enjeu.

Un RAG bien construit n'est pas simplement un LLM avec de la documentation collée devant. C'est un pipeline complet, avec ses choix d'architecture, ses paramètres à calibrer et ses points de défaillance propres. Comprendre chaque étape permet de diagnostiquer précisément ce qui ne fonctionne pas, et de construire un système sur lequel on peut réellement compter.