Le RAG en une passe échoue sur les questions multi-sauts et les comparaisons. L'agentic RAG laisse un agent décomposer, récupérer en itérant et s'arrêter au bon moment — avec ses garde-fous et son coût. Quand l'utiliser, et quand s'abstenir.
Le RAG classique suit toujours le même rituel : on reçoit une question, on récupère des passages, on génère une réponse. Une question, une récupération, une réponse. C'est efficace pour les questions simples et factuelles. Mais dès que la question se complique — plusieurs sous-questions, besoin de croiser des sources, ambiguïté à lever — ce schéma rigide montre ses limites. L'agentic RAG casse ce rituel : il laisse un agent décider quoi récupérer, quand, et surtout quand s'arrêter.
Voici ce que ça change, comment ça marche concrètement tour par tour, et quand cette complexité supplémentaire en vaut le prix.
Le RAG en une seule passe fait une hypothèse forte : une seule récupération suffit à répondre. Or beaucoup de questions réelles violent cette hypothèse :
Sur ces cas, le RAG en une passe récupère « à peu près » et génère une réponse partielle, avec aplomb. Le problème n'est pas la génération : c'est que la requête initiale ne contient pas l'information nécessaire pour récupérer les bons passages. Reprenons l'exemple des congés : aucun chunk ne parle à la fois du « plus gros bureau » et d'une « politique de congés ». L'embedding de la question pointe vers un vide sémantique. Le modèle reçoit des passages bancals et répond quand même — c'est exactement le scénario qui produit des hallucinations confiantes.
Le RAG classique répond à la question qu'il croit avoir comprise, en une seule récupération. L'agentic RAG prend le temps de décomposer, chercher, vérifier, recommencer si besoin.
Un agent RAG dispose d'une boucle de raisonnement et d'outils (au minimum, la recherche). À chaque tour, il décide :
Question ─► l'agent raisonne ─► récupérer ? quoi ?
▲ │
│ récupération
assez d'info ? ◄───────────┘
│ oui
réponse vérifiée
Pour rendre la boucle tangible, déroulons la question multi-sauts « Quelle est la politique de congés du pays où se trouve notre plus gros bureau, et combien de jours de plus que le minimum légal local accorde-t-elle ? » Le corpus contient un annuaire RH, des fiches d'effectifs par site, et des politiques de congés par pays.
Tour 1 — décomposition. L'agent lit la question et constate qu'il ne peut pas la résoudre d'un coup. Il génère un plan : (a) trouver le bureau avec le plus d'effectifs, (b) identifier son pays, (c) récupérer la politique de congés de ce pays, (d) comparer au minimum légal. Première recherche émise : effectifs par bureau.
Tour 2 — première récupération. La recherche renvoie une fiche listant les sites : Paris 240, Lisbonne 310, Berlin 180. L'agent lit, en déduit que le plus gros bureau est Lisbonne (310), donc le pays est le Portugal. Il note ce fait intermédiaire dans son contexte de travail. Il n'a toujours pas de quoi répondre : il enchaîne avec la sous-requête politique de congés Portugal.
Tour 3 — récupération ciblée. La recherche renvoie le passage « Portugal : 25 jours ouvrés de congés payés par an ». L'agent a maintenant le cœur de la réponse. Mais la question demandait aussi l'écart au minimum légal. Il lui manque cette pièce. Nouvelle sous-requête : minimum légal congés payés Portugal.
Tour 4 — comblement de lacune. La recherche renvoie « minimum légal au Portugal : 22 jours ouvrés ». L'agent dispose désormais des trois faits : Lisbonne = plus gros bureau, politique = 25 jours, minimum légal = 22 jours.
Tour 5 — auto-vérification et réponse. Avant de livrer, l'agent confronte chaque affirmation à une source citée : 310 effectifs (fiche sites), 25 jours (politique PT), 22 jours (référence légale). L'arithmétique 25 − 22 = 3 est faite sans outil. Réponse : « Le plus gros bureau est Lisbonne (Portugal). La politique y accorde 25 jours, soit 3 de plus que le minimum légal de 22. » Le plafond de tours (disons 8) n'a pas été atteint ; l'agent s'arrête car le contexte couvre toute la question.
Notez ce qu'un RAG en une passe aurait produit : une recherche unique sur la question entière, des passages mélangeant vaguement « bureau », « congés » et « légal », et une réponse plausible mais non vérifiée — au mieux correcte par chance, au pire inventant un pays ou un nombre.
Décomposition. Éclater une question complexe en sous-questions traitées séquentiellement. C'est ce qui se joue au tour 1 ci-dessus. Le pattern brille quand les sous-questions sont dépendantes : le résultat de l'une conditionne la suivante (il faut le pays avant de chercher sa politique). Pour des sous-questions indépendantes (« compare les clauses de résiliation des contrats A, B et C »), on peut les récupérer en parallèle et fusionner — moins de tours, moins de latence.
Routage. Choisir la bonne source ou le bon index selon la nature de la question. Un agent peut router une question juridique vers l'index des contrats, une question produit vers la doc technique, une question chiffrée vers une base structurée interrogée en SQL. Mini-exemple de logique de routage :
si question ∈ {prix, stock, dates} → outil SQL (table produits)
sinon si question juridique → index "contrats" (hybride + rerank)
sinon → index général de connaissances
Le routage évite de noyer une requête précise dans un corpus généraliste, et réduit le bruit en amont du reranking.
Récupération itérative. Récupérer, lire, identifier ce qui manque, récupérer encore — exactement les tours 2 à 4. La clé est la détection de lacune : l'agent doit savoir reconnaître qu'il lui manque une pièce plutôt que de répondre avec ce qu'il a. Une heuristique robuste consiste à demander au modèle, à chaque tour, « peux-tu répondre intégralement et avec citations ? oui/non + ce qui manque ».
Auto-vérification. Confronter la réponse aux sources avant de la livrer. En pratique : exiger que chaque affirmation factuelle soit rattachée à un passage récupéré, et déclencher une récupération supplémentaire si une affirmation n'a pas d'appui. C'est ce filet qui rattrape les hallucinations résiduelles — au prix d'un tour LLM de plus.
L'agentic RAG n'est pas gratuit. Chaque tour de boucle, c'est :
Pour fixer les ordres de grandeur : un tour de décision typique consomme l'historique de raisonnement plus les passages déjà lus. Comptez grossièrement 300 à 800 tokens en entrée par tour rien que pour le raisonnement, auxquels s'ajoutent les passages récupérés (souvent 1 000 à 4 000 tokens par fournée selon le top-k et la taille des chunks). Côté latence, chaque tour ajoute un aller-retour LLM, soit typiquement 0,5 à 2 s selon le modèle, plus la latence de recherche (quelques dizaines de ms en pgvector HNSW). Notre exemple à 5 tours coûte donc, en première approximation, 5 fois le budget d'une passe unique en appels LLM, et empile cinq aller-retours en latence. Une question simple traitée par erreur via l'agent paie ce surcoût pour rien.
Règle de sobriété : n'agentifiez que ce qui en a besoin. Une FAQ factuelle n'a pas besoin d'un agent ; une question multi-sauts, oui.
Oui : questions multi-sauts, comparaisons, recherche exploratoire, corpus hétérogène nécessitant un routage, cas où l'auto-vérification réduit fortement les erreurs.
Non : questions factuelles simples, contraintes de latence fortes (réponse temps réel), volumétrie massive où le coût par requête doit rester minimal. Dans ces cas, un RAG en une passe bien construit (hybride + reranking) reste le meilleur choix.
Pour décider sans dogmatisme, mesurez sur votre golden set et appliquez des seuils explicites :
Une approche pragmatique : commencer simple (RAG en une passe) et n'introduire l'agent que là où la mesure prouve que les questions complexes échouent. On évite ainsi de payer la complexité partout pour un bénéfice localisé. Un bon compromis intermédiaire est le routage à l'entrée : un classifieur léger envoie 90 % du trafic vers la passe unique et ne réveille l'agent que pour les 10 % qui le justifient.
L'agentic RAG n'est pas une mode à appliquer partout, mais un outil pour une classe de problèmes que le RAG en une passe ne sait pas traiter : les questions qui demandent de raisonner, décomposer et vérifier. Bien cadré — plafonné, tracé, mesuré — il fait passer un assistant de « répond souvent juste » à « répond juste même aux questions difficiles ». Mal cadré, il ajoute du coût et de l'imprévisibilité. La maturité, c'est de savoir lequel des deux mondes votre question exige — et, le plus souvent, de faire cohabiter les deux derrière un routage qui réserve l'artillerie lourde aux seules questions qui la méritent.
Le RAG en démo impressionne, en production il déçoit. Trois patterns changent tout : recherche hybride vectoriel + BM25 avec fusion RRF, reranking cross-encoder obligatoire, et décomposition des questions complexes en sous-requêtes.
Le RAG vectoriel récupère des passages isolés ; le GraphRAG relie les entités via un graphe de connaissances. Forces, faiblesses, coût d'ingestion et approche hybride : quand le graphe change vraiment la donne.
La similarité vectorielle comprend le sens mais rate le littéral (codes, acronymes). Recherche hybride dense + BM25 fusionnée par RRF, puis reranking cross-encoder : le combo qui rend un RAG vraiment précis.
Démarrez gratuitement. Premier audit Knowledge Pulse en 60 secondes.
Démarrer gratuitement