Architecture RAG
Modular RAG
Chaque composant est un module indépendant et interchangeable. La philosophie LEGO appliquée au pipeline RAG.
Mis à jour en avril 2026 - Génération 2024-2025
Qu'est-ce que le Modular RAG ?
Le Modular RAG, formalisé par Gao et al. (arXiv:2407.21059, 2024), dépasse le pipeline linéaire de l'Advanced RAG en décomposant le système en modules indépendants et opérateurs interchangeables. Chaque module expose une interface typée (inputs/outputs) et peut être remplacé, testé ou optimisé sans affecter le reste du pipeline.
L'architecture s'organise en trois niveaux : Module (L1) pour les grandes fonctions (Indexing, Retrieval, Generation), Sous-module (L2) pour les variantes (query expansion, reranking) et Opérateur (L3) pour les implémentations concrètes (BM25, HyDE, cross-encoder). Cette taxonomie permet de composer des pipelines arbitrairement complexes - linéaires, conditionnels, parallèles ou itératifs.
En 2026, le Modular RAG est l'architecture de choix pour les systèmes enterprise multi-domaines, les équipes qui itèrent rapidement sur leurs composants, et les cas d'usage qui nécessitent du routing conditionnel ou du raisonnement multi-hop. Les benchmarks FlashRAG (WWW 2025) montrent des gains de +22 % (Ret-Robust sur NQ) à +54 % (RECOMP sur 2WikiMQA) par rapport au RAG standard selon la combinaison de modules choisie.
Composez votre pipeline modulaire
Assemblez vos modules pour visualiser le pipeline résultant, puis évaluez la maturité modulaire de votre système actuel.
Constructeur de pipeline modulaire
Assemblez vos modules pour composer votre pipeline. Les modules grisés sont obligatoires.
Pipeline : 3 modules - Niveau : Minimal
845 ms
Latence estimée
8/10
Testabilité
6
Complexité
Latence hors réseau. Testabilité = facilité de tester le module en isolation. Complexité = effort d'intégration cumulé.
Checklist de maturité modulaire
8 questions pour évaluer si votre pipeline RAG est prêt pour l'approche modulaire.
1.Pouvez-vous remplacer votre retriever (ex: BM25 → hybrid) sans toucher au reste du pipeline ?
2.Testez-vous chaque composant (chunking, retrieval, reranking, generation) indépendamment ?
3.Les paramètres de chaque module (chunk size, top-K, modèle de reranking) sont-ils configurables sans modifier le code ?
4.Avez-vous des métriques par module (latence retrieval, score reranking, tokens generation) ?
5.Plusieurs personnes peuvent-elles travailler sur différents modules en parallèle sans conflit ?
6.Le pipeline s'adapte-t-il à la complexité de la question (routing conditionnel) ?
7.Évaluez-vous automatiquement la qualité (RAGAS ou équivalent) dans votre CI/CD ?
8.Pouvez-vous revenir à une version précédente d'un module spécifique sans rollback complet ?
Répondez aux 8 questions restantes pour obtenir votre verdict.
Les 6 modules standards (taxonomie Gao et al.)
Chaque module encapsule une responsabilité unique derrière une interface stable. Les opérateurs sont les implémentations concrètes, interchangeables à volonté.
Indexing
Ingestion et structuration
Point d'entrée du pipeline. Le module d'indexing découpe les documents, attache des métadonnées (source, date, section) et organise la structure (hiérarchique, knowledge graph, small-to-big). En Modular RAG, le chunking est un opérateur remplaçable : vous pouvez passer d'un chunking fixe à un chunking sémantique sans toucher aux modules suivants.
Opérateurs : Sliding Window, Metadata Attachment, Hierarchical Index, KG Index
Pre-retrieval
Transformation de la query
Avant le retrieval, la query utilisateur est enrichie ou transformée. Multi-query génère plusieurs reformulations pour couvrir plus d'angles. HyDE produit une réponse hypothétique pour combler le gap sémantique. Sub-query décompose les questions complexes en sous-questions indépendantes. Chaque opérateur est interchangeable et testable isolément.
Opérateurs : Multi-Query, Sub-Query, HyDE, Step-back Prompting, Rewrite
Retrieval
Recherche de documents
Le module de retrieval encapsule la stratégie de recherche derrière une interface standardisée. Qu'il s'agisse de BM25, dense, hybrid ou ColBERT, le reste du pipeline ne voit que l'interface : une query en entrée, une liste de documents scorés en sortie. C'est ce découplage qui permet le swap et l'A/B testing.
Opérateurs : Sparse (BM25), Dense (BGE, GTE), Hybrid RRF, ColBERT
Post-retrieval
Filtrage et reranking
Après le retrieval, le module post-retrieval affine les résultats. Le reranking cross-encoder reclasse par pertinence fine. La compression élimine les passages non pertinents. Le MMR diversifie. En Modular RAG, ces opérateurs se composent : rerank → compress → MMR, ou toute autre combinaison selon le besoin.
Opérateurs : Cross-encoder Rerank, LLMLingua, Selective Context, MMR
Orchestration
Routing et scheduling
Le module d'orchestration décide du chemin que prend chaque requête dans le pipeline. Un routeur classifie la complexité de la question et sélectionne le pattern adapté : linéaire pour les questions simples, itératif pour le multi-hop, branching pour le multi-source. C'est le cerveau du pipeline modulaire.
Opérateurs : Metadata Routing, Semantic Routing, LLM Judge, Rule Judge
Generation + Evaluation
Réponse et contrôle qualité
Le module de génération produit la réponse finale. En Modular RAG, il est couplé à un module d'évaluation qui vérifie automatiquement la faithfulness, la relevancy et la context precision (RAGAS). Si la qualité est sous le seuil, le pipeline peut itérer (pattern loop) ou déclencher un fallback.
Opérateurs : LLM Generation, RAGAS, Knowledge-base Verification
Les 5 patterns d'orchestration
Le Modular RAG ne se limite pas au pipeline linéaire. L'orchestration détermine comment les modules se composent pour traiter chaque requête.
Linéaire (serial)
Exécution séquentielle module par module. Le pattern le plus simple, équivalent de l'Advanced RAG.
Conditionnel (routing)
Un routeur sélectionne la branche selon la complexité de la query. Questions simples → chemin court, questions complexes → pipeline complet.
Branching (parallèle)
Exécution parallèle de plusieurs chemins + agrégation des résultats via RRF ou weighted ensemble.
Loop (itératif)
Retrieval itératif avec porte de décision : si la réponse est insuffisante, le pipeline re-retrieve avec une query reformulée. Paramètres : profondeur max K, seuil de confiance τ.
Tuning
Fine-tuning du retriever, du generator, ou des deux simultanément. Le module à optimiser est isolé et entraîné sans affecter le reste.
Frameworks modulaires : le comparatif 2026
Quatre frameworks supportent nativement l'approche modulaire, avec des philosophies différentes.
| Framework | Force | Overhead | Idéal pour |
|---|---|---|---|
| Haystack 2.0 | Architecture DAG, contrats typés, breakpoints debug | ~5,9 ms | Production auditée, conformité |
| LangGraph | Orchestration stateful, workflows agentiques | ~14 ms | Orchestration complexe, agents |
| DSPy | Signature-first, optimisation automatique des modules | ~3,5 ms | Optimisation automatique prompts |
| FlashRAG | 36 datasets, 23 algorithmes pré-implémentés | N/A (recherche) | Recherche reproductible, benchmarks |
DSPy se distingue par son approche signature-first : on définit la tâche (inputs/outputs + intention), et le framework optimise automatiquement les prompts et les modules. Les benchmarks montrent +10 % de qualité sur StackExchange et +30 % avec BayesianSignatureOptimizer. C'est le framework avec le plus faible overhead (~3,5 ms par noeud).
Haystack 2.0 est le choix production : architecture DAG avec contrats typés, breakpoints pour le debug pas-à-pas, et conformité auditée. LangGraph excelle pour l'orchestration stateful et les workflows agentiques, au prix d'un overhead plus élevé (~14 ms).
5 anti-patterns à éviter
La modularité mal appliquée est pire qu'un monolithe. Ces erreurs sont les plus fréquentes en production.
Over-modularisation
Diviser au-delà du raisonnable sans cas d'usage réel. Résultat : des modules "modulaires" en apparence mais reliés par du couplage caché. Règle : n'abstraire qu'à la 3e occurrence (Rule of Three).
Impact : Complexité inutile, couplage caché
Interfaces instables
Une abstraction qui change aussi souvent que son implémentation perd tout intérêt. L'interface d'un module doit être stable : inputs typés, outputs typés, contrat documenté.
Impact : Cascades de modifications, modules fragiles
Boucles non bornées
Les patterns loop/itératif sans profondeur maximale (K_max) ni seuil de confiance (τ) font exploser le coût en tokens et la latence. Toujours définir des bornes.
Impact : Coûts imprévisibles, timeouts en production
Contexte trop large
Passer plus de 5 documents au generator sans compression. Les benchmarks FlashRAG montrent une chute de performance de 40 % avec un excès de contexte.
Impact : Hallucinations, coûts LLM élevés
Latence cumulative ignorée
Chaque module ajoute de la latence. LangGraph ajoute ~14 ms d'overhead par noeud vs ~3,5 ms pour DSPy. Sur un pipeline à 10 modules, la différence est de 100+ ms.
Impact : Latence totale inacceptable en temps réel
Advanced RAG vs Modular RAG
Le Modular RAG n'est pas toujours la bonne réponse. Comparez les deux approches pour décider.
| Critère | Advanced RAG | Modular RAG |
|---|---|---|
| Architecture | Pipeline optimisé, linéaire | 6 modules + opérateurs reconfigurables |
| Flexibilité | Limitée (couplage fort) | Swap de modules indépendants |
| Testabilité | Tests end-to-end uniquement | Tests unitaires par module + E2E |
| Développement parallèle | Séquentiel (1 pipeline) | Parallèle par équipe/module |
| Latence | Faible (pipeline direct) | Plus élevée (coordination inter-modules) |
| Complexité initiale | Modérée | Élevée (interfaces, contrats) |
| Cas complexes | Limité sur multi-hop | Natif via patterns loop/branching |
| Observabilité | Globale | Fine, par module |
Choisir Advanced RAG quand la latence est critique, l'équipe est petite, le domaine est stable et un pipeline linéaire optimisé suffit. C'est le cas de la plupart des chatbots internes et des POC qui passent en production.
Choisir Modular RAG quand le système couvre plusieurs domaines, que l'équipe a besoin de développer en parallèle, que les questions sont hétérogènes (routing nécessaire) ou que l'observabilité fine est exigée (conformité, audit).
Aller plus loin
Le Modular RAG transforme le pipeline RAG en système reconfigurable. Sa taxonomie Module → Sous-module → Opérateur permet de composer des architectures arbitrairement complexes tout en gardant chaque composant testable et remplaçable indépendamment.
Pour les cas d'usage qui requièrent de l'auto-évaluation (Self-RAG), de la correction automatique (CRAG) ou du raisonnement multi-étapes (Agentic RAG), explorez les architectures suivantes du guide des 12 architectures. Chacune s'intègre comme un module supplémentaire dans un pipeline Modular RAG.