Agentic RAG vs RAG classique : quelle est la différence ?

Agentic RAG est une évolution de la Retrieval-Augmented Generation dans laquelle un agent IA autonome décide de manière dynamique si des connaissances sont récupérées, lesquelles et combien de fois. Le retrieval est alors un outil que l'agent appelle de façon réflexive, en plusieurs étapes et à partir de plusieurs sources. Le RAG classique, lui, fait passer chaque requête par un pipeline fixe, exécuté une seule fois, sans logique de décision.

• RAG classique = pipeline statique : embedding, une seule récupération, insertion dans le prompt, génération. Toujours le même déroulement.
• Agentic RAG = politique d'outils dynamique : un agent planifie, décide pour chaque requête, appelle le retrieval de manière itérative et se corrige lui-même.
• Compromis : Agentic RAG améliore la qualité sur les questions complexes, mais coûte davantage en latence et en argent, et comporte un risque de boucles d'outils incontrôlées.

RAG classique : le pipeline statique

Le RAG classique (classé dans la recherche comme Naive RAG et Advanced RAG, Gao et al. 2023/2024) suit un déroulement déterministe. La requête passe toujours par la même séquence d'étapes, qu'il s'agisse d'une question factuelle triviale ou d'une question imbriquée en plusieurs étapes.

Le chemin type d'une requête dans un pipeline RAG classique en production se présente ainsi :

1. Requête de l'utilisateur
2. Query Rewriter / HyDE (optionnel, une seule fois)
3. Embedding + requête BM25
4. Retrieval hybride (top_k = 50-100)
5. Re-Ranker (top_k = 5-10)
6. Modèle de prompt + citation des sources
7. LLM (générateur)
8. Sortie + contrôle de faithfulness

L'hypothèse centrale : une seule étape de retrieval fournit suffisamment de contexte pour la réponse. C'est solide, prévisible et facile à mesurer. La faiblesse apparaît avec les questions qui nécessitent plusieurs tours de récupération, pour lesquelles on ne sait pas quelle source est pertinente, ou dont la formulation initiale correspond mal à l'index. Le pipeline ne peut ni relancer une recherche, ni changer de cap, ni solliciter une deuxième source, car il n'a pas de logique de décision.

Agentic RAG : le retrieval comme outil d'un agent

Selon la revue de référence de Singh et al. 2025 (arXiv:2501.09136), Agentic RAG intègre des agents autonomes dans le pipeline RAG. Ces agents s'appuient sur quatre patterns de conception agentiques pour piloter dynamiquement la stratégie de retrieval :

• Reflection (autocritique) : l'agent évalue les sources récupérées et sa propre réponse intermédiaire, puis décide s'il faut relancer une recherche.
• Planning : l'agent décompose une question complexe en sous-étapes (Plan-and-Execute).
• Tool Use : le retrieval n'est qu'un outil parmi d'autres, à côté de la recherche web, des requêtes en base de données ou d'autres API.
• Multi-Agent Collaboration : plusieurs agents spécialisés se répartissent le travail.

Une formalisation précoce de ce principe est Self-RAG (Asai et al. 2023, arXiv:2310.11511), qui apprend, grâce à des tokens d'autoréflexion, quand une récupération est nécessaire et si la génération reste fidèle aux sources. Sur le plan conceptuel, une architecture Agentic RAG ressemble à ceci :

• Agent (planificateur) : planifie les étapes et choisit l'outil adapté.
• Outil search_kb(query) : appelle le pipeline RAG.
• Outil web_search(query) : effectue une recherche sur le web.
• Outil db_query(...) : interroge des données structurées.
• Mémoire : tampon de conversation et mémoire épisodique.
• Reflection : critique(answer, sources) vérifie la réponse par rapport aux sources et déclenche un nouveau tour si nécessaire.

Les quatre décisions que prend un agent

La différence décisive se résume à quatre décisions prises à l'exécution, qui sont figées dans le RAG classique :

• SI le retrieval a lieu (routage des requêtes) : une salutation ou un simple calcul ne nécessite aucune récupération. L'agent peut sauter le retrieval.
• QUOI récupérer (réécriture des requêtes, choix de la source) : l'agent reformule la requête ou l'oriente vers la source adaptée (base de connaissances interne, web ou base de données structurée).
• COMBIEN DE FOIS récupérer (multi-hop) : si une réponse ne suffit pas, l'agent relance avec une requête affinée.
• SI la réponse tient la route (autocorrection) : grâce à la Reflection, l'agent vérifie le résultat par rapport aux sources et corrige, au lieu de générer à l'aveugle.

Comparaison directe

Sources : Gao et al. 2023/2024 (arXiv:2312.10997) ; Singh et al. 2025 (arXiv:2501.09136).

Avantages et inconvénients : qualité contre latence et coûts

La force d'Agentic RAG, c'est la qualité de réponse sur les questions complexes. Les questions multi-hop (« Quel fournisseur de la région X a eu le taux de réclamation le plus élevé au dernier trimestre, et que dit le contrat-cadre à ce sujet ? ») exigent plusieurs récupérations dans plusieurs sources, plus un raisonnement intermédiaire. Un pipeline statique échoue structurellement face à elles ; un agent peut les résoudre étape par étape.

Cette qualité a un prix concret :

• Latence : chaque tour de Reflection et de multi-hop est un appel LLM supplémentaire. Une réponse peut vite se transformer en trois à cinq générations séquentielles.
• Coûts : plus d'appels LLM par requête signifie directement des coûts plus élevés. En allemand s'ajoute une difficulté : selon le tokenizer, les mots composés allemands consomment environ 1,3 à 1,7 fois plus de tokens que leur équivalent anglais, ce qui renchérit chaque étape de raisonnement supplémentaire.
• Stabilité : le mode de défaillance typique documenté dans la recherche, ce sont les boucles d'outils incontrôlées et l'explosion des coûts (Singh et al. 2025). Sans limites strictes sur les itérations, le budget et le timeout, le comportement devient imprévisible.
• Maturité du terme : en 2026, « Agentic RAG » n'est pas encore un terme clairement stabilisé. Il va du simple ReAct avec retriever jusqu'aux architectures multi-agents (HM-RAG, M-RAG). C'est à prendre en compte dans le choix des outils et la gestion des attentes.

Point important pour situer le sujet : Agentic RAG s'appuie sur le RAG classique et ne le remplace pas. Le pipeline sous-jacent (recherche hybride, re-ranking, Contextual Retrieval) reste le socle que l'agent appelle comme outil. De même, le débat parallèle sur le contexte long (fenêtres de contexte de 1-2 millions de tokens) constitue en 2026 un complément au RAG, pas un remplacement : dans le test multi-needle du rapport Gemini 1.5 Pro (Google, 2024 ; version du modèle de février 2024, 100 needles, jusqu'à 1 million de tokens), le recall n'atteignait qu'un peu plus de 60 %. S'y ajoutent, avec un contexte long, une latence et des coûts par requête nettement plus élevés qu'avec une récupération RAG ciblée.

Exemple concret : la même question, deux architectures

Requête : « Compare nos durées de conservation RGPD avec la pratique actuelle des autorités de contrôle et indique les écarts. »

RAG classique : embedding de la question, une récupération hybride dans la base de connaissances interne, re-ranking sur le top 5, génération. Résultat : les durées de conservation internes sont citées correctement. La « pratique actuelle des autorités de contrôle » manque, car elle ne figure pas dans la base interne et le pipeline ne peut pas interroger une deuxième source. Une seule génération, des coûts faibles et stables, mais une réponse incomplète.

Agentic RAG : l'agent planifie deux sous-questions. Étape 1 : search_kb("interne DSGVO-Löschfristen") fournit les valeurs internes. Étape 2 : la Reflection détecte que le référentiel de comparaison externe manque et appelle web_search("aktuelle Aufsichtspraxis Löschfristen"). Étape 3 : l'agent combine les deux sources et signale les écarts. Résultat : une réponse complète, mais trois tours de LLM au lieu d'un, avec une latence et des coûts plus élevés en conséquence.

Cette comparaison fait apparaître le critère de décision : l'effort supplémentaire par requête est-il rentable au regard du gain de qualité pour le cas d'usage concerné ?

Quand Agentic RAG est rentable

Agentic RAG se justifie si au moins l'un de ces facteurs s'applique :

• Une part significative des requêtes nécessite un raisonnement multi-hop portant sur plusieurs faits.
• Plusieurs sources hétérogènes doivent être intégrées (base de connaissances interne, web, base de données structurée).
• Les requêtes sont souvent ambiguës et bénéficient du routage et de la réécriture des requêtes.
• Un pipeline fixe unique fournit des scores de faithfulness ou de context recall trop faibles, mesures à l'appui (RAGAS).

Le compromis pragmatique est un hybride avec routage : un chemin classique rapide pour la majorité des questions factuelles simples et un chemin agentique réservé aux cas complexes. Les coûts élevés n'apparaissent ainsi que là où ils améliorent réellement la réponse. Dans tous les cas, il faut des garde-fous stricts : limite d'itérations, budget de coûts par requête, timeout et tracing de bout en bout (par exemple LangSmith ou Arize Phoenix).

Pour les agences et les décideurs B2B

Pour les agences et les équipes B2B en Europe, le message est sobre : Agentic RAG est un choix d'architecture délibéré, avec des conséquences sur les coûts, et non une mise à niveau standard. Commence par un pipeline RAG classique propre (recherche hybride, re-ranking, évaluation avec RAGAS) et mesure d'abord où il échoue sur les questions multi-hop ou multi-sources. Seules ces données justifient le passage à Agentic RAG et te fournissent l'argument pour défendre le budget. Si tu veux planifier ou évaluer cette architecture, le routage entre chemin classique et chemin agentique et les garde-fous nécessaires pour le marché européen, Blck Alpaca t'accompagne du choix d'architecture jusqu'à une mise en production conforme au RGPD, avec hébergement dans l'UE.