Architecture RAG
Corrective RAG (CRAG)
Un évaluateur filtre les documents récupérés et déclenche une correction automatique (web search, raffinement) quand les sources internes sont insuffisantes.
Mis à jour en avril 2026 - Yan et al. (arXiv:2401.15884, 2024)
Qu'est-ce que le Corrective RAG ?
Corrective RAG (Yan et al., 2024) part d'un constat : le retriever ne récupère pas toujours les bons documents. Plutôt que de faire confiance aveuglément aux résultats du retrieval, CRAG insère un retrieval evaluator entre le retriever et le générateur. Cet évaluateur classe chaque document en trois catégories : correct, incorrect ou ambigu.
Selon le verdict, CRAG déclenche une action corrective différente. Documents corrects ? Ils sont raffinés pour extraire l'essentiel. Documents incorrects ? Ils sont rejetés et remplacés par une recherche web ciblée. Documents ambigus ? CRAG combine les deux approches. Cette stratégie de triage élimine les sources non pertinentes avant qu'elles n'atteignent le LLM, réduisant les hallucinations à la source.
Contrairement au Self-RAG qui nécessite un fine-tuning du modèle, CRAG fonctionne comme un plug-in compatible avec n'importe quel LLM. C'est une approche pragmatique qui s'intègre dans un pipeline existant sans modifier le générateur.
Outils interactifs
Testez le pipeline CRAG et comparez-le à Self-RAG.
Simulateur de pipeline CRAG
Voyez comment Corrective RAG évalue, corrige ou rejette les documents récupérés selon 3 scénarios.
Requête
CorrectQuelle est la durée maximale d'un CDD en France ?
Simulation pédagogique basée sur Yan et al. (arXiv:2401.15884, 2024). Les scores et décisions sont illustratifs.
Comparateur Self-RAG vs CRAG
Comparez les deux approches sur 8 critères pour choisir celle qui convient à votre cas d'usage.
Self-RAG
Le modèle décide lui-même quand retriever via des reflection tokens appris pendant le fine-tuning.
CRAG
Un evaluator externe évalue les documents après le retrieval et décide de les garder, raffiner ou rejeter.
Self-RAG
Segment par segment - chaque portion de la réponse est évaluée individuellement ([IsSup], [IsUse]).
CRAG
Document entier - l'évaluation porte sur l'ensemble du passage récupéré (correct/ambiguous/incorrect).
Self-RAG
Pas de fallback externe. Si le retrieval est jugé inutile, le modèle génère sans source.
CRAG
Recherche web automatique quand les documents internes sont jugés incorrects ou ambigus.
Self-RAG
Oui - le modèle doit être fine-tuné pour apprendre les reflection tokens. Coût d'entraînement significatif.
CRAG
Non - fonctionne avec n'importe quel LLM. L'evaluator est un composant séparé (lightweight).
Self-RAG
Variable - skip le retrieval pour les questions triviales (plus rapide), mais multi-étapes pour les complexes.
CRAG
Constante pour les cas corrects. Ajout de latence significatif pour les cas ambigus/incorrects (web search).
Self-RAG
Limitée au corpus interne. Pas d'accès à des sources externes en cas de lacune.
CRAG
Étendue - peut compléter avec le web quand le corpus interne est insuffisant.
Self-RAG
-20 à 30 % sur PubHealth et FactScore grâce à la vérification segment par segment.
CRAG
Réduction significative sur PopQA (+5,5 points) et Biography grâce au filtrage strict des sources.
Self-RAG
Corpus stable et complet (médical, juridique interne). Questions variées en complexité.
CRAG
Corpus potentiellement lacunaire ou évolutif. Besoin de fraîcheur (actualités, réglementation).
Basé sur Asai et al. (NeurIPS 2023) pour Self-RAG et Yan et al. (arXiv:2401.15884, 2024) pour CRAG.
Les 4 composants du pipeline CRAG
CRAG s'articule autour de quatre composants qui forment un pipeline de correction. Chaque composant a un rôle précis dans le processus d'évaluation et de filtrage des sources.
Évaluer la pertinence des documents récupérés.
Un modèle léger (T5-large fine-tuné ou LLM via prompt) attribue à chaque document un verdict : correct, incorrect ou ambiguous. Le seuil de confiance est configurable (par défaut > 0,7 pour correct, < 0,3 pour incorrect).
Extraire et restructurer les informations pertinentes.
Méthode decompose-then-recompose : les passages sont découpés en unités de connaissance atomiques, filtrés par pertinence, puis recomposés en un contexte optimisé pour le LLM. Élimine le bruit sans perdre l'information clé.
Compléter le corpus quand les sources internes sont insuffisantes.
Déclenché pour les verdicts incorrect (remplacement total) et ambiguous (complément). La requête web est reformulée par le LLM pour maximiser la précision. Les résultats web passent ensuite par le knowledge refinement.
Produire la réponse finale à partir du contexte corrigé.
Le LLM génère à partir des passages filtrés et raffinés. Contrairement à Self-RAG, le générateur n'a pas besoin de fine-tuning spécifique - n'importe quel LLM peut être utilisé (GPT-4, Claude, Llama).
L'arbre de décision CRAG
Le retrieval evaluator produit un verdict pour chaque document. Ce verdict détermine l'action corrective appliquée. Voici les trois branches du pipeline.
Les documents sont pertinents. Le knowledge refinement extrait les segments clés et élimine le bruit pour optimiser le contexte du LLM.
Documents partiellement pertinents. CRAG combine le knowledge refinement des passages internes avec une recherche web ciblée pour compléter les lacunes.
Documents non pertinents. CRAG les rejette entièrement et déclenche une recherche web avec une requête reformulée. Seules les sources web alimentent le générateur.
Benchmarks CRAG
Yan et al. évaluent CRAG sur 4 datasets couvrant le QA court, la génération longue, la vérification de faits et le QA à choix multiples. Le gain le plus significatif est sur PopQA (+5,5 points d'accuracy).
| Dataset | Type | CRAG | RAG standard | Delta |
|---|---|---|---|---|
| PopQA | Short-form QA | 54,9 % | 49,4 % | +5,5 pts |
| Biography | Long-form generation | Score FactScore élevé | Baseline | +significatif |
| PubHealth | Fact verification | Accuracy améliorée | Baseline | +mesuré |
| ARC-Challenge | Multi-choice QA | Accuracy améliorée | Baseline | +mesuré |
Knowledge Refinement : decompose-then-recompose
Le knowledge refinement est le coeur du pipeline CRAG. Plutôt que de passer les documents bruts au LLM, CRAG les décompose en unités de connaissance atomiques. Chaque unité est une affirmation factuelle autonome extraite du passage original.
Ces unités sont ensuite filtrées par pertinence vis-à-vis de la requête. Les segments non pertinents (contexte historique, digressions, informations connexes mais hors sujet) sont éliminés. Les segments pertinents sont recomposés en un contexte optimisé - plus court, plus dense, plus ciblé.
Ce processus réduit le bruit de 40 à 60 % selon les datasets (Yan et al., 2024). Le LLM reçoit un contexte épuré où chaque phrase contribue directement à la réponse, ce qui diminue le risque de distraction et d'hallucination par association.
1. Décomposer
Chaque passage est segmenté en unités de connaissance atomiques (1 fait = 1 unité).
2. Filtrer
Les unités non pertinentes vis-à-vis de la requête sont éliminées par scoring.
3. Recomposer
Les unités pertinentes sont assemblées en un contexte optimisé pour le LLM.
Implémenter CRAG
CRAG étant un pipeline de composants (pas un modèle fine-tuné), il s'implémente avec les frameworks RAG existants. Voici trois approches courantes.
LangGraph
Implémentation native avec un graph de décision. Chaque nœud (retrieve → evaluate → refine/search → generate) est un step du graph. Idéal pour visualiser et débugger le flux.
- Graph de décision explicite
- Conditional edges pour le routing
- Intégration Tavily pour le web search
- Visualisation du flux dans LangSmith
LlamaIndex
Utilise le QueryPipeline avec un RetrieverEvaluator custom. Le ConditionModule route vers le refinement ou le web search selon le verdict.
- QueryPipeline modulaire
- RetrieverEvaluator pluggable
- WebSearchRetriever intégré
- Compatible avec tous les LLM providers
Custom (Python)
Pipeline Python pur avec un evaluator basé sur un LLM (prompt zero-shot ou few-shot). Plus flexible mais nécessite plus de code de plomberie.
- Contrôle total sur le routing
- Evaluator via prompt engineering
- API web search au choix (Serper, Tavily, Brave)
- Facilement testable unitairement
5 limites à connaître
CRAG apporte une correction significative au retrieval, mais introduit ses propres compromis. Voici les limites à évaluer avant adoption.
1. Dépendance au web search
Pour les cas incorrect et ambiguous, CRAG repose sur la disponibilité et la qualité des résultats web. En environnement air-gapped (défense, santé), ce fallback est inutilisable.
2. Latence variable
Un verdict correct ajoute ~100 ms (évaluation seule). Un verdict incorrect peut ajouter 2-5 secondes (recherche web + filtrage). L'expérience utilisateur est imprévisible.
3. Évaluateur imparfait
Le retrieval evaluator a un taux d'erreur propre. Un faux positif (incorrect classé correct) laisse passer un document non pertinent. Un faux négatif (correct classé incorrect) déclenche une recherche web inutile.
4. Pas de vérification segment par segment
Contrairement à Self-RAG, CRAG ne vérifie pas si chaque segment de la réponse est supporté par les sources. L'hallucination peut survenir à la génération malgré des sources correctes.
5. Qualité du knowledge refinement
La décomposition en unités de connaissance atomiques dépend de la qualité du prompt ou du modèle utilisé. Un mauvais découpage peut perdre du contexte ou introduire des fragments incohérents.
CRAG : la correction pragmatique du RAG
Corrective RAG s'insère entre le retriever et le générateur pour filtrer les sources non pertinentes. Son approche plug-and-play (pas de fine-tuning) et son fallback web en font une solution pragmatique pour les équipes qui veulent réduire les hallucinations sans modifier leur LLM.
Pour les cas où le corpus est complet et le contrôle segment par segment est critique, le Self-RAG reste plus granulaire. Pour une orchestration dynamique avec agents, explorez l'Agentic RAG dans le guide des 12 architectures.