Le routeur de modèles devient un agent apprenant

Résumé exécutif

Publié le 22 juin 2026, Agent-as-a-Router propose de remplacer le routage statique entre modèles par une boucle agentique qui apprend des exécutions réelles. Pour l’UAH, le signal est directement exploitable : le futur ModelRouterPort ne devrait pas seulement classifier une requête, mais accumuler des preuves sur le triplet tâche–modèle–résultat, puis ajuster ses décisions selon la qualité, le coût et le risque observés.

Ce qui vient de sortir

Les routeurs multi-modèles classiques choisissent un LLM à partir du prompt, de métadonnées ou de statistiques historiques. Les auteurs identifient une faiblesse centrale : le routeur manque d’informations sur ce qui se passe après la sélection. Ils montrent qu’ajouter de simples statistiques de performance par dimension de tâche améliore déjà le résultat relatif de 15,3 % par rapport à un routeur LLM sans ce contexte.

Le framework proposé formalise un cycle Context → Action → Feedback → Context. Son implémentation, ACRouter, combine un orchestrateur, un vérificateur et une mémoire. Le benchmark CodeRouterBench réunit environ 10 000 tâches de code et les scores vérifiés de huit modèles afin de comparer les routeurs par regret cumulé plutôt que par précision de classification isolée.

Fonctionnement technique

Le routeur reçoit le contexte de la tâche et l’état de sa mémoire. Il choisit un modèle, observe l’exécution, fait vérifier le résultat, puis transforme ce feedback en expérience réutilisable. Le routage devient donc une politique adaptative soumise à une boucle de preuve, proche d’un contextual bandit, plutôt qu’une table statique.

Pourquoi cela compte pour l’UAH

Cette architecture correspond au chaînon manquant entre l’Agentic Capability Gateway, les AAS spécialisés et un parc hétérogène de modèles locaux ou distants. Elle permettrait d’isoler le routage derrière un port agnostique, de brancher plusieurs politiques et d’utiliser le Reward Outcome Ledger comme mémoire d’apprentissage.

Le point important n’est pas de copier ACRouter, mais de reprendre son contrat : chaque décision doit produire une observation exploitable comprenant la tâche, le modèle choisi, le coût, la latence, les vérifications, le succès et les éventuels incidents.

Limites et points de vigilance

Les résultats portent principalement sur des tâches de programmation. La généralisation aux workflows de veille, de rédaction, de sécurité ou d’administration reste à démontrer. Le vérificateur peut aussi devenir un point de coût ou reproduire les biais du modèle évalué. Enfin, une politique apprenante peut exploiter de mauvaises métriques si les critères de succès sont incomplets.

Recommandation opérationnelle

Décision : expérimenter en shadow mode.

Créer un ModelRouterPort avec trois adapters : règle déterministe, score historique et politique agentique. Journaliser les décisions sans modifier la production, puis mesurer sur un corpus UAH : taux de succès vérifié, coût par outcome, latence, regret par rapport au meilleur modèle disponible et stabilité hors distribution. Ne promouvoir la politique agentique que si elle améliore le coût par succès sans dégrader la sécurité ni la reproductibilité.

Sources

Pengfei Zhou et al., « Agent-as-a-Router: Agentic Model Routing for Coding Tasks », arXiv, 22 juin 2026 : https://arxiv.org/abs/2606.22902
Jiahao Zeng, Ming Tang, Ningning Ding, « Learning to Route LLMs from Implicit Cost-Performance Preferences via Meta-Learning », arXiv, 4 juin 2026 : https://arxiv.org/abs/2606.06178
Jack Bell et al., « Continual Model Routing in Evolving Model Hubs », arXiv, 27 mai 2026 : https://arxiv.org/abs/2605.28577