Le coût caché de l’annotation des données robotiques

Les étiquettes en langage naturel, la calibration et la synchronisation temporelle sont le vrai coût de l’annotation des données robotiques. Pourquoi les comptages de trajectoires mis en avant masquent la fiabilité réelle d’un jeu de données.

9 min de lecture

Deux laboratoires enregistrent ce qu’ils appellent la même tâche : soulever une tasse posée sur une table. Sur le premier banc, le capteur de force de la pince et la caméra de poignet sont horodatés par une seule et même horloge. Sur le second, les horodatages de la caméra proviennent du pilote USB tandis que les mesures de force viennent d’une boucle de contrôle distincte, et les deux horloges dérivent d’environ 80 millisecondes l’une par rapport à l’autre. Alimentez le même modèle avec les deux et quelque chose se casse, de façon subtile. La politique apprend que la pince devrait commencer à se refermer légèrement avant que les doigts ne touchent réellement la tasse, parce que dans les données d’entraînement le signal de contact arrivait en avance. Les bons jours, cela paraît correct. Les mauvais jours, elle écrase la tasse.

Voilà le problème de l’annotation, et il ne s’agit pas vraiment de tracer des boîtes. La partie coûteuse et sujette aux erreurs d’un jeu de données robotiques moderne, c’est rarement le mouvement lui-même. Ce sont les métadonnées qui l’enveloppent : l’étiquette en langage naturel qui dit à quoi servait la trajectoire, la calibration qui dit où chaque caméra se situe réellement, et la synchronisation temporelle qui dit quelle observation a causé quelle action. Ratez cela et la trajectoire est toujours là, toujours rejouable, toujours comptabilisée dans votre chiffre affiché, et discrètement toxique à l’entraînement.

Les chiffres affichés sont l’indice révélateur. Un jeu de données présenté comme « un million de trajectoires » ou « trois mille heures » indique combien a été collecté, non pas combien est digne de confiance. L’écart entre ces deux quantités est là où réside l’essentiel du coût réel, et presque rien de tout cela n’atteint le communiqué de presse. Trois couches méritent la majeure partie du blâme.

L’étiquette sur laquelle personne ne s’accorde

Le conditionnement par le langage est désormais standard. Le π0 de Physical Intelligence, la gamme GR00T de NVIDIA, Gemini Robotics de Google DeepMind et les Large Behavior Models du Toyota Research Institute prennent tous une instruction en langage naturel et produisent des actions. Cela ne fonctionne que si les données d’entraînement portent des instructions, et les instructions sont l’endroit où le jugement humain s’infiltre.

Prenez la granularité. « Fais un café » est une étiquette ; « prends la tasse, place-la sous le bec, appuie sur le bouton » en fait trois ; un annotateur d’étapes clés en produira peut-être vingt. Ego4D a associé des narrations denses en forme libre à des milliers d’heures de vidéo à la première personne, et son successeur Ego-Exo4D a superposé des commentaires d’experts et des étapes clés au niveau de chaque geste, précisément parce qu’une seule légende ne peut servir à la fois un planificateur de haut niveau et un contrôleur de bas niveau. Chaque niveau que vous ajoutez est une passe d’annotation distincte, avec sa propre facture de main-d’œuvre et son propre désaccord entre annotateurs.

Vient ensuite la provenance de l’étiquette elle-même. Certains jeux de données recueillent d’abord l’instruction puis agissent, si bien que l’intention est propre mais le comportement peut divaguer. D’autres agissent d’abord et réétiquettent après coup, ce qui est peu coûteux et extensible, mais favorise des légendes qui décrivent ce qui s’est passé plutôt que ce qui était voulu. Les deux approches se défendent. Les mélanger en silence, au sein d’un même ensemble d’entraînement, c’est ainsi qu’un modèle apprend que « mets le bloc dans le bol » désigne tantôt le bloc bleu, tantôt le plus proche.

Un jeu de données robotiques ne vaut que son horodatage le plus mal aligné et son étiquette la moins cohérente. Ni l’un ni l’autre n’apparaît dans le comptage des trajectoires.

La calibration est un problème de données, pas une étape de mise en place

La calibration est généralement traitée comme quelque chose que l’on fait une fois, avant que le travail intéressant ne commence. Dans un jeu de données d’apprentissage, ce n’est pas une étape de mise en place ; c’est une étiquette, et une étiquette fragile. Les paramètres intrinsèques de la caméra vous disent comment l’objectif projette le monde sur des pixels. Les paramètres extrinsèques, y compris la transformation main-œil entre une caméra de poignet et la pince, vous disent où ces pixels se situent dans le repère du robot. Toute supervision 3D, alignement de profondeur, fusion de nuages de points, géométrie multi-vues, n’est jamais plus précise que ces chiffres.

Le mode de défaillance est silencieux. Une caméra de poignet décalée de deux degrés ne renvoie aucune erreur ; elle produit un jeu de données où la position projetée de la pince se trouve systématiquement à un centimètre de l’endroit où la pince se trouve réellement. Entraînez-vous sur suffisamment de données de ce type et la politique intériorise ce décalage. DROID a consacré un effort réel à standardiser sur un seul bras, le Franka Panda, à travers 13 institutions, précisément pour que la calibration et les conventions de contrôle ne varient pas d’un laboratoire à l’autre. Cette discipline explique en grande partie pourquoi les données se composent tout court.

Synchronisation temporelle : le mensonge des cinquante millisecondes

Les bancs modernes sont multi-cadence par nature. Le RGB tourne autour de 30 Hz, la profondeur selon son propre calendrier, la proprioception plus vite, le couple de force souvent à des centaines de hertz ou plus, l’audio plus vite encore. Chaque flux porte un horodatage, et les horodatages proviennent d’endroits différents : un pilote de caméra, une boucle de contrôle, un microcontrôleur, l’horloge système. Si vous alignez les flux sur le moment où votre enregistreur a reçu un paquet plutôt que sur le moment où le capteur a échantillonné le monde, vous avez incrusté une latence qui varie avec la charge du système.

Cinquante à quatre-vingts millisecondes semblent inoffensives. Pour une politique de manipulation riche en contacts, elles ne le sont pas, car elles corrompent la causalité. Le modèle essaie d’apprendre quelle observation a déclenché quelle action, et un canal de force mal aligné lui enseigne que le contact précède le mouvement, ou le suit, de manières qui ne se sont jamais produites. RH20T, qui apparie la vision au couple de force et à d’autres modalités sur plus de cent mille séquences, est fondamentalement un exercice consistant à faire concorder ces horloges.

Ce que le chiffre affiché dissimule

Quatre jeux de données largement utilisés, quatre paris différents sur l’endroit où dépenser l’effort d’annotation. Les chiffres ci-dessous sont approximatifs et arrondis.

Comment quatre jeux de données publics gèrent les étiquettes, la calibration et la synchronisation temporelle
Jeu de donnéesOrdre de grandeurOù va le coût d’annotation
Open X-Embodimentenviron 60 jeux de données regroupés sur 22 incarnations, de l’ordre d’un million de trajectoiresréconcilier des espaces d’action, des cadences de contrôle et des configurations de caméra discordants entre plus de 20 laboratoires
DROIDenviron 76 000 trajectoires, 564 scènes, 13 institutionsstandardisation du matériel et calibration cohérente entre les sites
Ego-Exo4Dde l’ordre de 1 300 heures, vues appariées à la première et à la troisième personneétiquettes en langage naturel à plusieurs niveaux, plus pose multi-caméra synchronisée
RH20Tplus de 100 000 séquences multimodales, plus de 140 tâchessynchroniser temporellement la vision, le couple de force et l’audio

Pourquoi le regroupement aggrave les choses

La réponse du domaine à la pénurie de données est l’agrégation, et l’agrégation multiplie chacun des problèmes ci-dessus. Open X-Embodiment a regroupé environ 60 jeux de données sur 22 incarnations issus de 21 institutions en un corpus d’entraînement unique, et à l’instant où vous faites cela, le « pince ouverte égale 1 » d’un jeu de données rencontre le « pince ouverte égale 0 » d’un autre, les mètres d’un laboratoire rencontrent les millimètres d’un autre, et le contrôle à 10 Hz rencontre le contrôle à 20 Hz. Rien de tout cela n’est visible non plus dans un comptage de trajectoires.

C’est pourquoi un format de données partagé, plutôt qu’un modèle partagé, effectue en silence le gros du travail. Hugging Face LeRobot pousse un schéma sur disque commun pour les épisodes, les observations et les actions, si bien que le travail d’alignement se fait une seule fois, à l’ingestion, au lieu d’être redécouvert par chaque équipe qui touche aux données. C’est peu glorieux, et c’est par là que transite désormais une grande part des données robotiques utilisables.

Le prochain vrai bond en manipulation n’arrivera probablement pas sous la forme d’une nouvelle variante d’attention. Il viendra plus vraisemblablement d’une équipe qui aura décidé qu’un horodatage est un artefact d’ingénierie de premier plan, que la calibration est une étiquette assortie d’une barre d’erreur, et qu’une phrase décrivant une tâche mérite le même contrôle de version que le code qui s’est entraîné dessus. Un travail ennuyeux. C’est aussi là que les données cessent de mentir.

robot-data-annotationdataset-labelingcalibrationtime-syncrobot-learning

Sources