Accueil › Glossaire › RAG (Retrieval-Augmented Generation)

RAG (Retrieval-Augmented Generation)

Le RAG (Retrieval-Augmented Generation) est une architecture IA qui combine un système de recherche documentaire (retrieval) avec un LLM (generation) pour produire des réponses fondées sur des sources vérifiables, réduisant les hallucinations et permettant l’accès à des connaissances actualisées ou propriétaires.

Le problème que le RAG résout

Les LLM comme GPT-4, Claude ou Mistral sont entraînés sur des corpus massifs de texte, mais ils ont trois limites fondamentales :

Connaissances figées. Le modèle ne sait que ce qui était dans ses données d’entraînement. Il ne connaît pas les événements récents, les nouvelles réglementations, ni les documents internes de votre entreprise.

Hallucinations. Quand le modèle ne « sait » pas, il invente. Il génère des réponses plausibles mais factuellement fausses, avec une confiance apparente qui peut tromper l’utilisateur.

Absence de sources. Le LLM produit du texte sans citer ses sources. Impossible de vérifier d’où vient l’information, ce qui est inacceptable dans les domaines régulés (santé, finance, juridique).

Le RAG résout ces trois problèmes d’un coup. Au lieu de se fier uniquement à la mémoire paramétrique du LLM (ses poids), on lui fournit une mémoire non-paramétrique (des documents récupérés en temps réel). Le modèle génère sa réponse en s’appuyant sur ces documents, qu’il peut citer. Les connaissances sont à jour (il suffit de mettre à jour la base documentaire), vérifiables (chaque affirmation est traçable à un document source), et propriétaires (on peut injecter n’importe quelle base de connaissances interne).

Architecture RAG : comment ça marche

Le pipeline RAG standard se décompose en deux phases : l’indexation (préparation des documents) et l’inférence (réponse à une requête).

Phase 1 : Indexation

Avant de pouvoir répondre à des questions, il faut préparer la base documentaire :

1. Collecte des documents. PDFs, pages web, bases de données, e-mails, documentation technique, rapports. Tout contenu textuel est candidat.

2. Chunking (découpage). Les documents sont découpés en morceaux (chunks) de taille adaptée. C’est une étape critique : des chunks trop grands diluent l’information pertinente dans du bruit. Des chunks trop petits perdent le contexte. Les stratégies courantes incluent le découpage par paragraphe, par nombre de tokens (typiquement 256 à 1024), ou par sections sémantiques. Le découpage avec recouvrement (overlap) de 10 à 20 % entre chunks adjacents préserve le contexte aux frontières.

3. Embedding (vectorisation). Chaque chunk est transformé en un vecteur numérique dense (un embedding) qui encode son sens sémantique. Les modèles d’embedding populaires incluent text-embedding-3 (OpenAI), BGE (BAAI), et les modèles de la famille Sentence Transformers (open source). Deux chunks qui parlent du même sujet auront des vecteurs proches dans l’espace vectoriel, même s’ils utilisent des mots différents.

4. Stockage dans un vector store. Les vecteurs sont indexés dans une base de données vectorielle (Pinecone, Weaviate, Milvus, Qdrant, Chroma, pgvector) qui permet une recherche par similarité rapide. Les structures d’index comme HNSW (Hierarchical Navigable Small World) offrent un excellent compromis entre précision et performance.

Phase 2 : Inférence (réponse à une requête)

1. Requête utilisateur. L’utilisateur pose une question en langage naturel.

2. Embedding de la requête. La question est transformée en vecteur avec le même modèle d’embedding que les documents.

3. Recherche par similarité. Le vector store identifie les k chunks les plus proches de la requête (typiquement k=3 à 10) par similarité cosinus ou produit scalaire.

4. (Optionnel) Reranking. Un modèle de reranking (Cohere Rerank, BGE Reranker, cross-encoders) reclasse les chunks récupérés par pertinence fine. Le reranking améliore significativement la qualité, surtout quand le retriever initial renvoie du bruit.

5. Augmentation du prompt. Les chunks récupérés sont insérés dans le prompt du LLM, avec la question originale et des instructions (« Réponds en te basant uniquement sur les documents fournis. Cite tes sources. »).

6. Génération. Le LLM produit une réponse fondée sur les documents récupérés. Les citations permettent à l’utilisateur de vérifier les affirmations.

Les stratégies de retrieval

Dense retrieval (sémantique)

La recherche dense utilise les embeddings pour trouver les documents sémantiquement proches de la requête, même s’ils n’utilisent pas les mêmes mots. C’est la base du RAG moderne. Le retriever capture l’intention et le sens, pas seulement les mots-clés. « Comment réduire mes coûts opérationnels ? » retrouvera des documents parlant d’« optimisation budgétaire » ou d’« efficacité des processus ».

Sparse retrieval (keyword)

La recherche sparse (BM25, TF-IDF) repose sur la correspondance exacte de mots-clés. Elle excelle pour les termes techniques précis, les codes produits, les références réglementaires, et le jargon métier que les embeddings sémantiques peuvent manquer.

Hybrid retrieval

La tendance dominante en 2026. Le hybrid retrieval combine dense et sparse retrieval, typiquement en fusionnant les scores des deux méthodes (Reciprocal Rank Fusion). Cela capture à la fois l’intention sémantique et la précision lexicale. Les déploiements en entreprise, particulièrement dans les domaines juridique, financier et technique, rapportent des améliorations significatives de précision avec l’approche hybride par rapport au dense retrieval seul.

GraphRAG

Le GraphRAG combine la recherche vectorielle avec des graphes de connaissances structurés (taxonomies, ontologies). Au lieu de simplement trouver les chunks les plus similaires, le système navigue dans un graphe de relations entre concepts pour récupérer des informations contextuellement liées. Cette approche atteint des précisions de recherche allant jusqu’à 99 % dans certaines configurations, car elle exploite les relations logiques entre les entités. C’est particulièrement puissant pour les bases de connaissances complexes avec des relations hiérarchiques (réglementations, organigrammes, catalogues produits).

Optimisations avancées du RAG

Query expansion et reformulation

La requête de l’utilisateur n’est pas toujours optimale pour le retrieval. Les techniques de query expansion génèrent plusieurs reformulations de la question (via le LLM lui-même) pour augmenter les chances de retrouver les documents pertinents. HyDE (Hypothetical Document Embeddings) est une approche innovante : le LLM génère d’abord une réponse hypothétique à la question, et c’est cet embeddings de cette réponse hypothétique qui est utilisé pour la recherche, souvent plus efficace que l’embedding de la question seule.

Context filtering et compression

Tous les chunks récupérés ne sont pas également utiles. Les modules de filtrage (CRAG, Self-RAG) évaluent la pertinence de chaque chunk avant de l’injecter dans le prompt. La compression de contexte résume ou élague les chunks pour ne garder que l’information directement pertinente, réduisant le bruit et le coût (moins de tokens = moins cher).

Multi-hop reasoning

Certaines questions nécessitent de chaîner plusieurs récupérations. « Quel est le chiffre d’affaires de l’entreprise dirigée par le CEO mentionné dans le rapport Q3 ? » requiert de retrouver d’abord le rapport Q3, d’en extraire le nom du CEO, puis de chercher le chiffre d’affaires de son entreprise. Les architectures RAG multi-hop (IRCoT, iterative RAG) effectuent plusieurs cycles retrieval-generation pour résoudre ces questions complexes.

RAFT (Retrieval-Augmented Fine-Tuning)

Le RAFT combine les avantages du RAG et du fine-tuning. On crée un dataset synthétique de questions, de documents pertinents et de réponses attendues, puis on fine-tune le LLM sur ce dataset. Le modèle « étudie » le domaine à l’avance, ce qui améliore ses performances par rapport au RAG standard, surtout dans les domaines spécialisés comme la médecine. C’est un compromis entre le coût du fine-tuning et la flexibilité du RAG.

Évaluation d’un système RAG

Évaluer un RAG nécessite de mesurer chaque composant séparément et le système dans son ensemble :

RAGAs (RAG Assessment) est le framework d’évaluation de référence, avec des métriques de faithfulness, answer relevance, context relevance et retrieval recall. L’évaluation est un processus continu : l’analyse régulière des cas d’échec révèle des opportunités d’amélioration (mauvais chunking, embeddings de qualité insuffisante, stratégie de retrieval inadaptée).

Applications du RAG

Chatbots d’entreprise. Le cas d’usage le plus répandu. Un chatbot RAG répond aux questions des employés ou des clients en s’appuyant sur la documentation interne (politiques RH, manuels techniques, FAQ). L’information est toujours à jour (il suffit de réindexer les documents modifiés) et traçable (chaque réponse cite les documents sources).

Recherche juridique et conformité. Les avocats et compliance officers utilisent le RAG pour interroger des bases de réglementations, de jurisprudence et de contrats. Le RAG retrouve les articles pertinents et les synthétise, avec des citations précises. Les études utilisant le RAG en entreprise rapportent des réductions de 30 à 50 % du temps d’édition manuelle.

Support médical. Le RAG interroge la littérature médicale, les guides de bonnes pratiques et les dossiers patients pour aider au diagnostic et à la prise de décision clinique. La fidélité aux sources est critique : une hallucination dans un contexte médical peut avoir des conséquences graves.

Finance et analyse. Génération de rapports de recherche actions, synthèse de résultats trimestriels, analyse de risques basée sur la documentation réglementaire. Le RAG avec des stratégies hybrides (dense + knowledge graph) montre des performances supérieures pour les tâches nécessitant des connaissances structurées comme le résumé de politiques.

Éducation. Des systèmes RAG légers et accessibles sur mobile permettent aux étudiants d’interroger leur matériel de cours (slides, enregistrements, guides d’étude). Des implémentations combinant LLaMA et Milvus fonctionnent sur du matériel modeste, rendant l’IA éducative accessible aux apprenants à faibles ressources.

RAG vs. fine-tuning : quand utiliser quoi

En pratique, le RAG est le choix par défaut pour la majorité des applications d’entreprise. Le fine-tuning est réservé aux cas où le RAG ne suffit pas : besoin d’un style très spécifique, vocabulaire ultra-spécialisé, performances critiques sur un benchmark précis. Le RAFT combine les deux pour le meilleur des deux mondes.

Défis du RAG

Qualité du chunking. Un mauvais découpage des documents dégrade toute la chaîne. Un chunk qui coupe une phrase au milieu ou qui sépare un tableau de sa légende produit un contexte incohérent pour le LLM. Le chunking sémantique (basé sur la structure du document plutôt que sur un nombre fixe de tokens) améliore la situation.

Retrieval noise. Les documents récupérés ne sont pas toujours pertinents. Un chunk qui partage quelques mots-clés avec la requête mais traite d’un autre sujet introduit du bruit. Le reranking et le context filtering sont essentiels pour atténuer ce problème.

Fenêtre de contexte. Même avec des fenêtres de contexte de 128K-200K tokens, injecter trop de documents dilue l’attention du LLM (phénomène « lost in the middle » : le modèle prête moins attention aux informations au milieu du prompt qu’au début et à la fin).

Accès contrôlé. En entreprise, tout le monde ne doit pas voir tous les documents. Le RAG doit respecter les permissions d’accès (ACL) de la base documentaire : un employé junior ne doit pas recevoir des informations issues de documents confidentiels réservés à la direction. C’est un défi d’ingénierie souvent sous-estimé.

Données structurées. Le RAG classique fonctionne bien sur du texte non structuré. L’interrogation de bases de données relationnelles, de tableurs ou de données structurées nécessite des approches spécialisées (Text-to-SQL, API directes) que les systèmes RAG avancés intègrent progressivement.

Évaluation continue. Un système RAG n’est pas un « set and forget ». Les documents changent, les requêtes évoluent, le modèle d’embedding peut ne pas couvrir un nouveau vocabulaire. L’A/B testing, le monitoring des métriques RAGAs et l’analyse d’erreurs sont indispensables en production.

Tendances RAG en 2026

Hybrid retrieval en standard. La combinaison dense + sparse est en train de devenir le default, pas l’exception. Les bases vectorielles comme Weaviate et Qdrant intègrent nativement le hybrid search.

RAG multimodal. Les systèmes récupèrent et exploitent non seulement du texte mais aussi des images, des tableaux, de l’audio et de la vidéo. Un ingénieur de maintenance peut poser une question avec une photo, et le RAG retrouve des schémas techniques et des historiques de pannes similaires.

Scalabilité enterprise. Les systèmes RAG gèrent désormais des corpus de centaines de millions de documents sans dégradation notable de qualité ou de vitesse, grâce aux progrès en recherche approximative de voisins (ANN), indexation hiérarchique et infrastructure distribuée.

RAG agentique. Le RAG s’intègre dans des agents IA qui décident quand récupérer des documents, quels outils appeler, et comment combiner les résultats. Le RAG n’est plus un pipeline statique mais un outil au service d’un agent qui raisonne sur sa stratégie de recherche.

LLM-agnostic. Les architectures RAG les plus robustes sont découplées du LLM : on peut changer de modèle (GPT-4, Claude, Mistral, LLaMA) sans reconstruire le pipeline de retrieval. Cette modularité protège contre le vendor lock-in et permet d’optimiser le rapport qualité/coût.

Verdict

Le RAG est le pattern architectural le plus important pour les applications LLM en entreprise. Il transforme un LLM « intelligent mais amnésique » en un système de connaissances fiable, à jour et vérifiable. Si vous déployez un LLM dans un contexte professionnel (chatbot, assistant, moteur de recherche interne), le RAG n’est pas optionnel : c’est le socle de crédibilité de votre système.

Le RAG a mûri considérablement entre 2023 et 2026. Ce qui était un prototype fragile (chunking naïf, retrieval dense seul, pas de reranking) est devenu une architecture de production robuste (hybrid retrieval, GraphRAG, reranking, context filtering, évaluation continue). Les outils (LangChain, LlamaIndex, Haystack) et les bases vectorielles (Pinecone, Weaviate, Qdrant) sont matures et bien documentés.

Conseil pratique : commencez simple (chunking par paragraphe, un embedding standard, un vector store hébergé, pas de reranking), mesurez avec RAGAs, identifiez les points de défaillance, et optimisez itérativement. Les optimisations prématurées (GraphRAG, multi-hop, RAFT) ne servent à rien si votre chunking de base est mauvais.