Astra peut-il résoudre RoboMME sans exploser le budget ?
Sur le benchmark RoboMME, consacré aux tâches de manipulation exigeant de la mémoire (retrouver un objet avant occlusion, respecter l'ordre d'une séquence démontrée), un système à trois niveaux atteint 79,13 % de réussite par épisode. Il combine GPT-6 Astra comme planificateur (« Système 2 »), qui choisit un sous-objectif ancré dans l'historique visuel stocké, une politique vision-langage-action π0.5 (« Système 1 ») qui exécute ce sous-objectif, et un moniteur Qwen3-VL-4B fine-tune (« Système 1.5 »). Ce dernier vérifie après chaque segment d'actions si le sous-objectif est terminé. L'instruction est conservée jusqu'à ce que le moniteur signale l'achèvement ou qu'un événement propre à la tâche survienne, pendant que la politique continue d'agir sur les nouvelles observations. Le coût moyen est de 3,63 appels à Astra et de 80,84 secondes par épisode. Le score dépasse de 34,62 points la meilleure référence publiée sans oracle, et reste 4,95 points sous GroundSG+Oracle, une configuration qui fournit à la politique bas niveau des sous-objectifs vérité terrain.
L'intérêt tient au compromis entre capacité de raisonnement et coût. Appeler un grand modèle de vision-langage avant chaque segment d'action est lent et cher, ce qui interdit en pratique tout déploiement cadencé. En ramenant les appels à moins de quatre par épisode, les auteurs montrent qu'un planificateur lourd peut être sollicité de façon parcimonieuse, un petit modèle de 4 milliards de paramètres assurant la surveillance continue. Le résultat suggère aussi que le goulot d'étranglement des VLA sur les tâches à mémoire se situe moins dans l'exécution que dans le raisonnement sur l'historique. L'écart de seulement 4,95 points avec l'oracle indique que la qualité des sous-objectifs générés est proche du plafond atteignable avec cette politique. Pour un intégrateur, c'est un argument en faveur d'architectures hiérarchiques plutôt que de politiques monolithiques à contexte long. Quelques réserves s'imposent : il s'agit d'un benchmark, vraisemblablement en simulation, et 80 secondes par épisode restent un temps de cycle peu compatible avec des cadences industrielles. Le chiffre ne dit rien non plus de la robustesse hors benchmark ni du coût financier réel des appels à Astra, malgré le titre qui le promet.
Ce travail s'inscrit dans la lignée des architectures « double système » popularisées par des modèles comme Helix de Figure ou GR00T, où un module lent délibère et un module rapide contrôle. Ici, π0.5 de Physical Intelligence sert d'exécutant, et l'ajout d'un étage intermédiaire de monitoring répond à la question de savoir quand relancer le planificateur. RoboMME pose un problème que les politiques réactives traitent mal, d'où l'écart de près de 35 points avec les meilleures bases non oracle. La suite logique consiste à tester le système sur robot réel, à mesurer la latence et le coût en conditions de production, et à comparer cette approche à des politiques dotées d'une mémoire native. Il s'agit d'une publication de recherche (preprint arXiv, v1) : aucun produit ni déploiement n'est annoncé.
Dans nos dossiers




