Intégration LeRobot LanceDB : une carte du transfert jeu de données vers politique

Ce que l'intégration LeRobot LanceDB change réellement

Un jeu de données peut servir l'entraînement et la curation, si le transfert tient

L'intégration LeRobot LanceDB est intéressante pour une raison simple : elle permet à LeRobotDataset de lire des jeux de données Lance natifs tout en permettant aussi d'inspecter et de curer ces mêmes données. Cela peut supprimer un casse-tête familier dans les données robotiques, où le code d'entraînement, les notebooks de curation et les exports de stockage finissent discrètement par diverger.

Le risque est tout aussi simple. Un stockage partagé ne prouve pas que l'entraîneur reçoit les mêmes exemples que ceux approuvés par la personne chargée de la curation. Une équipe robotique peut interroger des démonstrations, accepter un ensemble d'épisodes, puis entraîner à partir de ce qui semble être le même nom de jeu de données. Si les fenêtres d'images, le contenu des tables ou l'alignement des actions ont changé entre-temps, les exemples renvoyés peuvent différer de ceux qui ont été approuvés. Un simple changement d'ordre d'échantillonnage peut préserver l'appartenance tout en rendant une comparaison de chargeurs moins contrôlée.

L'annonce d'intégration du 24 septembre 2026 décrit la lecture native de Lance via LeRobotDataset, l'accès aléatoire distant et la curation à côté des données d'entraînement. C'est la partie utile. Le point plus strict est que le format de stockage ne constitue pas tout l'exemple d'entraînement. Les exemples sont faits d'actifs, d'horodatages, de fenêtres, d'actions, de transformations et de règles de découpage. Changez un seul de ces éléments, et une migration propre peut tout de même modifier le problème d'apprentissage.

La carte du transfert jeu de données vers politique d'Optijara est un cadre éditorial pour ce problème. Elle suit trois identités depuis l'enregistrement jusqu'à l'entraîneur : l'identité des actifs, l'identité temporelle et l'identité de sélection. Un récapitulatif de lancement demande ce qui est nouveau. Cette carte demande ce qui doit rester identique.

Le code natif existe, mais le mélange de versions est le point où les ennuis commencent

Les preuves ici reposent uniquement sur la documentation et l'inspection du code source. Les vérifications de migration ci-dessous sont des vérifications proposées. Aucun jeu de données n'a été téléchargé, aucune installation de paquet n'a été vérifiée, aucun modèle n'a été entraîné et aucun robot n'a été actionné.

La révision LeRobot inspectée est e624f3f7f8411ec3a02635d06e79373341e5ef35 ; la référence compagnon est 40bcb659a52df5511cb1c8035b80775a2ff773a7. Le registre de stockage natif enregistre un backend Lance. Les métadonnées du paquet compagnon déclarent la version 0.3.1, mais une chaîne de version dans le code source ne prouve pas que chaque environnement puisse installer un ensemble compatible. La documentation compagnon générée décrit encore d'anciennes classes de plugin. Ne combinez pas ces anciens exemples d'API avec le chemin du lecteur de stockage natif en appelant cela un plan de migration.

Voici mon avis le plus ferme sur cette version : le mode de défaillance le plus difficile n'est pas un chargement lent des données. C'est une équipe qui croit qu'un tampon de format signifie que le jeu de données est équivalent. Modifier storage_format n'est pas une conversion. Copier d'anciens imports de plugin dans une recette de stockage natif n'est pas une migration. Avant de déplacer une charge de travail, faites correspondre le convertisseur, le lecteur, la plage de dépendances et le runtime Python au chemin de code exact qui est testé.

Lisez la disposition à trois tables avant de toucher à l'entraînement

frames.lance, videos.lance et meta.lance

Le README compagnon épinglé à une révision décrit une disposition de sortie native avec trois tables Lance à côté d'un répertoire meta/ standard.

frames.lance contient les caractéristiques tabulaires, avec une ligne par image, triées par index. Les vecteurs numériques sont représentés comme des listes de taille fixe, et les noms de caractéristiques sont mappés dans la forme tabulaire.

videos.lance stocke les fichiers MP4 originaux avec le stockage blob v2, avec des informations d'indexation en octets qui incluent les positions des images clés. Le backend natif mappe les fenêtres demandées vers des plages d'octets alignées sur les images clés. Une image demandée est donc liée au contexte de décodage vidéo. Ce n'est pas une recherche d'octets isolée.

meta.lance transporte les fichiers de métadonnées pour les racines distantes. Le convertisseur écrit aussi storage_format: lance dans les métadonnées afin que le lecteur puisse sélectionner le backend. Ce tampon décrit une disposition déjà créée par la conversion. À lui seul, il ne crée rien.

La conversion native conserve la vidéo compressée au lieu de la réencoder. C'est important parce qu'un ancien chemin par images JPEG produisait une sortie non strictement identique bit à bit, même avec une qualité de 100, selon la comparaison de la documentation héritée. Pourtant, la conservation des octets MP4 établit seulement la continuité des actifs compressés. Elle n'établit pas l'égalité des tenseurs décodés, l'équivalence des horodatages ni la correspondance des fenêtres d'entraînement. La version du décodeur, les transformations, le dtype, la tolérance, le padding et les décalages d'action doivent encore être vérifiés.

Matrice de décision : disposition par défaut, ancienne sortie de plugin ou Lance natif

L'entraînement distant sans prétéléchargement de tout le corpus n'est pas identique à un entraînement sans trafic. Les lignes numériques, les métadonnées et les plages vidéo circulent tout de même. Les workers ont besoin de mémoire, de tampons et de caches. La conversion depuis un identifiant Hub peut télécharger des données sources non mises en cache. Gardez le trafic de conversion et le trafic d'entraînement séparés dans tout modèle de coût.

Appliquer la carte du transfert jeu de données vers politique

Transporter ensemble l'identité des actifs, l'identité temporelle et l'identité de sélection

L'identité des actifs indique quels enregistrements, quelles métadonnées et quelle représentation de stockage sont utilisés. L'identité temporelle indique comment les indices d'images, les horodatages, les observations, les actions et les frontières d'épisodes se rapportent les uns aux autres. L'identité de sélection indique quels exemples une exécution inclut et dans quel ordre.

Un transfert correct transporte les trois. La même vidéo associée à des actions décalées est un jeu de données différent pour l'apprentissage d'une politique. Les mêmes épisodes visités dans un ordre différent ne constituent pas une comparaison contrôlée de chargeurs. Une requête qui renvoie des lignes différentes après des mises à jour de table constitue une nouvelle population d'entraînement, même si le texte de la requête n'a pas changé.

Le noeud de sélection est un manifeste d'exécution proposé, et non l'affirmation que l'intégration implémente des instantanés transactionnels couvrant les trois tables. Enregistrez les versions de table disponibles et prouvez qu'elles sont compatibles. Figez les écritures, ou contrôlez-les d'une autre manière, pendant la capture de la sélection.

Ce JSON illustratif sert à la tenue des registres, ce n'est pas un fichier de configuration LeRobot accepté :

{
  "framework": "Dataset-to-Policy Handoff Map",
  "identities": ["asset", "temporal", "selection"],
  "testsExecuted": false,
  "codeRevision": "<verified-reader-and-converter-revisions>",
  "datasetRevision": "<immutable-source-revision>",
  "tableVersions": {"frames": "<version>", "videos": "<version>", "meta": "<version>"},
  "episodeSelection": "<fixed-train-and-heldout-manifests>",
  "rowSelection": "<stable-identifiers-at-recorded-versions>",
  "sampler": "<implementation-and-order-record>",
  "seed": "<recorded-seed>",
  "delta_timestamps": "<feature-offset-map>",
  "decoderSettings": "<decoder-version-transforms-and-padding>"
}

Préservez les identifiants sémantiques d'images à côté des références de lignes de stockage et des versions de table. Une position physique de ligne est une mauvaise identité à long terme après des réécritures. Exportez la liste d'épisodes acceptée. Conservez la requête, le code de scoring et la version de scoring qui l'ont produite.

L'annonce distingue le mélange global de l'échantillonnage par fenêtres. Testez séparément l'accès aléatoire, le mélange global et toute configuration de mélange de fenêtres. Être capable de récupérer n'importe quelle ligne ne prouve pas qu'un échantillonneur visite la distribution prévue. Pour les comparaisons contrôlées, enregistrez l'ordre réel des échantillons au lieu de vous fier seulement à une graine.

Gardez delta_timestamps, le padding aux frontières d'épisodes et l'alignement observation-action explicites. Le backend natif expose le comportement des fenêtres temporelles et du padding, mais utiliser la même API publique d'entraînement ne supprime pas la nécessité de comparer les éléments renvoyés. La recherche visuelle peut proposer des démonstrations à examiner. Elle ne doit pas certifier les labels. Séparez aussi les niveaux de produit : l'exemple add_columns et backfill différé de l'annonce est identifié comme LanceDB Enterprise, il ne doit donc pas être budgété comme flux de travail open source par défaut.

Reconvertir un petit jeu de données avant de déplacer une charge de travail

Checklist de migration proposée

Commencez avec un petit sous-ensemble source autorisé qui contient plusieurs épisodes, flux de caméra et cas limites. Conservez l'original comme référence. Enregistrez la révision immuable, les identifiants d'épisodes et la licence avant la conversion. Laissez l'entraînement de production inchangé pendant cette comparaison.

Pour les données de plugin avant 0.3, reconvertissez depuis l'entrée originale prise en charge. Ne renommez pas l'ancienne sortie. Vérifiez la disponibilité du paquet publié et les options CLI correspondantes avant de publier une commande d'installation, car l'inspection du code source seule n'établit pas qu'un environnement fonctionne.

Utilisez la même version de décodeur, les mêmes transformations, le même dtype de sortie et la même tolérance d'horodatage lorsque vous comparez des échantillons décodés. Si une tolérance est nécessaire, rattachez-la à la représentation et à l'usage d'entraînement prévu. Un seuil général peut masquer le décalage que le pilote devait justement détecter.

Inspectez les fenêtres aux débuts et fins d'épisodes, pas seulement les images faciles du milieu. Comparez les masques de padding et les horizons d'action demandés. Confirmez l'association des caméras et le timing des actions indépendamment, car des comptages correspondants ne peuvent pas prouver ces relations.

Le dataset doctor du dépôt vérifie la structure des jeux de données au format amont, y compris les plages d'épisodes, les fichiers référencés et la disponibilité d'images vidéo déduite des métadonnées du conteneur sans décodage. Utilisez-le lorsqu'il est pris en charge. Il n'établit pas l'intégrité des images décodées, la justesse des labels, l'alignement des actions ni l'absence de fuite dans l'évaluation.

N'étendez l'usage qu'après avoir expliqué les divergences et reproduit la comparaison dans une autre exécution. Si les actifs correspondent mais que les exemples diffèrent, vérifiez le décodage et la sélection temporelle avant de modifier les réglages d'entraînement. Si la sélection diffère, revenez au manifeste. Conservez le jeu de données de référence jusqu'à ce que l'écart soit compris. Une courbe de perte plausible ne remplace pas l'explication d'une divergence de données.

Ce que les équipes se trompent en curant des données robotiques

Découpages aléatoires par image et contamination du jeu tenu à l'écart

Séparez les enregistrements liés avant d'ajuster la curation. Les découpages aléatoires par image peuvent placer des vues voisines du même événement des deux côtés. La séparation au niveau des épisodes est un meilleur point de départ, mais elle ne suffit pas toujours.

Si l'affirmation porte sur de nouveaux environnements, collecteurs ou tâches, regroupez le découpage autour de cette affirmation. Les auteurs de la version rapportent des chevauchements entre bâtiments et collecteurs dans le découpage DROID qu'ils ont examiné. Ce constat appartient à leur analyse, mais c'est un avertissement utile : un pourcentage au niveau des images ne définit pas à lui seul une population tenue à l'écart qui ait du sens.

Ajustez les choix de scoring et les seuils sur les données d'entraînement. Gardez les épisodes tenus à l'écart fixes et excluez-les des réglages répétés de filtres. Parcourir les échecs d'évaluation puis modifier le filtre reste un retour d'information, même si aucun optimiseur ne consomme ces images. Enregistrez cette boucle et réservez un nouvel ensemble d'évaluation intact lorsque l'affirmation l'exige.

Filtres de lissage universels et sélections mouvantes

La version rapporte que les épisodes DROID naturels réussis étaient plus saccadés dans son analyse. Une expérience LIBERO séparée a injecté de la corruption et testé des détecteurs ciblés. Ce sont des questions différentes. Elles ne soutiennent pas un seuil de mouvement universel pour chaque tâche robotique.

Traitez les scores de mouvement brusque comme des signaux d'inspection dont la signification dépend de la tâche et du dispositif d'enregistrement. Un mouvement rapide valide ne doit pas être écarté simplement parce qu'une heuristique de lissage ne l'aime pas.

D'autres erreurs évitables sont plus ordinaires : mélanger l'ancienne documentation de plugin avec le code natif, traiter la similarité visuelle comme une vérité de label, entraîner depuis une requête après changement des versions sous-jacentes, et appeler la vitesse du chargeur compétence du robot. Un jeu de données d'apparence plus propre n'est pas automatiquement un meilleur signal d'enseignement. La curation aide lorsqu'elle préserve les bons exemples, pas lorsqu'elle flatte le tableau de bord.

Mesurer le comportement du chargeur séparément de la réussite de la tâche robotique

Un plan de mesure cadré

Maintenez constants le code, les exemples sélectionnés, l'ordre de l'échantillonneur, la graine, la configuration des batchs et les réglages temporels lorsque vous comparez les chemins de stockage. Rapportez séparément le comportement à cache froid et à cache chaud. Gardez les phases de téléchargement source et de conversion hors de l'entraînement mesuré, sauf si l'objectif est de mesurer le coût de migration.

Les comparaisons d'entraînement de la version rapportent un débit stable correspondant dans une petite comparaison Koch et une exécution Lance distante plus rapide dans une configuration DROID. Ce sont des résultats rapportés par les auteurs dans des conditions précisées, pas des mesures d'Optijara ni un avantage universel du stockage distant. Les comparaisons portant uniquement sur le chargeur ont aussi utilisé un lecteur amont en développement, donc la révision testée compte. Le guide d'Optijara sur les protocoles de benchmark explique pourquoi les détails de protocole doivent accompagner les résultats.

La perte d'entraînement et l'erreur sur la prochaine action ne sont pas une réussite de tâche en boucle fermée. L'expérience DROID décrite ne fournissait pas de preuve de réussite de tâche en simulateur. L'expérience LIBERO corrompue est séparée et doit le rester. Pour la distinction en aval, voir la carte d'évaluation de la réussite des tâches robotiques d'Optijara.

Réserves et limites

Prévoyez un budget pour la conversion, le stockage temporaire dupliqué, la localité réseau, l'egress, l'accès aux métadonnées et la mémoire des workers. Contrôlez les identifiants et l'accès aux enregistrements, surtout pour les scènes privées. Vérifiez la rétention avant de réutiliser d'anciens manifestes. Traitez les sélections périmées comme suspectes jusqu'à vérification de leurs versions de table et de leurs enregistrements de requêtes.

La licence Apache-2.0 du code compagnon ne remplace pas les permissions du jeu de données. Cette inspection établit le comportement documenté et la structure du code source, pas le succès de l'installation, la compatibilité avec une charge de travail ni les performances du robot. Gardez la première décision d'adoption étroite : ce chemin de stockage peut-il préserver les exemples prévus tout en améliorant le problème mesuré de livraison des données ?