Des chercheurs proposent le cadre PAPAV : seuls 3 benchmarks sur 64 testent la vérification

Lorsqu'un agent multimodal passe du pilotage d'un navigateur à celui d'un bras manipulateur, l'environnement change, mais le coût de l'erreur aussi. Une nouvelle étude publiée sur Hugging Face Daily Papers tente de décrire cette transition dans un langage commun. Ses auteurs introduisent la notion d'agents multimodaux incarnés (MMEA) et proposent le cadre PAPAV, composé de cinq fonctions. Leur principal constat empirique : sur 64 benchmarks analysés, seuls 5 évaluent la capacité à prévoir les conséquences des actions, et 3 seulement vérifient si le résultat est atteint. Presque tous les autres mesurent uniquement si la tâche a été accomplie.

Trois classes de systèmes et un dénominateur commun

Les auteurs commencent par une distinction. Les agents multimodaux (MMA) structurent leurs interactions autour du raisonnement, de la mémoire, des outils et du retour d'information. L'exemple le plus visible est celui des agents qui travaillent sur un ordinateur. Les systèmes robotiques (RS) relient perception et exécution dans un contexte de dynamique physique. Les MMEA se situent à la jonction : ce sont des systèmes orientés vers un but, qui associent le raisonnement multimodal sur la tâche à l'action physique et révisent leurs décisions selon le résultat obtenu.

La question centrale de l'étude est simple : qu'est-ce qui change quand un agent passe du computer-use au robot-use ? Pour y répondre, il faut une échelle de comparaison qui ne dépende pas d'une architecture particulière. Les auteurs choisissent donc de s'appuyer sur des fonctions plutôt que sur la conception du modèle.

PAPAV : cinq fonctions plutôt qu'une seule métrique

L'acronyme se décompose ainsi :

• Perceive : percevoir l'état actuel ;
• Anticipate : anticiper les effets des actions ;
• Plan : construire un plan réalisable ;
• Act : agir via une interface ou un corps ;
• Verify : vérifier le résultat.

Cette définition permet d'identifier ce que les trois classes ont en commun, puis de comparer les MMEA aux MMA classiques et à la robotique traditionnelle. Un agent qui clique sur des boutons et un manipulateur en usine exécutent tous deux les cinq fonctions. Ce qui diffère, c'est la difficulté de chacune et le coût d'une défaillance.

Où la physique réduit la marge de manœuvre

Les auteurs identifient cinq contraintes physiques. La liste va de l'observabilité partielle aux résultats invérifiables. L'effet général est le même : dans le monde physique, on peut fixer moins de décisions à l'avance, et il y a aussi moins de possibilités d'annuler une erreur. Un clic erroné dans une interface peut le plus souvent être annulé. Un objet qui tombe ou un mouvement incorrect, non.

D'où l'importance des fonctions Anticipate et Verify. Un agent incapable d'évaluer les conséquences à l'avance, puis de vérifier honnêtement le résultat, est dangereux en environnement physique, même avec une bonne planification.

Ce que révèle l'analyse de 64 benchmarks

Le chiffre principal de l'étude concerne l'état actuel de l'évaluation dans le secteur :

• 64 benchmarks ont été analysés au total ;
• l'évaluation explicite se concentre sur la fonction Act ;
• seuls 5 benchmarks évaluent Anticipate ;
• seuls 3 évaluent Verify ;
• ces deux fonctions restent pour l'essentiel masquées derrière l'indicateur final de réussite de la tâche.

Le problème est que la réussite de la tâche fond les cinq capacités en un seul chiffre. Un modèle peut avoir accompli une tâche grâce à une bonne perception, et non à une bonne anticipation. Il peut aussi l'avoir manquée à cause d'une vérification faible, alors que son plan était correct. Sans mesures séparées, il est difficile de comprendre ce qui s'est réellement amélioré d'une version du système à l'autre, et ce qu'il faut corriger.

C'est sur ces mêmes contraintes que les auteurs bâtissent leur liste de problèmes ouverts. On y trouve la conception d'agents physiques fiables et la mesure des progrès sur les cinq capacités.

Comment utiliser le cadre en pratique

Pour les équipes qui développent des agents pour robots, l'étude a une application concrète. Le cadre PAPAV peut servir de check-list d'audit : pour chaque fonction, déterminer quel test la mesure, et repérer celles qui ne sont pas couvertes. Si le pipeline ne comporte aucune vérification distincte du résultat après l'action, c'est une raison de l'ajouter avant de passer à l'échelle.

Pour les concepteurs de benchmarks, la conclusion est encore plus précise. Il faut des tâches où la prévision des conséquences et la vérification du résultat sont évaluées séparément, et pas seulement la réussite finale. Pour les investisseurs et les clients, c'est un repère pour lire les démos : un bel indicateur d'exécution des tâches ne dit pas encore comment le système se comporte quand le résultat ne peut pas être vérifié ou que l'erreur ne peut pas être annulée.

L'étude ne propose pas de nouveau modèle et ne promet pas de gain sur un test précis. Il s'agit d'une tentative de mettre de l'ordre dans les termes et les métriques à la jonction des agents et de la robotique, alors que la frontière entre les deux s'efface rapidement.