Qu'est-ce que le RAG (Retrieval-Augmented Generation)

Remarque : Ce document est une traduction automatique de la version originale anglaise.

Qu'est-ce que le RAG (Retrieval-Augmented Generation)

Imaginez un étudiant passant un examen à livre ouvert. Au lieu de répondre à chaque question de mémoire uniquement, l'étudiant feuillette un manuel, trouve les pages les plus pertinentes, les lit, puis rédige une réponse qui combine ses connaissances mémorisées avec des faits fraîchement consultés. La Retrieval-Augmented Generation (RAG) fonctionne de la même manière pour un grand modèle de langage. Le modèle ne s'appuie pas uniquement sur ce qu'il a mémorisé pendant l'entraînement — il recherche d'abord dans une base de connaissances externe, récupère les documents les plus pertinents et les utilise comme contexte supplémentaire lorsqu'il génère sa réponse.

Cette technique est importante car même les LLM les plus puissants ont une date limite de connaissances, peuvent « halluciner » (produire des affirmations plausibles mais incorrectes) et peuvent manquer de connaissances spécialisées dans un domaine. Le RAG traite ces trois faiblesses à la fois en donnant au modèle l'accès à des sources à jour, spécifiques au domaine et vérifiables chaque fois qu'il répond à une question.

En bref : le RAG est un schéma d'architecture qui combine un système de récupération avec un LLM. Ce n'est pas un type de modèle distinct — c'est une manière de travailler avec des connaissances et un contexte externes.

Comment ça fonctionne

Un pipeline RAG suit une séquence claire en cinq étapes. Comprendre chaque étape vous aide à évaluer si un projet revendiquant le RAG dispose d'une couche de récupération réellement fonctionnelle ou se contente d'envelopper un appel LLM standard.

Étape 1 — Requête utilisateur

Le processus commence lorsqu'un utilisateur soumet une question, une commande ou un prompt. Cette requête est le point de départ de tout ce qui suit. Par exemple, un utilisateur pourrait demander : « Quelles ont été les principales propositions de gouvernance sur Ethereum le mois dernier ? » Le système ne tente pas de répondre uniquement à partir de la mémoire du LLM — il traite la requête comme une instruction de recherche.

Étape 2 — Vectorisation de la requête

La requête textuelle brute est convertie en une représentation numérique appelée embedding — un vecteur de nombres qui capture le sens sémantique de la requête. Cette étape utilise un modèle d'embedding spécialisé (comme text-embedding-ada-002 d'OpenAI ou une alternative open source comme E5 ou BGE). Le vecteur résultant permet au système d'effectuer une recherche sémantique — trouver des documents par le sens plutôt que par correspondance exacte de mots-clés.

Étape 3 — Récupération depuis la base de connaissances

L'embedding de la requête est comparé à une base de données vectorielle (aussi appelée vector store) qui contient des embeddings précalculés de documents, de passages ou de fragments de données. La base renvoie les k éléments les plus sémantiquement similaires. Les bases de données vectorielles courantes incluent Pinecone, Weaviate, Qdrant, Milvus et Chroma.

La qualité de la récupération dépend de plusieurs facteurs :

Stratégie de découpage (chunking) — comment les documents originaux ont été divisés en morceaux plus petits. Des fragments trop grands diluent la pertinence ; des fragments trop petits perdent le contexte. Trouver la bonne taille de fragment est l'une des décisions d'ingénierie les plus impactantes dans un pipeline RAG.
Modèle d'embedding — la précision avec laquelle le sens est capturé dans les vecteurs. Un modèle d'embedding faible conduit à une récupération faible, quelle que soit la base de données.
Classement par pertinence — la recherche renvoie-t-elle des résultats réellement pertinents ou seulement superficiellement similaires ? Certains systèmes ajoutent une étape de re-classement qui utilise un cross-encoder pour rescorer les résultats initiaux.

Étape 4 — Injection du contexte

Les documents récupérés sont combinés avec la requête originale de l'utilisateur en un seul prompt (parfois appelé « prompt augmenté ») envoyé au LLM. Le prompt demande généralement au modèle de répondre à la question en utilisant le contexte fourni et d'indiquer lorsque le contexte ne contient pas assez d'informations.

Étape 5 — Génération par le LLM et sortie

Le LLM lit le prompt augmenté et génère une réponse ancrée à la fois dans ses connaissances pré-entraînées et dans les preuves récupérées. Un système RAG bien conçu peut aussi inclure une couche de citation qui relie des parties de la réponse à des documents sources spécifiques, offrant à l'utilisateur un moyen de vérifier les affirmations.

Étape	Entrée	Sortie	Composant clé
Requête	Texte de l'utilisateur	Requête brute	Interface utilisateur
Embedding	Requête brute	Vecteur de requête	Modèle d'embedding
Récupération	Vecteur de requête	Documents pertinents	Base de données vectorielle
Injection du contexte	Requête + documents	Prompt augmenté	Modèle de prompt
Génération	Prompt augmenté	Réponse finale	LLM

Pourquoi le RAG est important

Le RAG traite trois limitations bien connues des LLM autonomes :

Les hallucinations. Les LLM peuvent produire des réponses assurées mais incorrectes. Le RAG réduit ce risque en ancrant les réponses dans des documents réels. Lorsque le modèle peut se référer à un passage précis, le risque de fabrication diminue significativement.
Les connaissances obsolètes. Un modèle pré-entraîné a une date limite de connaissances. Le RAG permet d'accéder à des données fraîches et continuellement mises à jour — une base de données externe peut être actualisée quotidiennement, voire en temps réel.
La spécificité de domaine. Affiner un LLM pour un domaine étroit est coûteux et chronophage. Le RAG permet à un modèle généraliste de travailler avec des bases de connaissances spécialisées sans réentraînement, rendant le déploiement d'applications spécifiques à un domaine plus rapide et moins cher.

RAG vs fine-tuning

Le RAG et le fine-tuning visent tous deux à améliorer les performances d'un LLM sur des tâches spécifiques, mais ils fonctionnent de manières fondamentalement différentes.

Aspect	RAG	Fine-tuning
Quand les connaissances sont ajoutées	Au moment de l'inférence (à chaque requête)	Au moment de l'entraînement (une fois, puis statique)
Coût de mise à jour	Faible — mettre à jour la base de connaissances	Élevé — réentraîner ou ré-affiner le modèle
Fraîcheur des connaissances	Peut être quasi temps réel	Figée à la date limite d'entraînement
Nécessite une infrastructure d'entraînement	Non	Oui (GPU, datasets, pipeline d'entraînement)
Convient le mieux pour	Rappel factuel, Q&R sur documentation	Style, ton, format, optimisation de tâches étroites
Auditabilité	Élevée — les sources récupérées peuvent être journalisées	Faible — les connaissances sont intégrées dans les poids

En pratique, de nombreux systèmes en production combinent les deux : un modèle affiné fournit le ton et le comportement de tâche appropriés, tandis que le RAG apporte un ancrage factuel à jour.

Schémas RAG avancés

Le pipeline de base en cinq étapes décrit ci-dessus est parfois appelé RAG naïf. À mesure que la technique a mûri, les ingénieurs ont développé des variantes plus sophistiquées :

RAG multi-étapes (itératif). Au lieu de récupérer une seule fois, le système récupère, génère une réponse intermédiaire, identifie les lacunes de connaissances, récupère à nouveau avec une requête affinée, et répète jusqu'à ce que la réponse soit suffisamment complète. Cette approche traite les questions complexes auxquelles une seule passe de récupération ne peut répondre.
RAG agentique. L'étape de récupération est enveloppée dans un framework d'agent IA. L'agent décide quand récupérer, quelle base de connaissances interroger, s'il faut reformuler la requête, et quand il dispose d'assez de contexte pour générer une réponse finale. Ce schéma brouille la frontière entre RAG et agents autonomes.
Recherche hybride. Combiner la recherche sémantique vectorielle avec la recherche traditionnelle par mots-clés (BM25) dans la même étape de récupération. La recherche hybride capture à la fois les correspondances par sens et par termes, améliorant le rappel pour les requêtes contenant des termes techniques spécifiques ou des noms propres.
Graph RAG. Au lieu de fragments de documents plats, la base de connaissances est structurée en graphe de connaissances — entités et relations. La récupération suit les arêtes du graphe plutôt que (ou en plus de) la similarité vectorielle, permettant un raisonnement multi-sauts sur des données structurées. Ces schémas comptent pour l'évaluation : un projet qui décrit un pipeline graph-RAG avec récupération itérative fait une affirmation plus spécifique (et plus difficile à falsifier) qu'un projet qui dit simplement « nous utilisons le RAG ».

Exemples concrets de RAG

Le RAG n'est pas un concept théorique — il alimente certains des produits d'IA les plus utilisés aujourd'hui.

Bing Chat (Microsoft Copilot). Lorsque vous posez une question à Bing Chat, il recherche sur le web, récupère les pages pertinentes et utilise ces pages comme contexte pour la réponse du LLM. Les citations en ligne que vous voyez dans la réponse sont un résultat direct de l'étape de récupération.
Perplexity. Perplexity est construit autour d'une architecture RAG : chaque requête utilisateur déclenche une recherche web, les résultats sont fournis à un LLM, et la réponse inclut des références numérotées aux sources. L'utilisateur peut cliquer pour vérifier chaque affirmation.
Assistants de connaissances d'entreprise. Les entreprises utilisent des systèmes RAG internes pour permettre aux employés d'interroger en langage naturel les politiques RH, la documentation d'ingénierie ou les contrats juridiques. La couche de récupération recherche dans le fonds documentaire interne de l'entreprise plutôt que sur le web ouvert. Ces exemples démontrent que le RAG est une technologie grand public. Lorsqu'un projet d'IA crypto dit « nous utilisons le RAG », la question n'est pas de savoir si le RAG est une vraie technologie, mais si l'implémentation spécifique du projet est solide : quelles données sont récupérées, comment elles sont indexées, et si la qualité de la récupération a été mesurée.

Pourquoi le RAG apparaît dans les projets d'IA crypto

De nombreux projets d'IA crypto utilisent le RAG ou affirment l'utiliser dans leurs architectures. Les cas d'usage courants incluent :

Assistants de documentation — récupérer les docs de protocoles, les livres blancs ou les propositions de gouvernance pour répondre aux questions des utilisateurs sur les règles ou paramètres d'un protocole.
Outils d'intelligence crypto — extraire des données de marché en temps réel, des événements on-chain ou des articles de presse pour générer des résumés d'analyse ou des alertes.
Bases de connaissances pour agents — construire des référentiels structurés que les agents IA peuvent interroger avant d'agir, garantissant des décisions informées par les données les plus récentes.
Ancrage dans les données on-chain — connecter la couche de récupération à des indexeurs blockchain afin que le LLM puisse répondre aux questions sur les soldes de portefeuilles, les historiques de transactions ou les états de smart contracts avec des informations actuelles plutôt qu'avec des instantanés de l'entraînement.

Les valeurs typiques d'AI component dans les fiches projets DecAIHub impliquant des schémas RAG incluent : « 3D AI agents (RAG/memory/LLM catalog) », « AI summaries + crypto intelligence terminal » et « AgentData (real-time data streams for AI agents) ».

Le RAG n'est pas un modèle

Une idée fausse courante consiste à considérer le RAG comme un type de modèle d'IA. Ce n'en est pas un. Le RAG est un schéma d'architecture — une manière de combiner un système de récupération avec un LLM. Le modèle à l'intérieur d'un pipeline RAG peut être GPT, DeepSeek, Mistral ou tout autre LLM. Le composant de récupération peut être une base de données vectorielle, une API de recherche ou un graphe de connaissances structuré.

Dire « nous utilisons le RAG » vous indique comment le système est organisé. Cela ne vous dit pas quel modèle est utilisé, s'il est propriétaire, ni quelle est la qualité de la récupération. Deux projets peuvent tous deux revendiquer le RAG avec des niveaux de sophistication très différents — l'un avec une base de connaissances soigneusement organisée et des embeddings personnalisés, l'autre avec un prototype assemblé à la hâte qui renvoie rarement des documents pertinents.

Ce que le RAG ne prouve pas

Utiliser le RAG ne prouve pas que le LLM sous-jacent est propriétaire ou affiné. Le projet peut appeler une API tierce.
Construire un pipeline RAG ne prouve pas que la qualité de récupération est élevée. La qualité dépend de la base de connaissances, de la stratégie de découpage, du modèle d'embedding et de la pertinence de la recherche.
Avoir une architecture RAG ne prouve pas que les réponses sont exactes. Une récupération médiocre peut fournir un contexte non pertinent, et le LLM peut toujours halluciner.
Mentionner le RAG sur une page d'accueil ne prouve pas que le système effectue réellement de la récupération. Sans preuves Tier-1 — code, diagrammes d'architecture, journaux de démo — l'affirmation reste non vérifiée. Lorsque vous évaluez un projet d'IA crypto qui revendique le RAG, recherchez des précisions : quelle base de connaissances est interrogée, quel modèle d'embedding est utilisé, comment la pertinence est mesurée, et si des métriques de qualité sont publiées.

Où cela apparaît dans les fiches projets DecAIHub

Le RAG est généralement référencé dans le champ AI component — soit directement, soit à travers des descriptions impliquant un pipeline récupération-plus-génération. Le drapeau AI_1 vérifie si l'AI component est décrit avec suffisamment de spécificité. Écrire simplement « RAG » ne suffit pas ; la fiche doit expliquer ce qui est récupéré, d'où, et dans quel but.

Ne pas confondre avec

LLM — le moteur de génération à l'intérieur d'un pipeline RAG. Le RAG ajoute la récupération par-dessus.
L'entraînement — le RAG est un schéma appliqué au moment de l'inférence. Il ne réentraîne pas le modèle ; il augmente le prompt avec un contexte récupéré.
Agent IA — un agent peut utiliser le RAG comme l'un de ses outils, mais le RAG seul ne fait pas d'un système un agent.
Fine-tuning — le fine-tuning ajuste les poids du modèle pendant une phase d'entraînement. Le RAG injecte des connaissances externes au moment de l'inférence sans modifier le modèle.
Couche de récupération / de connaissances — le composant de récupération est une moitié du RAG. Le RAG ajoute l'étape de génération par-dessus la récupération pure.

Questions fréquentes

Quelle est la différence entre le RAG et le fine-tuning ?

Le fine-tuning modifie de façon permanente les poids du modèle en l'entraînant sur un dataset spécialisé. Les nouvelles connaissances deviennent partie intégrante du modèle lui-même. Le RAG laisse le modèle intact et fournit à la place des documents pertinents au moment de la requête. Le fine-tuning est meilleur pour enseigner à un modèle un nouveau style ou format de tâche ; le RAG est meilleur pour garder les réponses ancrées dans des faits frais et vérifiables. De nombreux systèmes en production utilisent les deux — le modèle affiné gère le ton et le format tandis que le RAG fournit un ancrage factuel à jour.

Le RAG rend-il les LLM plus précis ?

Le RAG peut réduire significativement les hallucinations en ancrant la sortie du modèle dans des preuves récupérées. Cependant, la précision dépend de la qualité de la récupération. Si le système de récupération renvoie des documents non pertinents ou obsolètes, le LLM peut produire des réponses fausses avec assurance — désormais étayées par les mauvaises preuves. Le RAG élève le plafond de précision mais ne la garantit pas. Mesurer la précision et le rappel de la récupération est essentiel pour tout déploiement RAG sérieux.

Qu'est-ce qu'une base de données vectorielle ?

Une base de données vectorielle est un magasin de données spécialisé conçu pour stocker et rechercher des vecteurs numériques de haute dimension (embeddings). Lorsqu'un embedding de requête est soumis, la base effectue une recherche par similarité — typiquement avec des algorithmes comme HNSW ou IVF — pour trouver les vecteurs les plus proches. Cela permet la recherche sémantique : trouver des documents par le sens plutôt que par correspondance exacte de mots-clés. Les bases de données vectorielles populaires incluent Pinecone, Weaviate, Qdrant, Milvus et Chroma.

Comment le RAG est-il utilisé dans les projets d'IA crypto ?

Les projets d'IA crypto utilisent le RAG pour connecter les LLM à des données propres à la blockchain : documentation de protocoles, propositions de gouvernance, historiques de transactions on-chain, flux de prix en temps réel et code source de smart contracts. La couche de récupération recherche dans ces sources spécialisées afin que le LLM puisse répondre à des questions spécifiques au domaine avec des données actuelles au lieu de s'appuyer sur des connaissances d'entraînement obsolètes. La qualité de tels systèmes varie largement — de bases de connaissances bien indexées et organisées à des configurations minimales qui récupèrent peu de contexte utile.

Le RAG peut-il fonctionner avec des données on-chain ?

Oui. La couche de récupération d'un pipeline RAG peut se connecter à des indexeurs blockchain, des subgraphs ou des API d'analytique on-chain. Lorsqu'un utilisateur pose une question sur un solde de portefeuille, un historique de transactions ou l'état d'un smart contract, le système de récupération va chercher les données on-chain pertinentes, et le LLM génère une explication lisible par un humain. Les principaux défis sont la latence (les requêtes blockchain peuvent être lentes), le formatage des données (les données on-chain brutes doivent être analysées et découpées pour l'embedding) et la fraîcheur (l'index doit être mis à jour assez fréquemment pour refléter l'état actuel de la chaîne).

Voir aussi

Références externes

Lewis, P. et al. « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. » arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. « Retrieval-Augmented Generation for Large Language Models: A Survey. » arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. « What is RAG? » https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. « Retrieval-Augmented Generation (RAG). » https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. « Retrieval-Augmented Generation (RAG) in Azure AI Search. » https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview