Cartographie du RAG : étapes du pipeline, composants clés et paysage des variantes
Comprendre le fonctionnement du génération augmentée par la récupération de données de bout en bout, quels composants nécessite un système RAG, et comment les nombreuses variantes de RAG s’intègrent dans une même architecture.
Sources: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
RAG en une phrase
RAG combine deux processus :
- Récupération : localisation d’informations pertinentes dans une source de connaissances externe.
- Génération : production d’une réponse par un modèle de langage, basée sur les informations récupérées.
En termes simples, RAG fournit au modèle une bibliothèque de référence à consulter avant qu’il ne réponde. La recherche qui a introduit cette approche l’a décrite comme une combinaison de la mémoire paramétrique du modèle, c’est-à-dire les connaissances stockées dans ses poids pendant l’entraînement, et d’une mémoire non paramétrique, un index externe qui peut être recherché et mis à jour de manière indépendante.
Une comparaison utile est celle d’un examen avec des livres ouverts :
- Le LLM est l’étudiant.
- La base de connaissances est le manuel scolaire.
- Le système de récupération est l’étudiant qui feuillette les pages appropriées.
- La réponse finale est la réponse de l’étudiant, rédigée avec ces pages ouvertes.
Le modèle apporte le raisonnement et un langage fluide ; le système de récupération fournit les faits pertinents pour cette question spécifique.
Les problèmes que RAG est conçu pour résoudre
Se fier uniquement aux connaissances intégrées à un modèle présente plusieurs limites pratiques. Pour chacune d’elles, RAG propose une solution partielle.
Des connaissances limitées au moment de l’entraînement
Réponses non étayées ou inventées
ne les élimine pas : la récupération peut retourner des passages erronés, les sources elles-mêmes peuvent être inexactes, et le modèle peut toujours faire des affirmations que les éléments fournis ne soutiennent pas.
Données privées que le modèle n’a jamais vues
Informations qui changent fréquemment
Documents trop volumineux pour être envoyés en totalité
Bruit provenant d’un contexte irrélevant
Trop de matériel peu lié entre eux rend plus difficile pour le modèle la découverte des éléments importants. Le filtrage, le réclassement et la compression du contexte visent tous à améliorer la qualité de ce qui parvient finalement au modèle.
RAG améliore le lien avec les données réelles et diminue le taux d’hallucinations, mais il ne garantit pas des réponses exactes ou exemptes d’hallucinations. Considérez-le comme un outil de fiabilité, et non comme une preuve de correction.
Les trois étapes d’un système RAG
Au niveau le plus simple, tout système RAG effectue trois actions : il prépare les connaissances, les récupère et en utilise le contenu pour générer des réponses.
Étape 1 : indexation
L’indexation a lieu avant même que l’utilisateur ne pose une question. Les matériaux sources tels que des PDF, des pages web, de la documentation ou des lignes de base de données sont :
- chargés dans le système,
- découpés en parties plus petites,
Le résultat est une représentation recherchable de vos connaissances. Conceptuellement, vous créez un index de recherche sur vos propres données.
Étape 2 : récupération
Lorsqu’une question arrive :
- la requête est convertie en un embedding à l’aide du même modèle utilisé lors de l’indexation,
- la base de connaissances est recherchée pour trouver des vecteurs proches,
- les fragments les plus pertinents sont sélectionnés,
- un filtrage ou un réclassement optionnels affinent la sélection.
Le flux allant de la question aux fragments candidats se présente comme suit :
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
La propriété importante est que les requêtes et les documents se trouvent dans le même espace vectoriel. C’est pourquoi le modèle d’incorporation utilisé au moment de la requête doit correspondre à celui utilisé pour construire l’index ; mélanger des modèles produit des vecteurs qui ne peuvent pas être comparés de manière significative.
Étape 3 : génération
Les extraits sélectionnés sont combinés avec la question de l’utilisateur pour former un prompt, et le modèle génère la réponse :
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
La réponse obtenue s’appuie sur les capacités générales du modèle ainsi que sur les éléments spécifiques tirés de votre source de connaissances. La manière dont le prompt présente ces éléments, par exemple en indiquant des étiquettes de source que le modèle peut citer, influence fortement dans quelle mesure la réponse reste fidèle à eux.
Dans le pipeline d’indexation
C’est lors de l’indexation que se décide la majeure partie de la qualité d’un système RAG. Sa structure de base :
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Données brutes
Les connaissances peuvent provenir de presque n’importe où :
- Sites web
- Documentation
- Documents texte
- Bases de données
- API
- Fichiers internes de l’entreprise
Chargeurs de documents
Document, et ils peuvent exposer à la fois load() et lazy_load(). La version différée produit les documents un par un au lieu de tout mettre en mémoire, ce qui est important pour de grandes collections. LangChain et LlamaIndex sont les deux écosystèmes avec lesquels la plupart des gens commencent.
Chunking
Les documents volumineux sont divisés en parties plus petites appelées chunks, car il est généralement plus utile de récupérer la section pertinente d’un document que de lui transmettre l’ensemble. Une bonne analogie est de transformer un livre en une pile de fiches index, chacune couvrant une idée.
La taille des chunks et le degré d’overlap n’ont pas de valeurs universellement correctes. Ils dépendent de la structure de vos documents, du type de questions auxquelles vous vous attendez, du modèle d’embedding que vous utilisez et de la quantité de contexte que vous pouvez fournir par la suite. Les chunks trop petits perdent le sens environnant ; ceux qui sont trop grands diluent le signal de la phrase importante. Pour en savoir plus sur cet équilibre, consultez le chunking qui préserve les éléments de preuve.
Modèles d’embedding
Chaque morceau de texte est converti en un embedding, c’est-à-dire une liste de nombres représentant son sens :
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Les embeddings permettent à un système de mesurer le degré de similarité entre deux contenus, ce qui est au fondement de la recherche sémantique : les textes ayant un sens similaire se trouvent proches l’un de l’autre dans l’espace vectoriel, même s’ils partagent peu de mots.
Dans la famille text-embedding-3 d’OpenAI, le modèle de petite taille génère par défaut des vecteurs de 1536 dimensions, tandis que le modèle de grande taille en génère de 3072.
Les deux modèles acceptent un paramètre dimensions pour obtenir des vecteurs plus courts, au prix d’une légère perte en précision en échange d’une moindre consommation de mémoire et d’une recherche plus rapide. La gamme des modèles évolue, il convient donc de vérifier les options actuelles dans la documentation du fournisseur.
Bases de données vectorielles
Les embeddings sont stockés dans une base de données vectorielle ou un index vectoriel conçu pour des recherches de similarité rapides. Parmi les choix courants on trouve :
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Un enregistrement stocké contient généralement plus que le vecteur lui-même. Il conserve également le texte d’origine par morceaux ainsi que des métadonnées telles que la source, le numéro de page, l’ID du document ou une date et heure. Ce sont ces métadonnées qui permettent par la suite de filtrer par date ou par type de document, et d’indiquer d’où provient une réponse.
Les éléments de base d’une application RAG
En résumé, une application RAG typique est composée de six types de composants :
- Source de connaissances : fournit les informations, par exemple des PDF, des sites web, des bases de données SQL ou des API.
- Décomposeur de texte : divise les documents en morceaux gérables, en utilisant les outils de décomposition de texte de LangChain ou votre propre logique.
Un aperçu de la famille RAG
Lorsque le flux de travail de base est clair, l’écosystème des variantes existantes peut sembler déroutant. Il n’existe pas de liste canonique unique des types RAG ; les articles scientifiques et les blogs techniques utilisent des noms parfois similaires pour désigner des architectures, des stratégies de récupération, des techniques de contexte, des sources de connaissances et des systèmes spécialisés. Les regrouper en fonction de ce qu’ils modifient permet de rendre ce paysage plus gérable.
Architectures de base
- RAG naïf : pipeline simple comprenant l’incorporation, la recherche et la génération.
- RAG avancé : ajoute des étapes avant et après la récupération, telles que la réécriture de la requête et le reclassement.
- RAG modulaire : traite chaque étape comme un module interchangeable qui peut être réassemblé.
Stratégies de récupération
- RAG à une seule passe : une récupération par question.
- RAG à plusieurs requêtes : génère plusieurs formulations de la question et effectue une récupération pour chacune.
- RAG itératif : effectue une récupération, raisonne, puis effectue à nouveau une récupération.
- RAG multi-étapes : enchaîne des récupérations lorsque la réponse nécessite de relier plusieurs faits.
- RAG hybride : combine la recherche vectorielle sémantique avec la recherche par mots-clés.
Méthodes de contexte et d’agrégation en blocs
- RAG parent-enfant : effectue des correspondances sur de petits blocs mais renvoie leur section parente plus large.
- RAG de fenêtre de phrase : récupère une phrase ainsi que ses phrases voisines.
- RAG hiérarchique : effectue des recherches à différents niveaux, des documents jusqu’aux passages.
- RAG contextuel : enrichit les blocs avec du contexte au niveau du document avant de les embedder.
- RAPTOR : crée un arbre de résumés récursifs et effectue des recherches à travers ses niveaux.
Méthodes d’autocorrection et adaptatives
- Self-RAG : le modèle évalue s’une récupération est nécessaire et si ses résultats sont étayés.
- Corrective RAG (CRAG) : il analyse les résultats récupérés et déclenche une nouvelle récupération lorsque ceux-ci sont insuffisants.
- Adaptive RAG : il oriente chaque question vers une stratégie adaptée à sa complexité.
- Feedback-based RAG : il utilise les retours des utilisateurs ou des évaluateurs pour améliorer progressivement la récupération d’informations.
Approches agentiques
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
Dans ces approches, un agent décide quand et où effectuer la récupération d’informations, éventuellement en utilisant plusieurs outils ou des agents collaborateurs, au lieu de suivre un processus fixe.
Variantes définies par la source de connaissances
Divers noms décrivent simplement l’origine des preuves. Vector RAG recherche dans un index d’embeddings, tandis que SQL RAG et Table RAG interrogent des données relationnelles ou tabulaires, souvent en faisant écrire la requête par le modèle. GraphRAG récupère des informations à partir d’un graphe de connaissances composé d’entités et de relations, Web ou Search RAG obtient des résultats en temps réel à partir d’un moteur de recherche, et Knowledge-Base RAG s’appuie sur un corpus soigneusement sélectionné tel qu’un centre d’aide ou une wiki.
Variantes multimodales
D’autres désignations font référence au type de contenu récupéré. Text RAG est le cas par défaut ; Image, Video et Audio RAG extraient des informations de ces médias, généralement via des embeddings ou des transcriptions, et Multimodal RAG est le terme générique désignant les systèmes qui combinent plusieurs de ces approches.
Variantes spécialisées
Un dernier groupe de systèmes de nomenclature adaptés à des exigences particulières : un seul domaine tel que le droit ou la médecine (spécifique au domaine), des questions sensibles au temps où la récente actualité est importante (temporelles), des réponses adaptées à un utilisateur individuel (personnalisées), des requêtes et des sources en plusieurs langues (multilingues), des données sensibles qui doivent rester protégées (respectueuses de la vie privée), ainsi que des index répartis sur plusieurs sites ou organisations (distribués ou fédérés).
Ces groupes se chevauchent librement. Un véritable système de production peut être à la fois hybride, agentic et spécifique à un domaine ; ces étiquettes décrivent des choix de conception, et non des produits mutuellement exclusifs.
Des pipelines naïfs aux pipelines avancés
Le pipeline le plus basique est une ligne droite :
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
C’est ce que les gens entendent généralement par RAG naïf ou basique : intégrer la question, sélectionner les fragments les plus proches parmi les k meilleurs et les transmettre au modèle. Il s’agit d’une première version sensée qui est souvent suffisante pour des corpus petits et bien structurés.
Les systèmes plus avancés ajoutent des étapes supplémentaires avant la récupération :
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Chaque étape cible une faiblesse spécifique. La réécriture des requêtes corrige les questions vagues ou conversationnelles, le routage envoie la question vers l’index ou l’outil approprié, la récupération hybride détecte les termes exacts que la recherche vectorielle pure manque, le filtrage des métadonnées élimine les documents hors champ, la réclassification réordonne les candidats à l’aide d’un modèle plus précis, et la compression réduit ce qui reste pour respecter les contraintes de ressources. N’ajoutez-les que lorsque vous pouvez mesurer le problème qu’elles résolvent ; la complexité n’est pas une fin en soi.
Pourquoi RAG est plus qu’une base de données vectorielles associée à un LLM
Une idée répandue chez les débutants est que RAG signifie « stocker des embeddings, les interroger, appeler le modèle ». Un pipeline de production ressemble plutôt à ceci :
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Chaque étape de cette chaîne peut nuire à la qualité de la réponse finale : une analyse incorrecte, un découpage négligent, l’absence de métadonnées, un modèle d’embedding inadapté, un filtrage insuffisant ou une prompt mal conçue. C’est pourquoi relier un stock vectoriel à un modèle n’est que le début. Peu importe la capacité du modèle, il ne peut pas compenser entièrement le fait de recevoir des informations erronées.
Comment évaluer un système RAG
Produire une réponse n’est pas l’unique critère. Un bon système RAG récupère des informations véritablement utiles et génère une réponse que les éléments obtenus soutiennent réellement. Les critères à prendre en compte sont :
- Qualité de la récupération : les documents ou fragments pertinents reviennent-ils bien ?
Mesurer chaque étape séparément permet de diagnostiquer les défaillances ; l’approche d’évaluation du RAG par étape de défaillance montre comment structurer cela.
Où aller ensuite
Le niveau suivant de profondeur concerne le chemin d’indexation lui-même : la manière dont un PDF est transformé en texte, les différences entre chargement, analyse et nettoyage, les compromis entre le découpage par caractères, tokens, méthode récursive, approche sémantique et prise en compte de la structure, l’effet réel du chevauchement des blocs, la manière dont les métadonnées doivent être conçues, la façon dont le texte devient un vecteur, les différences entre la similarité cosinus, le produit scalaire et la distance euclidienne, ainsi que le fonctionnement des bases de données vectorielles pour effectuer des recherches de similarité à grande échelle.
Points clés
- RAG associe les connaissances apprises par un modèle à un stockage externe consultable, permettant ainsi aux réponses de refléter des informations privées et actuelles sans avoir à reformerater le modèle.
- Cela réduit les réponses non fiables, mais ne garantit jamais la justesse ; la récupération des données, l’identification des sources et la génération de réponses peuvent encore échouer.