Résumé Technique : Hera – Apprentissage de la Coordination à Long Terme pour les Agents LLM Collaboratifs Dispositif–Cloud

1. Énoncé du Problème

Les agents basés sur les Grands Modèles de Langage (LLM) ont démontré leur capacité à résoudre des tâches complexes à long terme grâce à une interaction autonome avec des environnements. Cependant, leur déploiement dans le monde réel se heurte à un dilemme fondamental dispositif–cloud :

• Contraintes côté dispositif : Les modèles locaux (généralement <10 milliards de paramètres) sont efficaces et à faible latence, mais manquent souvent de la profondeur de raisonnement requise pour la planification complexe multi-étapes, entraînant une dégradation des performances et des trajectoires incohérentes.
• Limitations côté cloud : Les modèles cloud puissants offrent un raisonnement supérieur mais introduisent une latence réseau significative, des coûts de calcul élevés et des préoccupations en matière de confidentialité, les rendant peu pratiques pour les applications en temps réel comme la robotique ou la navigation d'interfaces graphiques interactives.

Les méthodes existantes de routage dispositif–cloud prennent généralement des décisions grossières au niveau de la tâche, affectant l'intégralité d'une requête soit au dispositif, soit au cloud, en fonction de la difficulté estimée ou de la confiance. Cette approche « tout ou rien » est inadaptée aux tâches d'agents à long terme où l'exécution se déroule comme une séquence d'étapes interdépendantes de difficulté variable. L'article postule qu'une stratégie de coordination au niveau de l'étape, plus fine, est nécessaire pour équilibrer efficacement la réussite de la tâche et le coût d'inférence.

2. Méthodologie : Le Cadre Hera

Les auteurs proposent Hera, un coordinateur dispositif–cloud léger au niveau de l'étape conçu pour optimiser le compromis entre la réussite de la tâche et l'utilisation du cloud. Hera est un Transformer uniquement décodeur de 500 millions de paramètres avec une tête de classification binaire qui décide, à chaque étape d'interaction $t$, d'acheminer l'état vers la politique locale du dispositif ($\pi_{\theta_d}$) ou vers la politique du cloud ($\pi_{\theta_c}$).

Hera emploie un paradigme d'entraînement en deux étapes novateur :

Étape 1 : Démarrage à froid par Apprentissage par Imitation (IL)

Pour initialiser la politique de routage sans signaux de renforcement directs, les auteurs utilisent l'apprentissage par imitation :

1. Collecte de Trajectoires : Les agents dispositif et cloud sont déployés pour générer des trajectoires pour un ensemble de tâches.
2. Filtrage : Les tâches où le cloud surpasse significativement le dispositif (dépassant une marge $\delta$) sont sélectionnées pour définir un régime où l'assistance du cloud est nécessaire.
3. Supervision : L'agent dispositif est « rejoué » sur les états de trajectoire réussis du cloud. Une étiquette de cohérence au niveau de l'étape $y_t$ est générée :
   • $y_t = 1$ (Acheminer vers le Cloud) : Si l'action du dispositif $a^d_t$ est en désaccord avec l'action du cloud $a^c_t$.
   • $y_t = 0$ (Acheminer vers le Dispositif) : Si les actions sont en accord.
4. Entraînement : Le routeur est entraîné comme un classifieur binaire en utilisant la perte d'entropie croisée binaire (BCE) sur cet ensemble de données, alignant son espace latent sur la différence de performance entre les deux modèles.

Étape 2 : Apprentissage par Renforcement (RL) Sensible aux Coûts avec Regroupement d'États

L'étape IL fournit une a priori mais n'optimise pas directement l'objectif conjoint de maximisation du retour et de minimisation des appels au cloud. Hera est affiné en utilisant le RL :

1. Déploiements : Plusieurs trajectoires ($N$) sont collectées pour chaque tâche en utilisant le routeur actuel, avec une stochasticité introduite via une distribution de Bernoulli mise à l'échelle par température pour encourager l'exploration.
2. Regroupement d'États : Les états identiques rencontrés lors de différents déploiements sont regroupés. Pour chaque état unique $s$, le système estime :
   • $\hat{R}(d; s)$ : Le retour de trajectoire attendu si la décision $d$ (dispositif ou cloud) est prise.
   • $\hat{C}(d; s)$ : Le nombre futur d'appels au cloud attendu (incluant l'étape actuelle) si la décision $d$ est prise.
3. Étiquetage des Préférences : Une étiquette de préférence $y(s)$ est dérivée en sélectionnant la décision ayant le retour estimé le plus élevé. Si les retours sont comparables (dans une marge $\epsilon$), la décision avec une utilisation future attendue du cloud plus faible est préférée.
4. Optimisation : Le routeur est mis à jour en minimisant la perte BCE sur ces étiquettes de préférence, avec un terme de régularisation $L_2$ pour empêcher une dérive excessive par rapport aux paramètres initialisés par IL.

3. Contributions Clés

L'article revendique trois contributions principales :

1. Premier Coordinateur au Niveau de l'Étape : Hera est présenté comme le premier coordinateur d'agents dispositif–cloud opérant au niveau de l'étape pour les tâches à long terme, abordant le compromis performance–coût de manière plus granulaire que les routeurs au niveau de la tâche précédents.
2. Cadre d'Entraînement en Deux Étapes : Les auteurs développent un pipeline d'entraînement spécifique combinant l'apprentissage par imitation (pour l'initialisation à froid basée sur la cohérence des actions) et l'apprentissage par renforcement avec regroupement d'états (pour l'optimisation conjointe du retour de trajectoire et du coût cloud).
3. Supériorité Empirique : Des expériences extensives démontrent que Hera surpasse les références de l'état de l'art, atteignant une frontière de Pareto plus forte entre la réussite de la tâche et l'utilisation du cloud.

4. Résultats Expérimentaux

Hera a été évalué sur trois benchmarks exigeants à long terme : ALFWorld (tâches ménagères incarnées), WebShop (navigation e-commerce) et AppWorld (tâches de codage multi-applications). Le modèle dispositif était Qwen2.5-7B-Instruct, et le modèle cloud était Qwen-Max.

Principales Constatations :

• Compromis Performance–Coût : Hera a atteint 92,5 % du taux de réussite du modèle cloud seul tout en utilisant le cloud pour seulement 46,3 % des étapes.
• Comparaison avec les Références :
  • Sur ALFWorld, Hera a atteint un taux de réussite de 86,1 % avec un coût de $4,0 \times 10^{-3}$, surpassant significativement la référence cloud seul (90,9 % de réussite, coût de $11,7 \times 10^{-3}$) et toutes les autres références de routage (par exemple, RouteLLM, FrugalGPT).
  • Sur WebShop, Hera a atteint 34,1 % de réussite avec un coût de $8,1 \times 10^{-3}$, contre 35,6 % de réussite pour le cloud seul à $14,7 \times 10^{-3}$.
  • Sur AppWorld, Hera a atteint 19,7 % de réussite avec un coût de $31,3 \times 10^{-3}$, contre 22,6 % de réussite pour le cloud seul à $43,8 \times 10^{-3}$.
• Latence : En réduisant les invocations du cloud, Hera a considérablement réduit la latence de bout en bout (par exemple, 105,5 s contre 174,1 s sur ALFWorld) tout en maintenant des taux de réussite élevés.
• Études d'Ablation : La suppression de l'étape RL a entraîné des taux de réussite plus faibles et une utilisation du cloud plus élevée. La suppression de l'étape IL a conduit à un entraînement instable et à de moins bonnes performances, confirmant la nécessité du pipeline en deux étapes.
• Micro-benchmarks : L'analyse a montré que Hera identifie efficacement les « étapes critiques » nécessitant un suivi de contexte approfondi ou une composition complexe de contraintes, les acheminant vers le cloud, tout en gérant les étapes routinières localement.

5. Signification et Revendications

L'article soutient que Hera représente un changement pivot du routage grossier au niveau de la tâche vers une collaboration dynamique et fine. Sa signification réside dans :

• Démocratisation des Agents Avancés : En démontrant qu'une petite fraction d'étapes critiques nécessite une intervention du cloud, Hera abaisse les barrières computationnelles et financières au déploiement d'agents sophistiqués sur les appareils des utilisateurs.
• Permettre les Applications Temps Réel : Le cadre rend les applications sensibles à la latence (par exemple, contrôle robotique, assistants interactifs) réalisables sur du matériel dispositif sans coûts ni délais prohibitifs.
• Évolutivité : Hera établit une forte frontière de Pareto performance–coût, suggérant une voie viable vers des agents autonomes évolutifs, durables et omniprésents dans des environnements réels où les contraintes de ressources sont primordiales.

Les auteurs notent des limitations, notamment l'hypothèse d'une connectivité synchrone et fiable et l'absence de mécanismes intégrés de préservation de la confidentialité pour les données transférées, identifiant ces aspects comme des domaines pour des recherches futures.