Résumé Technique : Nautilus : D'une seule invite à l'apprentissage robotique plug-and-play

1. Énoncé du problème

La recherche en apprentissage robotique est actuellement fragmentée selon trois axes largement indépendants : les familles de politiques ($P$, par exemple IL, RL, VLA, WAM), les suites de benchmarks ($B$, par exemple LIBERO, ManiSkill) et les corpus robotiques ($R$, par exemple Franka, Unitree H1). L'intégration de n'importe quel triplet spécifique $(P, B, R)$ nécessite généralement une couche d'intégration distincte et écrite à la main, impliquant une configuration Docker, des adaptateurs d'observation et des procédures de validation de confiance.

Cette fragmentation crée un « fossé de l'interface » (harness gap). Bien que les grands modèles de langage (LLM) aient progressé en génération de code, ils échouent fréquemment à produire des résultats reproduits de bout en bout en robotique, car ils manquent des priors procéduraux et des pratiques de validation spécifiques aux flux de travail de la recherche en robotique. La charge d'ingénierie s'échelonne selon $\Theta(N \cdot M \cdot K)$, où $N, M, K$ sont les cardinaux des politiques, des benchmarks et des robots. Les cadres existants (par exemple LeRobot, Isaac Lab) sont souvent couplés à des composants fixes, tandis que les agents de codage à usage général manquent de l'infrastructure spécifique au domaine requise pour naviguer dans les conflits de dépendances complexes et les incompatibilités d'interfaces.

2. Méthodologie : L'interface NAUTILUS

Les auteurs proposent NAUTILUS, une interface open-source conçue pour les agents, visant à transformer une seule invite en langage naturel (par exemple, « Évaluez la politique A avec le benchmark B ») en flux de travail prêts à l'emploi pour la reproduction, l'évaluation, le fine-tuning et le déploiement. NAUTILUS est structuré en deux couches : un substrat et une couche de contenu.

2.1 Le Substrat (Invariants d'ingénierie)

Le substrat fournit une surface stable sur laquelle l'agent peut raisonner, réduisant la complexité d'intégration de $\Theta(N \cdot M \cdot K)$ à $\Theta(N + M + K)$. Il repose sur trois invariants :

1. Contrats d'interface typés : Les politiques, les benchmarks et les robots sont exposés via des schémas fixes et lisibles par machine (par exemple infer(obs) -> actions, reset(seed), apply_action). Ces contrats masquent la machinerie spécifique à l'implémentation (par exemple, les piles CUDA, les pilotes ROS 2) et définissent l'unité d'intégration.
2. Exécution en chambre : Les artefacts générés s'exécutent dans des conteneurs jetables et isolés. Cela empêche les échecs de dépendances (par exemple, des versions CUDA conflictuelles) de se propager entre les modules. Un conteneur de politique, un conteneur de benchmark et un conteneur matériel occupent le même emplacement architectural du point de vue de l'agent.
3. Communication inter-modules uniforme :
   • Niveau 1 (Local au robot) : La détection et le contrôle à haut débit restent dans la pile native du robot (par exemple, ROS 2, mémoire partagée).
   • Niveau 2 (Hors robot) : L'agent ne voit qu'un protocole WebSocket léger reliant le conteneur de politique au point de terminaison du benchmark ou du robot réel. Cela garantit que les points de terminaison simulés et réels partagent un schéma unique d'observation/d'action.

2.2 La Couche de Contenu (Guides, Capteurs, État)

Construite sur le substrat, cette couche condense les flux de travail de la recherche en robotique en composants explicites et réutilisables :

• Guides : Instructions pré-génération qui orientent le comportement de l'agent, fournissant des règles de routage, des rôles de sous-agent et des protocoles de validation avant l'écriture du code.
• Capteurs : Validateurs post-génération qui vérifient les artefacts selon six critères (par exemple, filtrage pré-action, vérification d'interface, comparaison de spécifications, tests de fumée). Les capteurs peuvent déclencher des corrections locales ou bloquer les exécutions si les contrats sont violés.
• État : Un registre persistant validé par schéma JSON qui stocke les contrats typés et les artefacts figés (commits sources, images Docker). Cela permet à l'agent de réutiliser des connaissances de modules vérifiées plutôt que de redécouvrir les dispositions des dépôts à partir de zéro.
• Artefacts d'espace de travail : Journaux en écriture seule et reçus de reproduction qui enregistrent le commit source, les choix d'environnement et les décisions pour chaque exécution.

2.3 Flux d'Exécution

Lorsqu'un utilisateur émet une invite (par exemple, « Exécutez $\pi_0$ sur LIBERO »), l'orchestrateur achemine la demande vers un flux de travail de sous-agent spécifique. Le système vérifie le registre État pour les entrées vérifiées. Si elles manquent, il génère en parallèle les modules de politique et de benchmark, compare leurs spécifications typées (par exemple, clés d'observation, formes d'action), exécute un test de fumée WebSocket et écrit des reçus de reproductibilité.

3. Contributions Clés

1. Substrat Modulaire : Un système basé sur des contrats typés, une exécution en chambre et un transport uniforme qui réduit le coût d'intégration de l'apprentissage robotique inter-familles.
2. Priors Procéduraux Condensés : La conversion des connaissances tacites des flux de travail robotiques en Guides et Capteurs explicites, transformant la génération « boîte noire » de l'agent en un processus validé et étape par étape.
3. Plateforme Open-Source : La publication de NAUTILUS avec des flux de travail structurés supportant quatre familles de politiques (IL, VLA, RL, WAM), six suites de benchmarks et quatre classes de corpus. Elle inclut nautilus-collect, une plateforme de collecte de données qui valide le même contrat Robot sur du matériel hétérogène (Franka et Unitree H1).
4. Registre Extensible : Une plateforme communautaire où de nouvelles politiques, benchmarks ou robots peuvent être intégrés via 3 à 5 contrats de méthodes typés sans modifier le code du cadre, à condition qu'ils passent les protocoles de validation de confiance.

4. Résultats Expérimentaux

L'article évalue NAUTILUS à travers trois études :

• Validation de confiance des benchmarks : Le système a reproduit les résultats de référence pour des politiques publiques (Diffusion Policy, $\pi_0$, OpenVLA, etc.) sur LIBERO, ManiSkill, RoboTwin, ALOHA et RoboCasa. Les wrappers générés ont fidèlement reproduit les scores de référence avec de faibles écarts (par exemple, $\Delta \approx \pm 2\%$), confirmant que les adaptateurs préservent les protocoles d'évaluation prévus.
• Ablation sur l'extensibilité : Dans un banc d'essai « leave-one-benchmark-out », NAUTILUS a été comparé à un agent de codage standard.
  • Succès : NAUTILUS a atteint 100 % de succès de wrapping et un haut taux de réussite des tâches (98,7 % sur Claude Opus 4.7).
  • Efficacité des coûts : Le retrait du modèle typé (le substrat) a fait chuter le succès de wrapping à 55,3 % et a triplé l'utilisation des tokens (41,7 millions de tokens), démontrant que le substrat empêche l'agent de réapprendre le code d'assemblage.
  • Mise à l'échelle des modèles : L'interface a fourni des avantages relatifs plus importants sur des modèles plus faibles (Claude Sonnet 4.6), réduisant le nombre de tours d'interaction d'environ 27 % et les coûts d'environ 8 % par rapport à l'agent standard.
• Déploiement sur robot réel : Le système a déployé avec succès un checkpoint de manipulation VLA ($\pi_0.5$) sur un bras Franka et une politique de locomotion RL sur un Unitree H1. Dans les deux cas, le même artefact de politique enveloppé pour la simulation a été transféré au matériel en échangeant uniquement le conteneur matériel, sans modification du code de la politique ni du conteneur côté plateforme.

5. Signification et Revendications

L'article soutient que la contrainte principale sur l'automatisation par agents en apprentissage robotique n'est pas la capacité du modèle LLM, mais l'ingénierie de l'interface qui l'entoure. NAUTILUS démontre qu'en fournissant un substrat stable, basé sur des contrats, avec une validation explicite, la charge d'ingénierie de la reproduction et de l'évaluation inter-familles peut être considérablement réduite.

Les auteurs affirment que NAUTILUS transforme les flux de travail de recherche fragmentés en procédures structurées et agentic. En rendant l'expertise du domaine (contrats, protocoles de validation, gestion d'état) exécutable, réutilisable et inspectable, le système permet aux chercheurs de mettre à l'échelle leurs flux de travail sans devoir créer manuellement du code d'assemblage pour chaque nouvelle combinaison $(P, B, R)$. Ce travail positionne NAUTILUS non seulement comme un outil d'automatisation, mais comme une étape vers un avenir où des interfaces construites par des experts permettront aux modèles de mettre à l'échelle l'expertise du domaine à travers tout l'écosystème de l'apprentissage robotique.