Qu'est-ce que le RAG ? La génération augmentée par récupération expliquée

La génération augmentée par récupération (RAG) est une méthode dans laquelle un système recherche des passages pertinents dans un index de documents externe et les transmet à un modèle de langage avant qu’il ne génère une réponse. Au lieu de dépendre uniquement des poids figés pendant l’entraînement, le modèle peut répondre à partir d’informations privées, internes ou récemment mises à jour.

Un modèle de langage classique ne connaît que les données utilisées pour son entraînement jusqu’à sa date limite de connaissance. Si un utilisateur pose une question sur la politique interne de remboursement de votre entreprise, une spécification d’API récemment publiée ou une fiche de compte mise à jour il y a cinq minutes, le modèle de base ne peut pas connaître la réponse à partir de sa seule mémoire. Le RAG comble cette lacune en associant une étape de recherche à la génération : il récupère d’abord les faits pertinents, puis produit une réponse fondée sur le texte récupéré.

Que signifie la génération augmentée par récupération ?

La génération augmentée par récupération consiste à associer un système de recherche d’information à un modèle de génération de texte afin que sa réponse tienne compte de documents externes récupérés au moment de la requête. Au lieu d’attendre d’un réseau neuronal qu’il mémorise chaque fait dans ses paramètres, le RAG utilise un index de texte externe comme un livre ouvert que le modèle peut consulter avant de répondre.

En général, chaque processus RAG comprend deux phases essentielles :

1. Récupération : lorsqu’un utilisateur soumet un prompt, le système transforme sa question en requête de recherche dans un stockage externe, comme une base de données vectorielle, un index de recherche par mots-clés ou une solution hybride, puis récupère les passages les plus pertinents.
2. Génération : le système insère ces passages dans le contexte du modèle avec la question initiale de l’utilisateur, puis le modèle de langage génère une réponse fondée sur les passages fournis.

Le texte de référence étant récupéré dynamiquement pour chaque requête, il est possible de mettre à jour les connaissances du système en modifiant l’index documentaire, sans réentraîner le modèle sous-jacent. Le RAG est ainsi une méthode courante pour créer des assistants de support, des outils de recherche dans la documentation interne et des outils de questions-réponses spécialisés. Il côtoie des applications créatives où les équipes utilisent des outils dédiés comme AI Studio Video pour la production de médias et des API textuelles pour la récupération de connaissances.

En quoi l’article sur le RAG de 2020 diffère-t-il de la méthode actuelle ?

L’expression « génération augmentée par récupération » provient d’un article publié en 2020 par Patrick Lewis et ses collègues (arXiv:2005.11401), qui associait un modèle séquence à séquence préentraîné à un index vectoriel dense de Wikipedia. Aujourd’hui, les développeurs emploient généralement ce terme pour désigner une chaîne plus simple de construction de prompts. Comprendre les deux aide à saisir pourquoi le « RAG » est décrit de deux façons légèrement différentes dans les articles de recherche et la documentation technique.

L’architecture de Lewis et al. de 2020

Dans l’article original de 2020 et le billet de recherche de Meta AI qui l’accompagne, les auteurs présentaient les modèles de langage comme dotés de deux types de mémoire :

• Mémoire paramétrique : les connaissances stockées dans les poids du réseau neuronal, plus précisément ceux d’un modèle BART séquence à séquence préentraîné.
• Mémoire non paramétrique : les connaissances stockées dans un index vectoriel dense externe d’articles Wikipedia, interrogé par un moteur de récupération neuronal appelé Dense Passage Retrieval (DPR).

Dans ce dispositif de recherche, le moteur de récupération et le générateur étaient entraînés ensemble de bout en bout. L’article proposait deux formulations de l’influence des passages récupérés sur la génération :

• RAG-Sequence : le modèle utilise les mêmes passages récupérés pour générer l’intégralité de la séquence de sortie.
• RAG-Token : le modèle peut utiliser différents passages récupérés pour chaque token généré.

Dans les évaluations de questions-réponses ouvertes présentées dans les tableaux de l’article (arXiv:2005.11401), RAG-Sequence a obtenu un score 44.5 Exact Match sur le jeu Natural Questions, dépassant les références seq2seq uniquement paramétriques et les architectures de récupération et d’extraction testées dans l’étude.

La méthode technique actuelle

Dans le développement d’applications moderne, les équipes entraînent rarement ensemble un moteur de récupération et un générateur. Le « RAG » désigne presque toujours une chaîne exécutée à l’inférence, fondée sur des modèles d’embedding prêts à l’emploi et des API de LLM généralistes :

1. Découper les documents en passages plus petits (chunks).
2. Convertir ces chunks en embeddings vectoriels et les stocker dans un index.
3. Au moment de la requête, récupérer les chunks les plus pertinents.
4. Réordonner éventuellement les résultats pour améliorer leur pertinence.
5. Insérer directement les chunks récupérés dans le prompt et demander au LLM de répondre.

L’architecture neuronale de bout en bout de 2020 comme la chaîne actuelle qui insère des passages dans le prompt portent le nom de RAG. En ingénierie logicielle courante, sauf mention explicite de l’entraînement d’un moteur de récupération avec un modèle seq2seq, c’est la chaîne moderne qui est visée.

Comment fonctionne une chaîne RAG moderne, étape par étape ?

Un système RAG en production répartit son travail entre deux processus distincts : une chaîne d’ingestion hors ligne qui prépare et indexe les documents, et une chaîne de requête en ligne qui s’exécute à chaque question d’un utilisateur. Des guides d’architecture comme les recommandations AWS sur le RAG et le guide RAG du AWS Generative AI Innovation Center décomposent ces étapes en composants que l’on peut ajuster indépendamment.

1. La chaîne d’ingestion (indexation des données)

Avant même qu’un utilisateur n’envoie un prompt, le système doit rendre les documents sources interrogeables :

• Chargement et nettoyage des documents : extraire le texte brut et les métadonnées (titres, URL, horodatages, autorisations d’accès) de PDF, wikis, bases de données ou fichiers Markdown, en supprimant les mises en forme incorrectes et les éléments répétitifs de page.
• Découpage : diviser les documents longs en petits segments afin de récupérer uniquement les passages pertinents plutôt que des manuels entiers. Des chunks trop petits perdent leur contexte et interrompent les idées ; trop grands, ils apportent du bruit sans rapport et augmentent la consommation de tokens. Les équipes prévoient souvent un léger chevauchement entre chunks voisins pour préserver le sens des phrases aux frontières.
• Embedding : faire passer chaque chunk dans un modèle d’embedding qui transforme son texte en vecteur numérique dense représentant son sens sémantique.
• Indexation : stocker ces vecteurs avec le texte brut et les filtres de métadonnées dans une base vectorielle ou un moteur de recherche hybride associant similarité vectorielle et recherche par mots-clés, comme BM25.

2. La chaîne de requête (réponse aux questions)

Lorsqu’un utilisateur pose une question pendant l’exécution, la chaîne de requête assemble le prompt :

• Traitement et embedding de la requête : prendre la saisie de l’utilisateur, éventuellement la reformuler ou l’enrichir pour la clarifier, puis la convertir en vecteur avec exactement le même modèle d’embedding que pour l’ingestion.
• Récupération : rechercher dans l’index les chunks dont les vecteurs sont les plus proches de celui de la requête, souvent en associant recherche sémantique, mots-clés et filtres de métadonnées, par exemple pour limiter les résultats aux documents que l’utilisateur actuel est autorisé à lire.
• Réordonnancement facultatif : faire passer les chunks candidats initiaux dans un modèle de reclassement à encodeur croisé, qui évalue dans quelle mesure chaque passage répond directement à la question et réduit la liste aux meilleurs résultats.
• Assemblage du prompt et génération : insérer les passages les mieux classés dans un modèle de prompt structuré avec la question de l’utilisateur, envoyer l’ensemble au LLM et renvoyer la réponse générée, souvent accompagnée de références aux métadonnées des sources.

Comment le RAG se compare-t-il aux longues fenêtres de contexte et au fine-tuning ?

Le RAG, les longues fenêtres de contexte et le fine-tuning répondent à des aspects différents de la personnalisation des modèles. Les systèmes en production les combinent souvent plutôt que de les considérer comme des choix exclusifs. La bonne approche dépend du besoin : faits évolutifs, compréhension d’un grand volume dans une seule session ou modification du comportement du modèle.

Dimension	Génération augmentée par récupération (RAG)	Longue fenêtre de contexte	Fine-tuning
Objectif principal	Fournir à chaque requête des faits pertinents issus d’un corpus vaste ou évolutif	Permettre au modèle de lire un grand volume de texte dans une requête	Modifier le style, le ton, le format ou le comportement sur une tâche spécialisée
Mise à jour des connaissances	Mettre à jour ou remplacer les documents dans l’index externe	Remplacer les documents bruts insérés dans le prompt	Recueillir de nouveaux exemples et lancer un nouvel entraînement
Effet sur les tokens par requête	Faible à modéré (seuls les chunks récupérés sont envoyés)	Élevé (chaque document reste dans le prompt)	Faible (les connaissances ou le comportement sont intégrés aux poids)
Attribution des sources	Citation simple des chunks récupérés	Possible, mais plus difficile à préciser dans des entrées massives	Difficile ; les poids ne conservent pas de références explicites aux documents
Contrôle d’accès	Appliqué à chaque requête par les filtres de métadonnées de l’index	Filtrage nécessaire avant l’assemblage du prompt	Difficile à isoler ; tout contenu dans les poids peut être divulgué à tout utilisateur

RAG et longues fenêtres de contexte

Les modèles modernes prenant en charge de grandes fenêtres de contexte, il peut être tentant de supprimer la récupération et de coller toute la base de connaissances dans chaque prompt. Cela fonctionne pour quelques documents courts, surtout avec la mise en cache des prompts et un KV cache déjà rempli, pour éviter de retraiter les préfixes répétés depuis le début.

Cependant, lorsque le corpus atteint des milliers de fichiers, placer tout son contenu dans le prompt se heurte à deux obstacles :

1. Coût et latence : envoyer des prompts énormes à chaque échange augmente les dépenses d’API et le délai avant le premier token. C’est pourquoi la récupération sélective reste une stratégie centrale pour réduire les coûts des API d’IA.
2. Dégradation de l’attention : les modèles ne prêtent pas autant d’attention à toutes les parties d’un prompt massif. À mesure que le texte non pertinent s’accumule dans la fenêtre, la précision baisse souvent : c’est le phénomène de dégradation du contexte. Le RAG concentre le prompt sur les seuls passages utiles à la question actuelle.

RAG et fine-tuning

Le fine-tuning met à jour les poids d’un modèle à partir d’exemples sélectionnés. Il est efficace pour faire respecter un schéma de sortie strict, adopter une voix de marque ou apprendre une syntaxe propre à un domaine. Il est peu adapté à l’apprentissage de faits qui changent rapidement.

L’article de Lewis et al. de 2020 (arXiv:2005.11401) a montré l’importance de la mémoire non paramétrique pour les faits changeants grâce à une expérience de remplacement de l’index. Les auteurs ont testé leur modèle avec un extrait de Wikipedia de décembre 2016 et un autre de décembre 2018, sur des questions concernant des dirigeants mondiaux ayant changé entre ces dates :

• Lorsque l’année des questions correspondait à celle de l’index, le modèle répondait correctement à 70% des questions sur les dirigeants de 2016 avec l’index de 2016, et à 68% de celles sur les dirigeants de 2018 avec l’index de 2018.
• Lorsque l’index ne correspondait pas aux questions, la précision tombait à 12% (index de 2018 sur les dirigeants de 2016) et à 4% (index de 2016 sur les dirigeants de 2018).

Le simple remplacement de l’index externe a mis à jour les connaissances factuelles du système sur le monde sans réentraîner un seul poids du modèle.

Quelles sont les limites du RAG ?

Ajouter une récupération à un modèle de langage réduit les suppositions sur des sujets privés ou récents, mais ne supprime pas les hallucinations de l’IA et ne garantit pas des réponses exactes. Un système RAG comportant plusieurs composants, des erreurs peuvent survenir à la recherche comme à la génération :

• Passage pertinent non récupéré : si l’utilisateur formule sa question avec des termes différents de ceux du document source, ou si le découpage a séparé un tableau de son en-tête, le moteur peut ne pas trouver le passage qui contient la réponse. Sans le bon chunk dans le prompt, le modèle travaille à l’aveugle.
• Documents parasites ou périmés : un index dépend de la qualité de ses fichiers. Si la base contient les versions 2023 et 2026 d’un guide d’intégration sans filtrage clair des versions obsolètes, le moteur peut fournir au modèle des instructions dépassées.
• Récupération excessive : récupérer 25 chunks « au cas où » se retourne souvent contre l’objectif. Remplir le prompt de passages vaguement liés dilue la réponse, augmente la latence et peut provoquer une dégradation du contexte où des détails presque pertinents distraient le modèle.
• Injection indirecte de prompt par le texte récupéré : si l’index ingère du contenu externe non fiable, comme des e-mails entrants, des pages publiques ou des tickets soumis par des utilisateurs, un attaquant peut placer des instructions malveillantes dans un document. Une fois récupéré et inséré dans le prompt, ce document peut déclencher une injection de prompt qui détourne le comportement du modèle.
• Contexte ignoré ou mal lu par le modèle : même si le passage exact figure dans le prompt, le générateur peut mal interpréter une négation, mélanger incorrectement deux chunks distincts ou privilégier ses connaissances préentraînées lorsque le passage contredit des connaissances courantes.

Liste de contrôle pour construire un système RAG fiable

Lorsqu’un prototype RAG passe en production, quelques pratiques d’ingénierie rigoureuses évitent les erreurs les plus fréquentes :

• Garder un index à jour et sans doublons : créer des chaînes automatisées qui retirent les documents supprimés, archivent les versions remplacées et associent des horodatages et URL de source clairs à chaque chunk indexé.
• Récupérer moins, mais mieux : au lieu de remplir le prompt de dizaines de résultats peu pertinents, associer recherche hybride (vecteur + mots-clés), filtres de métadonnées et modèle de reclassement afin de ne transmettre au générateur qu’un petit nombre de passages utiles.
• Séparer clairement le texte récupéré non fiable des instructions système : entourer les chunks de délimiteurs structurels explicites, comme des balises XML ou des blocs de documents étiquetés, et demander dans le prompt système de traiter ces blocs uniquement comme des données de référence passives, jamais comme des commandes exécutables.
• Demander au modèle de s’abstenir si le contexte manque : lui demander d’indiquer clairement quand les passages fournis ne suffisent pas pour répondre. Une instruction dans le prompt ne garantit pas qu’il obéira toujours, mais lui donne une solution de repli plus claire que de deviner silencieusement lorsque la recherche échoue.

Questions fréquentes

Faut-il toujours une base de données vectorielle pour le RAG ?

Non. La génération augmentée par récupération exige seulement un moyen de récupérer du texte pertinent avant d’appeler le modèle. Les bases vectorielles sont populaires pour la recherche par similarité sémantique, mais de nombreux systèmes RAG en production utilisent des moteurs classiques de recherche par mots-clés, comme BM25 dans Elasticsearch ou la recherche en texte intégral de PostgreSQL, ou une recherche hybride associant mots-clés et vecteurs.

Le RAG peut-il empêcher complètement un LLM d’halluciner ?

Non. Le RAG réduit les hallucinations dues à des données d’entraînement absentes ou périmées, car il fournit directement le texte de référence au modèle dans le prompt. Cependant, celui-ci peut encore mal lire un passage, combiner incorrectement des faits issus de deux chunks sans rapport ou deviner une réponse si le moteur récupère des documents non pertinents.

Faut-il choisir le RAG ou le fine-tuning pour la documentation interne de mon entreprise ?

Commencez par le RAG si vous souhaitez qu’un modèle réponde à des questions sur des documents internes qui évoluent. Le RAG permet d’ajouter, de modifier ou de supprimer immédiatement des fichiers dans l’index et d’appliquer les droits d’accès de chaque utilisateur au moment de la requête. Le fine-tuning convient mieux à l’apprentissage d’un format, d’un ton ou de processus cohérents.

Sources

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1