Chapitre 10
La piste apprise a été testée : elle non plus ne suffit pas — mais elle élimine deux explications
Prérequis : Chapitres 1 à 9 — dont la politique apprise par clonage comportemental (Proposition B), promue priorité 1 au Chapitre 9.
Piste débutant
Là où on en était
Le Chapitre 9 se terminait sur une promotion : après que deux idées bon marché (des gestes tout
faits dans le menu, une manœuvre de croisière) aient échoué sans faire avancer le score, la piste
qui restait — entraîner une petite fonction qui apprend les bons gestes plutôt que de les écrire
à la main — devenait la priorité numéro un. Ce chapitre raconte ce qui s'est passé quand cette
piste a enfin été construite et testée pour de vrai.
Ce qui a été construit
L'idée : au lieu de proposer au planificateur (Chapitre 4) des histoires tirées au hasard, ou un
petit menu figé de gestes écrits à la main (Chapitre 8), on entraîne une fonction qui a regardé
des milliers d'images des parties d'experts (celles déjà utilisées ailleurs dans le projet) et des
épisodes de couverture aléatoire du Chapitre 7 (ceux qui montrent, eux, de vraies situations
« perdu, en train de chercher »). Cette fonction apprend à prédire : à partir de ce que l'agent voit
maintenant, quelle action un joueur choisirait probablement ensuite.
Point important, déjà annoncé au Chapitre 9 : cette fonction ne décide jamais de l'action finale.
Elle se contente de glisser ses meilleures suggestions dans le tas de 512 histoires imaginées que
le planificateur continue de juger et de corriger à chaque tour — exactement le même principe que
les méthodes de jeu très reconnues évoquées au chapitre précédent (celles qui ont battu des
champions humains aux échecs et au Go) : une intuition apprise propose des coups, une recherche
explicite les vérifie.
Une vérification refusée : l'honnêteté du projet à l'œuvre
Avant de faire confiance à cette fonction, il fallait vérifier qu'elle n'avait pas fait ce que ce
projet redoute depuis le tout premier chapitre : s'effondrer sur une seule réponse toujours
identique, quelle que soit l'image montrée (le piège du « collapse », Chapitre 2 — ici appliqué à
une politique d'action plutôt qu'à une représentation visuelle).
Deux versions ont été entraînées pour tester ça. La version prévue (parties d'experts + épisodes de
couverture mélangés) a passé le test : ses prédictions restent variées, et elle devient nettement
plus hésitante — elle propose un éventail d'actions plus large — sur les images qui ressemblent à
« perdu, en train de chercher » que sur celles qui ressemblent à une scène d'expert bien en face
d'un arbre. Une deuxième version, entraînée uniquement sur les parties d'experts (sans les épisodes
de couverture), a en revanche échoué au test : elle avait appris à presque toujours répondre
« attaque », exactement la faiblesse que le Chapitre 9 redoutait à l'avance. Le programme
d'entraînement a refusé d'enregistrer cette version défaillante — la même discipline que dans
tout le reste du projet : un outil qui échoue à son propre test n'est jamais gardé sous prétexte
qu'il a quand même tourné.
Le test en direct : toujours zéro
Sur 8 épisodes, avec cette fonction en place : 0 bûche coupée, récompense nulle. Comme pour les
tentatives précédentes à cette taille d'échantillon, ce chiffre seul ne prouve rien de définitif —
mais il ne montre non plus aucun signe positif à se raccrocher.
Ce que ce résultat élimine réellement
Le zéro en lui-même n'est pas la partie la plus intéressante. Deux choses précises ont pu être
vérifiées, et éliminées, grâce à ce test :
- Pas de verrouillage sur un seul geste. Contrairement au Chapitre 8, où l'agent se figeait sur
une seule action jusqu'à 100% du temps dans plusieurs épisodes, ici la répartition des actions
reste variée sur les 8 épisodes (l'action la plus fréquente occupe entre 16% et 54% du temps,
jamais plus). La fonction apprise fait bien ce pour quoi elle a été construite : proposer un menu
de gestes divers, pas un menu étroit sur lequel l'agent se fige.
- Pas de point de départ impossible à gagner. Un nouvel outil de diagnostic (annoncé comme
plan au Chapitre 9, construit depuis) confirme que, dans les 8 épisodes, quelque chose de
pertinent était visiblement présent à un moment ou un autre — largement au-dessus du seuil
minimal calibré. Ce lot ne peut donc pas être expliqué par « le point de départ rendait le
succès impossible dès le début », contrairement à certains épisodes des chapitres précédents.
Le nouveau suspect
Une source de propositions vraiment variée, entraînée correctement, testée sur des points de
départ confirmés jouables — et toujours zéro succès. C'est le résultat négatif le plus net de
toute cette enquête, pas juste un zéro de plus : la piste B était la réponse la plus « logique » au
diagnostic du Chapitre 8 (« le problème, c'est la génération des gestes candidats »), et elle n'a
pas fait bouger le résultat.
Ça pousse le diagnostic un cran plus loin, vers une nouvelle hypothèse — pas encore confirmée,
seulement posée : peut-être que le problème n'est pas la diversité des gestes proposés, mais la
façon dont le monde imaginé lui-même juge ces propositions dans une situation qu'il connaît
mal. Le modèle qui note les histoires imaginées a surtout appris sur les parties d'experts, où un
arbre est presque toujours garanti dans le champ de vision. Face à un vrai point de départ
aléatoire — sans cette garantie, avec un angle de caméra quelconque — peut-être qu'il évalue mal
même de bonnes propositions, un peu comme un joueur d'échecs entraîné presque uniquement sur des
ouvertures classiques qui se retrouve à mal juger une position rare et inhabituelle, même si sa
façon de réfléchir reste, par ailleurs, saine.
La suite
Avant de dépenser davantage de temps d'entraînement sur une nouvelle réparation, la prochaine étape
est plus simple : regarder attentivement les images enregistrées de ces 8 épisodes — voir
concrètement ce que l'agent fait sur un point de départ confirmé jouable qui échoue quand même à se
transformer en bûche coupée. Un regard qualitatif avant un nouveau chantier coûteux, exactement la
même discipline que le reste du projet.
Piste expert
Contexte
Le Chapitre 9 a promu la Proposition B (a priori de politique latente entraîné par clonage
comportemental) au rang de priorité 1, après que les Propositions A+C (Chapitre 8, attempt #8)
aient confirmé sans résoudre le diagnostic « mur comportemental ». Ce chapitre couvre l'attempt #9
de CLAUDE.md (Phase 5+) : Proposition B construite, vérifiée, et évaluée en direct.
Ce qui a été construit
mine_jepa/ebwm/actor.py::BCActor : un petit MLP classifieur sur les latents figés de ebwm.pt,
entraîné par scripts/trainactorbc.py avec un gate anti-collapse obligatoire (refuse
l'enregistrement en cas d'effondrement). Entraînement sur les démos Treechop + les épisodes de
couverture de l'attempt #3, pour mélanger du comportement de recherche authentique aux démonstrations
d'experts (le piège identifié au Chapitre 9 : un actor entraîné uniquement sur Treechop apprendrait
« toujours attaquer l'arbre visible »).
Câblage dans sampleactions() via planner.actor_prior (config-gated), vérifié bit-for-bit
identique à l'ancien échantillonneur quand désactivé — confirmé par un run réel à seed fixe, pas
seulement affirmé par analogie avec les autres changements config-gated du projet. Une
vérification d'atteignabilité indépendante montre que les candidats de l'actor gagnent
effectivement l'argmax du planificateur sur 6 tirages sur 40 (contre un taux de base de 25% à
tirage uniforme) — présent dans le flux exécuté, pas du code mort silencieux, sans pour autant
dominer.
Le gate anti-collapse : discriminant, avec un vrai échec refusé
- Actor avec couverture (celui utilisé pour l'évaluation) :
val_acc0,483, entropie moyenne
1,296 nats (sur un maximum de 2,833 nats) → PASS.
- Ablation Treechop-seul :
valacc0,587, entropie 1,102,topaction_frac0,964 → FAIL,
checkpoint correctement refusé.
Ce contraste confirme que les données de couverture étaient réellement porteuses pour le gate, pas
décoratives : sans elles, l'actor se serait effondré vers une politique dégénérée (dominée à 96,4%
par une seule action).
Résultat en direct
N=8, seed 0, configs/playcraftcommit4_actor.yaml, notation goal-centroid uniquement (aucun
signal de distance non plat disponible à ce stade — voir plus bas). 0/8 bûches, récompense nulle.
Fisher exact unilatéral contre le taux de base pooled commit_length=4 seul (3/31 ≈ 9,7%) : p ≈
0,21 — non significatif à ce N.
Ce que ce résultat élimine, précisément
- Pas de verrouillage. Concentration d'action sur les 8 épisodes : pic entre 16% et 54%, dans
toute la plage — rien qui approche le 83-100% de verrouillage quasi total observé à l'attempt #8
sur trois épisodes sur huit. Le mécanisme actor-prior fait ce pour quoi il a été conçu : proposer
un menu de candidats varié et non dégénéré.
- Pas de spawn invivable. Le diagnostic de viabilité du spawn (construit en suivi de l'attempt
#8, spawndiag dans scripts/playcraft.py) confirme que les 8 spawns étaient mesurablement
viables : maxchopstd entre 0,017 et 0,047, confortablement au-dessus du seuil calibré de
0,005. Ce lot ne peut donc pas être expliqué par « le point de départ rendait tout succès
impossible », contrairement à certains épisodes antérieurs.
Diagnostic affiné : un nouveau suspect, pas encore confirmé
C'est le résultat négatif le plus net de la campagne, pas un zéro de plus. Une source de
propositions authentiquement diverse, non effondrée, entraînée sur des démonstrations d'experts et
de la recherche authentique, testée sur des spawns démontrablement viables — et toujours zéro
succès. La Proposition B était la réponse « correcte » au diagnostic du Chapitre 8 (« le mur est
comportemental, réparer la génération d'action ») et elle n'a pas fait bouger le résultat.
Ceci pousse le diagnostic standing un cran plus loin : le goulot d'étranglement n'est peut-être pas
la diversité de ce qui est proposé, mais l'évaluation par le monde imaginé de ces propositions
sous la distribution visuelle de cold-start de MineRLObtainIronPickaxeDense-v0 (spawn aléatoire,
pose de caméra arbitraire, aucune garantie de forêt) — une distribution sur laquelle ebwm.pt n'a
jamais été entraîné à noter correctement, contrairement à celle, garantie-forêt, de Treechop. Pas
encore testé directement ; signalé comme hypothèse suivante, pas encore comme fait établi.
Rappel : deux pistes complémentaires du Chapitre 9 déjà closes avant ce test
- Réparation photométrique de la métrique de distance entraînée (attempt #7) : implémentée
(augmentation.colorjitter dans scripts/trainvalue_projector.py). Le gate offline de
séparation tient toujours (8,7× contre 7,9× à l'attempt #7). Mais la cible réelle — la confusion
avec la luminosité — empire au lieu de s'améliorer sur une mesure isolée plus propre :
corrélation r=0,117 (attempt #7, sans augmentation) → r=0,498 (avec augmentation).
NO-GO — la confusion est vraisemblablement ancrée dans l'espace latent figé de ebwm.pt
lui-même (Treechop, majoritairement diurne), pas introduite par l'entraînement du projecteur ;
perturber seulement les entrées du projecteur ne peut pas défaire un raccourci que l'encodeur
amont a déjà pris. checkpoints/valueprojectorcolorjitter.pt gardé pour comparaison, non
utilisé dans l'évaluation ci-dessus — d'où la notation goal-centroid seule pour l'attempt #9.
- Diagnostic de viabilité du spawn : construit et déjà utilisé ci-dessus (voir « ce que ce
résultat élimine »), pas seulement planifié.
Prochaine étape
Avant tout nouveau chantier d'entraînement : inspection qualitative du GIF
(assets/agentplaycraftcommit4actor.gif) et des vignettes de spawn
(assets/spawn_thumbs/) — comprendre visuellement ce que l'agent fait sur un spawn confirmé
viable qui ne se convertit toujours pas en coupe, avant de décider quel correctif tester ensuite.