Essayer 512 avenirs dans sa tête avant d'appuyer sur un bouton

Piste expert

Le problème et sa formalisation

À l'issue des Chapitres 1-3, on dispose de f_θ : x → s ∈ R^D (encodeur, figé depuis la Phase 1)

et g : (st, at) → ŝ_{t+1} (world model, Phase 2). Il manque une politique. Mine-JEPA choisit

de ne pas apprendre de politique paramétrique (pas de policy gradient, pas de fonction de

valeur) — la planification se fait directement par recherche dans l'espace latent, à chaque pas

de temps, en réutilisant les modules déjà entraînés sans gradient additionnel.

Construction du goal embedding

good_frames = frames[food >= 7]          # ~16 000 frames sur 32 000
goal = encoder(good_frames).mean(dim=0)  # [D] — centroïde

Le goal est un centroïde post-hoc dans l'espace latent, construit à partir d'un sous-ensemble du

dataset de collecte filtré sur un proxy de survie (food ≥ 7), sans aucune étiquette de tâche

fournie pendant l'entraînement de l'encodeur ou du world model.

Random-shooting MPC

Pour chaque pas de temps :
  1. Encoder l'état courant  →  s_t
  2. Tirer N=512 séquences d'actions aléatoires de longueur H=12
  3. Pour chaque séquence : dérouler le world model sur H pas → ŝ_{t+H}
  4. Scorer : score_i = -MSE(ŝ_{t+H,i}, s_goal)
  5. Exécuter la première action de la séquence au meilleur score
  6. Répéter (horizon glissant)

class LatentMPCPlanner:
    @torch.no_grad()
    def plan(self, s_current, s_goal):
        s = s_current.expand(self.n_candidates, -1).clone()          # [N, D]
        actions = torch.randint(0, self.n_actions,
                                 (self.n_candidates, self.horizon))    # [N, H]
        for h in range(self.horizon):
            s = self.predictor(s, actions[:, h])                      # [N, D]
        scores = -(s - s_goal).pow(2).mean(dim=1)                     # [N]
        return actions[scores.argmax(), 0].item()

L'intégralité du planificateur tient en une dizaine de lignes — un corollaire direct du fait que

tout le calcul lourd (compréhension de scène, dynamique) a déjà été poussé dans l'encodeur et le

predictor lors des phases précédentes ; le planificateur lui-même n'est qu'une recherche.

Justification du budget de calcul

Espace de séquences : 17^12 ≈ 6×10^11. Le budget de candidats (N=512) n'en couvre qu'une

fraction infime, mais suffit parce que de nombreuses actions ont des effets à court terme

similaires (redondance directionnelle de l'espace d'action de Crafter) — l'échantillonnage

i.i.d. couvre les grandes directions utiles sans avoir besoin d'une recherche exhaustive. Le

rollout batché de 512×12 pas s'exécute en < 5 ms sur GPU, car chaque pas n'est qu'un forward pass

du predictor (~140K paramètres) sur un batch de 512 — tout se passe en espace latent, sans jamais

retoucher le moteur de rendu ni l'environnement réel.

Horizon glissant

Re-planifier à chaque pas à partir de l'état réellement observé, plutôt que d'exécuter le plan

de 12 pas en aveugle, corrige l'erreur composée accumulée par le world model sur des rollouts

longs (cf. Chapitre 03, section sur l'accumulation d'erreur k-step). C'est un choix structurel :

la robustesse vient de la fréquence de re-planification, pas de la précision du world model seul.

Résultats mesurés — deux évaluations distinctes

docs/05_planning.md rapporte une évaluation sur 50 épisodes Crafter :

CLAUDE.md (le gate officiel de la Phase 3) rapporte des chiffres distincts sur ce qui semble

être un lot d'épisodes différent : 100% de taux de succès, 2,56 achievements/épisode contre

2,38 pour la baseline aléatoire (+7,5%), et récompense +14%. Les deux mesures viennent de

la même Phase 3 et pointent dans la même direction (amélioration nette sur les trois métriques,

succès quasi-total), mais ne coïncident pas chiffre pour chiffre — cohérent avec le fait qu'il

s'agit de deux runs d'évaluation distincts plutôt que d'une même mesure rapportée deux fois. Les

deux sont rapportées ici telles quelles plutôt que forcées à s'accorder. Le premier épisode

enchaîne 3 achievements (wakeup, collectwood, place_table) — une séquence qui suppose de

localiser un arbre, s'en approcher, le frapper, puis poser un objet, sans logique de tâche

codée à la main.

Pourquoi ça marche

Le predictor conditionné par l'action a appris la fonction de transition ŝ{t+1} = g(st, a_t).

Quand l'objectif est un centroïde de « bons » états, le score -MSE(ŝ{t+H}, sgoal) favorise

naturellement les séquences d'actions qui font converger la trajectoire latente vers cette région

— sans qu'aucune récompense de tâche explicite n'ait jamais été injectée dans l'entraînement de

l'encodeur ou du predictor. Le comportement orienté-but émerge entièrement de la combinaison

(world model + recherche), pas d'un objectif d'apprentissage par renforcement.

Limites identifiées et pistes du projet

Limite principale : le goal embedding est un centroïde — il encode à quoi ressemble le but,

pas comment l'atteindre. Deux états visuellement distincts peuvent être proches dans l'espace

latent sans être équivalents fonctionnellement (ambiguïté géométrique de l'espace latent) ; ceci

préfigure un problème plus large — la géométrie latente sur laquelle repose la planification n'est

pas garantie par la seule qualité de prédiction — qui refera surface dans une phase ultérieure du

projet, sur un jeu de données différent.

Extension future notée dans le plan de la Phase 3 : le CEM (Cross-Entropy Method) — affiner

itérativement la distribution d'échantillonnage des actions sur plusieurs itérations, plutôt

qu'un tir unique de 512 séquences i.i.d. — déjà implémenté pour actions continues dans

minejepa/ebjepa/planning.py au moment de la Phase 3, mais pas encore branché sur le

planificateur discret de Crafter. Une version discrète de cette idée reviendra dans une phase

ultérieure du projet.

Le pipeline complet à ce stade

Frames 64×64  →  [Encodeur Phase 1]  →  s_t  [D=128]
                                            │
                                      s_t + a_t
                                            │
                                  [World Model Phase 2]  →  ŝ_{t+1}
                                            │
                              512 séquences imaginées
                                            │
                                [Score vs s_goal]
                                            │
                                       best_action
                                            │
                                Crafter.step(action)
                                            │
                                  obs_{t+1}  ←─ (boucle)

Tout se passe en espace latent, à l'exception des deux extrémités : l'entrée pixel et l'action

finale.

Références (vérifiées, tirées de docs/references/index.md)

• Maes, Le Lidec, Scieur, LeCun, Balestriero, LeWorldModel, arXiv:2603.19312 (2026) — la

convention ratio = valpred/valcopy du Chapitre 03, socle sur lequel repose la fiabilité du

rollout latent exploité ici par le planificateur.

• Meta FAIR, ebjepa (github.com/facebookresearch/ebjepa) — la logique de planification

(minejepa/ebjepa/planning.py) réutilisée pour l'extension CEM mentionnée en fin de chapitre.