Le RAG « naïf » — récupérer le top-k, coller le contexte, générer — plafonne dès que la question demande du raisonnement : comparer deux sources, agréger des faits dispersés, ou « faire sens » d'un corpus entier. Cet article part du principe que vous connaissez déjà les embeddings et la recherche vectorielle (voir l'article dédié) et se place au-dessus : comment un agent transforme la récupération en boucle de raisonnement (Agentic RAG), et comment GraphRAG structure le corpus en graphe de connaissances pour répondre aux questions globales que le RAG vectoriel rate.

Pourquoi le RAG naïf plafonne

Le pipeline classique fait une seule passe : une requête, une récupération, une génération. Il n'itère pas, ne se corrige pas, et ne vérifie pas si les documents récupérés répondent réellement à la question. Trois angles morts reviennent constamment :

  • Récupération en un coup. Si le top-k est mauvais (requête ambiguë, mismatch de vocabulaire, chunk mal découpé), la réponse est mauvaise — sans recours.
  • Pas de raisonnement multi-étapes. Une question « multi-hop » (« Quel est le PDG de l'entreprise qui a racheté X en 2021 ? ») exige deux récupérations enchaînées ; le one-shot n'en fait qu'une.
  • Pas d'auto-évaluation. Le LLM reçoit le contexte et génère, qu'il soit pertinent ou non. Aucun garde-fou ne détecte une récupération hors-sujet avant qu'elle ne pollue la réponse.
  • Questions globales. « Quels sont les grands thèmes de ce corpus ? » n'a pas de réponse dans un sous-ensemble de k passages : l'information est répartie sur tout le corpus, pas concentrée dans quelques chunks.

Le symptôme typique est l'hallucination par contexte pauvre : le modèle, faute de preuve pertinente, comble les trous. Le RAG naïf reste excellent pour les questions factuelles simples où un seul passage suffit — c'est précisément là qu'il faut le garder. Le problème n'est pas le RAG, c'est l'absence de boucle quand la question l'exige.

Comparaison entre un pipeline RAG naïf linéaire en une passe et une boucle agentique avec évaluation, repli web et auto-réflexion. Figure : RAG naïf (one-shot) vs RAG agentique (boucle récupérer–raisonner). Diagramme original.

L'idée de l'Agentic RAG

L'Agentic RAG remplace le pipeline figé par un agent qui décide, à chaque étape, quoi faire : reformuler la requête, choisir une source, récupérer à nouveau, évaluer ce qu'il a obtenu, et seulement ensuite générer. La récupération devient un outil appelé dans une boucle de raisonnement, pas une étape unique en amont. On le formalise souvent comme une machine à états (un graphe de nœuds reliés par des arêtes conditionnelles) : récupérer → noter les documents → réécrire → générer → vérifier — avec des boucles de retour quand une étape échoue.

Réécriture et décomposition de requête

La requête de l'utilisateur est rarement la meilleure requête de recherche. Deux transformations clés :

  • Réécriture (query rewriting) : reformuler pour coller au vocabulaire du corpus, lever les pronoms, expanser les acronymes.
  • Décomposition (multi-hop) : casser une question complexe en sous-questions récupérées indépendamment, puis recomposer. Le coût croît linéairement avec le « fan-out », mais c'est ce qui débloque les comparaisons et les agrégations.
  • Expansion (HyDE) : générer une réponse hypothétique à la question, puis l'utiliser comme requête de recherche — souvent plus proche des documents cibles que la question brute.

Ces transformations sont peu coûteuses (un appel LLM court) et corrigent la cause la plus fréquente d'échec : une requête qui ne « parle pas la langue » du corpus indexé.

Routage

Avant de récupérer, un routeur dirige la requête vers la bonne source : base vectorielle pour le non-structuré, SQL pour le structuré, web pour l'actualité, un outil métier précis. L'Adaptive RAG pousse l'idée plus loin : un classifieur léger prédit la difficulté de la requête (pas de récupération / une étape / multi-étapes) et choisit la profondeur du pipeline — ce qui coupe 30–50 % du coût moyen sur un trafic mixte en évitant l'agent pour les questions faciles.

Bien routé, un système peut répondre à un simple « bonjour » sans aucune récupération, et engager toute la machinerie agentique uniquement sur les questions qui la méritent.

Boucles récupérer–raisonner (ReAct)

Le patron ReAct alterne raisonner et agir : à chaque tour l'agent réfléchit, appelle un outil (récupération, SQL, web, serveur MCP), observe le résultat, et recommence jusqu'à pouvoir répondre. C'est indispensable dès qu'on mélange sources non structurées, données structurées et actualité. Garde-fou impératif : un plafond d'itérations (5–6) pour éviter les boucles infinies, et une borne de profondeur d'outils.

Concrètement, on modélise la boucle comme un graphe d'états explicite, ce que des outils comme LangGraph rendent naturel :

  • des nœuds = étapes (récupérer, noter, réécrire, générer, vérifier) ;
  • des arêtes conditionnelles = décisions (« documents pertinents ? » → générer / réécrire / web) ;
  • un état partagé = la requête courante, les documents retenus, le compteur d'itérations.

Ce « flow engineering » rend la logique auditable : chaque décision est un point nommé du graphe, traçable et testable — bien plus maintenable qu'un prompt monolithique qui « décide tout seul ».

Voici l'ossature d'une telle boucle, où la récupération est un nœud rappelé tant que les contrôles ne passent pas :

# Graphe d'états Agentic RAG (pseudo-LangGraph)
def agent_loop(question, max_iters=5):
    state = {"question": question, "iters": 0, "docs": []}
    while state["iters"] < max_iters:
        state["iters"] += 1
        state["docs"] = retrieve(state["question"])         # nœud : récupérer
        verdict = grade_documents(state)                    # nœud : noter
        if verdict["route"] == "web_search":
            state["docs"] = web_search(state["question"])    # repli externe (CRAG)
        elif verdict["route"] == "rewrite":
            state["question"] = rewrite_query(state)         # arête conditionnelle
            continue
        answer = generate(state)                             # nœud : générer
        if is_grounded(answer, state["docs"]) and answers(answer, question):
            return answer                                    # contrôles Self-RAG OK
        state["question"] = rewrite_query(state)             # sinon : on reboucle
    return escalate_to_human(question)                       # garde-fou : plafond atteint

La sortie n'est jamais « la première génération venue » : elle doit franchir deux contrôles (ancrage + réponse à la question) hérités de Self-RAG, sinon la boucle réécrit la requête et recommence — jusqu'au plafond, où l'on escalade vers un humain plutôt que de tourner à l'infini.

Self-RAG : la réflexion par jetons

Self-RAG entraîne le modèle à émettre des jetons de réflexion qui le font s'auto-évaluer à chaque étape :

  • Retrieve — faut-il récupérer (oui / non / continuer) ?
  • ISREL — les passages récupérés sont-ils pertinents ?
  • ISSUP — la génération est-elle étayée par les passages (anti-hallucination) ?
  • ISUSE — la réponse est-elle utile à la question (note 1–5) ?

Le papier original entraîne en réalité deux modèles : un critic qui apprend à prédire ces jetons, et un generator qui les émet au fil de la décodage. À l'inférence, une recherche en faisceau au niveau du segment (segment-level beam search) sélectionne la continuation qui maximise une combinaison linéaire de la vraisemblance du texte et des probabilités de jetons « désirables » (ISREL = pertinent, ISSUP = étayé, ISUSE élevé). Le poids de chaque jeton est un curseur réglable à l'inférence : on durcit ISSUP pour une tâche médicale sensible, on l'assouplit pour une rédaction créative — sans réentraîner.

En pratique (par exemple avec LangGraph), des nœuds de grading implémentent cette logique sans modèle spécialement entraîné : on note la pertinence des documents ; si tous échouent, on réécrit la requête et on récupère à nouveau. Après génération, deux contrôles : la réponse est-elle ancrée dans les documents (anti-hallucination) et répond-elle vraiment à la question ? Si l'un échoue, la boucle repart avec une requête améliorée.

Corrective RAG (CRAG) : noter puis corriger

CRAG insère un évaluateur de récupération qui attribue une note de confiance aux documents et route vers trois actions :

  1. Correct (au moins un document au-dessus du seuil haut) → utiliser les documents, mais les raffiner d'abord.
  2. Incorrect (tous les documents sous le seuil bas) → les jeter et déclencher une recherche web (repli externe, p. ex. via une API de recherche).
  3. Ambiguous (entre les deux) → action mixte, on combine documents internes et complément web.

Le raffinement passe par une stratégie décompose-puis-recompose : chaque document est découpé en bandes de connaissance (knowledge strips), chaque bande est re-notée par l'évaluateur, les bandes hors-sujet sont filtrées et seules les pertinentes sont recollées. On évite ainsi de polluer le contexte avec les passages voisins, même corrects, qui ne servent pas la question. C'est ce qui rend CRAG plug-and-play : il s'insère devant n'importe quel pipeline RAG existant.

Self-RAG et CRAG sont complémentaires : CRAG améliore la qualité de la preuve (l'entrée), Self-RAG améliore la façon de raisonner sur cette preuve (la sortie). On peut chaîner les deux : CRAG nettoie/corrige les entrées, puis Self-RAG réfléchit sur la réponse finale.

Récapitulatif des patrons

Les systèmes de production combinent rarement un seul patron. Voici comment ils se positionnent :

  • Self-RAG — le modèle émet des jetons de réflexion et s'auto-note. Brille quand les signaux de récupération sont bruités ; gaspille des tokens sur un corpus fiable.
  • CRAG — un évaluateur externe trie en trois voies (garder / web / hybride). Idéal pour les bases hétérogènes mêlant docs produit et fils de forum.
  • Adaptive RAG — un classifieur prédit la difficulté en amont et choisit la profondeur. Coupe 30–50 % du coût moyen sur du trafic varié.
  • ReAct — boucle raisonner/agir avec outils hétérogènes (vecteurs, SQL, web, MCP). Indispensable en environnement multi-sources.
  • Décomposition multi-hop — sous-questions parallèles puis recomposition. Coût linéaire avec le fan-out ; parfait pour comparaisons et agrégations.

La règle pratique : commencer simple (hybride + rerank), ajouter l'Adaptive routing pour préserver la vitesse, puis n'activer Self-RAG/CRAG/multi-hop que sur les chemins qui en ont besoin.

# Esquisse d'un nœud d'évaluation CRAG (pseudo-LangGraph)
def grade_documents(state):
    question, docs = state["question"], state["documents"]
    kept = [d for d in docs if grader(question, d).score == "relevant"]
    if len(kept) == 0:
        return {"route": "web_search", "documents": []}   # repli externe
    if len(kept) < len(docs):
        return {"route": "rewrite", "documents": kept}      # confiance moyenne
    return {"route": "generate", "documents": kept}         # confiance élevée

Rappel express : hybride + reranking

Avant de raisonner, il faut bien récupérer. Sans ré-expliquer les embeddings, retenez le pipeline à deux étages devenu standard :

  1. Recherche hybride — fusionner le lexical (BM25, robuste sur les termes rares, codes, noms propres) et le dense (sémantique) ; renvoyer un large top-50.
  2. Reranking — un cross-encoder (Cohere, Voyage…) re-note finement la paire (requête, passage) et ne garde que le top-5. Le gain est net : le Recall@5 passe typiquement de ~0,70 (hybride seul) à ~0,82 avec reranking.

Le dense seul rate les correspondances lexicales exactes ; BM25 seul rate les synonymes. L'hybride couvre les deux, le reranker met de l'ordre. C'est le socle sur lequel les boucles agentiques opèrent.

Quelques rappels pratiques sur le découpage, sans ré-ouvrir le débat des embeddings :

  • Chunking sémantique (512–1024 tokens, 50–100 de chevauchement) bat le découpage à taille fixe : on respecte les frontières de sens.
  • Métadonnées sur chaque chunk (source, date, section) pour le filtrage avant la recherche vectorielle.
  • Fusion des scores (Reciprocal Rank Fusion) pour combiner les classements BM25 et dense de manière robuste, sans calibrer des échelles incompatibles.

Un reranker coûte un appel modèle de plus par requête, mais sur un top-50 réduit à top-5 il améliore directement la fidélité en aval : moins de bruit dans le contexte, moins d'hallucinations à corriger ensuite.

GraphRAG : structurer le corpus en graphe

Le RAG vectoriel échoue sur les questions globales parce qu'il récupère « un sous-ensemble de passages individuellement pertinents » — or une question de synthèse n'a pas de passage unique qui la contient. GraphRAG (Microsoft, From Local to Global) répond en pré-construisant un graphe de connaissances puis en le résumant hiérarchiquement. Le pipeline d'indexation a six étapes :

  1. Découpage + extraction. Le LLM lit chaque chunk et en extrait des triplets (entité, relation, entité) et des affirmations — p. ex. Steve Jobs — a fondé — Apple. Des prompts spécialisés et de l'auto-réflexion (le LLM relit pour les entités manquées) permettent de plus gros chunks sans perte de rappel.
  2. Construction du graphe. Les instances d'entités sont dédupliquées et agrégées : les nœuds sont des entités, les arêtes des relations, pondérées par leur fréquence dans le corpus.
  3. Détection de communautés (Leiden). L'algorithme de Leiden (amélioration de Louvain) partitionne récursivement le graphe en communautés imbriquées : niveau feuille (entités très liées), niveaux intermédiaires, niveau racine — un véritable arbre de communautés.
  4. Résumés de communautés. Chaque communauté reçoit un résumé type rapport, généré de bas en haut ; les niveaux supérieurs réutilisent les résumés des niveaux inférieurs sous contrainte de place.
  5. Requête (map-reduce). Pour une question globale, on map sur les résumés de communautés en parallèle (réponses partielles + score d'utilité), puis on reduce (tri par score → synthèse finale).
  6. Requête locale. Pour une question factuelle précise, la recherche locale part des entités correspondant à la requête, étend aux voisins et aux relations, récupère les chunks associés et répond sur ce contexte combiné.

La qualité d'extraction est l'étape critique : un graphe issu d'entités mal extraites ou mal dédupliquées propage ses erreurs partout. Trois leviers :

  • Prompts spécialisés au domaine, avec exemples few-shot, pour cadrer les types d'entités attendus.
  • Auto-réflexion d'extraction : le LLM relit le chunk pour repérer les entités manquées, ce qui autorise de plus gros chunks sans perte de rappel.
  • Résolution d'entités (déduplication) : fusionner « Apple », « Apple Inc. » et « la firme de Cupertino » en un seul nœud, sous peine de fragmenter le graphe.

Notez le parallèle : l'auto-réflexion sert ici à l'indexation, alors que dans l'Agentic RAG elle sert à la requête. La même idée — le modèle se relit — opère à deux moments différents du pipeline.

Graphe d'entités partitionné en communautés Leiden, et l'arbre de résumés hiérarchiques (racine, intermédiaire, feuille) utilisé pour les requêtes globales par map-reduce. Figure : graphe d'entités, communautés Leiden et résumés hiérarchiques. Diagramme original.

Global vs local : quand utiliser quoi

  • Requête locale — questions factuelles ciblées (« Qui dirige X ? »). Combine sous-graphe d'entités + chunks de texte. C'est proche du RAG vectoriel, en mieux ancré sur les relations.
  • Requête globale — questions de synthèse (« Quels sont les thèmes dominants ? », « Quelles tensions traversent ce corpus ? »). Utilise les résumés de communautés via map-reduce.

Le niveau de communauté interrogé est un curseur : la racine (C0) donne une vue très condensée et bon marché ; les feuilles donnent du détail au prix de beaucoup plus de tokens. Dans l'étude Microsoft, le niveau intermédiaire offre le meilleur équilibre exhaustivité/coût — un bon défaut de départ.

Quand GraphRAG bat le RAG vectoriel

Sur les questions de sensemaking global, GraphRAG domine nettement le RAG vectoriel : dans l'étude Microsoft, des taux de victoire de 72–83 % en exhaustivité (comprehensiveness) et 62–82 % en diversité des points de vue, sur des corpus d'environ un million de tokens. Mieux : interroger les résumés racine (C0) consomme 9× à 43× moins de tokens de contexte que l'approche « tout le texte source », tout en conservant un avantage d'exhaustivité de ~72 % sur le RAG vectoriel. Les résumés de niveau intermédiaire offrent le meilleur compromis.

La contrepartie est le coût d'indexation : construire le graphe est lourd (extraction LLM sur chaque chunk, résumés à chaque niveau) — l'étude rapporte ~281 minutes d'indexation pour un corpus « podcast » avec GPT-4-turbo. GraphRAG n'est donc pas un remplaçant universel du RAG vectoriel : c'est l'outil des questions globales et des corpus où la structure relationnelle porte le sens.

Combiner GraphRAG et Agentic RAG

Les deux approches ne s'opposent pas : un routeur agentique peut choisir la stratégie selon la question. Schéma fréquent en 2026 :

  1. Le routeur classe la requête : factuelle ciblée, multi-hop relationnelle, ou globale de synthèse.
  2. Factuelle → RAG vectoriel hybride + rerank (rapide, bon marché).
  3. Relationnelle / multi-hop → requête locale GraphRAG (suivre les arêtes du graphe sur plusieurs sauts).
  4. Globale → requête globale GraphRAG (map-reduce sur les résumés de communautés).
  5. Une boucle Self-RAG/CRAG enveloppe le tout pour vérifier et, au besoin, corriger ou replier sur le web.

Le graphe devient ainsi un outil parmi d'autres dans la boucle ReAct, mobilisé seulement quand la structure relationnelle compte.

Évaluer : RAGAS et au-delà

On ne pilote pas un système agentique sans mesure. RAGAS fournit des métriques par requête, calculées par un LLM-juge :

  • Faithfulness (fidélité, viser ≥ 0,9) — les affirmations de la réponse sont-elles étayées par le contexte récupéré ? C'est la métrique anti-hallucination.
  • Answer relevancy (pertinence de la réponse, ≥ 0,85) — la réponse colle-t-elle à la question ?
  • Context precision / relevancy (≥ 0,8) — les bons chunks ont-ils été récupérés ?
  • Context recall — le contexte couvre-t-il toute l'information nécessaire à la réponse de référence ?

Ces métriques se calculent par requête sur un jeu de test, ce qui permet de comparer objectivement deux configurations (avec/sans rerank, avec/sans CRAG) avant de toucher à la production.

Trois précautions opérationnelles : (1) le paradoxe de l'évaluateur — demander au même LLM faillible de se noter crée une circularité ; on l'atténue en ensemblant plusieurs juges, en figeant un golden set, et en faisant relire ~5 % des traces par des humains ; (2) le traçage de trajectoire (Phoenix, Langfuse, OpenTelemetry) pour déboguer chaque itération de l'agent ; (3) la surveillance de dérive (knowledge-base, embeddings, évaluation) chaque semaine contre un jeu de référence figé.

Coûts et arbitrages opérationnels

L'Agentic RAG est puissant mais cher : comptez 3× à 10× plus de tokens que le RAG simple, et 2× à 5× de latence (de ~1–2 s à ~8–12 s par requête). À 10 000 requêtes/jour, un coût de ~500 $/jour peut grimper à 1 500–5 000 $/jour sans optimisation. Les leviers : routage adaptatif (ne lancer la boucle que sur les questions ambiguës), cache sémantique, plafonds d'itérations, et budgets de tokens par requête.

Quand ne pas être agentique : FAQ, recherche d'un fait unique, contraintes UX sub-3 s. Le bon réflexe est l'Adaptive RAG — préserver la vitesse sur les questions faciles, ne raisonner en boucle que sur celles qui l'exigent vraiment.

Les pièges récurrents en production, à anticiper dès le jour un :

  • Boucles infinies — plafonner à 5–6 itérations puis escalader vers un humain.
  • Dérive de la base — suivre le Recall@5 chaque semaine contre un jeu figé.
  • Queue de coût — surveiller le p99, bien pire que la moyenne, pas seulement le coût médian.
  • Cascade d'appels d'outils — borner la profondeur du graphe d'outils (≤ 3).
  • Paradoxe de l'évaluateur — ensembler les juges, geler le golden set, relire ~5 % à la main.

Checklist d'implémentation

Un ordre de marche pragmatique pour passer du prototype à la production :

  1. Socle : hybride BM25 + dense, chunking sémantique, reranking cross-encoder.
  2. Mesure : brancher RAGAS (fidélité, pertinence, précision du contexte) + traçage (OpenTelemetry) dès le départ.
  3. Routage adaptatif : un classifieur de difficulté pour ne payer le raisonnement que quand il rapporte.
  4. Boucles : ajouter Self-RAG (réflexion) et CRAG (correction + repli web) sur les chemins difficiles.
  5. Graphe : introduire GraphRAG pour les questions globales / relationnelles, en outil de la boucle.
  6. Garde-fous : plafonds d'itérations, budgets de tokens, cache sémantique, alertes de dérive.

En résumé

Trois couches se superposent. Récupération : hybride (BM25 + dense) + reranking, le socle. Agentic RAG : réécriture/décomposition, routage, boucles ReAct, Self-RAG (réflexion) et CRAG (correction + repli web) pour transformer la récupération en raisonnement vérifié. GraphRAG : un graphe de connaissances + communautés Leiden + résumés hiérarchiques pour les questions globales que le vectoriel ne sait pas couvrir.

Aucune de ces couches n'est gratuite : chaque boucle, chaque graphe, chaque juge ajoute des tokens et de la latence. La maturité consiste donc à mesurer avant d'ajouter — instrumenter avec RAGAS et le traçage, router selon la difficulté, et n'investir le raisonnement que là où le gain de qualité justifie le surcoût. Le RAG naïf n'est pas obsolète : il reste le bon choix pour la majorité des requêtes factuelles. L'art, en 2026, est de dépenser le raisonnement là où il rapporte, et de rester en one-shot partout ailleurs.