Politiques conditionnées par l’objectif : un modèle, de nombreux objectifs

Entraînez un robot à empiler un bloc rouge sur un bloc bleu. Demandez-lui à présent d’empiler le bleu sur le rouge. S’il a été entraîné à l’ancienne, une politique pour une tâche, vous n’avez pas de chance : il s’agit d’une tâche différente, et il faut réentraîner le modèle. Une politique conditionnée par l’objectif traite l’objectif comme une entrée, et non comme une constante figée dans les poids, de sorte que le même modèle peut poursuivre les deux tâches sans réentraînement.

Ce choix de conception à lui seul, faire entrer l’objectif dans la politique, est l’une des raisons discrètes pour lesquelles un seul modèle humanoïde peut désormais tenter des centaines de tâches. Il redéfinit aussi ce que votre jeu de données doit contenir. Une politique capable d’accepter n’importe quel objectif doit avoir vu de nombreux objectifs, chacun associé au comportement qui permet de l’atteindre, et réussir cet appariement est plus difficile qu’il n’y paraît.

L’objectif comme entrée, pas comme hypothèse

Une politique classique associe une observation à une action. Une politique conditionnée par l’objectif associe une observation et un objectif à une action. L’objectif est un argument supplémentaire que le réseau lit à chaque étape, et les mêmes poids produisent un comportement différent selon ce qu’on lui demande.

Le gain, c’est la réutilisation. Un seul jeu de poids couvre une famille de tâches qui partagent la même dynamique mais diffèrent dans l’intention. C’est l’ossature des systèmes multi-tâches modernes, et c’est pourquoi des modèles de fondation comme NVIDIA Isaac GR00T et les politiques généralistes décrites sur le blog de Physical Intelligence sont présentés comme un seul modèle au service de nombreuses instructions, plutôt que comme une étagère de contrôleurs à tâche unique.

Comparez cela à l’alternative. Sans conditionnement par l’objectif, on entraîne un réseau par tâche, et rien de ce qui a été appris sur l’empilement de blocs n’aide à verser de l’eau. La structure partagée est gaspillée. Un modèle conditionné par l’objectif amortit au contraire ce qui est commun à toutes les tâches, l’atteinte, la préhension, le sens du contact, et ne consacre sa capacité qu’à ce qui diffère. C’est pourquoi un seul jeu de poids peut absorber des centaines d’instructions sans exploser en taille.

Comment dire à un robot ce que vous voulez

Un objectif reste abstrait tant que l’on n’a pas choisi une représentation, et ce choix a de réelles conséquences.

• Langage : «mets la tasse dans l’évier». Flexible et proche de l’humain, mais ambigu, et cela nécessite des données appariées langage-action pour ancrer les mots dans le mouvement. C’est la voie VLA empruntée par des systèmes comme Gemini Robotics.
• Image-objectif : une image de l’état final souhaité. Précise et sans ambiguïté, mais il faut cette image pour chaque exemple, et en spécifier une au moment du test peut s’avérer peu pratique.
• Coordonnées ou poses : positions cibles exactes. Excellent pour un mouvement bien défini, inutile pour «ranger la table».

Chaque représentation exige une étiquette différente sur chaque trajectoire. Cette charge d’annotation est le coût caché du passage au multi-tâche, et c’est pourquoi des corpus ouverts comme Open X-Embodiment consacrent un effort réel à standardiser la façon dont les objectifs et les instructions sont enregistrés à travers des dizaines de jeux de données contributeurs.

En pratique, les équipes en choisissent rarement une seule. Un système moderne accepte souvent une instruction en langage naturel de la part de l’humain, puis l’ancre en interne dans un objectif image ou coordonnée que le contrôleur bas niveau peut poursuivre. Cette superposition signifie que la même trajectoire peut nécessiter plusieurs étiquettes d’objectif à la fois, ce qui relève le niveau d’exigence quant à la richesse avec laquelle chaque démonstration est enregistrée.

Une politique conditionnée par l’objectif n’est jamais plus générale que l’ensemble des objectifs présents dans ses données. Objectifs restreints, robot restreint, quelle que soit la taille du modèle.

Le problème de données caché dans «de nombreux objectifs»

Voici le piège. Pour entraîner une politique capable d’atteindre n’importe quel objectif, il semblerait qu’il faille des démonstrations pour chaque objectif, ce qui est impossible. L’échappatoire est une astuce de réétiquetage appelée rétrospection (hindsight).

Le réétiquetage rétrospectif des objectifs est simple et puissant. Un robot essaie d’atteindre l’objectif A et se retrouve à la place dans l’état B. Cette trajectoire est un échec pour A, mais c’est une démonstration parfaite de la façon d’atteindre B. On la réétiquette donc : mêmes actions, nouvel objectif, désormais un succès. Une tentative ratée devient une donnée d’entraînement pour un objectif que personne n’avait demandé. C’est ce qui permet à l’apprentissage conditionné par l’objectif de tirer de nombreux objectifs de données finies, et cela change la façon dont un jeu de données doit être construit.

L’idée vient de l’apprentissage par renforcement, où on l’appelle hindsight experience replay (relecture d’expérience rétrospective), et elle retourne le problème de la récompense rare comme un gant. Au lieu qu’un robot échoue mille fois et n’apprenne rien jusqu’à ce qu’il tombe par hasard sur l’objectif, chaque tentative enseigne quelque chose, car chaque tentative atteint un état qui mérite d’être étiqueté. La conséquence pour la collecte de données est directe. Une trajectoire a de la valeur même lorsque le démonstrateur a manqué son coup, du moment que l’on a enregistré où elle a réellement fini.

Pourquoi le réétiquetage change ce que l’on capture

Si les tentatives ratées et les états finaux imprévus constituent des données d’entraînement, alors un pipeline de capture qui ne conserve que les réussites nettes jette la moitié de son rendement. La rétrospection valorise les données désordonnées, exploratoires, imparfaites, car chaque trajectoire atteint un état, et chaque état atteint est un objectif valide pour cette trajectoire.

Cela inverse le réflexe habituel qui consiste à ne filmer que la prise parfaite. Dans une logique rétrospective, la tentative maladroite qui a dérivé vers la mauvaise étagère n’est pas à jeter, c’est un exemple étiqueté qui montre comment atteindre volontairement cette mauvaise étagère. L’erreur du démonstrateur devient la cible de quelqu’un d’autre. Un pipeline construit autour de cette idée capture plus de données exploitables par heure qu’un pipeline qui recherche des démonstrations impeccables.

Les frameworks ouverts rendent cela concret. La pile Hugging Face LeRobot fournit des recettes conditionnées par l’objectif et multi-tâches qui attendent des données dans un format épisodique standard, avec les objectifs et les résultats enregistrés par épisode. La leçon est constante : le format dans lequel vous enregistrez détermine si vous pourrez réétiqueter plus tard, ou si ce signal est perdu.

Général de nom, ou dans les données

Un modèle, de nombreux objectifs, ce n’est pas seulement une astuce de modélisation. C’est un pari sur les données. La politique ne peut poursuivre que les objectifs qu’elle a effectivement vus, et le moyen le plus économique d’en voir davantage est de cesser de jeter les états que vos démonstrateurs ont atteints par accident. Décidez tôt de la représentation de l’objectif, enregistrez les résultats avec autant de soin que les intentions, et un stock fini de démonstrations s’étendra sur un ensemble de tâches bien plus large. Faites l’impasse là-dessus, et une architecture multi-objectifs pourtant puissante finira entraînée sur une tranche étroite d’objectifs, générale de nom seulement.