Corrective RAG et Self-RAG : des patterns de récupération autocorrectifs pour réduire les hallucinations

Corrective RAG (CRAG) et Self-RAG sont deux patterns de récupération autocorrectifs qui ajoutent un contrôle qualité au schéma RAG classique. CRAG évalue la pertinence des résultats récupérés et bascule vers un fallback de recherche web lorsque la qualité de la récupération est insuffisante. Self-RAG laisse le modèle de langage décider lui-même, grâce à des tokens de réflexion, s'il doit effectuer une récupération, puis vérifie si sa propre réponse est étayée par les sources. Tous deux visent le même problème : les hallucinations qui surviennent malgré le RAG.

• CRAG en une phrase : un évaluateur de récupération classe les résultats comme corrects, ambigus ou incorrects et, face à un mauvais contexte, déclenche une mesure corrective au lieu de continuer à générer à l'aveugle.
• Self-RAG en une phrase : grâce à des tokens de réflexion appris, le modèle détermine lui-même quand effectuer une récupération et si sa réponse concorde avec les sources.
• Socle commun : tous deux appartiennent à la famille des patterns Agentic RAG et traitent la récupération non pas comme un prétraitement statique, mais comme une étape vérifiable et pilotable.

Pourquoi le RAG classique ne suffit pas

Le RAG standard (Naive RAG selon la taxonomie de Gao et al. 2023, arXiv:2312.10997) suit un déroulé fixe : vectoriser, récupérer, insérer dans le prompt, générer. Le problème : le pipeline fait aveuglément confiance aux résultats top-k. S'ils sont sémantiquement proches mais hors sujet sur le fond, voire tout simplement absents, le modèle génère quand même une réponse et l'appuie sur des sources inadaptées.

Deux types d'erreurs sont typiques. Dans la context-unfaithful generation, le modèle cite des sources, mais s'écarte de leur contenu. Les contre-mesures habituelles sont les garde-fous de fidélité, l'autocritique et les prompts qui imposent la citation (citation forcing). Le second type d'erreur apparaît en l'absence de re-ranking : les résultats top-k sont alors souvent proches, mais pas pertinents. C'est précisément dans cette brèche que s'engouffrent CRAG et Self-RAG : ils rendent la qualité de la récupération explicitement vérifiable et réagissent en conséquence.

Un point important pour situer le sujet : le principal levier contre les hallucinations reste la qualité de la récupération elle-même. Anthropic Contextual Retrieval réduit le taux d'erreur de récupération top-20 de 49 % (de 5,7 à 2,9 %), et de 67 % en combinaison avec le re-ranking (à 1,9 %) ; il s'agit de benchmarks publiés par l'éditeur Anthropic lui-même, données de septembre 2024. L'autocorrection est la deuxième ligne de défense, pas la première.

Corrective RAG (CRAG) : évaluer les résultats, puis corriger

CRAG ajoute un évaluateur de récupération au pipeline. Après la récupération, mais avant la génération, cet évaluateur juge la pertinence des documents trouvés et les répartit en trois classes de confiance :

• Correct (confiance élevée) : les résultats sont pertinents. Ils sont affinés (par exemple par decompose-recompose, pour éliminer le bruit) puis transmis au générateur.
• Incorrect (confiance faible) : les résultats ne conviennent pas. Au lieu de générer à partir d'un mauvais contexte, le système déclenche un fallback, généralement une recherche web, pour récupérer des contenus externes à jour.
• Ambiguous (confiance moyenne) : incertain. Les deux voies sont combinées : contexte interne plus résultats de la recherche web.

Le mécanisme décisif est le fallback de recherche web lorsque la qualité de la récupération interne est faible. CRAG compense ainsi une base de connaissances incomplète ou obsolète sans que le modèle se mette à halluciner. CRAG est indépendant du modèle : il peut être placé comme nœud supplémentaire en amont de n'importe quel pipeline RAG existant, sans réentraîner le LLM générateur. CRAG remonte à Yan et al. 2024 (arXiv:2401.15884).

Self-RAG : le modèle se critique lui-même

Self-RAG (Asai et al., University of Washington, arXiv:2310.11511, octobre 2023) transfère le contrôle au modèle. Celui-ci est entraîné à produire des tokens dits de réflexion, avec lesquels il pilote et évalue son propre processus. Schématiquement, quatre décisions se succèdent :

• Retrieve? Le modèle décide pour chaque requête (ou chaque segment) si une récupération est vraiment nécessaire. Les questions triviales ou déjà couvertes par les connaissances du modèle ne nécessitent aucune récupération.
• Is Relevant? Le modèle évalue si le passage récupéré est pertinent pour la question.
• Is Supported? Après la récupération, le modèle vérifie si l'affirmation générée est étayée par le passage récupéré : une autocritique de fidélité intégrée.
• Is Useful? Le modèle évalue sur une échelle de 1 à 5 l'utilité de la réponse pour la question.

L'intérêt : le modèle n'effectue une récupération que s'il la juge lui-même nécessaire (ce qui réduit les coûts pour les questions simples). Lors de la génération, Self-RAG produit plusieurs segments candidats, les évalue via un score pondéré issu des tokens de critique (pertinence, étayage, utilité) et conserve le mieux noté (Asai et al. 2023). Refuser de répondre ou escalader vers un humain ne fait pas partie de la méthode, mais peut se construire sur ces tokens. Le prix à payer : l'implémentation originale de Self-RAG suppose un modèle spécialement entraîné sur les tokens de réflexion. En pratique, de nombreuses équipes approchent ce comportement par prompting et par une boucle d'autocritique avec un modèle standard, ce qui est moins coûteux à mettre en œuvre, mais moins fiable qu'un modèle entraîné à cet effet.

Comparatif : CRAG vs Self-RAG vs RAG standard

Selon la taxonomie d'évolution du RAG (Naive, Advanced, Modular, Graph, Agentic), les deux patterns relèvent du stade Agentic RAG. Singh et al. 2025 (arXiv:2501.09136) décrivent l'Agentic RAG comme des patterns dans lesquels la récupération fonctionne comme un outil qu'un agent appelle de façon dynamique et itérative, avec réflexion, planification et utilisation d'outils. Self-RAG n'apparaît pas dans cette revue de littérature, mais s'y inscrit comme un exemple précoce, puisque le modèle décide lui-même de la récupération. Singh et al. présentent Corrective RAG comme une architecture à part entière (Agentic Corrective RAG). Par honnêteté, il faut préciser qu'en 2026 la notion d'Agentic RAG n'est pas encore clairement stabilisée.

Exemple concret : une base de connaissances de support avec des lacunes

Prenons une agence qui exploite pour un client B2B un assistant de support basé sur le RAG et adossé à une base de connaissances interne. Un utilisateur pose une question sur une fonctionnalité annoncée hier seulement dans une note de version qui n'est pas encore indexée.

• RAG standard : récupère les trois documents anciens les plus proches, ne trouve pas la réponse et hallucine une configuration plausible, mais fausse. Une hallucination classique malgré le RAG.
• CRAG : l'évaluateur de récupération classe les résultats comme incorrect (faible confiance dans la pertinence), lance une recherche web dans la documentation publique du produit, trouve la note de version et génère une réponse correcte avec sa source.
• Self-RAG : le modèle classe les chunks récupérés comme non pertinents via le token Is Relevant et constate, via le token Is Supported, qu'aucune réponse n'est étayée par eux. Une règle applicative construite sur ces tokens supprime alors la réponse non étayée et escalade vers un humain.

Un calcul pour illustrer le compromis : si un appel RAG standard coûte par exemple un appel au LLM, CRAG ajoute au moins un appel à l'évaluateur, plus le traitement de la recherche web lorsque le fallback se déclenche ; une boucle d'autocritique de type Self-RAG peut entraîner d'autres appels selon la conception. Pour les questions simples, Self-RAG peut même faire l'économie de l'étape de récupération. En règle générale : l'autocorrection n'est pas une amélioration gratuite, mais un échange délibéré de latence et de coûts supplémentaires contre un risque d'hallucination plus faible. Les systèmes RAG agentiques ajoutent un risque typique : des boucles d'outils incontrôlées qui multiplient le coût par requête.

Les cas où ces patterns sont pertinents

Les patterns autocorrectifs sont rentables lorsqu'au moins l'un de ces points s'applique :

• La base de connaissances est incomplète ou obsolète, et un fallback vers le web ou des sources tierces comble de vraies lacunes (CRAG).
• Les mauvaises réponses coûtent cher : droit, finance, support réglementé, tout ce qui engage la responsabilité.
• Le refus de répondre en cas d'incertitude est souhaité et accepté (Self-RAG fournit pour cela les tokens de critique).

Ils sont moins pertinents si la base de connaissances est complète et proprement indexée, si la latence est prioritaire ou si le budget par requête est serré. Dans ces cas, les mesures moins coûteuses du stade Advanced RAG offrent généralement un meilleur rapport coût-bénéfice : recherche hybride (dense plus BM25 pour ne pas manquer les codes exacts), Contextual Retrieval contre les chunks privés de leur contexte, re-ranking par cross-encoder et garde-fou de fidélité via RAGAS dans le pipeline de CI. Selon Anthropic, le Contextual Retrieval (embeddings contextualisés plus BM25 sur les chunks contextualisés), combiné au re-ranking, réduit le taux d'erreur de récupération jusqu'à 67 %. Ce n'est qu'ensuite qu'il vaut la peine d'ajouter CRAG ou Self-RAG de manière ciblée sur les chemins critiques.

Pour les agences et les décideurs B2B

Pour les agences, le message aux clients est clair : les patterns de récupération autocorrectifs ne sont pas une fonctionnalité standard qu'on active par défaut, mais un investissement ciblé pour les cas d'usage à fort risque d'hallucination. La voie pragmatique passe par une base de référence mesurable (mesurer la qualité de la récupération et la fidélité avec RAGAS) et n'ajoute CRAG ou Self-RAG que là où les chiffres le justifient. Pour les projets B2B en Europe, un point s'ajoute : un fallback de recherche web (CRAG) doit être aligné sur la gouvernance des données personnelles et des sources, car des contenus externes entrent soudain dans la chaîne de réponse. Blck Alpaca conçoit des architectures RAG de sorte que l'autocorrection se trouve là où elle fait la différence, sans gonfler partout les coûts et la latence.