Skip to content
Guides5 min read

Évaluer les agents computer-use, étape par étape

Un parcours guidé de l'évaluation humaine des agents computer-use et GUI dans Potato : juger chaque action, vérifier l'ancrage du clic sur la capture d'écran et passer en revue les appels d'outils un par un.

Potato Team

Un agent computer-use lit une capture d'écran, décide d'une action et clique. L'évaluer, c'est vérifier chaque étape : l'action était-elle correcte, et le clic a-t-il vraiment atterri sur l'élément qu'il désignait — pas seulement si la tâche a fini par réussir. La réussite de la tâche masque le clic qui a touché le mauvais bouton mais a quand même progressé, ainsi que l'action correcte par chance. Potato passe en revue ces exécutions avec une surface de trajectoire GUI dédiée et une revue des appels d'outils, toutes deux configurées en YAML.

Un agent computer-use — aussi appelé agent GUI ou OS — voit l'écran sous forme de pixels ou de DOM et agit via les mêmes contrôles qu'une personne. Des benchmarks comme OSWorld, ScreenSpot et AndroidWorld notent automatiquement l'achèvement des tâches. La notation automatique est peu coûteuse et vaut la peine d'être lancée, mais elle ne peut pas vous dire pourquoi une exécution a échoué, ni attraper la réussite par chance. C'est la lacune que comble la revue humaine étape par étape.

Anatomie d'une étape de computer-use : capture d'écran, action, verdict et ancrage du clicJugez l'action et déterminez si le clic a atterri sur l'élément qu'il désignait

Que juge-t-on réellement dans une trajectoire GUI ?

Chaque étape associe une capture d'écran (ce que l'agent a vu) à une action (ce qu'il a fait). Vous jugez l'action, et lorsque l'étape porte des coordonnées de clic, vous vérifiez le marqueur d'ancrage que Potato dessine sur la capture d'écran :

  • Justesse de l'action — correcte, mauvais élément, mauvaise action ou hallucinée.
  • Ancrage du clic — les coordonnées ont-elles atterri sur l'élément que l'action désignait ?
  • Résultat — l'exécution a-t-elle achevé la tâche, et à quelle étape a-t-elle d'abord dérapé ?

Une étape de computer-use avec un verdict d'action et un marqueur d'ancrage du clicPassez chaque étape en revue : justesse de l'action et ancrage du clic sur la capture d'écran

yaml
annotation_schemes:
  - annotation_type: gui_trajectory
    name: gui_review
    description: "For each step: was the action correct and did the click land right?"
    steps_key: steps
    screenshot_key: screenshot
    action_key: action
    coord_space: normalized
    verdict_options: [correct, wrong_element, wrong_action, hallucinated]

Chaque étape fournit screenshot, action et, en option, x/y (ou un click: {x, y} imbriqué). Le marqueur d'ancrage est la partie que les métriques automatisées manquent le plus souvent : un modèle peut produire la bonne étiquette d'action tout en cliquant à dix pixels de la cible, et un succès/échec sur l'écran final ne le fera jamais apparaître.

Pourquoi la première étape erronée compte-t-elle plus que le résultat final ?

Parce que c'est l'étape que vous corrigeriez ou sur laquelle vous entraîneriez le modèle. Une exécution qui échoue à l'étape 9 parce que l'étape 3 a mal lu une boîte de dialogue est en réalité un problème d'étape 3, et l'étiqueter à l'étape 9 enseigne la mauvaise leçon. Attraper la première divergence relève de la même idée que les modèles de récompense de processus : un signal à chaque étape localise l'erreur au lieu d'effondrer toute la trajectoire en un seul chiffre.

Comment passer en revue les appels d'outils d'un agent ?

Les agents GUI appellent aussi des outils et des fonctions, et ceux-ci échouent à leur manière : bonne intention, mauvais outil ; bon outil, arguments mal formés ; bon appel, mauvais ordre. Le schéma tool_call_review extrait chaque appel de la trace et lui donne une carte avec le nom de l'outil et les arguments mis en forme, de sorte que vous les jugez un par un (à l'image de BFCL v4 / MCPMark).

Verdicts par appel sur chaque appel d'outil d'une traceJugez chaque appel d'outil : bon outil, arguments corrects, bon ordre

yaml
annotation_schemes:
  - annotation_type: tool_call_review
    name: tool_review
    description: "Judge each tool call: right tool? correct arguments?"
    steps_key: steps
    # verdict_options: [correct, wrong_tool, wrong_args, wrong_order]

Les appels d'outils sont extraits au moment du rendu depuis le champ tool_calls, tool_call ou action de chaque étape, de sorte qu'une trajectoire qui mêle clics dans l'UI et appels d'API peut être passée en revue sur les deux axes au sein d'une même tâche.

Comment mettre cela en place ?

Chaque surface est livrée avec un exemple exécutable sous examples/agent-traces/. Pointez Potato vers l'un d'eux pour voir le schéma avec des données d'exemple :

bash
pip install --upgrade potato-annotation
python potato/flask_server.py start examples/agent-traces/gui-trajectory/config.yaml -p 8000

Vos propres données s'insèrent sous forme de liste d'étapes, chacune avec une URL de capture d'écran ou un data-URI et une chaîne d'action. Pour des agents web plus larges qui travaillent à partir de pages rendues plutôt que de captures d'écran brutes, voir Évaluation des agents web.

Pour aller plus loin