Pourquoi l'écran trompe
Imaginez qu'un agent travaille avec une application de bureau. Il voit une fenêtre avec plusieurs champs et un bouton « Enregistrer ». Du point de vue de la capture d'écran, c'est le même écran, mais en réalité le formulaire peut être vide, partiellement rempli ou déjà envoyé — et seule la logique cachée du système d'exploitation sait quel scénario est en cours d'exécution. Cette situation est appelée observabilité partielle : l'agent n'a accès qu'aux manifestations externes, et non à l'état réel du système.
Le danger réside dans le fait qu'une action localement plausible — par exemple, un clic sur un bouton — peut, dans un cas, terminer le scénario, dans un autre, déclencher une erreur de validation, et dans un troisième, être simplement ignorée. Des écrans visuellement similaires peuvent appartenir à différentes branches du flux de travail, ce qui conduit à des résultats très différents. Par conséquent, un comportement efficace nécessite non seulement la reconnaissance des objets de l'interface, mais aussi une exploration active : il faut déterminer quels états sont réellement atteignables et lever l'ambiguïté avant de prendre une décision.
C'est précisément à cette tâche qu'est consacré l'article « ScreenSearch: Uncertainty-Aware OS Exploration » (arXiv:2605.16024), dont les auteurs sont Michael Solodko et Justin Weigle. Ils formulent le problème comme une exploration des états de l'ordinateur : l'agent doit trouver un équilibre entre l'expansion du front atteignable et la réduction de l'incertitude.
Approche : graphe d'états et bandit
Plutôt que de s'appuyer sur des captures d'écran individuelles, le système proposé, ScreenSearch, construit un graphe global d'états dédupliqués. Pour ce faire, il utilise une recherche structurelle : les arbres UIA sont transformés en caractéristiques tenant compte de la disposition des éléments, et les écrans associés sont indexés via une recherche par jetons éparse et des filtres de métadonnées. Le graphe d'états est maintenu sur plusieurs machines virtuelles, ce qui permet de faire évoluer l'exploration.
La stratégie de sélection de la prochaine action est définie par un bandit de graphe PUCT, qui prend en compte l'ambiguïté des états. Cela signifie que l'agent privilégie non seulement les transitions prometteuses en termes de nouveauté, mais aussi celles qui réduisent l'incertitude. En substance, le système explore simultanément l'espace des états et affine ses connaissances à son sujet.
Comment mesurer l'ambiguïté
La contribution clé de l'article est un signal d'ambiguïté évolutif. Il repose sur une observation simple : si des écrans visuellement similaires, avec la même signature d'action, mènent à des états suivants différents, cela signifie que l'état actuel n'est pas suffisamment étudié. La variance des résultats devient un indicateur que l'agent n'a pas encore compris comment fonctionne cette partie du flux de travail.
Ce signal est combiné aux récompenses pour l'expansion du front d'exploration. Il devient ainsi possible d'évaluer les politiques sur le graphe global via le replay-start : on exécute la politique à partir d'un ensemble fixe d'états de départ et on observe comment elle gère les tâches. Il est important de noter que certaines politiques peuvent réduire rapidement l'ambiguïté, mais presque sans découvrir de nouveaux états, tandis que d'autres explorent activement, mais sans parvenir à « finaliser » les situations ambiguës. Les auteurs soulignent donc que la simple réduction de l'ambiguïté n'est pas un objectif suffisant.
Expériences : diversité et compromis
Pour valider l'approche, 11 applications de bureau ont été utilisées. Au cours des expériences, plus d'un million de captures d'écran et plus de 30 000 états uniques ont été collectés. Les corpus obtenus présentent une diversité considérable, tant entre les applications qu'au sein de chacune d'elles — ce qui permet de tester les agents dans des conditions réalistes.
Sur la tranche fixe de replay-start, le compromis entre nouveauté et ambiguïté est clairement visible. Certaines stratégies réduisent presque immédiatement le niveau d'incertitude, mais découvrent rarement de nouveaux états. D'autres, au contraire, élargissent rapidement les frontières du connu, mais laissent de nombreuses « zones grises ». Les auteurs concluent que l'objectif de l'exploration doit être global.
Des ablations supplémentaires ont révélé un effet intéressant : le renforcement des propositions (proposal priors) améliore nettement la découverte d'états uniques lors de la construction du corpus. En d'autres termes, la qualité des actions proposées à l'agent influence directement la complétude du graphe d'états collecté.
Conclusions
L'étude ScreenSearch confirme que, pour un fonctionnement fiable d'un agent dans un système d'exploitation, il ne suffit pas de bien reconnaître les éléments de l'interface. Ce qui importe davantage, c'est de comprendre l'identité de l'état, de générer des propositions d'actions de qualité et de savoir chercher en tenant compte de l'ambiguïté. Ce sont précisément ces trois facteurs qui déterminent quand il faut poursuivre l'exploration et quand on peut fixer le résultat.
Les auteurs ont présenté un article de 22 pages avec 8 figures et 21 tableaux, décrivant en détail à la fois la méthode et les expériences. C'est une bonne base pour de futurs travaux dans le domaine des agents GUI fiables.
