Architecture RAG : comment la génération augmentée par récupération résout le plus grand

Le problème d’hallucination que le RAG résout

Les grands modèles de langage présentent un défaut fondamental qui rend leur déploiement en entreprise risqué : ils hallucinent. Demandez à GPT-4 ou Claude le chiffre d’affaires de votre entreprise au troisième trimestre, et il produira avec assurance un nombre potentiellement entièrement inventé. Demandez-lui de citer la politique RH de votre entreprise sur le télétravail, et il génèrera un texte de politique vraisemblable qui n’existe dans aucun document réel. Pour les chatbots grand public, c’est un désagrément. Pour les applications d’entreprise — recherche juridique, informations médicales, reporting financier, conformité — c’est un risque majeur.

La cause profonde est architecturale. Les LLM génèrent du texte en prédisant le token suivant le plus probable, basé sur des schémas appris lors de l’entraînement. Ils ne disposent pas d’une base de données de faits qu’ils peuvent interroger. Ils ne distinguent pas entre l’information qu’ils « connaissent » (schémas dans les données d’entraînement) et l’information qu’ils fabriquent (complétions plausibles qui se trouvent être fausses). Cela les rend peu fiables pour toute application nécessitant une exactitude factuelle sur des informations spécifiques, propriétaires ou en évolution rapide.

La génération augmentée par récupération (RAG, Retrieval-Augmented Generation) répond à ce problème en ajoutant une étape de récupération avant la génération. Au lieu de demander au LLM de répondre uniquement à partir de sa mémoire paramétrique, un système RAG recherche d’abord dans une base de connaissances les documents pertinents, récupère les passages les plus appropriés et les inclut dans la fenêtre de contexte du LLM aux côtés de la question de l’utilisateur. Le LLM génère alors sa réponse sur la base des informations récupérées, réduisant considérablement les hallucinations car la réponse est ancrée dans des documents réels. Le concept a été formalisé pour la première fois dans un article de 2020 par Facebook AI Research (aujourd’hui Meta AI), publié à NeurIPS 2020. En 2025-2026, le RAG est devenu le patron d’architecture IA d’entreprise dominant, avec un marché mondial du RAG évalué à environ 1,9 milliard de dollars en 2025 et projeté à 9,86 milliards de dollars d’ici 2030 selon MarketsandMarkets. Gartner prédit que 70 % des outils d’IA d’entreprise intégreront le RAG d’ici fin 2025.

Les chiffres sur la réduction des hallucinations sont convaincants. Les études montrent que le RAG réduit les hallucinations de 70 à 90 % par rapport aux LLM standard. Une étude a démontré que GPT-4 utilisant des sources évaluées par les pairs avec le RAG a réduit les taux d’hallucination à quasi zéro, contre 6 % sans RAG. À l’échelle de l’industrie, les taux d’hallucination globaux des LLM sont passés de 21,8 % en 2021 à moins de 1 % en 2025, le RAG étant un moteur principal de cette amélioration.

La pile technologique du RAG

Un système RAG en production implique plusieurs composants distincts, chacun avec ses propres choix technologiques et compromis. La première étape est l’ingestion et le découpage des documents : les connaissances de l’entreprise — PDF, wikis, bases de données, emails, messages Slack — doivent être découpées en morceaux suffisamment petits pour tenir dans la fenêtre de contexte du LLM. La meilleure pratique de l’industrie se centre sur 256 à 512 tokens par morceau, avec un chevauchement de 10 à 20 % entre les morceaux adjacents pour préserver le contexte aux frontières. La stratégie de découpage est cruciale : des morceaux trop petits perdent le contexte ; des morceaux trop grands diluent la pertinence. Les approches avancées utilisent le découpage sémantique (découpage sur les frontières thématiques plutôt que par fenêtrage de taille fixe), et la technique de récupération contextuelle d’Anthropic — introduite en septembre 2024 — ajoute un contexte explicatif spécifique à chaque morceau avant l’embedding, réduisant les taux d’échec de récupération de 35 à 49 % selon la configuration.

La deuxième étape est l’embedding : chaque morceau est converti en une représentation vectorielle dense à l’aide d’un modèle d’embedding. Les options principales incluent text-embedding-3 d’OpenAI (lancé en janvier 2024), embed-v4.0 de Cohere (la dernière version multimodale et multilingue), et les alternatives open source comme BGE-M3 de BAAI (supportant la récupération dense, creuse et multi-vecteurs) et E5-Mistral de Microsoft. Ces vecteurs capturent le sens sémantique dans un espace de haute dimension, où les concepts similaires sont positionnés proches les uns des autres. Le choix du modèle d’embedding affecte la qualité de la récupération — les modèles multilingues, les modèles spécifiques à un domaine et les modèles entraînés sur différents objectifs produisent des espaces vectoriels différents avec des forces différentes.

La troisième étape est le stockage et la récupération vectorielle. Les bases de données vectorielles stockent des millions de vecteurs et permettent une recherche de similarité en moins d’une seconde. Les solutions spécialisées incluent Pinecone (qui a levé 100 millions de dollars pour une valorisation de 750 millions de dollars en 2023 et explorait une vente potentielle en 2025), Weaviate, Qdrant (construit en Rust pour des temps de requête inférieurs à 5 ms), Chroma (qui a subi une réécriture en Rust en 2025 pour une amélioration de performance de 4x), et Milvus (conçu pour des milliards de vecteurs à grande échelle). Lorsqu’un utilisateur pose une question, celle-ci est plongée dans le même espace vectoriel, et la base de données renvoie les morceaux de documents les plus similaires. Cette recherche sémantique est fondamentalement différente de la recherche par mots-clés : une requête sur « politique de congés des employés » correspondra à un document intitulé « Directives relatives aux congés annuels et aux absences » même si les mots sont différents, car le sens sémantique est similaire.

L’étape finale est la génération : les morceaux récupérés sont insérés dans le prompt du LLM comme contexte, et le modèle génère une réponse qui synthétise les informations pertinentes. Le prompt indique généralement au modèle de répondre uniquement sur la base du contexte fourni et de reconnaître lorsque le contexte ne contient pas suffisamment d’information. Ce suivi d’instructions, combiné à l’ancrage dans les documents récupérés, produit des réponses à la fois fluides et factuellement fondées.

Quand le RAG fonctionne et quand il échoue

Le RAG n’est pas une solution miracle. Son efficacité dépend de la qualité de chaque composant du pipeline, et un échec à n’importe quelle étape se propage jusqu’à la sortie finale. Le mode de défaillance le plus courant est l’échec de récupération : le système récupère des documents non pertinents ou insuffisamment pertinents, et le LLM génère une réponse basée sur un contexte incorrect. Cela peut se produire lorsque le modèle d’embedding ne capture pas la sémantique spécifique au domaine (terminologie médicale, jargon juridique, noms de produits propriétaires), lorsque les morceaux sont mal construits, ou lorsque la base de données vectorielle contient des informations obsolètes ou contradictoires.

Le problème du « perdu au milieu » est une autre limitation connue. Une recherche de Stanford et UC Berkeley (Liu et al., 2023, publiée dans Transactions of the Association for Computational Linguistics, 2024) a démontré que les LLM accordent moins d’attention aux informations situées au milieu de leur fenêtre de contexte qu’aux informations au début ou à la fin. Dans un système RAG avec plusieurs passages récupérés, le passage le plus pertinent peut être enfoui au milieu du contexte et effectivement ignoré par le modèle. Le reranking — utilisant un modèle cross-encoder pour réordonner les passages récupérés par pertinence avant de les transmettre au LLM — résout partiellement ce problème mais ajoute de la latence et des coûts.

Plus fondamentalement, le RAG fonctionne mieux pour les questions auxquelles on peut répondre en récupérant des passages spécifiques dans une base de connaissances. Il peine avec les questions qui nécessitent un raisonnement sur plusieurs documents, la synthèse d’informations contradictoires ou des déductions logiques en plusieurs étapes. « Quelle est notre politique de remboursement ? » est une excellente question RAG. « Comment nos taux de remboursement ont-ils évolué par rapport aux concurrents au cours des trois dernières années, et quelles implications stratégiques cela a-t-il ? » nécessite des capacités analytiques que la simple récupération ne fournit pas. Les données de l’industrie soulignent le défi : environ 51 % des échecs d’IA d’entreprise en 2025 étaient liés au RAG, souvent parce que les organisations sous-estimaient l’ingénierie requise pour des pipelines de récupération de qualité production.

Schémas avancés : GraphRAG, RAG agentique et auto-correction

L’écosystème RAG a évolué rapidement au-delà du schéma basique récupérer-et-générer. GraphRAG, développé par Microsoft Research et publié en open source en 2024, combine la récupération vectorielle avec des structures de graphe de connaissances. Au lieu de traiter les documents comme des morceaux de texte plats, GraphRAG extrait les entités et les relations pour construire un graphe de connaissances, puis utilise la traversée de graphe conjointement avec la similarité vectorielle pour récupérer l’information. Cette approche excelle pour les questions nécessitant la compréhension des connexions — « Sur quels projets cet employé a-t-il travaillé avec les équipes du bureau de Londres ? » — que la recherche vectorielle plate manquerait.

Le RAG agentique va au-delà de la récupération à requête unique vers le raisonnement en plusieurs étapes. Un agent IA reçoit une question, la décompose en sous-questions, récupère les informations pertinentes pour chaque sous-question, synthétise les réponses intermédiaires et itère jusqu’à avoir suffisamment d’informations pour produire une réponse complète. Une enquête formelle du domaine a été publiée en janvier 2025 (arXiv:2501.09136), et le cadre A-RAG plus récent (février 2026) a introduit des interfaces de récupération hiérarchiques combinant recherche par mots-clés, recherche sémantique et lecture au niveau des morceaux pour une récupération adaptative multi-granularité. Les frameworks comme LlamaIndex et LangChain fournissent les blocs de construction pour les implémentations de RAG agentique, et ce schéma peut traiter les questions analytiques complexes que le RAG basique ne peut pas : l’agent pourrait récupérer des données financières d’une source, une analyse de marché d’une autre et des documents de stratégie interne d’une troisième, les combinant en une réponse cohérente.

Le RAG correctif (CRAG) ajoute une étape de vérification formalisée. Après que le système a récupéré les documents, un évaluateur de récupération léger évalue leur qualité, classant les résultats comme Correct, Incorrect ou Ambigu. Si l’évaluateur détecte une récupération de faible qualité, le système déclenche de manière adaptative des stratégies alternatives — recherche web, récupération élargie ou requêtes plus ciblées — avant la génération. Le Self-RAG va plus loin en demandant au LLM d’évaluer si sa propre réponse générée est fidèle au contexte récupéré, régénérant ou signalant pour révision humaine lorsqu’une hallucination est détectée. Ces schémas réduisent davantage les taux d’hallucination mais augmentent la latence et les coûts de calcul, créant un compromis entre précision et vitesse qui doit être ajusté pour chaque cas d’usage.

Le paysage des bases de données vectorielles et le RAG géré

Le marché des bases de données vectorielles, évalué à 2,55 milliards de dollars en 2025 et projeté pour croître à un TCAC de 22 % jusqu’en 2034, continue de mûrir par consolidation et convergence. Les bases de données vectorielles spécialisées — Pinecone, Qdrant, Milvus, Weaviate — sont en concurrence avec les entreprises de bases de données établies qui ont ajouté des capacités vectorielles. PostgreSQL avec pgvector (et l’extension pgvectorscale) gère les déploiements de taille modérée jusqu’à 50-100 millions de vecteurs de manière compétitive. MongoDB Atlas Vector Search et la recherche kNN d’Elasticsearch intègrent la récupération vectorielle dans les piles d’entreprise existantes. Oracle a introduit Oracle Database 23ai avec support vectoriel natif. AWS a lancé Amazon S3 Vectors pour un stockage optimisé en coûts, affirmant jusqu’à 90 % d’économies par rapport aux bases de données vectorielles traditionnelles tout en supportant des trillions de vecteurs. Pour les entreprises, l’infrastructure RAG est de plus en plus disponible au sein des piles technologiques existantes plutôt que de nécessiter une infrastructure spécialisée séparée.

Les principaux fournisseurs cloud ont également fait du RAG géré un service de première classe. Amazon Bedrock Knowledge Bases fournit un pipeline RAG entièrement géré — de l’ingestion de documents à la récupération et l’augmentation de prompt — avec support pour la récupération multimodale à travers le texte, les images, l’audio et la vidéo. Google Vertex AI Search offre un RAG natif avec des interfaces de chat personnalisables via Vertex AI Agent Builder. Azure AI Search s’intègre étroitement avec Azure OpenAI pour les entreprises ancrées dans l’écosystème Microsoft. Ces services gérés abaissent considérablement la barrière : les organisations n’ont plus besoin de construire et maintenir chaque composant de la pile RAG à partir de zéro, bien que la personnalisation et le fine-tuning nécessitent encore une expertise approfondie.

Sécurité : la surface d’attaque émergente du RAG

À mesure que le RAG devient l’architecture IA d’entreprise par défaut, ses vulnérabilités de sécurité apparaissent plus clairement. Le risque le plus critique est l’empoisonnement de la récupération. PoisonedRAG, présenté à USENIX Security 2025, a démontré que l’injection d’aussi peu que cinq documents soigneusement conçus dans une base de connaissances de millions peut atteindre un taux de réussite d’attaque de 90 %, manipulant le LLM pour qu’il génère des réponses choisies par l’attaquant pour des requêtes ciblées. Contrairement aux attaques d’injection de prompt directes contre le modèle lui-même, l’empoisonnement du corpus cible la base de connaissances — qui est souvent plus facile à compromettre.

L’injection de prompt indirecte via les documents récupérés est désormais considérée comme la vulnérabilité la plus critique dans les systèmes d’IA agentiques. Un attaquant qui peut insérer du contenu dans n’importe quelle source de données alimentant le pipeline RAG — une page Confluence, un document partagé, un email ingéré — peut intégrer des instructions cachées que le LLM peut suivre lors de la génération. Cela est particulièrement dangereux dans les systèmes RAG agentiques où le modèle peut entreprendre des actions (appeler des API, envoyer des messages, modifier des données) basées sur le contexte récupéré.

Le paysage défensif est encore en retard. Les meilleures pratiques incluent des contrôles d’accès stricts sur le contenu de la base de connaissances, la détection d’anomalies au niveau des embeddings pour identifier les documents adversaires, le filtrage des sorties pour détecter les réponses qui dévient des schémas attendus, et la révision humaine pour les sorties à enjeux élevés. Les organisations déployant le RAG en production devraient traiter leur base de connaissances avec la même rigueur sécuritaire qu’elles appliquent à toute base de données contenant des informations sensibles — car dans un système RAG, la base de connaissances façonne directement ce que l’IA dit et fait.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Meta AI / NeurIPS 2020
• Lost in the Middle: How Language Models Use Long Contexts — Stanford / UC Berkeley
• GraphRAG: Unlocking LLM Discovery on Narrative Data — Microsoft Research
• Contextual Retrieval in AI Systems — Anthropic
• Agentic Retrieval-Augmented Generation: A Survey — arXiv, January 2025
• PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation — USENIX Security 2025
• Retrieval-Augmented Generation Market Worth $9.86 Billion by 2030 — MarketsandMarkets
• Vector Database Market Size and Share, 2026-2034 Trends — GMInsights
• LLM Security Risks in 2026: Prompt Injection, RAG, and Shadow AI — Sombra
• Amazon Bedrock Knowledge Bases — AWS
• LlamaIndex RAG Framework — LlamaIndex
• LangChain Agentic RAG — LangChain