Chaque flotte devrait apprendre de sa propre expérience.

Imaginez un véhicule qui approche d’une zone de travaux ayant changé pendant la nuit. Son modèle peine à interpréter la nouvelle configuration. L’enregistrement devrait devenir bien plus qu’un fichier journal ou qu’une investigation ponctuelle. Avec le bon contexte, il peut aider l’équipe à comprendre la défaillance, à préparer de meilleures données d’entraînement et à vérifier si le prochain modèle gère cette situation avec davantage de fiabilité.

C’est l’avenir que nous souhaitons pour les machines autonomes : une expérience qui devient un apprentissage utile, cycle après cycle, des premières démonstrations qu’une équipe enregistre aux flottes qu’elle exploitera un jour. Un robot de livraison, une machine de récolte et un bras industriel font face à des problèmes différents. Leurs concepteurs partagent le besoin de relier ce qui se passe dans le monde à ce qui change dans le modèle. Nous voulons que ce lien devienne une infrastructure fiable.

Chez Tesla Autopilot, j'ai été le premier ingénieur à travailler sur le fleet learning : les systèmes qui transformaient les cas limites de la flotte en améliorations du modèle. Ce travail m'a appris à regarder au-delà du modèle lui-même : comment l'équipe trouve des exemples utiles, préserve le contexte capteur, décide de ce qui s'est passé et transforme ces décisions en jeu d'entraînement suivant. La capacité à répéter ce processus compte autant que n'importe quelle percée isolée.

J’ai fondé Avala parce que les autres équipes de Physical AI ne devraient pas avoir à construire tout ce socle à partir de zéro. Elles devraient pouvoir consacrer le meilleur de leur ingénierie aux machines et aux modèles qui les distinguent. Avala devrait leur offrir un moyen fiable d’apprendre du monde, de leur premier flux de travail en production aux flottes qu’elles exploiteront un jour.

La stack IA compte cinq couches, de la machine à l’œuvre jusqu’à l’électricité qui l’alimente. Les données ne sont pas une couche à part. Elles vivent dans la couche des modèles, en tant qu’actif du client, parce que c’est d’elles que le modèle apprend. L’infrastructure est ce sur quoi un modèle est construit, amélioré et exécuté : tout ce qui touche aux données qui le créent, et la puissance de calcul sous-jacente.

1. Applications

   Ce qu’une machine fait pour quelqu’un : le robot, le véhicule, le drone à l’œuvre.

2. Modèles

   Le cerveau et ce qui l’instruit : le modèle du client et les données du client. L’évaluation et le post-entraînement ont lieu ici, sur la propre puissance de calcul du client.

3. Infrastructure

   Ce sur quoi les modèles sont construits, améliorés et exécutés : tout ce qui touche aux données qui les créent, de la collecte à la publication vérifiée, et l’outillage, la puissance de calcul et le cloud sous-jacents.

   Avala est ici

4. Puces

   Le silicium.

5. Énergie

   L’électricité qui borne tout le reste.

Avala est dans la couche d’infrastructure, juste sous le modèle du client. Nous ne construisons pas de robots, ne possédons pas le modèle du client, ne vendons pas de puissance de calcul et ne fabriquons pas de puces. Nous construisons l’infrastructure de données et d’apprentissage par laquelle le propre modèle du client apprend de sa propre flotte.

Une machine peut échouer parce qu’elle n’a pas rencontré une situation, parce que sa supervision est incohérente, ou parce que le problème se situe ailleurs que dans ses données d’entraînement. La première tâche est de comprendre l’écart.

Notre vision est un système qui relie un objectif d’apprentissage à un plan de données explicite : quelle expérience existante utiliser, quelle expérience nouvelle acquérir, comment la qualifier, et quelle expérimentation établira si elle a aidé. La couverture large et l’apprentissage ciblé vont ensemble. Le but n’est pas simplement un dataset plus grand. C’est une décision mieux étayée sur ce qu’il faut faire ensuite.

Cette discipline joue dans les deux sens. Parfois, la bonne intervention consiste à réparer une calibration, à modifier une politique d’annotation ambiguë ou à rééquilibrer les données qu’une équipe possède déjà. Un partenaire de données crédible devrait parfois dire à un client de ne pas acheter davantage de données.

Un dataset est une preuve, pas l’objectif. Pour chaque objectif d’apprentissage, nous conservons la capacité mise à l’épreuve, les situations qui la sollicitent, les preuves utilisées pour l’entraîner, le critère utilisé pour l’évaluer et le résultat.

C’est ce qui rend un programme d’apprentissage reproductible. La même capacité peut être testée sur une nouvelle version des données, un nouveau modèle ou un nouvel environnement d’exécution sans reconstruire le raisonnement qui l’a produite. Avec le temps, ces capacités versionnées deviennent l’historique opérationnel de la façon dont une machine a appris.

Un exemple utile du monde physique est plus qu’une image d’un objet. La tâche peut dépendre de ce qui s’est passé avant, de ce que la machine ou la personne a tenté, et de ce qui s’est passé ensuite. Nous relions les observations des capteurs au contexte disponible pour la tâche : chronologie, géométrie, trajectoires, actions là où elles ont été enregistrées, résultats et interprétation humaine.

Ce contexte reste inspectable tout au long de la collecte, de la revue, de la préparation du dataset et de l’évaluation. Les informations manquantes ou incertaines sont visibles, et non cachées derrière une annotation terminée. Une scène 4D reconstruite préserve le contexte physique pour qu’il puisse être inspecté ; elle ne remplace pas les actions mesurées, le contact ou la validation là où une tâche les exige.

Notre travail commence avec les données de production d'une flotte : des enregistrements capteurs multimodaux reconstruits en données 4D, labellisés par l'IA et des relecteurs experts, et publiés comme jeux de données versionnés sur lesquels le client s'entraîne. Les enregistrements MCAP et ROS, les images caméra, le LiDAR et les trajectoires de robots doivent rester reliés au contexte qui les rend utiles. Nous réunissons logiciel et opérations expertes pour préparer des données qui répondent aux exigences d'entraînement du client.

Commencez par un problème récurrent : des annotations incohérentes, des exemples manquants ou un jeu de données d’entraînement qui nécessite un nouveau cycle de corrections. Définissez ce qui est acceptable. Mesurez les délais, la qualité et l’effort total. Puis facilitez la production de la version suivante. C’est ainsi qu’un projet de données précis peut devenir un système sur lequel le client s’appuie, plutôt qu’une livraison isolée de plus.

En 2028, Avala est l’infrastructure ouverte sur laquelle tout opérateur de machines dans le monde physique transforme sa propre expérience en sa propre intelligence, avec les données, les modèles et le déploiement sous son propre contrôle, pour que chacun puisse être propriétaire de son intelligence plutôt que locataire de celle d’un autre. Nous comptons mériter cette position en quatre phases reliées.

1. 01

   Faire ses preuves sur un flux de travail en production.

   Résoudre un problème qu’un client doit résoudre maintenant. Livrer selon un critère d’acceptation clair et mesurer le résultat par rapport au processus précédent. Rendre le cycle suivant plus fiable, sans se contenter d’une première livraison impressionnante.

2. 02

   Devenir le socle commun aux modèles et aux équipes.

   Étendre la même identité du dataset, le même historique de revue et les mêmes politiques de qualité à davantage de flux de travail. Chaque extension devrait réutiliser l’infrastructure déjà en place. Le test consiste à vérifier si une autre équipe ou un autre modèle peut en bénéficier sans nouveau projet d’ingénierie sur mesure.

3. 03

   Automatiser la recherche entre la découverte et l’amélioration.

   Progresser vers des agents de recherche capables d’enquêter sur une défaillance de flotte, de retrouver les preuves, de les comparer aux cas antérieurs, de proposer une expérimentation, de trouver ou de commander les exemples manquants et d’évaluer le résultat. Leurs conclusions restent traçables jusqu’aux preuves physiques, leurs évaluateurs sont testés sur des critères cachés, et les changements à fort impact restent soumis à examen et réversibles. Le but n’est pas un agent qui produit plus de données. C’est un système qui devient meilleur pour décider quelle expérimentation mérite d’être menée ensuite.

4. 04

   Rendre l’apprentissage portable dans tout l’écosystème.

   Relier les systèmes robotiques, les modèles et l’infrastructure au moyen d’interfaces ouvertes. Les équipes devraient pouvoir adopter de meilleurs outils sans renoncer à leur historique. Des datasets et des modèles partagés peuvent étendre ce socle lorsque leurs propriétaires choisissent de les partager et que leur réutilisation est autorisée. L’interopérabilité devrait élargir l’accès, sans imposer de céder le contrôle.

Une expérience utile du monde physique existe déjà, mais elle est incomplète, inégalement couverte et, pour l’essentiel, déconnectée des décisions qui amélioreraient un modèle donné. L’expérience qui compte le plus est encore produite un déploiement à la fois, par les entreprises qui possèdent les machines, et ce sont surtout des exceptions : les situations que personne n’a simulées. Aucune entreprise ne la détiendra seule. C’est pourquoi l’infrastructure qui la trouve, la qualifie, la combine et la complète doit être indépendante, et pourquoi elle doit laisser la propriété là où les données sont nées.

Les clients devraient conserver l’avantage que leur confèrent leurs ressources propriétaires. Apprendre de l’expérience d’une flotte ne doit pas signifier regrouper discrètement ses données avec celles d’un concurrent. Les enregistrements, annotations, résultats d’évaluation et modèles d’un client ne deviennent jamais l’avantage d’un autre client sans l’accord explicite de ce client. Un dataset partagé l’est par accord, et sa réutilisation est rendue explicite. Ouvert a pour nous un sens précis : des interfaces interopérables, des données et un historique exportables, des droits d’usage clairs et un déploiement contrôlé par le client. L’indépendance signifie que votre partenaire d’infrastructure n’appartient ni à un laboratoire de modèles, ni à un fabricant de robots, ni à un hyperscaler. Avala devrait mériter sa place par la valeur du système, et non par la difficulté à le quitter.

Les personnes qui enseignent aux machines et les évaluent apportent plus qu’une capacité d’annotation. Elles définissent les tâches, reconnaissent les erreurs significatives, jugent les résultats et fixent les critères à l’aune desquels les systèmes automatisés sont testés. Leur jugement mérite de bons outils, une rémunération juste et des voies d’accès à un travail plus qualifié. Nous voulons que l’automatisation élimine les efforts répétitifs tout en donnant plus de valeur à l’expertise : de meilleures décisions consignées dans le processus, de meilleurs logiciels pour accompagner la tâche suivante et moins d’erreurs répétées.

L’objectif plus large est un travail physique plus sûr et plus productif, ainsi que des services utiles à la portée de davantage de personnes. Nous voulons qu’une petite équipe de robotique puisse s’appuyer sur des capacités qui exigeraient autrement une vaste organisation interne. De meilleures machines sont le moyen. Permettre à davantage de personnes de construire, de gagner leur vie et d’en bénéficier est le but.

La Physical AI va changer ce qu’est le travail, qui peut se payer des soins, et comment circulent les biens et la nourriture. Nous voulons que ce changement soit bon pour les gens d’une manière qui puisse être vérifiée, et non supposée. Quatre engagements façonnent notre façon de construire.

1. 01

   Les personnes qui enseignent aux machines sont rémunérées et formées pour cela.

   Les coworkers d’Avala sont rémunérés pour le travail accepté, à des tarifs supérieurs à la norme pour ce travail et ce lieu, avec la formation intégrée. L’automatisation élimine la répétition ; le jugement qualifié reste aux personnes.

2. 02

   Le propriétaire de la machine possède le modèle.

   Les données de flotte d’une entreprise et l’intelligence qui en est tirée restent sous son contrôle, dans des formats ouverts qu’elle peut emporter en partant. Aucun laboratoire, fabricant de robots ou cloud ne s’interpose entre une équipe et sa propre expérience.

3. 03

   Mesurée avant qu’on lui fasse confiance.

   Chaque version est notée par rapport à une référence fixée par le client, y compris ce qui ne s’est pas amélioré. Une machine gagne un usage plus large par les preuves, une évaluation à la fois.

4. 04

   Les petites équipes obtiennent des capacités de grande entreprise.

   Une équipe de robotique de dix personnes devrait pouvoir apprendre du monde comme le fait une flotte de milliers de machines. Abaissez le coût de cette boucle, et davantage de personnes pourront construire de meilleures machines, en tirer un revenu et en bénéficier.