付録D―再現とレビューのチェックリスト

「動いた」を再現可能な記録へ

空欄は、想像で埋めない

「トマトスープを作った」と二人が言っても、一人は缶詰を二時間煮て、もう一人は生トマトを電子レンジに五分かけたかもしれません。料理名だけでは同じ結果を期待できません。

LeVJEPA も、Walking Tours の公開既定学習、K710 20%の論文統制比較、ノートブックでの1,000ステップ実習、公開重みの読み込みでは、支持できる主張が違います。以下は取得から結論までの実験受領証です。未測定の欄は空白か TODO のまま残し、もっともらしい既定値で埋めません。

A　方法と版の身元

• 論文名、arXiv ID、版、取得日を記録する。2608.27395v1 と書き、「最新版」だけで済ませない。
• プロジェクトページと公式リポジトリの URL を残す。
• 40桁の Git コミットを固定する。本シリーズの検査点は 3ea0dda16030bc0fd6472bf809fc0a0ad836a812（2026-09-02）。
• git status --short を保存する。変更があれば差分を保管し、上流そのままの実験と別名にする。
• 公開チェックポイントのリポジトリ、リビジョン、ファイルハッシュを残す。
• リポジトリ本体の MIT と、V-JEPA から派生した module.py および重みの CC BY-NC 4.0 を分けて確認する。商用利用の判断を本チュートリアルだけに任せない。

git rev-parse HEAD
git status --short
uv --version
uv run python - <<'PY'
import platform, torch
print(platform.platform())
print(torch.__version__, torch.version.cuda)
print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else "no CUDA")
PY

B　環境と機器

• OS、Python、PyTorch、CUDA、ドライバー、uv.lock のハッシュを保存する。
• GPU の型と台数、VRAM、CPU コア数、主記憶、記憶装置を記録する。
• 数値精度（例 bf16-mixed）と分散学習方式を書く。
• GPUメモリ使用量の最大値、1ステップの平均所要時間、データ待ち時間、全実時間を実測する。
• FLOPs を比べるなら、計算対象に入力、目標枝、予測器、プローブのどこまでを含めたかと、各入力の形も記す。

RTX 5080で12時間という著者報告から、別の16 GB機器の所要時間をそのまま予測できません。チップ、ソフトウェア、データ読み込みで実時間は変わります。

C　データの受領証

• データ集合名、版、許諾、元 URL 一覧、取得日を記録する。
• 元動画または一覧にハッシュを付け、差し替えや削除を検出できるようにする。
• 復号解像度、フレーム率、JPEG 品質、エピソード長、Lance の構築コマンドを残す。
• 有効なエピソード数、各エピソードのフレーム数、除外した短区間、総バイト数を実測する。
• T=16、保存15 fps、frame_stride=2 なので、学習は約7.5 fps、約2.1秒を覆うと記す。
• 元動画、人物、場所などの独立出所を単位に訓練・検証・試験を分ける。先に短い窓へ切って無作為分割しない。
• 大域・局所視点の最初の一組をコンタクトシートにし、同じ16時刻を使うことを目で確認する。
• 色空間、正規化の平均・標準偏差、切り抜き範囲、光度変換を記録する。

source videos: 10
stored fps: 15
episodes: ...
frames: ...
train/val/test split unit: source-video
Lance bytes: ...
manifest sha256: ...

省略記号は「まだ測っていない」であって、暗黙の既定値ではありません。

D　モデルと目的関数

• ViT の規模、patch_size=16、tubelet_size=1、num_frames=16 を書く。
• 大域224、局所96、局所視点数 V、それぞれの切り抜き尺度を記す。
• token_drop_rate=0.95 と attn_mode=block_causal を明記する。
• 投影器 D→2048→256、BatchNorm、GELU を記す。
• L = L_inv + 0.02·L_SIGReg、17積分点、1024無作為方向、固定版の既定値 normalize_by_n=false を書く。
• 大域・局所の両枝へ勾配が流れることを確かめ、宣言のない detach を入れない。
• 学習用の目標エンコーダーと予測器がないことを確かめる。
• Polyak / EMA 重みを保存するなら、減衰率、更新間隔、評価時に生重みと EMA のどちらを使うかを書く。損失へ入らないことも明記する。

E　最適化と計算予算

• 装置1基あたりのバッチサイズ、装置数、ノード数、勾配蓄積、実際の実効バッチサイズを記録する。
• 最適化器、学習率、β係数、重み減衰、バイアス・正規化層の除外規則を書く。
• ウォームアップの最適化ステップ数と、その後が一定か減衰かを記す。
• 周回数、最適化ステップ数、見た動画窓数、1ステップあたりのトークン数、総 FLOPs 概算、実時間を並べる。
• データ抽出、視点変換、トークン削減、初期化、プローブの乱数種を固定して残す。
• 少なくとも三学習乱数種を試す。単一実行ならそう明記し、最良一回を安定性の証拠にしない。
• コマンドラインで上書きした値だけでなく、Hydra が最終的に解決した全設定を保存する。

公開設定の注記にある実効バッチサイズ3,072は、次の積です。

2 nodes × 8 GPUs × 96 clips/device × 2 gradient accumulation = 3072

GPU 1基、バッチサイズ8、勾配蓄積なしなら実効バッチサイズは8です。有用な動作確認ですが、論文の実験設定を再現したものではありません。

F　最低限の計器盤

一実行ごとに、少なくとも次を保存します。

• pred_loss、sigreg_loss、重み付け前後の総損失。
• [CLS] の次元別平均・標準偏差、共分散スペクトル、最小・最大特徴分散、有効階数。
• 大域–局所の正対応距離と、バッチ軸を乱した負対照距離。
• 生エンコーダーと EMA 複製に同じ検証用プローブを当てた結果。
• 勾配ノルム、学習率、重み減衰、処理量、最大記憶量。
• 少なくとも一組の、保持トークンの時空分布図。
• 未来フレームを変えても過去パッチが変わらないブロック因果試験。
• NaN / Inf、全零勾配、重複標本、データ待ちの警告。

総損失だけを見ると、不変性項が下がる一方で SIGReg が暴れる故障、またはその逆を隠します。二項を別々に記録します。

G　小さい門から順に通る

1. **接続試験：**架空入力で前向き計算し、全形状と型を断言する。
2. **目的試験：**定数埋め込みでは不変性が小さく SIGReg が大きくなる。対応を乱すと不変性が増える。
3. **因果試験：**未来だけを変えて過去パッチが変わらない。[CLS] は変わってよい。
4. **小データ試験：**極小データで説明可能な過適合を観察し、同時に崩壊を監視する。
5. **教材試験：**公式の実習ノートブックを動かし、図、曲線、設定を保存する。
6. **GPU 1基での試験：**モデルやバッチサイズを資源に合わせて縮め、論文再現ではないと明記する。
7. **実験条件の試験：**データ、予算、実効バッチサイズ、モデル、評価手順が一致して初めて論文値と比べる。

前の門で失敗したら、そこで直します。大規模学習は軸順の誤りや未来漏洩を治してくれません。

H　評価と公平な比較

• エンコーダーを凍結し、事前に宣言した線形プローブまたは注意機構付きプローブだけを学習する。
• 全方式でデータ分割、入力フレーム・時間幅、プローブの容量、最適化予算、視点抽出をそろえる。
• ImageNet-1K、K400、SSv2 を別に報告する。それぞれ外観、動作、細かな運動への重みが違う。
• 平均、標準偏差、乱数種数、信頼区間または乱数種別の全結果を示す。
• 周回数一致と FLOPs 一致で、それぞれ何を固定したかを書く。
• 独自データでは、無作為初期化、教師あり事前学習、同予算の代替法の少なくとも一つを基準にする。
• 予測、検索、特徴図の成功例と失敗例を保存し、もっともきれいな PCA だけを選ばない。
• プローブで読み出せることは、その情報を世界モデルが使用する証明ではないと明記する。

I　文ごとに証拠の強さを書く

[方法事実]      論文または固定コードが直接定義
[著者報告]      元論文が指定手順で報告
[今回の観察]    今回のログや成果物が直接表示
[仮定付き理論]  列挙した仮定の内側で成立
[推論]          複数証拠から導くが直接未検査
[仮説]          実験で反証・支持を待つ

例えば次の三文は強さが違います。

• [方法事実] 公開実装は学習時にパッチトークンの95%を一様無作為に落とす。
• [著者報告] ImageNet のアブレーションで、削減率0から0.95へ上げると正解率が33.9から47.6へ上がった。
• [仮説] 高速で細かな動作のデータでは、時刻をまたぐ対応点を残す標本化が一様削減よりよい。

保存できる実験受領証

experiment: levjepa-walkingtours-smoke-001
paper: arxiv:2608.27395v1
code_commit: 3ea0dda16030bc0fd6472bf809fc0a0ad836a812
local_diff_sha256: null
data:
  name: walking_tours
  manifest_sha256: TODO
  split_unit: source_video
model:
  name: vit_tiny
  frames: 16
  patch: 16
  tubelet: 1
  token_drop: 0.95
  attention: block_causal
objective:
  sigreg_weight: 0.02
  projections: 1024
  knots: 17
budget:
  devices: 1
  batch_per_device: 8
  accumulation: 1
  optimizer_steps: 100
seeds: [0]
status: smoke_test_not_paper_reproduction
artifacts:
  resolved_config: TODO
  metrics_log: TODO
  checkpoint_sha256: TODO

TODO は欠落を正直に示します。架空の値より役に立ちます。

「再現」と呼ぶための七つの門

1. 方法版とコードハッシュが一意ですか。
2. データと分割を追跡でき、近接標本の漏洩がありませんか。
3. モデル、目的、実効バッチサイズ、ステップ、予算が一致していますか。
4. プローブと比較基準の手順は公平ですか。
5. 複数乱数種と元成果物を取り出せますか。
6. 数値は事前に決めた許容幅へ収まりますか。
7. 結論を、本当に繰り返した範囲へ限定しましたか。

全部が「はい」でなければ、より正確な名前を使います。「導入確認」「前向き動作確認」「教材級の再実行」「部分再現」「著者チェックポイントの下流評価」は、いずれも立派な成果です。

チェック表の根拠

• 固定版の公式 README
• 固定版 conf/config.yaml
• LeVJEPA v1 の実験手順
• 固定版モデルカードの重み仕様

この監査順は本チュートリアルが提案する再現手順であり、論文著者が認定制度として主張したものではありません。

最後の三行

1. 「動いた」「著者重みを使った」「論文結果を独立再現した」は別の主張です。
2. 設定に加え、データ指紋、実効バッチサイズ、予算、ログ、失敗例を保存します。
3. 再現の最後の仕事は数字を得ることではなく、結論を証拠の届く範囲へ縮めることです。

提出前の三問

1. GPU 1基、バッチサイズ8で100ステップ動かしたら、論文の実験設定を再現したと呼べますか。
2. なぜ Walking Tours の隣接エピソードや短い窓を無作為分割せず、独立した出所で分けますか。
3. 公式コードと重みがあるのに、なぜ独立再現済みとは言えませんか。