Apprendre à fabriquer : la règle est comprise, le premier arbre reste hors de portée

Piste débutant

Le prochain objectif : fabriquer un outil

Le Chapitre 5 s'est arrêté sur une vraie victoire : l'agent coupe du bois en vrai Minecraft,

environ une fois sur quatre. La suite logique, c'est de lui apprendre à faire quelque chose

avec ce bois — le transformer en planches, puis en outil. Le rêve de départ était « une IA qui

fabrique une épée en bois ». Petit contretemps amusant : dans la version de Minecraft utilisée

par ce projet (MineRL 0.4.4), l'épée en bois n'existe tout simplement pas comme action de

fabrication — seule la branche technologique qui mène à la pioche est câblée dans le jeu. Le

nouvel objectif devient donc : couper une bûche, puis la transformer en planches, en bâton, poser

une table d'établi, et fabriquer une pioche en bois. La chaîne complète de fabrication.

Pour ça, le projet change d'environnement : au lieu de Treechop (« coupe un arbre, rien

d'autre »), il passe à MineRLObtainIronPickaxeDense, une version de Minecraft qui donne accès à

l'inventaire du joueur (combien de bûches, de planches, de bâtons il possède) et qui récompense

chaque objet obtenu (une bûche vaut 1 point, une planche 2, etc.).

Premier essai : deviner l'inventaire depuis l'image → ça ne peut pas marcher

La première idée semblait naturelle : garder l'encodeur qui résume l'image (Chapitre 1), et lui

coller une petite extension qui essaie de deviner l'inventaire à partir de cet embedding (ce

résumé en nombres de l'image).

Ça ne pouvait pas marcher, et la raison est presque évidente une fois qu'on la voit : l'écran

ne montre jamais le nombre de planches que tu possèdes. Quand tu fabriques des planches dans

Minecraft, l'image à l'écran ne change presque pas — le compteur « planches : 36 » est une donnée

à part, jamais dessinée dans la vue à la première personne. Résultat : cette extension n'apprend

que des vagues corrélations de décor (« scène de forêt → peu de planches », « près d'une table →

plus de planches »), jamais la vraie règle. Et comme l'image ne change presque pas pendant qu'on

fabrique, le world model se contente de « copier » l'embedding précédent — sa prédiction ne

change quasiment rien. En jeu, cet agent ne fait rien d'utile. Un échec net, mais qui apprend

quelque chose d'important.

L'idée clé de ce chapitre

Puisqu'on ne peut pas deviner l'inventaire depuis l'image, il faut que l'inventaire devienne une

entrée du world model — une donnée qu'on lui fournit directement, au lieu d'essayer de la lui

faire retrouver depuis les pixels. C'est exactement pour ça que Minecraft, dans cette version de

l'environnement, donne l'inventaire comme observation séparée : le jeu sait bien que ce n'est pas

visible à l'écran.

Deuxième essai : l'inventaire comme mémoire du modèle → ça marche

La nouvelle version du world model (appelée WM v4 dans le projet) sépare deux choses :

• une partie visuelle — l'eb-JEPA du Chapitre 5, qui comprend « y a-t-il un arbre devant

moi ? suis-je près d'une table ? » ;

• une partie inventaire — une petite fonction ajoutée au modèle qui prend l'inventaire

actuel, l'action choisie, et ce que voit la partie visuelle, et qui prédit le nouvel

inventaire.

Concrètement : `nouvelinventaire = ancieninventaire + changement(ancien_inventaire, action,

cequeje_vois)`. En entraînant cette fonction sur les parties d'humains, le modèle a appris,

tout seul, une règle simple mais très concrète : fabriquer avec une bûche produit quatre

planches — exactement la vraie recette de Minecraft, apprise sans jamais être écrite dans le

code, juste observée dans les données.

Le piège des démonstrations humaines : personne ne rate jamais un craft

Un modèle qui sait « fabriquer → +4 planches » n'est pas suffisant. Une fois mis en jeu, l'agent

s'est mis à appuyer sur « fabriquer » en boucle, même sans aucune bûche en poche — ce qui,

bien sûr, ne produit rien.

La raison est amusante et instructive : aucun joueur humain n'essaie de fabriquer quelque chose

sans en avoir les ingrédients. Les enregistrements de parties humaines utilisées pour

l'entraînement ne contiennent donc aucun exemple de craft raté. Le modèle a appris « fabriquer

→ +4 planches » de façon absolue, sans jamais voir qu'il fallait une bûche au préalable. C'est un

piège classique de l'apprentissage à partir de démonstrations d'experts : des experts ne

montrent jamais leurs échecs, donc le modèle n'apprend jamais les conditions qui doivent être

réunies avant d'agir.

La solution retenue ici, sans attendre une boucle complète d'exploration autonome (le sujet des

prochains chapitres) : fabriquer artificiellement des exemples négatifs. On dit au modèle,

explicitement : « si tu fabriques sur un inventaire vide, le résultat est zéro ». Il a fallu

doser cet ajout avec soin — la première tentative, trop appuyée, a écrasé le signal positif (le

modèle s'est mis à prédire quasiment zéro planche tout le temps, même sur les vrais crafts

réussis). Le bon équilibre : donner beaucoup plus de poids aux rares moments de craft réel dans

les données (144 sur 85 000 instants, largement noyés sinon) et une pénalité plus modérée pour le

craft sur inventaire vide. Résultat final : le modèle sait à la fois « craft + bûche → +4

planches » et « craft + inventaire vide → rien ». L'agent arrête de fabriquer dans le vide.

Un planificateur qui change d'objectif selon ce qu'il a en poche

Le planificateur (celui du Chapitre 4, qui imagine plusieurs futurs et choisit le meilleur) reçoit

maintenant deux objectifs possibles, et choisit selon l'inventaire :

• pas de bûche → objectif « couper du bois » (la même astuce qu'au Chapitre 5) ;
• au moins une bûche → objectif « maximiser le gain d'inventaire » (planches, bâtons...).

La preuve que la fabrication marche, en vrai Minecraft

Pour vérifier que la fabrication marche vraiment, indépendamment du problème « trouver le

premier arbre » (qui reste dur, on va y venir), le projet lance l'agent dans une version de test

de l'environnement qui démarre directement avec du bois en poche (5 bûches, 3 planches). Sur 6

épisodes, 100% de réussite : l'agent fabrique à chaque fois entre 16 et 20 planches

supplémentaires, avec une récompense de 10 points. C'est un agent qui planifie et exécute

lui-même toute la chaîne de fabrication — on lui donne juste le bois de départ.

Petite remarque amusante et cohérente avec tout ce chapitre : on ne voit rien à l'écran pendant

que l'agent fabrique. La preuve de la réussite, ce n'est pas une image impressionnante — c'est

le compteur d'inventaire et la récompense qui montent. Exactement la raison pour laquelle

l'inventaire a dû devenir une mémoire du modèle plutôt qu'une chose à deviner depuis l'image.

Le mur qui reste : trouver le premier arbre, seul

Voici l'honnêteté qui clôt ce chapitre. Une fois lâché dans le vrai jeu, en mode survie, sans

bois de départ, l'agent se comporte de façon sensée — il passe tout son temps en mode « couper du

bois », avance de façon dirigée plutôt qu'au hasard — mais sur 5 épisodes, il n'a coupé aucune

bûche.

Pourquoi c'est plus dur qu'au Chapitre 5 : dans Treechop (Chapitre 5), le joueur apparaît toujours

au milieu d'une forêt dense, avec des arbres garantis dans son champ de vision. Ici, le joueur

apparaît n'importe où dans un monde de survie généré au hasard — les arbres peuvent être

loin, cachés derrière une colline, ou totalement absents du champ de vision de départ. L'agent

doit d'abord chercher un arbre avant de pouvoir le couper, une capacité que rien, jusqu'ici,

ne lui a jamais appris.

Le bilan honnête de ce chapitre : la partie « comprendre la règle de fabrication » est

résolue — le world model a vraiment appris la recette, et l'agent fabrique parfaitement une fois

qu'il a du bois. Le vrai problème ouvert, c'est de trouver ce premier arbre depuis un point de

départ aléatoire. C'est le sujet des chapitres suivants.