JEPA4Japan · チュートリアル
JA

第37章 — 信頼できるLeWM改良実験を設計する

1,198文字 4分で読めます #LeWorldModel#World Models#JEPA

対象とする失敗機構を明示し、最小反例、計算量の統制、アブレーション、オラクル条件、負の結果を用いて、指標差を機構説明へつなげます。

コース進捗 コース目次 48レッスン中 48件を公開中

第0部　読み方ガイド：私たちは何を学ぶのか

  1. 01 第0章 — はじめる前に 公開中

第1部　世界モデル：エージェントの頭の中にある実験場

  1. 02 第1章 — なぜエージェントには「未来を想像する」力が必要なのか 公開中
  2. 03 第2章 — なぜ次の画像をそのまま予測しないのか 公開中
  3. 04 第3章 — JEPAの発想：画面の複製ではなく意味を予測する 公開中
  4. 05 第4章 — 1枚の図でLeWMを理解する 公開中

第2部　画面を状態に変える：LeWMのモデル構造

  1. 06 第5章 — 軌跡データ：モデルにとって世界は画像集ではない 公開中
  2. 07 第6章 — 視覚エンコーダー：各フレームに「状態パスポート」を発行する 公開中
  3. 08 第7章 — 動力学予測器：頭の中で時間を前へ進める 公開中
  4. 09 第8章 — 完全な順伝播：1バッチを最初から最後まで追う 公開中

第3部　モデルの抜け道を防ぐ：予測損失とSIGReg

  1. 10 第9章 — 最も危険な近道：表現崩壊 公開中
  2. 11 第10章 — 予測損失：モデルはどのように次の一歩を学ぶのか 公開中
  3. 12 第11章 — SIGRegの直感：表現空間に「呼吸」をさせる 公開中
  4. 13 第12章 — 必要最小限の数学 公開中
  5. 14 第13章 — オリジナルLeWMのエンドツーエンド学習の仕組み 公開中
  6. 15 第14章 — すぐに表現崩壊しないモデルを訓練する 公開中

第4部　モデルを行動に使う：潜在空間での計画

  1. 16 第15章 — 目標条件付き計画：「今いる場所」から「行きたい場所」へ 公開中
  2. 17 第16章 — 潜在ユークリッド距離：便利だが、常に信頼できるとは限らない 公開中
  3. 18 第17章 — CEM：勝ち抜き方式で行動を探索する 公開中
  4. 19 第18章 — MPC：モデルを一度に長く信じすぎない 公開中
  5. 20 第19章 — 長期ロールアウト：小さな誤差が大事故へ育つまで 公開中
  6. 21 第20章 — 最小のLeWMプランナーをゼロから実装する 公開中

第5部　エンジニアリング再現：論文から動くシステムへ

  1. 22 第21章 — 公式リポジトリと実験環境 公開中
  2. 23 第22章 — 最初の実験：TwoRoomのスモークテスト 公開中
  3. 24 第23章 — 2つ目の実験：PushTを再現する 公開中
  4. 25 第24章 — 世界モデルを公平に評価する方法 公開中
  5. 26 第25章 — 失敗診断マニュアル 公開中

第6部　LeWMは何を学んだのか

  1. 27 第26章 — 線形プローブ：潜在状態にはどの物理量が含まれるのか 公開中
  2. 28 第27章 — 潜在空間を「健康診断」する 公開中
  3. 29 第28章 — 期待違反：モデルは「あり得ない出来事」に驚くのか 公開中
  4. 30 第29章 — 「世界を理解する」を厳密に語るには 公開中

第7部　「予測が正確」でも「計画がうまくいかない」のはなぜか

  1. 31 第30章 — 訓練目的と計画目的のあいだにある亀裂 公開中
  2. 32 第31章 — 大域的には表現崩壊していなくても、タスクに必要な動力学が保たれるとは限らない 公開中
  3. 33 第32章 — 等方ガウス事前分布はいつ強すぎるのか 公開中
  4. 34 第33章 — 長期計画：より遠くを予測するか、より賢く計画するか 公開中
  5. 35 第34章 — 位置の距離からタスクの進捗へ 公開中
  6. 36 第35章 — マルチタスク、実ロボット、視覚的外乱 公開中
  7. 37 第36章 — 理論的な境界：真の状態はいつ同定できるのか 公開中

第8部　再現者から研究者へ

  1. 38 第37章 — 信頼できるLeWM改良実験を設計する 現在のレッスン
  2. 39 第38章 — 実行可能な12の研究課題 公開中
  3. 40 第39章 — LeWM研究の未解決問題 公開中

付録　数学・実装・再現・査読のための参照資料

  1. 41 付録A — 最低限必要な数学ツールキット 公開中
  2. 42 付録B — PyTorch実装クイックリファレンス 公開中
  3. 43 付録C — テンソル形状の完全一覧 公開中
  4. 44 付録D — 実験設定カード 公開中
  5. 45 付録E — 論文タイムラインとエビデンスレベル 公開中
  6. 46 付録F — 用語集 公開中
  7. 47 付録G — 再現チェックリスト 公開中
  8. 48 付録H — 専門家査読チェックリスト 公開中

まず大きな絵

  1. 故障を一つ名指す予想する failure pattern を書きます。
  2. 部品を一つ変えるdata、budget、evaluation を固定します。
  3. 全結果を残すpositive、null、negative は全部必要です。
改善が信頼できるのは、intervention が mechanism を試し、falsifier によって説明が負けられるときです。

小さなお話：全部を交換した整備士

車が左へ寄ります。整備士は tire、steering、engine、road map、driver を全部交換しました。車は真っすぐ走りました。何かは効きましたが、修理からほとんど学べません。

world-model system にも分けられる部品があります。data/preprocessing、representation、action-conditioned dynamics、planning cost、CEM search、execution/evaluation です。全部を一緒に動かすと、高い success number からどの idea が効いたか分かりません。

LeWM control system の representation、dynamics、search、execution を固定し、cost block だけを変えます。

一つの locked comparison は claim を局所化します。同じ repair が全 environment で効く証明ではありません。

技術のリュック

run の前に claim を書きます。

  1. Failure mechanism: 例として terminal Euclidean cost が壁越し endpoint を不当に高順位にする。
  2. Predicted interaction: reachability-aware cost は matched open-room goal より wall-separated goal を大きく助けるはず。
  3. Falsifier: 壁を除いても同じ大きな gain、oracle dynamics で消える、または追加 CEM budget だけで起きる。
  4. Locked contract: dataset/hash、preprocessing、encoder、predictor、checkpoint rule、seed、start/goal、action budget、CEM population/elites/refinements、executed prefix、episode count、metric。

ablation ladder を使います。baseline → component を追加 → 削除 → signal を shuffle/randomize → strength sweep です。可能なら parameter count と compute の両方を合わせます。training budget と planning budget は別通貨です。extra epoch を fewer candidate plan と黙って交換したり、extra CEM candidate を representation gain と呼んだりできません。

oracle substitution は bottleneck を切り分けます。

DynamicsCostこの cell が尋ねること
learnedlearnedfull system は働くか
oraclelearnedrollout error を除いても failure が残るか
learnedoracle同じ model を良い ranking が救うか
oracleoraclesimulator knowledge 下でも search/execution が限界か

oracle state、shortest path、dynamics は simulator-only diagnostic tool です。oracle gain は headroom を示しますが、learned replacement が達成可能だとは示しません。

壊してみる

matched TwoRoom layout を使います。一方は separating wall と doorway があり、もう一方は wall を除きます。同じ start、goal、candidate bank、model checkpoint、budget を再利用します。topological-cost hypothesis は wall case でより大きな改善を予測します。“repair” が open space でも同じだけ勝つなら、単なる score rescaling や optimization change かもしれません。

一つの best run ではなく seed と goal type ごとの distribution を報告します。代表 trajectory を保存し、failure を encoder aliasing、action-insensitive prediction、self-fed rollout drift、wrong cost ranking、CEM miss、execution mismatch に分類します。null result は「この条件で支持される gain なし」であって「永遠に不可能」ではありません。予想した境界に一致する negative result は、ときに最も強い手掛かりです。

実験レシートと証拠の境界

  • diagnostic を動機付ける source: LeWorldModel v3、RC-aux v1、TwoRoom reproduction v1、VIScore v2、ACPC v1、Objective Bottleneck v1、DA-LeWM v1、stable-worldmodel v1。
  • 凍結 public snapshot: LeWM 8edfeb3、RC-aux ecb4496、tinylab efa9e5d、VIScore bbb60fc、ACPC 90d4276、stable-worldmodel addbab4、release 0.1.1。DA-LeWM code は未確認です。
  • 引用 diagnostic version は 2026-08-10 から 2026-08-19、cutoff は 2026-08-20、Asia/Tokyo。明記した TwoRoom 再実装以外の source evaluation は author-reported です。ここで提案する experiment は、誰かが run するまでは tutorial construction です。
  • 許される結論は「この design 内で isolate」「locked condition 下で mechanism を支持」「ここでは改善しなかった」です。「原因を証明」「universal reachability を学習」「platform が fairness を保証」「TwoRoom が robotics generalization を確立」は避けます。

3つのクイック質問

  1. representation、predictor、planner を一緒に変える実験が弱いのはなぜですか？
  2. 四つの oracle cell は、どの異なる bottleneck を切り分けますか？
  3. wall-removal test のどんな結果が topology explanation を弱めますか？