EXP-3D-RGBD-DEPTHSPLAT-JEPA-TTT-V1：以 DepthSplat 为基座检验逆向 JEPA 与 TTT

结论：两者都作为机制成立；相对无模型方法的优势都只达到 PARTIAL，场景一致性不够。逆向 JEPA 的补全水平与旧项目的 G1 载体相当，没有超过它。

• Core A（逆向 JEPA）：A_PARTIAL。
  • 训练前，DepthSplat 的高斯几乎碰不到上下文没看到的区域（FAR 覆盖率 2%）。用"预测其他视角的深度与 RGB"训练整个编码器之后，状态覆盖了 68% 的 FAR，FAR AbsRel 从 0.425 降到 0.360。
  • 相对调和补全（0.429）平均好 0.069 [+0.014, +0.138]，但只有 45/77 个场景变好。
  • 相对旧项目的 G1 载体，增量只有 +0.015，不显著。
• Core B（TTT）：B_MECHANISM_ONLY。
  • 新到达 4 帧 RGB-D 后，在 DepthSplat 由 7 帧生成的高斯状态上做 100 步测试时优化。查询深度 ALL AbsRel 从 0.148（只缓存）降到 0.118，73/78 个场景变好（SUPPORTED）。
  • 平均也好于同样 7 帧的无模型重投影（0.175，+0.057），但只有 54/78 个场景变好（PARTIAL），中位数只好 0.005。
  • 收益全部来自已有测量的区域，对 7 帧都没看到的区域没有作用。

说明：

• 预注册见 PROTOCOL.md。2026-10-08 01:16:18 锁定，preregistration.json 的 sha256 为 fa87f117…。
• 两次修订都只涉及执行，没有改动任何设置：
  • 修订 1：训练第一次因显存不足失败后重跑；
  • 修订 2：应用户要求，先读取 TTT 的真值。
• 评估队列：FRESH78 = EVAL-V5 + TRAIN-EXT，78 个场景、156 个 episode、312 个查询。
• 统计单位是场景，bootstrap 10,000 次，种子 20260928，判定用 V2 gate。
• 保护集未打开，未下载新数据，未推送。

设计（简述）

• 状态构建器： 所有构建器都在有效像素处注入测得深度。
  • ZS：发布权重，高斯尺度上限 0.1。
  • ZS3：发布权重，上限 3.0。
  • J1–J3：逆向 JEPA。
    • 从发布权重出发，种子 20261008–10，各 4000 步，lr 5e-6，ViT 5e-7。
    • 数据为 TRAIN72 加 SEG-V1，共 312 条记录。
    • 每步把 3 帧上下文的状态渲染到 2 个其他帧。损失是原始渲染深度的相对 L1 加 0.5 × RGB L1；上限 3.0。
    • 每个种子用时 1.65 h，显存 6.2 GB。
• 臂：
  • CTX：3 帧上下文；
  • CACHE：3 帧上下文加 4 帧流帧，作为 7 视角前馈；
  • TTT：在 CACHE 上做 100 步 Adam，只用于 ZS，步长 m = 1，在 DEV 上选出。
  • 无模型对照：
    • REPROJ_HARMONIC（3 帧 1 像素 z-buffer 加调和补洞）；
    • REPROJ7_HARMONIC（7 帧）；
    • G1：旧项目最强载体，3 个种子；FAR_G1 = NEAR 用调和补全，FAR 用 G1。
• 读出： DepthSplat 深度 = (depth_z / α) / cos，只在 α ≥ 0.5 处使用。
  • _F / _F7：其余像素回退到 REPROJ_HARMONIC / REPROJ7_HARMONIC。
  • _G1：NEAR 用调和补全；FAR 中 α ≥ 0.5 处用 DepthSplat，其余用 G1。
  • _H7：NEAR7 用 REPROJ7_HARMONIC，其余像素同 _F7。
• 区域：
  • NEAR：距 3 帧重投影命中 8 像素以内。
  • FAR：其余有效像素。
  • NEAR7 / FAR7：用 7 帧计算的同样划分。

主检验

读法：

• A1： 留一场景均值都 > 0（0.047 到 0.076），正向贡献最大的单个场景占 22%。唯一没过的是"不变差的场景 ≥ 75%"：只有 58%。场景中位数为 +0.007。
• B1： 每一项都通过。留一场景均值在 0.027 到 0.031 之间，最大单场景占比 9%。
• B2： 同样只差场景一致性（69%）。均值被少数场景放大：在这些场景里，无模型的 1 像素 z-buffer 彻底失效（例如 ai_027_007 的一个查询 AbsRel 为 5.07），最大单场景占比 45%。场景中位数只有 +0.005。

次要分析

各读出的均值（场景平均 AbsRel）与覆盖率

探索性事后分析（未预注册，results/FRESH78_posthoc_exploratory.json）

• 在状态覆盖到的 FAR 像素上，逐像素对比：

  构建器	覆盖了 FAR 的多少	覆盖处 DepthSplat	同样像素上的调和补全	同样像素上的 G1	场景数
  J（3 种子平均）	0.681	0.305	0.403	0.312	74
  ZS3	0.246	0.319	0.360	0.334	55
  ZS	0.020	0.193	0.327	0.338	14

  • J 相对调和补全：+0.098 [+0.030, +0.179]，48/26。
  • J 相对 G1：+0.007 [−0.049, +0.069]，40/34。
  • 逆向 JEPA 学到的补全在它预测的地方明显好于调和插值，与旧的 G1 载体相当。
  • J 在覆盖处的平均对数偏差为 −0.06，略偏近；调和补全为 +0.03。
  • TTT 的收益在哪里：
  • NEAR7 占 ALL 像素的 95%。TTT 把 NEAR7 的 AbsRel 从 0.1345（CACHE）降到 0.1035，REPROJ7 为 0.1611。NEAR7 对 ALL 差值的贡献为 +0.0297，FAR7 为 0.0000。
  • TTT 修的是多视角一致性和遮挡，不会补全 7 帧都没看到的几何。

解读

• 逆向 JEPA：
  • 在 DepthSplat 上，"预测其他视角"的训练确实改变了状态做什么。像素对齐的高斯原本只能停在上下文像素的射线上，训练后学会伸进未观测区域，而且在那里比调和插值准。这一点在三个种子上非常一致。
  • 但它的补全能力与旧项目的 G1 载体处在同一水平。G1 只有约 6.4 万参数，DepthSplat 有 1.2 亿。所以"更强的基座"没有把 learned completion 推过旧的天花板。
  • 场景层面仍然有约 40% 的场景比调和插值差，与旧项目的结论（PARTIAL、ND）一致。
• TTT：
  • 在 DepthSplat 状态上，测试时梯度写入的机制效应比旧载体更清楚：+0.030，73/78；旧载体 V8 为 +0.021。
  • 它让状态在平均上超过了无模型的 7 帧重投影。但这主要来自 1 像素 z-buffer 在遮挡处的失效，而不是新的几何信息。中位数场景只好 0.005。
  • 对没看到的区域（FAR7）毫无作用。
• 仍是最大的收益： 把新帧本身缓存进来（+0.093）和多测几帧（+0.087）。
• 一个直接的后续问题： TTT 的这点优势究竟来自学到的基座，还是只来自"高斯表示加测试时优化"？由 EXP-3D-RGBD-DEPTHSPLAT-TTT-ABLATION-V1（无网络高斯加同样的 TTT）检验。

完整性

• 封存与复核：
  • arms 封存（G1 三种子、REPROJ_HARMONIC、NEAR）在读真值前完成，query_depth_read = false。
  • 几何封存对 arms 封存复核：最大差 0.0，NEAR 完全一致。
  • 流帧与 V6/V7 的封存逐一一致。
• TTT： 156 个 episode 中失败 0 次。7 帧上的深度项从 0.115 降到 0.017。均值最大位移平均 0.17 m。协方差重建误差 ≤ 1.1e-6。
• 训练： 三个种子都完成，没有非有限损失。DEV 曲线（覆盖像素 AbsRel / 覆盖率）从 0.255 / 0.824 到第 4000 步的 0.255 / 0.970、0.212 / 0.946、0.222 / 0.950，只作记录，没有用于选择。
• 分析确定性： 两次分析的结果文件逐字节相同（audit/cpu_score.log）。
• GPU 不可逐位复现： 用 3 个种子，只做同设备比较。

事故与修订

• 修订 1： 第一次正式 GPU 作业把 3 个训练与 3 个 TTT 分片同时调度，显存超过 47.4 GiB，三个训练在第一步退出。按同一命令重跑，见 audit/incident_attempt1_oom.md、audit/amendment_1.json。
• 修订 2： 用户要求先看 TTT 的结果，因此 Core B 的真值在三个逆向 JEPA 训练已经运行时先读取。这一阶段的输出在 stage1_coreB/，与最终结果逐项相同；见 audit/amendment_2.json。

文件

• PROTOCOL.md、preregistration.json、frame_role_lock.json、evaluation_contract.json、manifest_fresh78.json、ttt_selection.json
• code/：全部脚本
• development/：DEV 上的开发记录
• raw/eval/FRESH78/：arms 封存
• geometry/：几何封存
• ds/FRESH78/<构建器>/：DepthSplat 封存
• checkpoints/J1–J3/：每个种子的权重（484 MB）与训练日志，哈希见 checkpoints/SHA256SUMS
• stage1_coreB/、scores/FRESH78/、results/（含 figures/）：评分与分析结果
• audit/：日志、事故记录与修订