Pourquoi le data flywheel de la robotique a besoin d’échecs, pas seulement de réussites
Les démonstrations composées uniquement de réussites flattent une policy robotique et masquent l’endroit où elle échoue. Pourquoi le data flywheel ne prend de l’ampleur que lorsque l’on capture les échecs et les quasi-échecs.
Une policy qui n’a jamais vu que des situations où tout se passe bien n’a aucune idée de ce qu’il faut faire lorsque les choses tournent mal. Montrez-lui dix mille préhensions propres et elle apprendra à merveille la préhension propre. Puis, en déploiement, la pince accroche la tasse, la tasse bascule d’un demi-centimètre, et la policy se retrouve face à une scène qu’aucune démonstration ne contenait. Elle n’a aucune parade pour cela. La seule compétence dont elle a désormais besoin, savoir se rattraper, était précisément la chose que personne n’avait songé à enregistrer.
Presque tous les efforts de capture sont tournés vers la réussite. C’est compréhensible : une démonstration est ce que l’on souhaite voir le robot imiter, alors on garde la prise qui a fonctionné et on jette le raté. Mais une policy progresse le plus vite à partir des états où elle échoue, et ce sont précisément ces états qu’un jeu de données uniquement composé de réussites laisse de côté. Le data flywheel que tout le monde convoite, déployer, collecter, réentraîner, ne prend de l’ampleur que si l’étape de collecte capture les échecs et les quasi-échecs, les exploite, et dirige le prochain lot de capture précisément vers ces états.
Le problème est structurel, ce n’est pas une question de discipline. Dans tout ensemble sélectionné, les échecs sont plus rares que les réussites, ils sont plus délicats à stocker, et bien plus difficiles à annoter. Livré à lui-même, chaque jeu de données dérive vers le biais du survivant : une archive bien rangée de victoires faciles qui flatte le modèle et ne vous apprend presque rien sur l’endroit où il échoue.
La policy échoue là où l’expert n’est jamais allé
Commençons par le mode de défaillance qui hante l’apprentissage par imitation depuis ses origines. Entraînez une policy en copiant des démonstrations d’expert et elle n’apprend la correspondance entre états et actions que pour les états que l’expert a réellement visités. Ces démonstrations sont, par construction, un ruban étroit de trajectoires quasi parfaites. En déploiement, la policy commet une petite erreur, cette erreur l’écarte du ruban, et la voilà dans un état un peu plus éloigné de tout ce qu’elle a vu à l’entraînement, où son action suivante est un peu moins bonne. Les erreurs se cumulent. C’est le covariate shift (décalage de covariables), et c’est pourquoi une policy dont la précision par pas atteint 99 % peut malgré tout échouer la plupart du temps sur une tâche à long horizon.
La solution classique, DAgger et ses successeurs, n’est pas une fonction de perte plus astucieuse. C’est une règle de collecte de données : exécuter la policy actuelle, la laisser dériver vers les états qu’elle atteint réellement, et recueillir les corrections de l’expert précisément là. Les travaux issus de Berkeley BAIR et, plus largement, de la littérature cs.RO redécouvrent sans cesse le même constat sous un habillage nouveau : les données qui réparent une policy ne sont pas davantage de trajectoires idéales de l’expert, c’est la couverture des états hors distribution que la policy visite lorsqu’elle commence à mal tourner. Ces états jouxtent les échecs, car dériver vers un échec est exactement leur nature.
Le rattrapage est une compétence, et il doit être montré
Il y a une différence entre une policy qui n’échoue pas et une policy qui se rattrape, et seule la seconde survit au contact du monde réel. Le rattrapage est une compétence à part entière : reprendre la préhension après un glissement, se réapprocher après un raté, se dégager d’un blocage pour tenter un autre angle. Rien de tout cela n’apparaît dans un jeu de données où chaque épisode part d’une réinitialisation propre et se termine par une réussite. Si le modèle n’a jamais vu la transition du raté au corrigé, il ne peut pas produire cette transition à la demande.
C’est pourquoi la collecte corrective, de type intervention, compte. Un superviseur humain observe la policy s’exécuter, prend la main dès l’instant où elle commence à échouer, montre comment s’en sortir, puis rend le contrôle. Les images précieuses sont celles qui encadrent l’intervention : la glissade vers les difficultés et la remontée. Les obtenir suppose de laisser la policy échouer un peu volontairement, ce qui heurte tout l’instinct selon lequel la capture doit être propre. Un jeu de données qui ne laisse jamais le robot trébucher ne pourra jamais lui apprendre à se rattraper.
Les négatifs difficiles, ou la valeur de savoir ce qu’il ne faut pas faire
Les démonstrations réussies indiquent à un modèle ce qu’il faut faire. Elles restent muettes sur ce qu’il ne faut pas faire, et ce silence coûte cher dès l’instant où vous avez besoin qu’un modèle juge, classe ou note un comportement plutôt que de simplement l’imiter. Un modèle de récompense, une fonction de valeur ou un modèle du monde appris doit distinguer une bonne trajectoire d’une mauvaise. Ne lui donnez que des bonnes et il n’a aucune base pour faire la distinction. Il n’a jamais vu la frontière qu’il est censé tracer.
Le hard-negative mining est la discipline qui consiste à trouver les échecs les plus proches de la réussite, les quasi-échecs où la prise a presque tenu ou le tenon s’est presque logé, et à leur accorder un poids élevé, car ce sont ces cas qui fixent réellement la frontière. Google DeepMind et d’autres groupes qui construisent de grands modèles de comportement et modèles du monde traitent de plus en plus les journaux de déploiement comme une mine pour exactement ces états : ceux où la policy était incertaine, ou ceux où une exécution autonome a divergé de ce qu’un humain aurait fait. Un échec facile, le robot qui rate de très loin, n’apprend pas grand-chose. Le négatif difficile, l’échec qui ressemblait à une réussite jusqu’au dernier centimètre, vaut cent victoires propres.
Un jeu de données composé uniquement de réussites apprend à un robot à avoir de la chance, pas à être robuste. Les états qui décident d’un déploiement sont ceux que personne n’a voulu enregistrer.
Pourquoi les victoires faciles s’accumulent et pas les échecs
Si les données d’échec ont tant de valeur, pourquoi sont-elles si rares ? Parce que chaque maillon de la chaîne conspire à les écarter. La téléopération, encore le cheval de bataille de la capture de haute qualité, produit naturellement des réussites : un opérateur habile se trompe rarement, et quand cela arrive, le réflexe est de supprimer la prise et de recommencer. Les échecs sont déjà plus rares au départ, et les bons, les quasi-échecs instructifs, le sont plus encore. Ils sont plus délicats à stocker, souvent partiels ou ambigus, sans état final propre pour les ancrer. Et ils sont bien plus difficiles à annoter. Une réussite s’annote d’elle-même, la tâche est accomplie. Un échec soulève des questions auxquelles un humain doit répondre : quand exactement les choses ont-elles mal tourné, quelle était la bonne action à cet instant, et à quoi aurait ressemblé le rattrapage. Cette annotation est lente, subjective et sujette à l’erreur.
Le résultat se voit dans les corpus publics. Les grands jeux de données de téléopération et cross-embodiment sur lesquels le domaine s’entraîne sont, en écrasante majorité, des trajectoires réussies, car c’est ce qu’il valait la peine de conserver sous l’ancienne hypothèse selon laquelle on imite les réussites. Toyota Research Institute, dans ses travaux sur les large behavior models, reconnaît franchement qu’une évaluation honnête, et par extension un entraînement honnête, dépend de la couverture des cas où le comportement se dégrade, et pas seulement de ceux où il brille. Vous ne pouvez même pas mesurer la robustesse sans échecs pour la mettre à l’épreuve, encore moins l’entraîner.
| Dimension | Capture uniquement de réussites | Capture tenant compte des échecs |
|---|---|---|
| Couverture des états | Le ruban étroit des trajectoires d’expert | Ajoute les états hors distribution vers lesquels une policy dérive |
| Robustesse en déploiement | Fragile dès que les erreurs se cumulent | Tient sous la dérive et les perturbations |
| Comportement de rattrapage | Absent, aucune transition du raté au corrigé | Exemples explicites de reprise de préhension et de nouvelle approche |
| Signal pour les modèles de valeur et de récompense | Aucun négatif, impossible de tracer la frontière | Des négatifs difficiles qui fixent la ligne bon/mauvais |
| Difficulté de collecte | Faible, les réussites viennent gratuitement | Élevée, vous devez laisser la policy échouer volontairement |
| Coût d’annotation | Faible, une réussite s’annote d’elle-même | Élevé, quelqu’un doit annoter quand et pourquoi elle a échoué |
L’avantage revient à celui qui garde les erreurs
L’instinct de collecter des réussites n’est pas faux, il est incomplet. Une policy doit voir la forme de la tâche bien exécutée, et elle doit voir les moments où la tâche a failli se défaire avant d’être sauvée. Les équipes qui prennent de l’avance ne sont pas celles qui détiennent le plus gros tas de démonstrations impeccables. Ce sont celles qui ont cessé de jeter les échecs, ont appris à les annoter, et ont commencé à orienter le prochain lot de capture droit vers les états où leur meilleur modèle échoue encore.