La récompense montait, pas la qualité

À 3 h 14, j’ai envoyé un message Slack dans un canal où j’étais le seul encore éveillé.

cassie run 18402: reward 847.3 (new best)

C’était mon meilleur score. J’ai lancé la dernière simulation en m’attendant à voir une démarche nettement meilleure. Ce n’était pas le cas. Cassie avançait vite, mais ses pas restaient raides et coûteux. Une petite variation du terrain aurait probablement envoyé le robot sur le côté.

J’ai fermé l’ordinateur, mis mes chaussures et fait le tour du quartier.

Une récompense est une spécification

J’entraînais un robot bipède dans MuJoCo avec Ray RLlib. La boucle paraît simple : définir une fonction de récompense, exécuter beaucoup d’épisodes simulés, puis mettre à jour la politique vers les actions qui rapportent davantage.

La difficulté consiste à définir ce que signifie « meilleur ».

Pour la locomotion, je peux récompenser la vitesse vers l’avant et le maintien debout, puis pénaliser l’énergie consommée, les mouvements brusques des articulations ou les pieds qui glissent. Chaque terme reçoit un poids. J’avais choisi ces poids trois semaines plus tôt, devant un café, à partir du comportement recherché et des échecs déjà observés.

La politique ne sait pas que je veux une marche convaincante. Elle ne voit que le score. Si elle avance avec une démarche raide et étrange qui exploite une faiblesse de ma fonction de récompense, elle a correctement résolu le problème que je lui ai donné.

Ce n’est pas l’agent qui triche. C’est la spécification qui est incomplète.

Pourquoi ce score me gênait

Il faisait doux pour un mois de mai. Paris était assez calme pour entendre mes pas et quelques scooters. Une boulangerie avait déjà allumé ses lumières ; quelqu’un préparait les plaques pour le matin.

Pendant ce temps, le robot continuait ses épisodes sur le cluster, bien plus vite que le temps réel. Le problème de récompense m’a alors semblé moins lié au seul RL qu’à une habitude très générale.

Nous pilotons beaucoup de systèmes à l’aide d’indicateurs indirects. L’engagement remplace l’intérêt. Le temps de résolution remplace la qualité du support. Le nombre de lignes modifiées peut remplacer le progrès en ingénierie. Un benchmark remplace la qualité réelle d’un modèle.

Ces indicateurs sont utiles parce que l’objectif véritable est souvent difficile ou coûteux à mesurer. Le problème commence lorsque l’indicateur devient l’objectif. Une équipe de support peut fermer des tickets rapidement tout en laissant les clients mécontents. Un modèle peut réussir un benchmark et échouer sur des entrées ordinaires. Un robot peut obtenir 847,3 tout en marchant mal.

L’IA permet de reproduire ce problème à grande échelle. Lorsqu’un système sait optimiser une cible mesurable à faible coût, une petite erreur dans la cible se répète avec une efficacité impressionnante.

Le désalignement sans science-fiction

Les discussions sur l’alignement de l’IA sautent vite vers les machines conscientes ou les scénarios catastrophes. Dans mon travail, la version courante est beaucoup moins spectaculaire.

C’est un modèle qui fait exactement ce que l’évaluation récompense, sans fournir la réponse souhaitée. Un processus automatisé qui améliore un tableau de bord tout en dégradant le service. Une équipe qui fait confiance à un indicateur propre alors que le comportement réel a dérivé.

Les personnes qui construisent ces systèmes ne cherchent généralement pas à nuire. Elles essaient de livrer, de comparer des expériences et de faire bouger le score. Je le sais : j’en fais partie.

La solution n’est pas d’arrêter de mesurer. Il faut continuer à regarder ce que la mesure représente. Observer la démarche. Lire l’échange avec le client. Tester le modèle hors benchmark. Demander qui supporte l’échec lorsque l’indicateur est mauvais.

Ce travail prend plus de temps que la lecture d’une courbe. C’est précisément pour cela qu’on le saute facilement.

Le lendemain

J’ai dormi jusqu’à midi, répondu à mes messages et modifié la pénalité d’énergie. La récompense a baissé. Après un nouvel entraînement, elle est remontée, cette fois avec une démarche plus fluide.

J’ai enregistré une démo parce que le résultat était réellement meilleur. Puis j’ai appelé mon père pour lui demander comment il avait appris à réparer des voitures à mon âge. Il a parlé quarante minutes ; j’ai pris des notes.

Il n’y a pas eu de révélation. Je n’ai pas quitté l’IA ni décidé que les métriques étaient mauvaises. J’ai écrit une meilleure fonction de récompense et repris le travail.

La leçon est plus modeste : lorsqu’un nombre s’améliore et que le résultat paraît moins bon, il faut regarder le résultat. Le malaise signale peut-être quelque chose que l’objectif ne sait pas mesurer.