Explication d’un pipeline RAG de base : des documents bruts aux réponses fondées sur des données concrètes.

Les modèles de langage ont une habitude gênante : ils semblent sûrs d’eux-mêmes même lorsqu’ils ne disposent pas des informations nécessaires. Posez-lui des questions sur une politique interne de l’entreprise, le manuel d’un produit sorti le mois dernier, un document juridique peu connu ou une demande de support d’hier, et le modèle peut tout simplement ne pas savoir. Pire encore, il peut produire quelque chose de plausiblement convaincant pour combler ce manque.

La génération augmentée par récupération d’informations, souvent abrégée en RAG, est la solution standard. Un pipeline RAG permet à un modèle de consulter des connaissances externes au moment où cela est nécessaire. Il n’est pas obligatoire que tout soit stocké dans la mémoire du modèle, car le système recherche une base de connaissances fiable, extrait les passages les plus pertinents et rédige une réponse basée sur eux. En termes simples, un assistant qui ne dispose que de connaissances préenregistrées devient un assistant pouvant accéder à des informations en temps réel.

Cette approche a attiré l’attention grâce à une étude de recherche de 2020 sur la génération augmentée par la récupération d’informations pour des tâches de traitement du langage naturel à forte intensité cognitive, qui combinait un modèle génératif avec un outil de recherche explorant une collection de documents externes. L’observation principale était que les connaissances intégrées au modèle et les informations externes pouvaient se compléter mutuellement : le modèle fournissait la capacité linguistique, tandis que l’outil de recherche apportait des détails actuels et spécifiques.

Un pipeline de base se déroule en deux phases. L’indexation prépare les documents pour la recherche. La réponse prend la question de l’utilisateur, récupère le matériel pertinent et le transmet au modèle en tant que contexte. Cela semble simple, mais chaque étape cache des décisions qui influencent le résultat. Un système faible échoue rarement à cause d’un modèle de mauvaise qualité. Bien plus souvent, il récupère les documents incorrects, les extraits sont désordonnés, la demande est vague, ou le système est incapable d’admettre qu’il n’a pas de réponse.

Les sections suivantes développent cette idée depuis zéro.

Ce que fait RAG en pratique

Le cycle de base comporte quatre étapes. Un utilisateur pose une question. Le système recherche dans la base de connaissances. Les passages les plus pertinents sont intégrés à la demande adressée au modèle. Le modèle répond en s’appuyant sur ce contexte récupéré.

Imaginez un client qui souhaite savoir si un ordinateur portable réparé peut encore être retourné après 20 jours. Un chatbot classique pourrait deviner en se basant sur des habitudes commerciales générales. Un chatbot RAG peut consulter la politique de retour réelle, trouver la section consacrée aux produits réparés et y répondre. Si la politique prévoit une période de 14 jours pour les ordinateurs portables réparés, le bot peut le confirmer. Si la politique ne mentionne pas les ordinateurs portables réparés, le bot ne doit pas inventer de règle.

C’est là l’essentiel : la récupération d’abord, la génération ensuite. La récupération réduit le champ des informations à quelques éléments utiles, tandis que la génération les transforme en une réponse utile. Bien mis en œuvre, le RAG améliore la précision factuelle, rend les réponses plus faciles à vérifier et permet de mettre à jour les connaissances du système sans devoir reformerater un modèle.

Choix de la source de connaissances

Chaque pipeline commence par un ensemble de documents à partir desquels il faut récupérer des informations. Les sources typiques sont la documentation de l’entreprise, les manuels produits, les articles des centres d’aide, les PDF, les contrats, les articles de recherche, les notes de réunion, les enregistrements de base de données, la documentation de code et les tickets d’assistance.

La source la plus importante n’est pas toujours la meilleure. Un ensemble de documents ciblés, bien organisés et à jour l’emporte généralement sur une grande quantité de fichiers obsolètes. RAG ne peut pas corriger des documents de mauvaise qualité ; par conséquent, des documents dépassés, peu clairs ou contradictoires produisent des réponses similaires.

Avant d’indexer quoi que ce soit, il est utile de se poser quelques questions pratiques :

• Les informations sont-elles exactes et à jour ?
• Qui en est le propriétaire ?
• Tous les utilisateurs ont-ils le droit de les consulter ?
• Y a-t-il des versions dupliquées ou contradictoires ?
• Les tableaux, les images, les notes de bas de page ou les clauses juridiques nécessitent-elles un traitement particulier ?

Une base de connaissances petite et bien entretenue constitue un bon point de départ. Pour un premier projet, choisissez un cas d’usage clair, comme des questions relatives au manuel du personnel ou aux FAQ d’un produit, et développez-la une fois que cela fonctionne bien.

Nettoyage et préparation des documents

Les fichiers bruts sont rarement prêts à être consultés. Les PDF peuvent présenter des sauts de ligne défectueux. Les pages Web incluent des menus, des bannières de cookies, des publicités et des pieds de page qui se répètent sur chaque page. Les documents internes peuvent avoir des titres ne fournissant pas suffisamment de contexte, et les tableurs peuvent cacher des détails importants dans des colonnes difficiles à lire en texte brut.

Le nettoyage transforme ce désordre en texte pouvant être recherché. Il peut consister à supprimer le texte générique, à conserver les titres, à extraire les tableaux, à convertir tout le contenu en un format cohérent et à ajouter des métadonnées. Les métadonnées sont particulièrement utiles, car un fragment gagne en valeur lorsqu’il contient des informations telles que le titre du document, l’auteur, la date, le département responsable, la version du produit, un lien, le niveau d’accès ou le titre de la section.

Comparez un fragment simple comme « Les retours doivent être demandés dans les 14 jours » avec un fragment étiqueté : le titre indique la politique de retour des ordinateurs portables reconditionnés, la section correspond à la période de retour, il a été mis à jour pour la dernière fois en mars 2026, et le texte précise qu’un retour d’ordinateur portable reconditionné doit être demandé dans les 14 jours suivant sa réception. Cette seconde forme offre plus de matériel aux outils de recherche et au modèle, ce qui simplifie les citations et le filtrage par la suite.

Décomposer les documents en fragments

Les modèles de langage et les systèmes de récupération ne gèrent généralement pas des livres entiers, des manuels ou des bibliothèques de politiques en une seule fois. Ils fonctionnent mieux avec de plus petits passages appelés blocs.

La segmentation en blocs fait partie des éléments les plus importants du processus, car la récupération s’effectue au niveau des blocs. Si les blocs sont trop grands, la réponse peut se trouver parmi du texte irrelevant. S’ils sont trop petits, le système peut récupérer des fragments sans suffisamment de contexte pour répondre correctement. Un bon bloc est suffisamment grand pour contenir une idée complète et suffisamment petit pour rester ciblé.

Pour les systèmes à forte charge de texte, les développeurs commencent souvent par des blocs de quelques centaines de mots et les ajustent en fonction des résultats. Certains utilisent des blocs qui se chevauchent afin que le contexte ne soit pas perdu à une frontière, par exemple lorsque un en-tête termine un bloc et le texte de politique qu’il introduit commence le suivant.

Le découpage doit suivre autant que possible la structure du document. Diviser le texte par sections, titres, paragraphes ou paires questions-réponses est généralement préférable à une coupure basée sur un nombre fixe de caractères, et différents types de documents, tels que les politiques de remboursement, les guides de dépannage et les articles scientifiques, peuvent nécessiter chacun une approche propre.

C’est là que de nombreux systèmes basiques réussissent ou échouent silencieusement. Le modèle ne peut répondre qu’à partir de ce qu’il reçoit, de sorte qu’un fragment tronqué sans contexte peut mettre en difficulté même un modèle performant.

Création d’embeddings

Après nettoyage et découpage, chaque fragment est converti en un embedding, c’est-à-dire en une représentation numérique du sens. Techniquement, il s’agit d’un vecteur, une liste de nombres capturant les informations sémantiques du texte. Les textes ayant des significations similaires ont tendance à se trouver proches les uns des autres dans l’espace vectoriel, ce qui permet à un système de rechercher en fonction du sens et non seulement en fonction de mots-clés exacts.

Supposons maintenant que la question porte sur le délai imparti pour retourner un ordinateur réparé, alors que le document indique que les ordinateurs portables réparés peuvent être retournés sur demande dans un délai de 14 jours après la livraison. Une recherche par mots-clés traditionnelle risque de manquer le lien entre « retourner » et « retours », ou entre « ordinateur » et « ordinateur portable ». Une recherche basée sur l’incorporation est plus susceptible de percevoir cette relation.

Ce type de correspondance sémantique explique pourquoi la récupération dense est devenue importante dans le domaine des réponses à des questions en contexte ouvert. Les travaux sur la récupération de passages denses de 2020 ont montré que des représentations denses apprises pouvaient surpasser un modèle de référence solide comme BM25 sur plusieurs benchmarks de récupération pour les questions en contexte ouvert.

Dans un pipeline de base, vous intégrez chaque morceau dans la base de connaissances. Lorsqu’un utilisateur pose une question, vous l’intégrez également, vous la comparez aux embeddings des morceaux stockés et vous récupérez les correspondances les plus proches.

Stockage des embeddings dans une base de données vectorielle

Les embeddings ont besoin d’un endroit qui permette des recherches, c’est là que intervient une base de données vectorielle. Elle conserve l’embedding de chaque morceau, son texte original ainsi que tout métadonnée utile. Lorsqu’une question est posée, elle identifie les morceaux dont les embeddings sont les plus proches de ceux de la question.

Pour un prototype, un stockage local ou en mémoire suffit. En environnement de production, on peut avoir besoin d’une base de données vectorielle gérée, d’un moteur de recherche prenant en charge les vecteurs, ou d’une extension de base de données ajoutant la fonction de recherche vectorielle. Le choix doit être guidé par des critères tels que l’échelle, la vitesse, le coût, les besoins de filtrage, la sécurité et la fréquence de modification des documents.

Considérez-le comme faisant partie du moteur de recherche et non simplement comme une boîte de stockage. Un bon filtrage des métadonnées peut faire une grande différence. Une question concernant la politique de remboursement européenne ne devrait pas faire apparaître une politique d’une autre région. Si un utilisateur ne peut consulter que les documents RH de son propre département, le système de recherche doit en garantir le respect avant que quoi que ce soit n’atteigne le modèle.

Cela est important car RAG peut divulguer des informations lorsque le contrôle d’accès est laxiste. On ne doit pas compter sur le modèle pour cacher du contenu restreint après la recherche, et il est plus sûr d’empêcher tout accès au matériel restreint.

Récupération des fragments pertinents

La réponse commence lorsque l’utilisateur pose une question. Le système intègre la question, recherche dans le stockage vectoriel et renvoie les fragments qui correspondent le mieux. Les professionnels appellent cela une recherche top-k, où k indique le nombre de fragments retournés ; top-5 signifie les cinq plus proches.

Choisir la valeur de k relève d’un équilibre délicat. Si l’on récupère trop peu d’informations, la réponse peut omettre des détails importants. Si l’on en récupère trop, la requête devient bruyante, coûteuse ou confuse. Plus de contexte n’est pas toujours mieux, mais un meilleur contexte l’est assurément.

De nombreux systèmes de base commencent par une recherche de similarité vectorielle, qui gère bien les questions liées au sens mais n’est pas parfaite. Certaines requêtes dépendent de mots exacts, d’ID, de noms, de dates, de codes d’erreur ou de formulations juridiques, et dans ces cas, une recherche par mots-clés peut surpasser la recherche vectorielle seule.

C’est pour cette raison que la recherche hybride est populaire. Elle combine une recherche vectorielle avec une recherche par mots-clés sur du texte intégral et fusionne les résultats. Azure AI Search, par exemple, décrit la recherche hybride comme une seule requête qui exécute les deux types de recherche simultanément et fusionne les résultats classés à l’aide de la Reciprocal Rank Fusion. En termes simples, le système dispose de deux voies pour trouver la réponse : par le sens et par les mots exacts.

La recherche vectorielle constitue une première étape judicieuse. Si le public tape fréquemment des codes de produits, des titres de politiques, des formulations juridiques ou des messages d’erreur, envisagez d’adopter une approche hybride.

Création du prompt

Lorsque les fragments ont été récupérés, ils sont intégrés dans le prompt du modèle, qui doit indiquer clairement le contexte, la question de l’utilisateur et ce que l’on attend du modèle. Un prompt RAG simple peut indiquer au modèle de répondre en s’appuyant sur le contexte fourni, de ne se baser que sur les informations qui s’y trouvent, d’indiquer qu’il ne sait pas répondre lorsque le contexte manque d’informations, et de citer le titre ou la section de la source si possible. Les fragments récupérés et la question suivent ensuite.

Ces instructions sont importantes car le modèle possède des connaissances générales propres. Sans directives claires, il peut mélanger les faits obtenus et ses propres hypothèses. Cela est parfois acceptable, mais pour un bot d’assistance, un assistant juridique, un outil médical ou un aide à la prise de décisions, le modèle doit rester fidèle aux éléments dont il dispose.

La documentation d’ingénierie des prompts d’OpenAI décrit le RAG comme l’ajout de contextes pertinents, tirés d’une base de données vectorielle ou d’une recherche de fichiers, à la demande de génération. La formulation est cruciale : elle fait en sorte que le texte obtenu soit présenté comme la source sur laquelle le modèle doit s’appuyer.

Un prompt bien rédigé gère également l’incertitude, en permettant au modèle d’indiquer que les documents fournis ne répondent pas à la question. Cette réponse, bien moins prétentieuse qu’une supposition assurée, est bien plus utile.

Génération de la réponse

Désormais, le modèle de langage rédige la réponse finale, celle que voient réellement les utilisateurs. Elle doit être claire, fondée et suffisamment précise. Il ne faut pas présenter de texte brut extrait, sauf si cela est demandé. Le modèle doit expliquer en langage naturel, mentionner les limites importantes et citer des sources chaque fois que possible.

Un bon exemple : « Les ordinateurs portables reconditionnés doivent être retournés dans un délai de 14 jours suivant la livraison. La politique ne prévoit aucune exception pour les retours après 20 jours, donc, selon cette politique, un retour demandé après 20 jours ne serait pas accepté. » Cela fonctionne car il énonce la règle, l’applique à la situation de l’utilisateur et ne prétend pas qu’une exception existe lorsque la source n’en mentionne aucune.

Les citations ajoutent également de la valeur, car elles permettent aux utilisateurs de vérifier une réponse plutôt que de se fier uniquement au modèle. Rendre les réponses de l’IA traçables constitue l’un des plus grands avantages pratiques du RAG.

Évaluation du pipeline

Un système RAG doit être testé avant que quiconque ne s’y fie. Une erreur fréquente consiste à ne vérifier que la réponse finale. Il est préférable d’évaluer séparément la récupération des informations et leur génération : d’abord s’assurer que le système de récupération a trouvé les extraits appropriés, puis vérifier si le modèle les a utilisés correctement.

Un ensemble d’évaluation simple associe des questions réelles posées par des utilisateurs aux passages sources corrects ainsi qu’aux réponses attendues. Pour chaque question, il faut s’assurer que le document approprié figure parmi les résultats obtenus. Lorsque le bon passage n’atteint jamais le modèle, il est peu probable d’obtenir des réponses fiables.

Ensuite, il convient d’examiner la réponse générée. Reste-t-elle fidèle au contexte ? Ajoute-t-elle des affirmations non étayées ? Répond-elle à la vraie question et cite-t-elle la bonne source ? Lorsque les documents ne suffisent pas, l’auteur admet-il cela ?

Le livre de recettes Claude RAG recommande d’évaluer séparément le pipeline de récupération des informations et le système global, plutôt que de se fier à des impressions vagues quant à la qualité des réponses, un conseil qui vaut la peine d’être suivi même pour de petits projets.

Un cycle d’évaluation de base peut suivre :

• Précision de la récupération, c’est-à-dire si le passage approprié a été trouvé.
• Fidélité, c’est-à-dire si la réponse est étayée par le contexte récupéré.
• Complétude, c’est-à-dire si les détails importants sont présents.
• Qualité des citations, c’est-à-dire si les sources citées sont réellement pertinentes.
• Latence, le temps nécessaire pour obtenir une réponse.
• Cost, les tokens et les appels de récupération utilisés.
• Satisfaction de l’utilisateur, c’est-à-dire si le problème a été résolu.

RAG est rarement parfait dès la première tentative. L’évaluation permet de déterminer où il faut améliorer les choses, que ce soit la segmentation en blocs, les métadonnées, le processus de récupération, les prompts, la réclassification ou les documents sources eux-mêmes.

Où échouent les pipelines de base

La première version d’un pipeline fonctionne généralement suffisamment bien pour être impressionnante, mais aussi suffisamment mal pour être décevante. Problèmes courants :

• Mauvaise segmentation en blocs. Un bloc pertinent est retourné, mais la réponse complète n’y figure pas.
• Bruit dans la récupération des informations. Des passages qui semblent pertinents mais ne répondent pas à la question sont affichés, souvent lorsque la requête est vague, ambiguë ou contient des termes présents dans de nombreux documents.
• Informations obsolètes. Mettre à jour les données est plus simple que de réentraîner le modèle, mais uniquement si la base de connaissances est tenue à jour. Les documents anciens restant dans l’index peuvent encore être récupérés.

Erreurs de métadonnées. L’absence de dates, de versions, de régions ou de permissions permet l’inclusion d’informations techniquement pertinentes mais en réalité inutiles.

Faible méfiance. Le RAG réduit les hallucinations sans pour autant les éliminer. Le modèle peut encore interpréter à tort le contexte, généraliser de manière excessive ou combiner des extraits de façon trompeuse. Le fait d’avoir un fondement concret ne garantit pas la vérité.

Failles de sécurité. L’injection de commandes représente un risque réel dans les applications d’LLM. OWASP la décrit comme une manipulation du comportement du modèle par le biais d’entrées spécialement conçues, y compris celles qui amènent le système à ignorer des instructions ou à divulguer des informations. Dans le RAG, des instructions malveillantes peuvent se trouver à l’intérieur de documents récupérés et non seulement dans les messages des utilisateurs. Une page web, un ticket de support ou un document partagé peut contenir du texte indiquant au modèle d’ignorer des instructions antérieures et de révéler la prompt du système. Traitez tout ce qui est récupéré comme des données, et jamais comme des instructions fiables.

Une architecture simple

Une conception adaptée aux débutants fonctionne en deux étapes. Du côté de l’indexation, les documents sont collectés, nettoyés, divisés en fragments, intégrés sous forme d’embeddings et stockés dans un entrepôt vectoriel avec le texte original et les métadonnées. Du côté de la réponse, la question de l’utilisateur est également intégrée sous forme d’embedding, les fragments les plus pertinents sont récupérés, éventuellement filtrés ou réclassés, puis intégrés dans une instruction destinée au modèle de langage pour qu’il donne une réponse à partir de ce contexte.

En bref : les documents deviennent des fragments, puis des embeddings, qui sont stockés dans un entrepôt vectoriel ; une question devient un embedding de requête, est traitée par le système de récupération pour générer un contexte, et le modèle de langage transforme ce contexte en réponse.

Des frameworks tels que LangChain et LlamaIndex fournissent des outils pour charger des documents, créer des index et des systèmes de récupération, ainsi que pour relier ces systèmes aux modèles de langage. La documentation de LangChain présente la récupération d’informations comme une utilisation de vos propres bases de connaissances via des chargeurs et des entrepôts vectoriels. LlamaIndex envisage le RAG comme un indexation préalable de vos données afin que chaque requête puisse obtenir le contexte pertinent avant l’appel au modèle de langage.

Aucun système complexe n’est nécessaire pour apprendre cela. Un petit prototype ne nécessite que cinq éléments : des documents dans un dossier, un modèle d’embedding, un endroit pour stocker les vecteurs, un système de récupération et un modèle de chat. Ce qui compte, c’est de comprendre chaque étape et de ne pas traiter le pipeline comme une boîte noire.

Ce qui distingue un bon pipeline

Un bon pipeline fait plus que simplement récupérer du texte. Il trouve le texte adéquat, le présente au modèle sous une forme utilisable et fournit une réponse fidèle aux éléments disponibles. Les meilleurs systèmes partagent quelques habitudes : des sources propres et à jour, un découpage minutieux du texte, la conservation des métadonnées, une recherche basée à la fois sur le sens et sur la précision lorsque c’est nécessaire, des instructions claires, des citations, une évaluation distincte de la récupération et de la génération, la protection des données sensibles avant qu’elles n’atteignent le modèle, ainsi que la capacité d’admettre son ignorance.

Un bon RAG est donc bien plus qu’une simple fonctionnalité d’IA. Il combine la gestion des connaissances, la recherche, la conception de produits et la sécurité.

Où aller ensuite

Lorsqu’un pipeline simple fonctionne, plusieurs améliorations sont possibles :

• Ajouter une recherche hybride permettant de rechercher selon le sens et des termes exacts.
• Ajouter une étape de réclassement dans laquelle un deuxième modèle examine et ordonne les fragments récupérés.

Diviser le texte en blocs selon la structure du document et non selon des longueurs fixes.

Réécrire les requêtes vagues pour en faire des requêtes plus claires.

Améliorer les citations en enregistrant les titres des sources, leurs sections et les liens correspondants.

Créer des tableaux de bord pour suivre la qualité au fil du temps.

Les configurations avancées intègrent des agents, une recherche en plusieurs étapes ou via des graphes, des requêtes sur des bases de données structurées, une recherche dans des images et du texte, ou des outils de réclassification adaptés à un domaine spécifique. Des enquêtes récentes indiquent que le domaine évolue vers des systèmes modulaires plutôt que vers des systèmes RAG simples, où la recherche, la génération et l’amélioration constituent des composants distincts et flexibles plutôt qu’un processus unique et fixe. Néanmoins, le flux de travail de base reste la fondation : localiser les preuves pertinentes, les transmettre au modèle, et vérifier que la réponse est cohérente avec ces preuves.

Pourquoi il vaut la peine d’apprendre

RAG a gagné en popularité car il répond à un besoin pratique. Les entreprises, les chercheurs, les développeurs et les équipes stockent déjà des connaissances précieuses dans des documents, des bases de données, des manuels, des tickets et des notes, et un modèle linguistique seul ne peut pas en connaître de manière fiable le contenu. RAG permet au modèle de trouver ces informations.

La méthode est simple : préparer des documents, les diviser, intégrer et stocker leurs parties, récupérer celles nécessaires, puis faire en sorte que le modèle y réponde. La véritable difficulté réside dans les détails, où la qualité des sources, le découpage en fragments, la récupération d’informations, la conception des prompts, l’évaluation et la sécurité jouent tous un rôle important. Un pipeline de base n’est pas encore la forme finale d’un assistant intelligent, mais il reste l’une des approches les plus directes pour obtenir une intelligence artificielle plus utile, à jour et mieux fondée. Plutôt que de demander au modèle d’être un oracle omniscient, RAG lui donne une carte de bibliothèque et lui apprend à utiliser correctement la bibliothèque.