16 architectures RAG comparées : quel modèle convient à quel problème

Les chatbots qui affirment des faits inventés, oublient tout entre les messages ou échouent à trouver le document approprié souffrent généralement du même problème de base : un pipeline de récupération conçu de manière trop simpliste pour la tâche. Il existe seize architectures RAG, allant du pipeline de récupération le plus simple aux systèmes fédérés respectueux de la vie privée, chacune corrigeant une faiblesse spécifique. Ce qui suit explique en quoi consiste chacune d’elles, dans quels cas elles sont adaptées et ce qui les distingue des autres.

Les trois problèmes à l’origine de RAG

Les grands modèles de langage sont impressionnants, mais trois défauts fondamentaux en font des outils peu fiables dans les applications réelles.

Premièrement, l’hallucination. Un modèle affirme des informations fausses avec assurance, et ce non pas occasionnellement mais régulièrement, car il n’a pas conscience de ce qu’il ignore. Deuxièmement, la date de fin de formation : chaque modèle est figé à la fin de son entraînement et ne connaît rien de ce qui s’est produit par la suite. Troisièmement, l’ignorance des données privées. Les documents internes, les bases de données de produits et les contrats clients n’ont jamais fait partie de son entraînement.

RAG résout ces trois problèmes en fournissant au modèle un répertoire de documents réels avant qu’il ne réponde. Comparez les deux comportements. Sans récupération de données :

Without RAG:
  User: "What's our refund policy?"
  LLM:  "I believe you offer a 14-day return..." (guessing)

Et avec cela :

With RAG:
  User: "What's our refund policy?"
  → Step 1: Search internal docs → Finds: "Refunds within 30 days..."
  → Step 2: LLM reads the doc and answers accurately
  LLM:  "Your refund policy allows returns within 30 days..."

Le concept est simple et les résultats sont convaincants, bien que le système devienne de plus en plus complexe à mesure que les cas d’usage augmentent. Le processus en quatre étapes qui sous-tend chaque variante est l’indexation, la récupération, l’augmentation et la génération.

Seize modèles répartis en quatre niveaux

En classant les modèles en fonction de leur impact dans le monde réel, on obtient quatre niveaux. Le premier couvre ce dont ont besoin environ 80 % des systèmes en production, tandis que les niveaux suivants traitent de problèmes spécialisés.

Niveau 1 : à connaître absolument

1. RAG standard, la base

Niveau de difficulté : débutant. Idéal pour ceux qui commencent. Chaque projet RAG commence ici, et cette approche comporte quatre étapes :

1. Indexation : diviser les documents en fragments, les transformer en embeddings et les stocker dans une base de données vectorielle.
2. Récupération : encoder la requête de l’utilisateur et rechercher des fragments similaires.
3. Augmentation : intégrer les fragments récupérés dans le prompt.
4. Générer : le LLM répond à partir de ce contexte réel.

La boucle principale tient en environ dix lignes :

# The core loop in ~10 lines
query_embedding = embed(user_query)
relevant_docs = vector_store.search(query_embedding, top_k=5)
context = "\n".join(relevant_docs)
prompt = f"Answer using this context:\n{context}\n\nQuestion: {user_query}"
answer = llm.generate(prompt)

C’est simple, il gère la plupart des cas d’usage réels, et tout le reste s’y base. L’utilisez pour créer votre premier bot de réponse aux questions à partir de documents d’entreprise, de PDF, de tickets de support ou de toute base de connaissances statique.

2. RAG hybride : la plus grande amélioration en termes de qualité

Niveau de difficulté : débutant. Idéal lorsque la qualité de la récupération des informations est importante. La recherche sémantique via des embeddings manque les correspondances exactes de mots-clés, tandis que la recherche par mots-clés avec BM25 néglige le sens ; donc la récupération hybride combine les deux méthodes.

User: "React useState hook"
→ Semantic search finds: "state management in React components"
→ BM25 finds: docs with exact string "useState"
→ Hybrid (RRF fusion): gets the best of both

La Fusion de rangs réciproques (RRF) combine les deux listes classées sans avoir à normaliser leurs scores, ce qui en fait une méthode élégante et efficace. De nombreuses équipes rapportent des améliorations de précision allant de 10 à 20 pour cent rien qu’avec ce changement. Elle convient à tout système de production, en particulier à la documentation de code, aux manuels techniques et aux documents juridiques, où les termes exacts et leur signification sont tous deux importants.

3. RAG de récupération contextuelle, conçu pour le dialogue

Niveau de difficulté : intermédiaire. L’utiliser une fois que des questions complémentaires apparaissent. Une erreur fréquente consiste en ceci : quelqu’un demande des informations sur le plan Premium puis demande son prix. Le RAG standard cherche des expressions comme « it cost » et ne trouve rien d’utile. Cette version réécrit la requête en utilisant l’historique de la conversation avant de rechercher.

User turn 1: "Tell me about the Premium plan"
User turn 2: "How much does it cost?"

Before search, rewrite → "How much does the Premium plan cost?"
Now retrieve → finds the pricing document ✓

Cette étape de réécriture, souvent appelée contextualisation de la requête, est essentielle dans tout chatbot à plusieurs échanges, car la conversation se désintègre dès que quelqu’un utilise un pronom. Elle est indispensable si les utilisateurs peuvent poser des questions supplémentaires.

Niveau 2 : avantage concurrentiel

4. Agentic RAG, la tendance forte de 2025 et 2026

Difficulté : intermédiaire. Idéal lorsque votre bot doit faire plus que simplement effectuer des recherches. Le RAG standard ne récupère que des documents, tandis que l’Agentic RAG fournit au modèle un ensemble d’outils lui permettant de choisir parmi eux.

User: "What was NVDA's stock return last quarter vs its historical average?"

Agentic RAG decides:
  → Use web_search tool for current stock data
  → Use calculator tool for return calculation
  → Use document_retrieval tool for historical reports
  → Synthesize all three into one answer

L’agent suit le modèle ReAct, en raisonnant et en agissant : il réfléchit à ce qu’il doit faire, l’exécute, observe le résultat et réfléchit à nouveau. Cela revient à planifier et à récupérer des informations en boucle. Ce modèle convient aux assistants financiers, aux outils de recherche et aux outils de développement, là où plusieurs sources de données ou des informations en temps réel sont impliquées.

5. Self-RAG, pour les cas où les erreurs sont inacceptables

Difficulté : avancée. Idéale lorsque la précision est cruciale. Un contrôle de qualité est intégré au processus lui-même, et le système ne répond pas aveuglément après la récupération des informations. Il passe par quatre étapes de vérification. L’étape de récupération détermine si une récupération est même nécessaire pour cette requête. L’étape de pertinence vérifie si le document obtenu est réellement pertinent. L’étape de fidélité s’assure que la réponse reste conforme aux faits récupérés, tandis que l’étape d’utilité évalue si la réponse est utile. L’échec à l’une de ces étapes signifie que le système doit récupérer à nouveau les informations, les modifier ou refuser de répondre. Les systèmes médicaux, l’IA juridique et les conseillers financiers constituent des domaines naturels d’application, partout où une réponse erronée peut causer des dommages réels.

6. HyDE RAG, le pont lexical

Difficulté : avancée. Idéale lorsque les utilisateurs parlent différemment de vos documents. HyDE signifie Hypothetical Document Embeddings. Imaginez qu’un utilisateur demande pourquoi les objets tombent, tandis que les documents parlent de l’accélération gravitationnelle de 9,81 m/s². Les deux ne partagent presque aucun vocabulaire, ce qui fait que une recherche par embedding risque d’échouer. La astuce de HyDE consiste à générer d’abord une réponse fictive avant de procéder à la recherche avec celle-ci.

User: "Why do things fall down?"
→ LLM generates hypothesis: "Objects fall due to gravitational force..."
→ Search with the hypothesis (technical vocabulary)
→ Find the actual document about gravitational acceleration
→ Answer using the real document

Aucune formation n’est nécessaire et il fonctionne immédiatement avec n’importe quel LLM. Il convient aux produits destinés aux consommateurs où des utilisateurs occasionnels consultent des documents techniques.

Niveau 3 : spécialistes à fort impact

7. Graph RAG, pour le raisonnement relationnel

Niveau de difficulté : intermédiaire. Idéal lorsque vous devez répondre à la question de la relation entre X et Y. La recherche vectorielle permet de trouver des documents similaires, mais elle ne peut pas répondre à des questions comme celles concernant les entreprises liées à une personne donnée via au moins deux membres du conseil d’administration, ce qui exige une exploration du graphe. Graph RAG crée un graphe de connaissances à partir des documents, avec des entités en tant que nœuds et des relations en tant qu’arêtes, et les requêtes parcourent ce graphe.

Text: "Dr. Chen collaborated with Dr. Patel on a 2022 study funded by NIH."

Graph nodes: Dr. Chen, Dr. Patel, 2022 study, NIH
Graph edges: COLLABORATED_WITH, FUNDED_BYQuery: "Who funded Dr. Chen's work?" → traverse: Chen → study → NIH

Le respect des réglementations, la gestion des connaissances, la littérature scientifique et les réseaux organisationnels en bénéficient le plus.

8. RAG à mémoire augmentée, un bot qui se souvient de vous

Niveau de difficulté : intermédiaire. Idéal lorsque un chatbot doit se souvenir de ses utilisateurs entre les sessions. Avec un bot standard, chaque conversation commence à zéro. Cette version ajoute trois types de mémoire : une mémoire de conversation pour le chat en cours, une mémoire sémantique pour des informations sur l’utilisateur telles que ses préférences en matière d’explications techniques, et une mémoire épisodique pour les sessions précédentes, comme une question posée il y a deux semaines sur un sujet donné.

user_profile = memory.get_user_facts(user_id)
recent_context = memory.get_recent_conversations(user_id, k=3)
answer = rag_with_context(query, user_profile, recent_context)
memory.update(user_id, query, answer)

Les applications de tutorat, les bots de succès client et les assistants à la productivité personnelle en tirent le plus de bénéfices.

9. RAG modulaire : échanger n’importe quelle partie sans réécrire

Niveau de difficulté : intermédiaire. Idéal lorsque vous devez itérer rapidement. Il s’agit d’une philosophie architecturale selon laquelle chaque composant du pipeline peut être remplacé indépendamment. Passer de FAISS à ChromaDB ne nécessite qu’une seule ligne de code, et tester BM25 contre des systèmes de recherche densifs ne requiert aucun refactoring.

Standard RAG:   [fixed retriever] → [fixed reranker] → [fixed LLM]

Modular RAG:    [pluggable retriever] → [pluggable reranker] → [pluggable LLM]
                     ↑ swap anytime         ↑ swap anytime        ↑ swap anytime

Les équipes qui expérimentent activement, qui étudient les configurations, ainsi que tout projet dont l’ensemble technologique est censé évoluer, constituent ce public.

10. RAG spécifique à un domaine, conçu pour une industrie

Difficulté : avancée. Choisissez-la pour la médecine, le droit ou la finance. L’abréviation MI signifie attaque cardiaque pour un cardiologue, mais un chatbot dépourvu de connaissances spécialisées la comprend comme l’État du Michigan. Le RAG générique échoue dans les domaines spécialisés, et ce non pas à cause d’une mauvaise récupération d’informations. Le système ne parvient tout simplement pas à saisir le jargon, les exigences réglementaires ou les contraintes de sécurité. Trois éléments font la différence : un vocabulaire sectoriel comprenant les termes, abréviations et synonymes propres au domaine ; des règles de conformité telles que l’ajout de mentions légales et la citation des sources à chaque fois ; ainsi que des mécanismes de sécurité, comme le refus de proposer des doses spécifiques et l’orientation de l’utilisateur vers un professionnel. Les applications typiques incluent le soutien à la prise de décision clinique, la recherche juridique, l’analyse financière et le suivi de la conformité.

11. RAG amélioré, trois sources et une réponse

Niveau de difficulté : avancé. Idéal lorsque des données structurées et non structurées doivent être utilisées ensemble. Une seule requête combine des bases de données SQL ou autres structurées pour obtenir des chiffres précis, des graphes de connaissances pour représenter les relations, et des embeddings de documents pour le contexte narratif.

Query: "Tell me about the Mars Exploration Program"

→ SQL: "Mars: 1.52 AU from sun, 687-day orbit"
→ Graph: Mars → explored_by → Curiosity Rover, Perseverance
→ Text: "Mars is the fourth planet... known as the Red Planet..."→ Fused Answer: Combines all three for comprehensive, expert-level response

Les outils de recherche scientifique, les plateformes d’analyse financière et les bases de connaissances d’entreprise contenant des types de données variés en tirent profit.

12. RAG récursif ou à plusieurs étapes, pour les questions complexes

Niveau de difficulté : avancé. Choisissez-le lorsque une seule recherche ne suffit pas à répondre à la question. Certaines questions exigent une chaîne de connaissances. Comprendre comment l’invention du transistor a conduit à l’IA moderne nécessite au moins cinq étapes : transistor, circuit intégré, CPU, GPU, apprentissage profond, LLMs. Le RAG récursif récupère les informations, les analyse, puis les récupère à nouveau.

Round 1: Retrieve about transistors → learn about miniaturization
Round 2: Retrieve about integrated circuits → learn about computing power
Round 3: Retrieve about GPUs → learn about parallel processing
Round 4: Retrieve about deep learning → learn about compute requirements
Round 5: Synthesize the full chain into a coherent answer

Les assistants de recherche, les outils académiques, l’analyse stratégique ainsi que toute question nécessitant plusieurs étapes de traitement l’exigent.

Niveau 4 : cas d’usage spécialisés

13. ODQA RAG, répondre à n’importe quelle question

Niveau de difficulté : intermédiaire. Idéal lorsque la base de connaissances est vaste et ouverte. La réponse à des questions dans des domaines variés repose sur RAG à grande échelle, couvrant la science, l’histoire, la géographie et la culture. Le défi ne réside pas dans la qualité de la récupération des informations, mais plutôt dans la gestion de l’ampleur des données et dans la capacité à reconnaître lorsque la réponse est inconnue. ODQA intègre une évaluation de la fiabilité, de sorte que lorsque les documents récupérés ne fournissent pas de bonne réponse, le système admet son manque de certitude sans inventer de réponses. Les assistants polyvalents, les bots de connaissances générales, les plateformes de recherche et les bases de connaissances internes interdisciplinaires l’utilisent.

14. RAG multimodal, texte, images et audio ensemble

Difficulté : avancée. Idéale lorsque la base de connaissances comprend des images, des graphiques ou de l’audio. La plupart des systèmes RAG ne gèrent que du texte, or les connaissances réelles existent également sous forme de diagrammes anatomiques, de photos de produits, d’enregistrements et de graphiques. Un système multimodal crée un espace d’embedding partagé entre les différentes modalités, permettant ainsi à une requête textuelle de trouver une image et à une requête visuelle de trouver un document.

User (text): "Show me the anatomy of the heart"
→ Retrieves both: text descriptions AND anatomical diagrams
→ Response includes both text explanation and relevant image

L’éducation médicale, les catalogues de produits, les plateformes d’e-learning et les archives médiatiques sont des applications adaptées.

15. Streaming RAG, connaissance en temps réel

Niveau de difficulté : intermédiaire. Idéal lorsque les informations changent toutes les quelques minutes. Une question posée à 9 heures du matin puis à 11 heures du matin mérite des réponses différentes chaque fois que les données sous-jacentes ont changé. Le streaming RAG maintient une base de connaissances constamment mise à jour, en indexant de nouveaux documents au fur et à mesure de leur arrivée.

Time 9:00 AM: "What's happening with NVDA?"
→ Retrieves this morning's earnings report

Time 11:30 AM (after news breaks): "What's happening with NVDA?"
→ Retrieves the breaking news from 11:15 AM

Les assistants aux nouvelles financières, les bots de support en direct, ainsi que les tableaux de bord de surveillance d’événements et d’opérations s’appuient sur cette technologie.

16. RAG fédéré, privacité avant tout et sources multiples

Difficulté : avancée. Idéal lorsque les données ne peuvent pas quitter leur source. Il résout un conflit fondamental dans l’intelligence artificielle d’entreprise : plusieurs propriétaires de données souhaitent un système partagé, mais aucun ne veut partager des données brutes. Les hôpitaux qui contribuent à un assistant médical en sont un exemple typique, car les dossiers patients ne peuvent pas être centralisés. Chaque source utilise son propre système de récupération local, les requêtes sont envoyées à toutes les sources en même temps, et seuls les extraits récupérés, jamais les données brutes, parviennent au système central.

Central Query: "What's the survival rate for treatment X?"

→ Hospital A retriever: returns relevant anonymized snippets
→ Hospital B retriever: returns relevant anonymized snippets
→ Hospital C retriever: returns relevant anonymized snippets
→ Central LLM synthesizes — never saw raw patient recordsResult: HIPAA/GDPR compliant, collaborative AI

Les réseaux de soins de santé, les consortiums financiers, les bases de données juridiques ainsi que tout système impliquant plusieurs organisations ayant des exigences en matière de gouvernance des données sont visés.

Ordre de mise en place mois par mois

Tous les seize éléments ne sont pas nécessaires dès le premier jour. La plupart des systèmes de production se développent progressivement.

Month 1:  Standard RAG           ← Get something working
Month 2:  + Hybrid RAG            ← Biggest retrieval quality win
Month 3:  + Contextual Retrieval  ← Multi-turn conversations work now
Month 4:  + Self-RAG              ← Stop hallucinations
Month 5:  + Agentic capabilities  ← Tools beyond just search

This covers 80-90% of production RAG needs.

Combinaison de modèles

Les systèmes de production mélangent presque toujours plusieurs modèles. Quelques exemples :

• Un chatbot d’entreprise combine les modèles Standard, Hybrid, Contextual et Memory pour des conversations à plusieurs tours, une bonne récupération d’informations et une personnalisation efficace.
• Un assistant médical utilise les modèles Domain-Specific, Self-RAG et Enhanced, car l’exactitude est cruciale et des données structurées sont impliquées.
• Un outil de recherche associe les modèles Agentic, Hybrid et Recursive pour répondre à des questions complexes, impliquant plusieurs étapes et outils.
• Le service client combine les modèles Standard, Contextual et Streaming pour assurer des suivi et des mises à jour en temps réel.
• La recherche juridique emploie les modèles Domain-Specific, Graph et Hybrid pour analyser les relations entre entités et fournir des citations précises.
• Un analyseur de nouvelles utilise les modèles Streaming, ODQA et Multi-Modal pour traiter des données en temps réel, des sujets variés et des images.

Un choix rapide

Pour un premier bot de questions-réponses sur des documents, commencez par Standard RAG. Pour une meilleure recherche en environnement de production, ajoutez Hybrid. Un chatbot à plusieurs échanges nécessite Contextual Retrieval, tandis qu’un bot qui utilise des outils ou des API a besoin de la version agentic. Un travail exigeant en matière de précision dans le domaine médical ou juridique requiert Self-RAG, et les utilisateurs occasionnels confrontés à des documents techniques optent pour HyDE. Les questions relationnelles exigent Graph RAG, un assistant personnalisé pour Memory-Augmented, des expérimentations avec différentes architectures pour Modular, et des domaines réglementés pour Domain-Specific. Les données mixtes structurées et non structurées conviennent à Enhanced RAG, les questions à plusieurs étapes à Recursive RAG, et les Q&A polyvalents à ODQA. Les images et l’audio nécessitent Multi-Modal, les données en temps réel exigent Streaming, et les configurations multi-organisations sous HIPAA ou GDPR requièrent Federated.

Exécution des exemples

Chaque implémentation est conçue pour être exécutée directement : clonez un répertoire, installez les dépendances nécessaires, configurez une clé API d’OpenAI et commencez avec le premier modèle.

# Clone the repo
git clone https://github.com/Manjunadh86/RAG-Materials.git
cd RAG-Materials

# Install dependencies
pip install -r requirements.txt# Set your OpenAI API key
export OPENAI_API_KEY="sk-your-key-here"# Run your first RAG system
cd 01-Standard-RAG
python hands_on.py

Chaque module contient un README qui explique le concept, l’architecture et les cas d’usage, ainsi qu’un script exécutable pour le modifier, avec des commentaires à chaque étape.

RAG évolue rapidement. Les systèmes agents deviennent de plus en plus performants, la récupération multimodale se perfectionne, et les approches fédérées gagnent en importance à mesure que les exigences de gouvernance de l’IA se renforcent. La meilleure façon d’apprendre RAG est de le développer soi-même.