Workflow RAG de bout en bout : comment fonctionne la génération augmentée par récupération

Retrieval Augmented Generation (RAG) est un modèle d'architecture AI qui connecte les grands modèles de langage à des sources de connaissances externes lors de l'inférence, permettant à ces modèles de générer des réponses précises et adaptées au contexte qui dépassent leurs données d'entraînement statiques. Plutôt que de s'appuyer sur les connaissances encodées lors du pré-entraînement, un système RAG récupère des documents pertinents dans une base de données externe en réponse à chaque requête de l'utilisateur et injecte ce contenu dans le prompt du LLM avant la génération. Le résultat est un système d'AI générative qui produit des réponses précises et spécifiques à un domaine, basées sur des sources vérifiées — sans nécessiter un réentraînement complet du modèle à chaque fois que les connaissances sous-jacentes changent.

Les LLM fournissent souvent des réponses obsolètes en raison de limites de connaissances et ne peuvent pas accéder à des documents internes propriétaires ou à des sources de données externes en temps réel. Le RAG répond directement à cette limitation. Plus de 60 % des organisations développent activement des outils de recherche basés sur l'AI, ce qui reflète une transition fondamentale : au lieu de s'appuyer uniquement sur la mémoire du modèle, elles connectent dynamiquement l'AI à des bases de connaissances en direct contenant des documents internes, de la documentation produit et des données à jour.

Ce guide présente l'ensemble du workflow RAG — des composants de l'architecture et de l'ingestion des données à la recherche hybride, la conception des prompts, l'évaluation et le déploiement — avec des conseils pratiques pour les équipes qui construisent des pipelines RAG en production.

Composants clés d'une architecture RAG

Les systèmes RAG contiennent quatre composants principaux : une base de connaissances qui stocke les connaissances externes, un composant de recherche d'informations (le retriever) qui trouve les documents pertinents pour chaque requête, une couche d'intégration qui assemble le contexte récupéré dans un prompt de LLM, et un générateur (le LLM) qui produit la réponse finale. Chaque composant peut être optimisé indépendamment, et la qualité globale du pipeline est limitée par le maillon le plus faible — un LLM de haute qualité ne peut pas compenser un retriever qui présente systématiquement des documents non pertinents.

Le retriever et la base de données vectorielle

Le retriever accepte une requête de l'utilisateur, la convertit en une représentation comparable et renvoie les documents les plus pertinents de la base de connaissances. La qualité du retriever est le principal facteur déterminant de la qualité des résultats du RAG. La base de données vectorielle stocke des représentations numériques de fragments de documents — appelées embeddings — permettant une recherche de similarité rapide et à grande échelle. Contrairement aux bases de données relationnelles qui effectuent des correspondances sur des valeurs exactes, les bases de données vectorielles trouvent les documents dont le sens est le plus proche sémantiquement de la requête en utilisant des mesures de distance comme la similarité cosinus.

Le générateur et la couche d'orchestration

Le générateur est le grand modèle de langage qui reçoit le prompt augmenté — la question d'origine de l'utilisateur combinée au contexte récupéré — et produit la réponse finale. La couche d'orchestration connecte tous les composants en un pipeline RAG cohérent, gérant l'assemblage des prompts, l'historique des conversations et la gestion des erreurs. Des frameworks comme LangChain et LlamaIndex fournissent des primitives d'orchestration communes, tandis que des plateformes comme Databricks offrent une infrastructure gérée pour l'ensemble de la pile.

Sources de données et connaissances externes

L'éventail des sources de données valides pour un système RAG est large : données structurées dans des tables relationnelles, texte non structuré dans des fichiers PDF et markdown, documents internes comme des guides de procédures d'ingénierie et des politiques HR, documentation produit et bases de connaissances externes. Les données spécifiques au domaine — le contenu directement pertinent pour les questions que les utilisateurs poseront — doivent être ingérées en premier et gérées avec le plus grand soin. Les données internes, y compris les recherches propriétaires et les documents internes, génèrent l'avantage le plus solide dans une implémentation RAG car elles représentent des connaissances sur lesquelles aucun LLM public n'a été entraîné.

La question pratique lors de la sélection des sources de données est la densité de pertinence : quel pourcentage de documents indexés sera réellement récupéré en réponse à des requêtes réelles ? Les sources à forte pertinence justifient les coûts informatiques et financiers de l'embedding et de l'indexation ; les sources à faible pertinence diluent la qualité de la recherche en augmentant le bruit que le retriever doit filtrer.

Plusieurs sources de données peuvent être combinées dans un seul système RAG — pour exemple, en associant un corpus de documentation produit à une base de données clients en temps réel — à condition que le pipeline d'ingestion normalise chaque source dans un format de texte cohérent. Les équipes doivent documenter la traçabilité des données de chaque source indexée afin que l'origine de tout document récupéré puisse être retracée jusqu'à sa source faisant autorité, ce qui permet des workflows d'audit et de conformité dans les secteurs réglementés.

Modèle d'embedding et magasin de vecteurs

Sélectionner un modèle d'embedding

Un modèle d'embedding est un modèle de langage spécialisé qui convertit le texte en représentations numériques — des vecteurs à haute dimension qui encodent la signification sémantique. Lorsqu'un utilisateur soumet une requête, le même modèle d'embedding convertit cette entrée utilisateur en un vecteur comparable, permettant une comparaison mathématique entre la requête et tous les embeddings de documents stockés. Le modèle d'embedding utilisé lors de l'ingestion doit être identique à celui utilisé au moment de la requête.

La sélection du modèle implique des compromis entre la qualité de la représentation, la dimensionnalité des vecteurs, la latence d'inférence et les coûts financiers. Les modèles à usage général comme bge-large-en produisent des vecteurs de 1 024 dimensions performants dans divers domaines. Les modèles d'embedding spécifiques à un domaine, affinés sur des textes techniques, surpassent souvent les modèles généraux dans des tâches de recherche ciblées. Les modèles d'embedding transforment le texte brut en représentations numériques qui rendent possible la recherche de similarité vectorielle.

Les modèles d'embedding peuvent également être évalués sur leur capacité à gérer des requêtes formulées différemment des documents qu'ils doivent récupérer — une propriété appelée robustesse multilingue ou à la paraphrase. Dans les environnements d'entreprise où les utilisateurs formulent des questions de manière conversationnelle alors que la documentation est rédigée de manière formelle, cette passerelle sémantique est essentielle. Tester le modèle d'embedding par rapport à un échantillon représentatif de requêtes d'utilisateurs réels avant de s'engager dans une phase d'indexation en production peut éviter un ré-embedding coûteux de l'ensemble du corpus plus tard.

Stratégie de découpage (chunking) et indexation

Les documents volumineux doivent être découpés en fragments (chunks) plus petits avant l'embedding, car la fenêtre de contexte du modèle d'embedding est limitée et parce que des fragments plus petits permettent une recherche plus précise. La taille des fragments affecte directement la qualité des résultats : des fragments trop petits perdent le contexte environnant, tandis que des fragments trop grands diluent le passage spécifique le plus pertinent pour la question de l'utilisateur. Les stratégies courantes incluent le découpage à taille fixe par nombre de tokens et le découpage aux limites des phrases avec chevauchement pour réduire le risque qu'un contexte clé se retrouve à une frontière.

Une fois les embeddings générés, les vecteurs sont stockés et indexés dans le magasin de vecteurs. Un index vectoriel utilisant des algorithmes comme HNSW organise les embeddings pour permettre une recherche de plus proches voisins approximatifs à grande échelle, réduisant la recherche d'un balayage linéaire de tous les embeddings à une recherche en moins d'une milliseconde.

Recherche d'informations et recherche hybride

La recherche sémantique — l'épine dorsale de la plupart des systèmes RAG — trouve les documents dont le sens est le plus proche de la requête de l'utilisateur, en gérant naturellement la paraphrase et les synonymes. Databricks AI Search implémente la recherche vectorielle sémantique avec une synchronisation automatique à partir des tables Delta, de sorte que la base de connaissances reflète les nouvelles données sans ré-indexation manuelle.

La recherche sémantique pure présente une faiblesse connue avec les requêtes de correspondance exacte : codes d'erreur spécifiques, numéros de version ou entités nommées. La recherche hybride y répond en combinant la recherche vectorielle sémantique avec la recherche par mots-clés BM25 — un modèle probabiliste de fréquence de termes qui excelle dans la correspondance de termes exacts et rares. L'exécution en parallèle des deux parcours de recherche et la fusion des résultats à l'aide de la fusion de rangs réciproques améliorent l'efficacité de la recherche sur une distribution de requêtes plus large.

Une étape de réordonnancement (reranking) peut encore améliorer les résultats en appliquant un modèle de cross-encoder pour évaluer chaque document récupéré par rapport à la requête et réordonner les résultats afin que les documents les plus pertinents apparaissent en premier. Les méthodes de recherche comme le reranking améliorent considérablement la précision et sont particulièrement précieuses lorsque la fenêtre de contexte du LLM limite le nombre de documents pouvant être transmis au générateur.

Les seuils de similarité ajoutent une barrière de qualité finale : les documents dont le score de pertinence est inférieur à un seuil minimum doivent être entièrement filtrés plutôt que transmis au générateur en tant que contexte de faible qualité. Transmettre un contexte non pertinent est pire que de ne transmettre aucun contexte — cela consomme la fenêtre de contexte et augmente le risque que le LLM mélange des informations correctes et incorrectes dans la réponse générée. Définir des seuils prudents et surveiller le taux de filtrage au fil du temps est un moyen simple de maintenir la qualité de la recherche sans modifications architecturales.

Comment fonctionne le RAG : de l'ingestion à la génération

Le workflow RAG suit cinq étapes séquentielles qui transforment la question d'un utilisateur en une réponse fiable et précise.

Étape 1 : Ingérer et normaliser les données externes

Le pipeline RAG commence par l'ingestion des données. Les documents bruts sont chargés dans un pipeline ETL qui nettoie et normalise le texte — en supprimant le contenu standardisé inutile, en normalisant les espaces et en extrayant le contenu structuré des tableaux et du code. L'architecture de data lakehouse centralise l'ingestion de contenus structurés et non structurés sous une gouvernance unifiée, ce qui en fait une base naturelle pour la base de connaissances RAG.

Étape 2 : Découper, générer des embeddings et indexer

Les documents nettoyés sont divisés en fragments (chunks), chaque fragment passe par le modèle d'embedding pour générer un vecteur, et les embeddings qui en résultent sont enregistrés dans le vector store aux côtés du texte d'origine et des métadonnées (titre du document, date, URL source). Les métadonnées permettent une recherche filtrée — en limitant les résultats aux documents publiés dans une plage de dates spécifique ou accessibles à un rôle utilisateur particulier. Le RAG nécessite des mises à jour continues pour maintenir la pertinence des données ; les systèmes en production ont besoin de pipelines automatisés qui détectent les documents sources mis à jour et déclenchent un ré-embedding de manière planifiée ou pilotée par des événements.

Étape 3 : Récupérer les documents pertinents

Lorsqu'un utilisateur soumet une requête, le système RAG applique le même modèle d'embedding pour convertir la saisie de l'utilisateur en une représentation vectorielle et interroge le vector store, en exécutant une recherche de similitude qui renvoie les top-k fragments de documents les plus pertinents. La valeur k — le nombre de fragments à récupérer — fait un compromis entre la couverture de la recherche et la consommation de la fenêtre de contexte, et doit être ajustée pour le LLM cible.

Étape 4 : Augmenter le prompt du LLM

Les documents récupérés sont assemblés dans le prompt augmenté. Une structure typique place d'abord une instruction système (« Répondez à la question de l'utilisateur en vous basant uniquement sur le contexte fourni. Si vous ne trouvez pas la réponse dans le contexte, dites-le. »), suivie des fragments de texte récupérés, puis de la question d'origine de l'utilisateur. Placer les documents les plus pertinents en premier a tendance à améliorer la concentration, en particulier pour les modèles sujets au phénomène de « lost in the middle » (perte au milieu), où le contexte situé près du début et de la fin reçoit plus d'attention que le contenu au centre.

Étape 5 : Générer la réponse finale

Le générateur reçoit le prompt augmenté et produit la réponse finale. Le post-traitement peut ajouter des citations de sources, filtrer les résultats hors sujet ou structurer les résultats dans un format cohérent. Le LLM génère des réponses précises car il a accès au contexte récupéré plutôt que de s'appuyer uniquement sur les données d'entraînement statiques issues du pré-entraînement.

La gestion de l'historique des conversations est une préoccupation importante de la couche de génération pour les applications RAG multi-tours. Lorsque le système RAG doit se souvenir des échanges précédents d'une session — afin que les utilisateurs puissent poser des questions de suivi faisant référence aux réponses précédentes —, l'historique des conversations doit être intégré dans le prompt augmenté. Cela augmente la longueur effective du prompt et réduit la fenêtre de contexte disponible pour les documents nouvellement récupérés. Les équipes doivent mettre en œuvre une gestion explicite du budget de contexte qui alloue les tokens entre l'historique, le contexte récupéré et la requête actuelle de l'utilisateur.

AI générative, conception de prompts LLM et orchestration

Un modèle de prompt LLM réutilisable sépare les instructions statiques — rôle du système, contraintes de comportement, format de sortie — du contenu dynamique inséré au moment de l'exécution : le contexte récupéré et la requête de l'utilisateur. L'instruction de répondre « uniquement à partir du contexte fourni » est particulièrement importante pour les systèmes RAG. Sans elle, les modèles d'AI générative compléteront le contenu récupéré avec des données d'entraînement mémorisées, produisant des réponses qui mélangent des informations vérifiées avec des connaissances potentiellement incorrectes du modèle.

L'injection de citations — l'ajout de métadonnées de documents sources à chaque réponse générée — permet aux réviseurs humains de vérifier que les réponses sont fondées sur des données réelles récupérées. Dans les déploiements en entreprise, la prise en charge des citations et les instructions système qui limitent la portée du sujet, la longueur des réponses et le comportement d'escalade sont des exigences de production pour obtenir des réponses précises.

Fine-Tuning, connaissances du domaine et alternatives

Le fine-tuning adapte un modèle pré-entraîné à un domaine spécifique en modifiant les poids du modèle sur un ensemble de données sélectionné. Contrairement au RAG, le fine-tuning modifie le comportement du modèle sous-jacent — son vocabulaire, son ton et ses connaissances implicites du domaine — plutôt que d'injecter du contexte au moment de l'inférence. Le fine-tuning est approprié lorsque le modèle de base comprend systématiquement mal la terminologie spécifique au domaine ou lorsque le style de réponse requis ne peut pas être obtenu uniquement par le prompt engineering.

Le fine-tuning n'est pas un substitut efficace au RAG lorsque l'objectif est d'accéder à des informations à jour. Le fine-tuning des LLM sur de nouvelles données entraîne des coûts informatiques et financiers importants et ne peut pas suivre le rythme des bases de connaissances en constante évolution. La plupart des systèmes en production combinent les deux : un modèle fine-tuné gère le ton et la terminologie du domaine tandis que le flux de travail RAG fournit l'accès aux connaissances. S'appuyer uniquement sur le fine-tuning pour l'accès aux connaissances est une erreur courante et coûteuse.

Le prompt engineering — la conception d'instructions système et d'exemples few-shot pour guider le comportement du modèle — reste le point de départ de référence pour toute personnalisation de LLM. Il ne nécessite aucune infrastructure supplémentaire et produit des résultats immédiatement. Pour les systèmes RAG, le prompt engineering contrôle la manière dont le contexte récupéré est présenté au modèle et la manière dont le modèle signale l'incertitude lorsque les documents récupérés ne répondent pas entièrement à la question de l'utilisateur. Chaque système RAG intègre le prompt engineering par définition, puisque l'assemblage du prompt augmenté est lui-même une forme de conception de prompt.

Évaluation du RAG et tests de récupération

Mesurer la qualité de la récupération

L'évaluation du RAG doit évaluer indépendamment le composant de récupération d'informations et le composant de génération. L'évaluation de la récupération utilise la précision@k : sur les k documents récupérés pour une requête donnée, quelle proportion est réellement pertinente ? Un ensemble de données d'évaluation de référence (ground-truth) — des requêtes associées à des documents et des réponses connus comme corrects — est le prérequis nécessaire. La constitution de cet ensemble de données nécessite beaucoup de travail mais s'avère essentielle ; sans elle, les équipes ne peuvent pas distinguer les véritables améliorations de l'évaluation du RAG des variations aléatoires.

Mesurer la fidélité de la génération

L'évaluation de la génération mesure si les réponses du modèle sont fidèles au contexte récupéré — si la réponse générée contient des informations incorrectes ou fabriquées tirées des données d'entraînement du modèle plutôt que des sources récupérées. L'évaluation de type LLM-as-judge, où un second LLM évalue la fidélité de chaque réponse, offre une couverture évolutive sur de grands ensembles de tests. L'évaluation des LLM avec MLflow intègre les métriques de récupération et de génération dans un cadre unifié de suivi des expériences. Le RAG réduit les hallucinations dans les modèles d'AI générative mais ne peut pas éliminer toutes les hallucinations d'AI dans les réponses générées.

Surveillance, gouvernance et sécurité

Les systèmes RAG héritent des exigences de gouvernance de leurs sources de données. Les utilisateurs ne doivent récupérer que les documents qu'ils sont autorisés à consulter. Unity Catalog offre une gouvernance précise sur l'ensemble de la base de connaissances RAG — index vectoriels, tables Delta et points de terminaison de modèles régis par un modèle de contrôle d'accès commun avec un suivi complet de la lignée des données (data lineage). Le marquage de provenance — qui consiste à associer chaque réponse générée aux fragments de documents spécifiques qui l'ont produite — permet aux réviseurs humains de vérifier les sources citées et d'auditer le contenu généré par l'AI. Dans les secteurs réglementés, la provenance est souvent une exigence de conformité.

La surveillance doit également suivre l'obsolescence de la base de connaissances — l'écart entre la dernière mise à jour des documents sources et le dernier rafraîchissement de l'index RAG. Une base de connaissances qui renvoie systématiquement des documents obsolètes est opérationnellement équivalente à un LLM avec une limite d'entraînement dépassée ; les deux produisent réponses qui étaient exactes à un moment donné mais ne reflètent plus les informations actuelles. Des alertes d'obsolescence automatisées qui se déclenchent lorsqu'un document source n'a pas été ré-indexé dans le cadre d'un SLA défini évitent une dégradation silencieuse de la précision des réponses au fil du temps.

Les vector stores doivent être chiffrés au repos, les points de terminaison d'inférence d'embedding et de LLM déployés dans des limites de réseau sécurisées, et les journaux d'audit doivent capturer toutes les requêtes et événements de récupération pour détecter les accès anormaux.

Les contrôles d'accès basés sur les rôles au niveau de la couche de récupération sont particulièrement importants dans les déploiements RAG multi-locataires (multi-tenant) où différents utilisateurs ou équipes ne doivent récupérer que des documents provenant de leurs domaines de données autorisés. Sans contrôles d'accès au niveau de la couche de récupération, la requête d'un utilisateur pourrait faire surface des documents confidentiels d'une unité commerciale non liée — une faille de gouvernance des données invisible dans la réponse générée mais présente dans le journal de récupération sous-jacent. Concevoir le contrôle d'accès dans l'architecture RAG dès le départ est nettement plus facile que de l'intégrer après l'indexation des données.

Mise à l'échelle opérationnelle et meilleures pratiques de déploiement

L'ingestion initiale d'une grande base de connaissances nécessite un embedding par lots (batch embedding) à grande échelle. Après le chargement initial, l'ingestion incrémentielle ne ré-embedde que les documents nouveaux ou mis à jour. Les systèmes doivent adapter automatiquement l'échelle du calcul d'embedding pour les chargements initiaux et la réduire pour les mises à jour incrémentielles en cours. L'embedding par lots est nettement moins cher par document que l'embedding en temps réel ; les systèmes en production doivent utiliser le traitement par lots pour les charges de travail d'ingestion et réserver l'embedding en temps réel pour le traitement des requêtes des utilisateurs.

L'inférence de LLM domine généralement les coûts d'exploitation du RAG. Transmettre plus de documents récupérés au LLM augmente proportionnellement le coût d'inférence par requête ; les équipes doivent définir des politiques explicites sur le nombre maximal de documents récupérés et la longueur du prompt pour limiter les coûts. Chaque composant — inférence d'embedding, vector store, service d'orchestration, point de terminaison de LLM — doit être conteneurisé pour un déploiement reproductible avec une logique de tentative (retry) et des modèles de disjoncteur (circuit-breaker) pour le basculement.

Databricks MLflow fournit un suivi des expériences, un registre de modèles et des outils d'évaluation intégrés à l'ensemble de la pile RAG, permettant aux équipes de versionner les modèles d'embedding, de suivre les expériences de récupération et de gérer le cycle de vie des pipelines RAG en production.

Foire aux questions

En quoi le flux de travail RAG diffère-t-il du fine-tuning d'un LLM ?

Le workflow RAG récupère les documents pertinents au moment de l'inférence et les injecte dans le prompt du LLM, tandis que le fine-tuning modifie les poids du modèle en l'entraînant sur de nouvelles données avant le déploiement. Le RAG offre un accès dynamique à des informations à jour sans réentraîner le modèle, ce qui le rend plus rentable pour les connaissances qui changent fréquemment. Le fine-tuning est mieux adapté pour adapter le style de réponse, le vocabulaire du domaine ou la spécialisation des tâches. La plupart des systèmes en production combinent les deux : un modèle fine-tuné pour le ton du domaine, associé à un workflow RAG pour l'accès aux connaissances.

Quel est le mode de défaillance le plus courant dans un système RAG ?

Une mauvaise qualité de récupération est le mode de défaillance du RAG le plus courant. Si le composant de récupération d'informations renvoie des documents non pertinents, le LLM génère des réponses qui semblent sûres d'elles mais ne sont pas basées sur des informations correctes — une défaillance plus difficile à détecter que les hallucinations évidentes. Les échecs de récupération découlent d'un chunking inadéquat, d'une inadéquation entre l'espace sémantique du modèle d'embedding et la distribution des requêtes, d'une couverture de recherche hybride insuffisante ou d'une base de connaissances qui ne contient tout simplement pas les informations demandées par les utilisateurs. Évaluer la précision de la récupération séparément de la fidélité de la génération est essentiel pour diagnostiquer cette catégorie de défaillance.

Comment le RAG réduit-il les hallucinations de l'AI ?

Le RAG réduit les hallucinations dans les modèles d'AI générative en fournissant au LLM un contexte spécifique et vérifié pour chaque requête, plutôt que de demander au modèle de répondre de mémoire. Lorsque le prompt indique explicitement au modèle de répondre uniquement à partir du contexte récupéré, le modèle a moins de liberté pour inventer des informations. La réduction est proportionnelle à la qualité de la récupération — plus les documents récupérés sont pertinents et complets, moins le modèle a besoin d'extrapoler. Le RAG ne peut pas éliminer toutes les hallucinations de l'AI, car les modèles interprètent parfois mal le contexte récupéré, mais il réduit considérablement leur fréquence par rapport à une génération sans récupération.

Quelles sources de données externes fonctionnent le mieux avec le RAG ?

Les sources à haute densité et spécifiques à un domaine produisent les meilleurs résultats de récupération : documentation produit, bases de connaissances techniques, documents de politique d'entreprise et référentiels internes sélectionnés. Les sources ayant un formatage cohérent et des limites de paragraphes claires se prêtent au chunking et à l'embedding de manière plus fiable que les contenus peu structurés. Les sources de connaissances externes provenant de fournisseurs tiers — rapports réglementaires, normes industrielles, littérature académique — étendent la couverture au-delà du contenu propriétaire. Les systèmes RAG dépendent de la qualité des sources de données externes ; des documents sources inexacts ou mal formatés produisent des réponses inexactes, quelle que soit la qualité de l'architecture de récupération.

Quels sont les composants clés d'une architecture RAG ?

Une architecture RAG contient quatre composants principaux : la base de connaissances (le stockage de données externes indexées), le récupérateur (le composant de récupération d'informations qui fait remonter les documents pertinents), la couche d'intégration (la logique d'orchestration qui assemble le contexte dans un prompt de LLM) et le générateur (le grand modèle de langage qui produit la réponse finale). La base de données vectorielle est un élément d'infrastructure critique de la base de connaissances, stockant les représentations numériques des chunks de documents et permettant une recherche rapide par similarité sémantique. Découvrez-en plus sur les modèles d'architecture de génération augmentée par récupération sur la page du glossaire Databricks.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original