Un agent de 8B pour iOS dépasse Gemini-3.5-Flash sur UINavBench et égale Gemini-3.1-Pro

Une équipe de chercheurs propose d'entraîner de petits modèles de navigation d'interfaces non pas sur des démonstrations enregistrées, mais en interaction directe avec de vraies applications iOS. L'agent obtenu, doté de 8 milliards de paramètres, dépasse Gemini-3.5-Flash et Qwen3.8-27B sur UINavBench — un benchmark d'applications iOS réelles dont le succès est vérifié par un juge VLM — et fait jeu égal avec Gemini-3.1-Pro. Sur AndroidWorld, soit un autre système d'exploitation que l'agent n'a pas vu à l'entraînement, son taux de réussite est près de sept fois supérieur à celui du modèle de base après SFT.

Pourquoi scinder l'agent entre planificateur et « pointeur »

Le problème qui motive ce travail est bien connu de ceux qui ont tenté de construire des agents d'interface. Les modèles de pointe savent naviguer à l'écran, mais coûtent parfois plusieurs dollars par tâche, ce qui est trop cher pour un usage quotidien. Les petits modèles entraînés par SFT ou par RL hors ligne mémorisent les trajectoires des données d'entraînement. Il suffit que l'application affiche un écran inattendu pour que l'agent ne sache plus revenir sur le bon chemin.

Les auteurs ont découpé le système en deux. Le planificateur observe la capture d'écran, conserve l'historique des étapes passées et produit, par une chaîne de raisonnement, l'étape en cours et un plan à long terme. Un modèle d'ancrage (grounding) distinct convertit cette étape en action concrète et en coordonnées de toucher. L'ancrage est une tâche quasi déterministe, que le SFT classique résout bien. Le RL, coûteux, n'est donc appliqué qu'au planificateur. Celui-ci part de Qwen3-VL-8B-Instruct, affiné sur des trajectoires humaines, dont le jeu de données public GUIOdyssey, destiné aux scénarios de bascule entre applications. Le planificateur dispose aussi d'une action de clarification : si la tâche est formulée de façon incomplète, il peut demander ses préférences à l'utilisateur.

Une récompense à chaque étape et un critique stabilisé

L'entraînement repose sur un LLM juge qui émet deux signaux. La récompense dense évalue chaque étape : rapproche-t-elle de l'objectif, sans hallucination ni boucle absurde ? La récompense terminale vérifie si la tâche est entièrement accomplie. Le signal dense est nécessaire là où le succès final est rare : l'agent reçoit un retour même dans les épisodes ratés et apprend à se sortir d'états inattendus.

L'optimisation passe par PPO avec estimation de l'avantage étape par étape (GAE). Les auteurs décrivent ici un travers connu : quand on rémunère les étapes, l'agent se met à allonger la trajectoire. Pour y remédier, ils appliquent une actualisation asymétrique : les récompenses locales liées au processus sont actualisées, pas celle de l'achèvement de la tâche.

La seconde nouveauté est GiGPPO. La méthode estime la valeur d'un état en tenant compte des récompenses d'états visuellement proches dans des trajectoires parallèles. Cela stabilise le critique. Les auteurs soulignent la différence avec GiGPO, où la ligne de base est calculée sur des états qui se répètent à l'identique : dans leur environnement, ces états sont presque toujours uniques. Le signal est donc transmis via une fonction de valeur apprenable. Selon les auteurs, la récompense dense comme GiGPPO accélèrent la convergence, et le résultat dépasse celui du SFT et du RL à récompense terminale seule.

Infrastructure : 512 iPhone virtuels

Le RL en ligne exige un très grand nombre d'interactions réelles. Les auteurs ont monté un parc d'appareils iOS virtuels dans le cloud, pilotés en VNC avec un jeu d'actions comme tap, swipe, type, long press, home et wait. Chaque appareil est configuré une fois : installation des applications, connexion à l'identifiant Apple, prise d'un snapshot. Chaque épisode se termine ensuite par un retour au snapshot, plutôt que par la recréation de la session, et le redémarrage prend environ 10 secondes. 512 trajectoires tournent en parallèle, chacune sur son propre appareil. Les auteurs affirment qu'il s'agit du premier entraînement à grande échelle d'agents d'interface entièrement réalisé sur de vrais appareils iOS avec de véritables applications.

Ce qu'il faut garder en tête

Il s'agit d'un preprint, et la description disponible ne donne pas de pourcentages de réussite précis pour les benchmarks. Le « près de sept fois » porte donc sur la base SFT, basse, sur AndroidWorld, et non sur un niveau absolu. L'évaluation sur UINavBench repose sur un juge VLM, tandis que les récompenses d'entraînement viennent d'un juge LLM : les erreurs des juges peuvent donc affecter à la fois l'entraînement et la mesure. La comparaison avec Gemini a été menée sur un benchmark précis d'applications iOS réelles et ne se transpose pas forcément à toutes les tâches.

La leçon pratique pour les équipes qui conçoivent des agents mobiles : séparer planification et ancrage, et ajouter une récompense par étape fournie par un juge, permet d'obtenir d'un modèle de 8B une qualité de niveau modèles de pointe sur un domaine étroit. Le prix de cette approche est de disposer de sa propre ferme d'appareils virtuels, et c'est elle, d'après ce travail, qui devient la condition principale du passage à l'échelle.