Dynamic routing : l’orchestration adaptative des agents IA

Un système RAG traite une question factuelle simple et une requête complexe qui nécessite de croiser trois sources, vérifier une date, puis raisonner sur le résultat. Les deux empruntent le même pipeline, les mêmes étapes, dans le même ordre. Le routage dynamique corrige ce déséquilibre en donnant au système la capacité de choisir, à chaque étape, le bon chemin selon ce qu’il est en train de traiter.

Le pipeline statique casse

Le pipeline RAG (Retrieval Augmented Generation, une technique où le système cherche dans des documents externes avant de générer sa réponse) classique fonctionne en trois étapes fixes ^[1]. D’abord, on découpe les documents en morceaux de taille gérable (des « chunks », segments de texte de quelques centaines de mots). Ensuite, on calcule une représentation vectorielle (un « embedding », la traduction numérique qui capture le sens du texte) de chaque chunk et de la requête. Enfin, on récupère les chunks les plus similaires (les « top-k », les k résultats les plus proches dans l’espace vectoriel) et on les transmet au modèle pour générer une réponse.

Pour une question factuelle directe, ce pipeline fonctionne. Mais face à des requêtes qui demandent de relier des informations dispersées dans plusieurs documents (des tâches « multi-hop », nécessitant plusieurs sauts de raisonnement entre sources), il s’effondre.

L’analyse du survey GA-RAG ^[2] le montre avec des chiffres concrets. Le paradigme Naive Graph RAG, qui se contente de récupérer les nœuds les plus proches dans un index vectoriel, obtient un score multi-hop de 23 à 56. En revanche, Agentic Graph RAG, qui fait intervenir un agent orchestrateur et des agents travailleurs planifiant et s’adaptant dynamiquement, atteint 44 à 81 sur les mêmes benchmarks ^[2].

Pire, augmenter naïvement le volume de documents récupérés ne résout pas le problème. Le système ReSP montre qu’à partir d’un certain seuil de chunks, la performance se dégrade : le contexte s’encombre, le modèle perd le fil des informations pertinentes ^[3]. Ce phomenène de surcharge contextuelle affecte toutes les approches RAG, y compris les méthodes itératives comme IRCoT ^[3].

Le problème fondamental : chaque requête appelle une stratégie différente. Une question factuelle a besoin d’une seule passe de récupération. Une question multi-hop nécessite des allers-retours entre récupération et raisonnement. Une analyse complexe exige des appels d’outils et une planification. Un pipeline figé ne peut pas faire cette distinction.

Ce que « dynamic routing » veut dire en contexte agentic

En contexte agentic, le dynamic routing est le mécanisme par lequel un système choisit, à chaque étape de son traitement, quel agent, quel modèle, quel outil ou quel chemin d’exécution activer, en fonction du contexte courant : la requête elle-même, l’historique des étapes précédentes et les résultats intermédiaires ^[4].

La logique de routage peut reposer sur de la classification (catégoriser la requête pour la diriger vers un gestionnaire spécialisé), des heuristiques (des seuils de confiance et des règles prédéfinies) ou des arbres de décision appris à partir de données ^[4].

C’est distinct du model switching, qui désigne le processus plus large de sélectionner un modèle spécialisé différent selon les exigences de la tâche, les préférences de l’utilisateur ou des objectifs d’optimisation des performances ^[4]. Le dynamic routing opère à un niveau plus granulaire : il décide quoi faire à chaque pas de temps dans un workflow, pas seulement au point d’entrée.

L’analogie : le model switching, c’est choisir entre une calculatrice et un traitement de texte avant de commencer. Le dynamic routing, c’est décider, en cours de tâche, s’il faut aller chercher plus de données, appeler un agent de raisonnement, ou générer la réponse finale.

Les trois familles de logique de routage

Trois approches concrètes coexistent, chacune avec ses forces et ses compromis.

Le routage par classification. Le système catégorise la requête entrante (question factuelle, requête analytique, demande d’opinion) et la dirige vers un gestionnaire spécialisé. C’est rapide, mais rigide : le routage se fait une fois, à l’entrée, et ne s’adapte pas si la tâche se révèle plus complexe que prévu.

Le routage par heuristiques. Des règles et des seuils déclenchent différents chemins en temps réel. Le système CRAG (Corrective RAG) illustre cette approche : un évaluateur léger mesure la qualité des documents récupérés et retourne un degré de confiance ^[5]. Si la confiance est insuffisante, le système déclenche une recherche web pour enrichir les résultats, puis applique un algorithme de décomposition-recomposition pour extraire les informations clés et filtrer le bruit ^[5]. Cette approche est réactive et adaptative, sans nécessiter d’entraînement préalable.

Le routage par apprentissage par renforcement (RL). Le système apprend de ses erreurs pour améliorer ses décisions de routage au fil du temps. RI-ARAG (Reinforcement Integrated Agentic RAG) intègre des mécanismes de RL dans un système multi-agents : le retour d’exécution des tests qualité sert de signal de récompense, permettant une amélioration continue sans intervention humaine ^[6]. Cette approche a produit une amélioration de 10,8% de la détection de défauts et une réduction de 23% des faux positifs ^[6].

Approche	Vitesse	Adaptativité	Entraînement requis	Exemple concret
Classification	Rapide	Faible (routage initial uniquement)	Labels supervisés	Classificateur d’intention de requête
Heuristiques	Moyenne	Moyenne (réactive)	Aucun (règles manuelles)	CRAG [5]
RL	Plus lente	Élevée (apprend dans le temps)	Signal de récompense + trajectoires	RI-ARAG [6]

Le pattern orchestrateur-travailleurs : où le routing opère

C’est ici que le dynamic routing prend vie dans une architecture concrète.

Le système décrit dans GA-RAG ^[2][7] repose sur un ensemble d’agents spécialisés par tâche : un planner (qui planifie les étapes du raisonnement), un searcher (qui cherche l’information pertinente) et un reasoner (qui raisonne sur les résultats collectés) ^[7]. Un agent coordinateur central orchestre le workflow : il invoque dynamiquement les agents, route l’information entre eux et suit la progression vers une réponse finale ^[7].

Le coordinateur garde le contrôle sur le processus de décision et termine le workflow une fois qu’une sortie satisfaisante est produite ^[7]. Ce point est essentiel : le système ne suit pas une séquence fixe. Il boucle, s’adapte aux résultats intermédiaires, et s’arrête quand il a trouvé la réponse.

Le dynamic routing opère à deux niveaux dans ce cycle. Le coordinateur décide d’abord quel agent invoquer (ou ré-invoquer) en fonction des résultats intermédiaires. Chaque agent peut ensuite décider de la stratégie à employer : chercher dans le graphe de connaissances, lancer une recherche web, décomposer la question.

Ce fonctionnement s’inscrit dans la boucle think-act-observe telle que décrite dans les architectures d’applications agentic ^[8] :

Concrètement, le cycle fonctionne ainsi ^[8] :

1. Percevoir : lire les signaux entrants (entrée utilisateur, sortie d’outil, état de la conversation).
2. Réfléchir : planifier la prochaine étape, décider si un outil est nécessaire, façonner le prochain tour de prompt. C’est ici que la décision de routage se prend.
3. Agir : exécuter une action (appeler un outil, lancer du code, chercher des données).
4. Observer : capturer le résultat et le normaliser dans le contexte de travail.
5. Évaluer : vérifier la progression par rapport à l’objectif, réviser le plan, décider de continuer ou d’arrêter.
6. Mémoriser : stocker les éléments de travail à court terme et les faits à long terme en mémoire externe.

Pour entraîner de tels systèmes, GA-RAG utilise une approche d’auto-entraînement : des trajectoires d’interaction diverses entre agents sont générées pour chaque entrée, évaluées par un modèle de récompense, et les trajectoires à haute récompense deviennent des données de supervision ^[7]. Cela crée une boucle vertueuse où les décisions de routage s’améliorent automatiquement.

Les patterns de workflow construits sur le routing

Le dynamic routing n’est pas une fonctionnalité isolée ; c’est le socle qui rend possibles plusieurs patterns opérationnels, du plus simple au plus sophistiqué.

Prompt chaining (chaînage de prompts). Une tâche complexe est décomposée en étapes séquentielles où chaque étape construit sur la précédente ^[9]. Le routage détermine comment décomposer la tâche et quel sous-agent gère chaque étape. Cette approche améliore la précision en simplifiant chaque sous-tâche avant de passer à la suivante ^[9].

Modular Graph RAG. Le pipeline est découpé en étapes découplées : récupération de sous-graphe, puis raisonnement et réordonnancement sur le graphe, puis génération ^[2]. Le routage opère entre les étapes, décidant s’il faut affiner le sous-graphe, re-raisonner, ou passer à la génération. Ce paradigme atteint des scores multi-hop de 48 à 81, un bond significatif par rapport aux 23 à 56 des approches naïves ^[2].

Agentic Graph RAG. Les agents orchestrateurs et travailleurs planifient, réfléchissent et invoquent des outils graphiques de façon adaptative ^[2]. Ce paradigme atteint 44 à 81 avec l’avantage de l’autocorrection et de la scalabilité via la conception modulaire des agents ^[2].

CRAG (Corrective RAG). L’évaluateur de récupération déclenche différentes stratégies (générer directement, enrichir via une recherche web, décomposer et recomposer les documents pour isoler les informations clés) selon la qualité des résultats ^[5]. C’est du routage au niveau de la récupération elle-même.

Golden-Retriever. Conçu pour des bases de connaissances industrielles vastes où le jargon spécialisé rend la récupération classique insuffisante, ce système navigue efficacement en adaptant sa stratégie de recherche au type de requête ^[10].

La progression est nette :

Paradigme	Score multi-hop	Idée clé	Forces	Limites
Naive Graph RAG	23 à 56	Index vectoriel, top-k	Simple, efficace pour factuel	Ignore la structure, échoue en multi-hop
Advanced Graph RAG	36 à 72	Clustering hiérarchique	Raisonnement abstrait, réduction du bruit	Dépend de la qualité du clustering
Modular Graph RAG	48 à 81	Étapes découplées	Robuste, raffinement itératif	Plus lent (multi-étapes)
Agentic Graph RAG	44 à 81	Orchestrateur + agents adaptatifs	Auto-correction, scalable	Complexité d’orchestration

Du retrieval statique au routing agentic, la performance multi-hop presque double ^[2].

Quand router, quand chaîner : les arbitrages

Tout système n’a pas besoin d’un routing agentic complet. Le choix repose sur des compromis opérationnels concrets.

La complexité de la tâche est le premier critère. Pour des requêtes factuelles simples, un pipeline RAG classique suffit. L’évaluation TagRAG sur quatre jeux de données (Agriculture : 12 documents, 1 756 chunks ; CS : 10 documents, 1 858 chunks ; Legal : 94 documents, 4 294 chunks ; Mix : 61 documents, 579 chunks) montre que des méthodes RAG de base traitent correctement les requêtes directes ^[11]. Les questions multi-hop, qui nécessitent de croiser plusieurs documents, exigent une récupération itérative ou du routage agentic ^[2][3].

Le budget de latence façonne l’architecture. Les applications interactives de type chat exécutent des chemins de requête synchrones où la latence est critique, nécessitant des modèles préchauffés, des orchestrateurs légers et un minimum d’allers-retours ^[8]. Les services backend asynchrones privilégient l’idempotence et la cohérence éventuelle plutôt que le temps de réponse brut ^[8]. Si vos utilisateurs attendent des réponses en moins d’une seconde, un routing agentic complet avec de multiples invocations d’agents sera probablement trop coûteux en latence.

Le coût d’infrastructure. Chaque décision de routage et invocation d’agent ajoute du calcul. L’approche de récupération multi-tours de ReSP est plus précise mais traite plus de tokens par requête ^[3]. Le fallback de recherche web de CRAG ajoute des appels API externes ^[5]. L’arbitrage se fait entre précision et coût opérationnel.

L’explicabilité. Les systèmes agentic avec des décisions de routage explicites sont plus interprétables : on peut tracer quel agent a été appelé, pourquoi, et ce qu’il a retourné ^[2]. Les pipelines boîte noire n’offrent pas cette visibilité.

Critère	RAG simple	RAG itératif	Routing agentic complet
Type de requête	Factuel	Multi-hop	Analyse complexe, multi-outils
Tolérance latence	Faible requise	Moyenne	Plus élevée acceptable
Précision requise	Suffisante	Bonne	Optimale
Coût opérationnel	Faible	Moyen	Plus élevé
Explicabilité	Faible	Moyenne	Élevée

Construire son premier système à routage dynamique

Voici une progression opérationnelle en cinq étapes, de la simplicité vers l’autonomie.

Étape 1 : un agent unique avec un outil RAG. Commencez simple. Construisez un agent LLM (un modèle de langage capable d’utiliser des outils) muni d’un seul outil de récupération. L’exemple de l’agent analyste financier utilise un agent LlmAgent configuré avec une persona et un outil knowledge_lookup qui encapsule tout le pipeline RAG : connexion à la base de données, calcul de l’embedding, recherche vectorielle (HNSW, un algorithme de recherche approximative rapide), retour des résultats ^[12]. L’agent décide lui-même quand appeler l’outil et comment exploiter les résultats. C’est déjà du routage : l’agent « choisit » de chercher plutôt que de répondre de mémoire.

Étape 2 : ajouter un orchestrateur. Passez à un coordinateur central qui dispatche les requêtes vers des agents spécialisés. L’architecture GA-RAG montre comment un coordinateur invoque dynamiquement des agents planner, searcher et reasoner selon la tâche ^[7]. Le coordinateur décide de l’ordre, du nombre d’itérations et du moment d’arrêt.

Étape 3 : mémoire partagée. Ajoutez une architecture de type « tableau noir » (blackboard) où les agents partagent le contexte ^[13]. Les architectures de mémoire basées sur des graphes de connaissances supportent la cohérence multi-session et l’adaptation personnalisée ^[14]. Cela permet aux agents de capitaliser sur le travail des autres sans traitement redondant.

Étape 4 : boucle d’amélioration continue. Mettez en place une optimisation pilotée par le feedback. RI-ARAG démontre que des mécanismes de RL intégrés à un système multi-agents permettent une amélioration continue : le système apprend du retour d’exécution et s’adapte sans intervention humaine ^[6]. SwarmAgentic va plus loin : des systèmes d’agents optimisés sur un modèle (GPT-4o-mini) se transfèrent efficacement vers d’autres modèles (Gemini-1.5-Pro), avec des gains supplémentaires lors d’optimisations spécifiques au modèle cible ^[15].

Étape 5 : évaluation et monitoring. Suivez les décisions de routage, mesurez la précision par type de requête et surveillez la surcharge contextuelle. ReSP alerte sur le fait que la performance se dégrade quand trop de contexte s’accumule ^[3] ; votre logique de routage devrait inclure des contrôles de qualité à chaque étape, à l’image de l’évaluateur de récupération de CRAG ^[5].

Sources

• [1] A Comprehensive Survey on Long Context Language Modeling · Jiaheng Liu et al. · 2025 · preprint · arXiv:2503.17407
• [2] Graph-Based Agentic Retrieval-Augmented · 2025 · livre · Amazon
• [3] Retrieve, Summarize, Plan: Advancing Multi-hop Question Answering with an Iterative Approach · Zhouyu Jiang et al. · 2024 · preprint · arXiv:2407.13101
• [4] Designing AI Interfaces Design Principles for Creative and Autonomous AI · livre · Amazon
• [5] Corrective Retrieval Augmented Generation · Shi-Qi Yan et al. · 2024 · preprint · arXiv:2401.15884
• [6] Reinforcement Learning Integrated Agentic RAG for Software Test Cases Authoring · Mohanakrishnan Hariharan · 2025 · preprint · arXiv:2512.06060
• [7] CIIR@LiveRAG 2025: Optimizing Multi-Agent Retrieval Augmented Generation through Self-Training · Alireza Salemi et al. · 2025 · preprint · arXiv:2506.10844
• [8] Generative AI on Kubernetes Operationalizing Large Language Models · livre · Amazon
• [9] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG · Aditi Singh et al. · 2025 · preprint · arXiv:2501.09136
• [10] Golden-Retriever: High-Fidelity Agentic Retrieval Augmented Generation for Industrial Knowledge Base · Zhiyu An et al. · 2024 · preprint · arXiv:2408.00798
• [11] TagRAG: Tag-guided Hierarchical Knowledge Graph Retrieval-Augmented Generation · Wenbiao Tao et al. · 2025 · preprint · arXiv:2601.05254
• [12] GenAI on Google Cloud Enterprise Generative AI Systems and Agents · livre · Amazon
• [13] Agentic AI for Engineers · livre · Amazon
• [14] Graph-based Agent Memory Taxonomy, Techniques, and Applications · Chang Yang et al. · 2026 · preprint · arXiv:2602.05665
• [15] SwarmAgentic: Towards Fully Automated Agentic System Generation via Swarm Intelligence · Yao Zhang et al. · 2025 · preprint · arXiv:2506.15672