GenUI-Harness fait passer un modèle 4B de 9,33% à 58% de Pass@3 et devance Claude Opus 5

Les auteurs d'un article publié sur arXiv proposent GenUI-Harness : un harnais multi-agents dans lequel le modèle répond à une requête complexe non pas par un paragraphe de texte, mais par une interface éphémère avec formulaires, listes et choix de paramètres. Après un apprentissage par renforcement, un modèle de 4 milliards de paramètres passe de 9,33% à 58,00% de Pass@3 et devance Claude Opus 5, qui obtient 46,67%. Dans l'enquête auprès des relecteurs, la longueur moyenne du dialogue tombe de 3,4 à 1,2 tour.

Deux agents plutôt qu'un seul chat

L'architecture est simple. Le Tool Agent s'occupe de la recherche d'informations et de l'exécution des tâches : il interroge les bases de données et appelle les outils. Le GUI Coder Agent examine la requête et le résultat, repère les ambiguïtés et écrit le code front-end d'une interface structurée. Si l'utilisateur demande de « changer de vol », l'agent ne pose pas cinq questions de clarification d'affilée. Il affiche un formulaire avec les options réelles issues de la base.

Les auteurs partent du principe que le texte, comme canal pour des tâches complexes, surcharge l'utilisateur. Il crée de l'ambiguïté, du bruit informationnel et une saisie lente. Une interface construite pour des données précises et pour une étape précise de la tâche élimine ces problèmes.

Comment entraîner un codeur d'interfaces

Le cœur du travail d'ingénierie réside dans l'entraînement du GUI Coder par RL. Deux problèmes se posent, et chacun a sa solution.

Premier problème : une récompense vérifiable pour une interface interactive exige d'exécuter réellement le code, ce qui coûte cher. Les auteurs ont donc créé Dynamic UX, un paquet léger qui assure, dans un seul bac à sable, l'interaction dynamique et la collecte des récompenses.

Second problème : lorsque la récompense vient d'un LLM-juge, le modèle apprend vite à le tromper. Contre le reward hacking, les auteurs proposent Reward Auditor, une méta-récompense. Il surveille la distribution des récompenses, isole des motifs de diagnostic et les consolide dans une grille d'évaluation commune et une spécification de notation. Le juge ne reste pas figé pendant l'entraînement.

Benchmark et chiffres

Pour la validation, les auteurs ont créé UI-TAU Bench. Il repose sur 10 bases de données métier réelles issues de sources ouvertes et reprend le cadre de Tau-Bench pour le tool use. Il existe une version Lite (300 tâches) et une version Full (1000 tâches).

• Gain moyen de Pass@3 face à smolagents sur Lite : 4,48 points de pourcentage.
• Modèle 4B après entraînement dans GenUI-Harness : de 9,33% à 58,00% de Pass@3.
• Claude Opus 5 sur le même benchmark : 46,67%.
• Robustesse : le système tient aussi bien sur les requêtes ambiguës que sur les requêtes sans ambiguïté.
• Enquête auprès des relecteurs : le dialogue passe de 3,4 à 1,2 tour.

Les 9,33% de départ du modèle 4B montrent à quel point la tâche est difficile pour une version de base sans spécialisation. Le bond à 58% indique que le RL avec audit des récompenses apporte plus que la taille du modèle. Mais la comparaison se fait sur un benchmark conçu par les auteurs eux-mêmes, pour leur propre cadre, et les modèles de frontière n'ont pas été entraînés spécifiquement pour lui.

Le gain de 4,48 points de pourcentage face à smolagents paraît bien plus modeste que l'envolée du modèle 4B, et il faut précisément garder ces deux chiffres en tête ensemble. L'enquête auprès des relecteurs ne remplace pas non plus une expérience avec de vrais utilisateurs. Les auteurs eux-mêmes limitent leurs conclusions aux « scénarios évalués avec des bases de données ».

Où cela peut servir

Les cas les plus proches de la pratique sont ceux où l'agent dispose d'un backend structuré : support client, réservation, panneaux d'administration internes, gestion de commandes. Dans ces cas, un dialogue de clarification coûte cher, alors que les réponses possibles sont en nombre fini et se trouvent dans la base.

Une équipe qui construit des agents a intérêt à retenir deux techniques transposables. La première : séparer l'exécutant des tâches du générateur d'interface et les entraîner séparément. La seconde : surveiller la distribution des récompenses d'un LLM-juge comme une entité à part entière, au lieu de se fier à une grille rédigée une fois pour toutes. Cette seconde technique est utile dans tout pipeline de RL avec juge, pas seulement pour la génération d'interfaces.

Pour l'instant, il s'agit d'un article en préprint v1 : le code, la reproductibilité et le comportement sur des données extérieures aux dix domaines restent à vérifier.