Architecture RAG
Adaptive RAG
Un classifier de complexité route chaque requête vers la stratégie optimale : no retrieval, single-step ou multi-step RAG.
Mis à jour en avril 2026 - Jeong et al. (arXiv:2403.14403, 2024)
Qu'est-ce que l'Adaptive RAG ?
Adaptive RAG (Jeong et al., 2024) part d'un constat simple : toutes les questions n'ont pas la même complexité, mais les pipelines RAG classiques traitent chaque requête de la même manière. Une question triviale ("Quelle est la capitale de la France ?") passe par le même retrieval qu'une question multi-hop complexe. Résultat : latence inutile pour les cas simples, précision insuffisante pour les cas complexes.
Adaptive RAG introduit un classifier de complexité en amont du pipeline. Ce classifier évalue chaque requête entrante et la route vers l'une des trois stratégies : no retrieval (le LLM répond seul), single-step RAG (un passage de retrieval classique) ou multi-step RAG (décomposition en sous-questions avec retrievals multiples).
Cette approche optimise le rapport latence/précision à l'échelle du système. Les requêtes simples sont traitées instantanément, les requêtes modérées passent par un pipeline standard, et seules les requêtes complexes mobilisent le pipeline complet. Combiné avec CRAG en aval, il forme un pipeline à la fois rapide et fiable.
Outils interactifs
Testez le routing adaptatif et estimez les gains pour votre profil de trafic.
Simulateur de routing adaptatif
Voyez comment Adaptive RAG classe la complexité et choisit la stratégie optimale.
Requête
simpleQuelle est la capitale de l'Allemagne ?
Question factuelle triviale. Le LLM possède cette connaissance dans ses paramètres. Le retrieval ajouterait de la latence sans améliorer la réponse.
Simulation pédagogique basée sur Jeong et al. (arXiv:2403.14403, 2024). Les classifications sont illustratives.
Calculateur latence vs précision
Estimez le gain du routing adaptatif selon votre profil de trafic.
Pipeline uniforme (single-step)
350 ms
Précision : 78 %
Adaptive routing
382 ms
Précision : 87 %
Routing non rentable
Trop peu de requêtes simples pour justifier le routing. Un pipeline single-step ou multi-step uniforme sera plus simple et aussi performant.
Latences indicatives : no retrieval 80 ms, single-step 350 ms, multi-step 900 ms, classifier 30 ms. Précision basée sur les benchmarks Jeong et al. (2024).
Les 3 stratégies de routing
Le classifier évalue la complexité de chaque requête et la route vers la stratégie la plus adaptée. Chaque stratégie a son profil latence/précision.
Questions factuelles triviales que le LLM maîtrise déjà (capitales, dates, définitions courantes). Le retrieval ajouterait de la latence sans valeur. Le classifier détecte ces cas et skip le retriever.
Questions nécessitant des données factuelles spécifiques ou à jour. Un seul passage de retrieval récupère les documents pertinents. C'est le pipeline RAG classique (Advanced RAG) appliqué aux cas qui le justifient.
Questions multi-hop, comparaisons, synthèses nécessitant plusieurs passages de retrieval. La requête est décomposée en sous-questions, chacune faisant l'objet d'un retrieval séparé. Les contextes sont fusionnés avant génération.
Le classifier de complexité
Le coeur d'Adaptive RAG est le classifier qui évalue la complexité de chaque requête. Trois approches sont possibles, chacune avec ses compromis en termes de latence, précision et coût de développement.
LLM-based (zero-shot)
Le LLM lui-même classifie la complexité via un prompt dédié avant de router.
Avantages
- Pas d'entraînement supplémentaire
- Fonctionne avec n'importe quel LLM
- Facile à itérer (modifier le prompt)
Inconvénients
- Coût d'un appel LLM supplémentaire (~30-50 ms)
- Précision variable selon le modèle
- Risque de sur-classification (biais vers complexe)
Classifier fine-tuné (BERT/T5)
Un modèle léger fine-tuné sur des données étiquetées (simple/modéré/complexe).
Avantages
- Latence très faible (~5-10 ms)
- Précision élevée après fine-tuning
- Coût d'inférence négligeable
Inconvénients
- Nécessite un dataset étiqueté
- Maintenance du modèle (drift)
- Temps de développement initial
Règles heuristiques
Classification par règles : nombre d'entités, mots interrogatifs, longueur de la question.
Avantages
- Zéro latence ajoutée
- Totalement explicable
- Pas de modèle à maintenir
Inconvénients
- Précision limitée (pas de sémantique)
- Fragile face aux reformulations
- Maintenance des règles
Benchmarks Adaptive RAG
Jeong et al. évaluent Adaptive RAG sur des datasets couvrant le QA single-hop, multi-hop et le raisonnement multi-étapes. Le gain est maximal sur les datasets multi-hop (HotpotQA, MuSiQue) où le routing vers multi-step fait la différence.
| Dataset | Type | Adaptive RAG | RAG uniforme | Note |
|---|---|---|---|---|
| SQuAD | Single-hop QA | Comparable | Baseline | Requêtes simples - le routing skip le retrieval inutile sans perte de précision |
| HotpotQA | Multi-hop QA | +3-5 pts | Baseline | Le multi-step retrieval capture les connexions entre entités |
| MuSiQue | Multi-step reasoning | +4-7 pts | Baseline | Questions à 3-4 sauts - le gain du routing multi-step est maximal |
| TriviaQA | Open-domain QA | Comparable | Baseline | Mix de complexités - le routing évite le sur-traitement des questions simples |
Adaptive RAG vs CRAG vs Self-RAG
Ces trois architectures résolvent des problèmes différents du pipeline RAG. Elles sont complémentaires, pas concurrentes.
| Critère | Adaptive RAG | CRAG | Self-RAG |
|---|---|---|---|
| Décision principale | Avant le retrieval (routing) | Après le retrieval (évaluation) | Pendant la génération (reflection tokens) |
| Optimise | Latence (skip les étapes inutiles) | Précision (filtre les mauvaises sources) | Fidélité (vérifie segment par segment) |
| Fine-tuning requis | Optionnel (classifier) | Non | Oui (modèle complet) |
| Fallback web | Non | Oui | Non |
| Complexité d'implémentation | Faible à moyenne | Moyenne | Élevée |
| Combinable avec | CRAG, Self-RAG (en aval) | Adaptive RAG (en amont) | Aucun (remplace le pipeline) |
5 limites à connaître
Adaptive RAG optimise la latence, mais introduit un nouveau point de défaillance : le classifier. Voici les limites à évaluer.
1. Erreurs du classifier
Un classifier imparfait peut router une question complexe vers no-retrieval (réponse incorrecte) ou une question simple vers multi-step (latence inutile). Le taux d'erreur du classifier impacte directement les performances globales.
2. Cold start
Les classifiers fine-tunés nécessitent un dataset étiqueté de qualité. Au lancement, sans données historiques, l'approche LLM-based ou heuristique est un fallback nécessaire.
3. Overhead de classification
Chaque requête passe par le classifier avant le pipeline. Pour un classifier LLM-based, cela ajoute 30-50 ms. Pour un volume élevé de requêtes simples, cet overhead peut annuler le gain du skip de retrieval.
4. Granularité limitée à 3 niveaux
La classification simple/modéré/complexe est réductrice. Certaines questions modérées bénéficieraient d'un retrieval ciblé (2 passages) plutôt que du pipeline complet (5 passages).
5. Pas de correction post-retrieval
Contrairement à CRAG, Adaptive RAG ne vérifie pas la qualité des documents récupérés. Si le retriever renvoie des passages non pertinents, ils sont transmis au LLM sans filtrage.
Adaptive RAG : l'optimisation latence/précision
Adaptive RAG place la décision en amont du pipeline : un classifier évalue la complexité de chaque requête et la route vers la stratégie la plus efficiente. Pour les systèmes à fort trafic avec un mix de complexités, le gain de latence est significatif sans sacrifier la précision.
Pour filtrer les sources non pertinentes après le retrieval, combinez-le avec Corrective RAG. Pour une vérification segment par segment, le Self-RAG complète le pipeline. Explorez toutes les architectures dans le guide des 12 architectures RAG.