Résumé Technique : L'Agent en tant que Routeur (Agent-as-a-Router)

1. Énoncé du Problème

Les utilisateurs réels ont souvent accès à plusieurs modèles de langage (LLM) provenant de différents fournisseurs, chacun excellant dans des domaines distincts (par exemple, la conception d'algorithmes, la science des données ou la complétion de code), mais aucun ne domine l'ensemble des tâches. Les agents de codage actuels s'appuient généralement sur un seul LLM fixe pour toutes les tâches, une conception qui privilégie la prévisibilité du côté du fournisseur au détriment de l'efficacité des coûts et de la qualité par tâche pour l'utilisateur.

Le problème central est le routage automatique de modèles : déterminer quel modèle doit gérer chaque tâche de codage entrante afin de maximiser la performance tout en minimissant le coût. Les méthodes de routage existantes traitent cela comme un problème de classification statique et ponctuelle, employant souvent des modèles de langage comme politiques de routage. Cependant, des expériences préliminaires révèlent un écart de performance significatif entre ces routeurs statiques et un « oracle par tâche » (qui connaît le meilleur modèle pour chaque tâche spécifique). Le document identifie que le goulot d'étranglement des routeurs existants n'est pas un manque de capacité de raisonnement, mais un déficit d'information : les routeurs statiques ne parviennent pas à accumuler une expérience fondée sur l'exécution lors du déploiement.

2. Méthodologie

2.1. Diagnostic : Déficit d'Information

Les auteurs ont mené une étude d'ablation utilisant un routeur LLM zero-shot (propulsé par Claude Sonnet 4.6).

• Routeur Vanille : Score de performance moyenne (AvgPerf) de 41,41 %.
• + Statistiques de Performance : Lorsqu'on lui fournit des statistiques de performance préalables issues d'un ensemble de sondage (probing set) mis de côté, le score monte à 47,74 % (+15,3 % de gain relatif), dépassant même le meilleur routeur heuristique (47,50 %) qui encode les mêmes priors statiques.
• Conclusion : La limitation principale est l'absence d'informations dynamiques fondées sur l'exécution, et non la capacité de raisonnement du modèle de routage lui-même.

2.2. Le Cadre "Agent-as-a-Router"

Pour remédier au déficit d'information, les auteurs proposent le cadre Agent-as-a-Router, qui formalise le routage comme une boucle Contexte-Action-Feedback (C-A-F). Contra�à contrairement aux routeurs statiques, ce cadre évolue au fil d'un flux de tâches :

1. Contexte ($c_i$) : Le routeur observe le prompt de la tâche, les métadonnées et l'historique accumulé (Mémoire) des boucles précédentes.
2. Action ($a_i$) : Le routeur sélectionne un modèle parmi le pool de candidats.
3. Feedback ($f_i$) : La sortie du modèle sélectionné est exécutée dans un bac à sable (sandbox), et un vérificateur génère un score et un coût.
4. Mise à jour : Le feedback est mémorisé et fusionné dans le contexte pour la tâche suivante ($c_{i+1}$).

Cette formulation se rapporte à un problème de bandit multi-bras contextuel, où la métrique naturelle d'évaluation est le regret cumulé (l'écart accumulé entre la performance du routeur et l'oracle par tâche).

2.3. Instanciation ACRouter

Le cadre est instancié sous le nom d'ACRouter, comprenant trois modules de base :

• Orchestrateur : Prend les décisions de routage en intégrant le prior DimensionBest, les 10 voisins historiques les plus proches (récupérés via kNN par cosinus depuis la Mémoire), et les métadonnées de la tâche. Il utilise un modèle léger et affiné (fine-tuned) Qwen3.5-0.8B combiné à des règles heuristiques via un vote pondéré.
• Vérificateur : Évalue les sorties des modèles dans un environnement sandboxé. Il agrège des signaux (parsing AST, résultats d'exécution, LLM-as-Judge) en un score de performance unifié ($u_i \in [0, 1]$).
• Mémoire : Un magasin de vecteurs en ligne indexé par les embeddings de tâches. Il enregistre le modèle choisi, la performance, le coût et les traces de vérification. Il utilise un magasin à limite FIFO (20K entrées) pour permettre une récupération fine et sensible au contexte des succès et échecs passés.

2.4. CodeRouterBench

Pour évaluer le routage sur des flux de tâches, les auteurs introduisent CodeRouterBench, un benchmark comprenant :

• ~10 000 tâches réparties sur 10 dimensions de codage (9 tâches single-turn en distribution et 1 dimension de programmation agentique hors distribution).
• 8 LLM de pointe (incluant Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5, etc.).
• Scores vérifiés par exécution : Les tâches sont évaluées via une exécution en sandbox ou par LLM-as-Judge, fournissant une matrice d'observation de vérité terrain pour la comparaison basée sur le regret.

3. Contributions Clés

1. Cadre : La proposition de l'Agent-as-a-Router, qui formalise le routage de modèles comme une boucle C-A-F, permettant aux routeurs de combler activement l'écart d'information grâce à un feedback fondé sur l'exécution.
2. Artefacts :
   • ACRouter : Une instanciation concrète du cadre avec les modules Orchestrateur, Vérificateur et Mémoire.
   • CodeRouterBench : Un environnement d'évaluation standardisé (~10K tâches, 8 LLM) conçu spécifiquement pour la comparaison de routeurs basée sur le regret sur des flux de tâches, incluant un banc d'essai de programmation agentique OOD (hors distribution).
3. Résultats :
   • Déficit d'Information : Le goulot d'étranglement du routage est l'accès à l'information, non le raisonnement. Fournir des statistiques de performance génère un gain relatif de 15,3 %.
   • Performance : ACRouter atteint le regret cumulé le plus bas sur les tâches en distribution (ID) et généralise efficacement aux tâches de programmation agentique hors distribution (OOD).
   • Limites du Statique : Les routeurs statiques légers (classificateurs entraînés, heuristiques) performent raisonnablement sur les tâches ID mais échouent de manière significative sur les tâches OOD, là où ACRouter maintient une performance solide.

4. Résultats Expérimentaux

Les expériences ont été menées sur des flux de tâches en distribution (ID) et hors distribution (OOD).

• Performance en Distribution (ID) :

  • ACRouter a atteint la performance moyenne la plus élevée (49,98 %) et le regret cumulé le plus bas (205,5), surpassant l'heuristique statique "DimensionBest" (47,50 %) et tous les modèles de base (baselines) de politique entraînée.
  • Il a également démontré une meilleure efficacité des coûts (ratio Perf/$ de 3,79) par rapport à l'utilisation systématique du modèle le plus puissant (Always-Opus 4.6, qui avait un ratio de 1,29).

• Généralisation Hors Distribution (OOD) :

  • Sur le banc d'essai de programmation agentique (176 tâches), ACRouter a atteint 62,50 % d'AvgPerf, surpassant nettement la baseline Always-Opus (57,14 %) et tous les autres routeurs.
  • Les classificateurs statiques (ex: LogReg, RouteLLM-BERT) se sont effondrés sur les tâches OOD, avec des performances chutant entre 8,93 % et 21,43 %, soit moins qu'une sélection aléatoire.
  • La capacité d'ACRouter à accumuler une expérience vérifiée pendant le flux lui a permis de s'adapter à la nouvelle distribution de tâches, contrairement aux méthodes statiques reposant sur des priors figés.

• Analyse des Coûts :

  • Bien qu'ACRouter incurre des frais pour les modules Mémoire et Vérificateur, il reste plus rentable que de toujours sélectionner le modèle le plus coûteux (Opus 4.6) tout en délivrant une qualité supérieure.
  • La stratégie "Always-Kimi-K2.5" offrait l'efficacité de coût la plus élevée (Perf/$ 12,62) mais au prix d'une perte substantielle de performance absolue (36,66 % AvgPerf).

5. Signification et Revendications

Le document affirme qu'agir pour combler l'écart d'information par un feedback fondé sur l'exécution est un principe général pour construire des systèmes agentiques devant router entre des outils ou des modèles hétérogènes.

• Changement de Paradigme : Ce travail déplace le routage d'un problème de classification statique vers un processus dynamique et auto-adaptatif (boucle C-A-F).
• Utilité Pratique : Il démontre que les utilisateurs peuvent atteindre une performance proche de l'oracle et une efficacité des coûts optimale en routant dynamiquement les tâches, plutôt qu'en s'appuyant sur un seul "meilleur" modèle.
• Généralisabilité : La boucle C-A-F est présentée non seulement comme un mécanisme de routage, mais comme un paradigme de décision plus large applicable à la sélection d'outils, la sélection de points de terminaison d'API et l'allocation d'efforts.
• Modestie : Les auteurs reconnaissent des limites, telles que l'impossibilité d'observer les taux de succès du cache côté fournisseur (rendant les estimations de coût relatives plutôt qu'absolues) et l'utilisation d'une limite d'étapes réduite pour les tâches OOD afin de maintenir la tractabilité du budget. Ils notent que si leur instanciation actuelle utilise une politique LLM avec une mémoire kNN, d'autres techniques de mémoire au niveau des paramètres restent à explorer.

En résumé, l'article soutient que pour les systèmes de codage agentiques, l'avenir ne réside pas dans la recherche d'un modèle unique dominant, mais dans la construction de routeurs adaptatifs qui apprennent du feedback d'exécution pour sélectionner le bon outil pour la bonne tâche.