问题清单与解决方案
下面的“解决”分成三类：
- 已验证修复：有明确的复测结果或官方回执；
- 工程缓解：降低风险，但没有证明提高线上分数；
- 未解决假设：观察到相关性，但没有足够实验建立因果关系。
1. 训练数据文件齐全，但数据语义仍需验证
现象
550 条 processed 文件数量正确、模型能训练，仍然可能存在 action/qpos 时间偏移、三相机顺序错误、专家 profile 混合或 rescue 轨迹的动作模式不一致。
已验证修复
建立严格 audit：检查文件集合、16-D、左右臂 metadata、有限值、三相机长度和逐帧 next-state 对齐。canonical processed550 达到 next_state_max_error=0，manifest SHA 也固定。
仍需改进
把每条 layout 的采集配置、对象模型、姿态、yaw、expert profile、stock/retry/rescue 来源固化到独立 manifest；不要只用一个全局 episode 数字掩盖 joint coverage 空洞。
2. rescue 数据占比高，可能造成分布偏差
现象
exact550 里 rescue=257，占比很高。rescue 轨迹解决了数据覆盖和落盘问题，但它们可能带有不同的接管阶段、速度、末端姿态和动作时序。
工程处理
先保留 canonical550 不改主线，避免在临近截止时同时改数据、gripper 权重和采样。另建 clean50 用于诊断，观察最干净子集能否快速学会。
结论边界
clean50 与 exact550 的表现差异支持“数据分布值得研究”，但不足以证明 rescue 是线上低分的唯一原因。后续应做同架构、同 seed、同评测拓扑的 stock/rescue ablation，并用新 seed panel 验证。
3. 训练步数不够，不能用低 loss 掩盖
现象
官方 ACT 目标是 6000 epoch，但主线最终只完成到 e1250，随后又尝试了 e1500/e1750/e2000 方向。临近截止的短续训不能替代从头完整训练，也不能保证优化器状态、数据顺序和归一化统计等价。
已验证事实
e1250 那一段是正常完成阶段性 1000/1000，不是 OOM。停止原因是人为阶段上限和硬件/截止时间约束。
正确做法
开赛前锁定 6000 epoch 计算预算；每 250 epoch 落盘一份不可变 checkpoint；每个完整 checkpoint 只在空闲、干净、单进程 evaluator 上做固定 fresh3；用 fixed seed 的 success 选择候选，而不是只看 train/val loss。
4. 普通 runner 与 trace runner 分数不同
现象
clean50 e6500 的普通 fresh3 是 0/3, 1/3，trace 诊断版是 1/3, 5/9。同一权重出现明显差异。
根因判断
trace 版本对 run_act_eval.py 做了 monkey-patch 来记录动作边界和终态，运行拓扑、reset 顺序、初始化和 RNG 消耗不能自动视为与官方 runner 相同。
解决
普通 runner 结果作为正式门禁；trace 只用于定位失败阶段。两者并列保存，不挑高、不平均、不将 trace 高分提交到线上。
以后要做
最终 gate 使用 organizer-matched persistent process，公开 seed 顺序固定，模型只加载一次，逐 episode reset 路径与官方一致。若要隔离 hang，可用独立进程做筛选，但不能把筛选结果直接当最终成绩。
5. 本地 public seed 与线上 private seed 差距很大
现象
历史控制候选本地 fresh3 为 2/3，线上 T4 只有 25.3/100。本地公开 3 条成功率不能代表私有 100 条的平均层数。
解决
建立分级评测：fresh3 只做接口/明显坏模型筛选，fresh10/20 做候选稳定性，之后使用完整固定 public panel；候选还必须通过代码包、checkpoint、stats 和官方环境 preflight。
不应做
不能把一次 clean50 trace 成功、训练集 replay、专家轨迹视频或“没有报错”写成线上 success。不能在看过失败 seed 后把它们加入训练再用原 seed 报告泛化提升。
6. 正确账号与提交队列确认
现象
曾经误用另一个只解锁到较低赛道的账号提交 T4，服务端返回 403。之后第二版虽然在截止前启动上传，但官方回执在截止后到达。
已验证修复
提交前只保留令牌尾号作核对，使用已解锁 T4 的账号重新提交，拿到明确的 #719 T4 和 submit_exit=0。第二版收到 提交已截止 后，停止重复重投。
以后要做
提交脚本应先执行账号解锁状态检查，上传结束必须保存官方 response、queue id、server SHA 和时间戳。截止前没有回执时，不应根据“进程还在”推断已入队。
7. 提交包边界和 checkpoint 命名
现象
T2/T3/T4 线上评测只支持官方 ACT 依赖和选手上传的最小代码面。把整个工程根目录、软链接、wandb、原始数据或额外依赖放进包，会带来解包拒绝、导入失败或配置/权重不匹配。
解决
提交前将代码根限定为 external/robotwin_local 的最小 immutable snapshot；checkpoint 包固定为 policy_last.ckpt + dataset_stats.pkl；拒绝符号链接、硬链接、父目录穿越和额外包；本地模拟打包后先做 ACT import smoke。
以后要做
所有提交候选必须记录：代码树 SHA、deploy config SHA、权重 SHA、stats SHA、打包文件清单和 server response。不要让 policy_best.ckpt、policy_last.ckpt 或 config 的语义在训练、评测、上传三处不一致。
8. 官方 action alignment 与本地修改
现象
ACT loader 在 sim 数据路径下使用 next-state 语义。若本地把 action[max(0, start_ts - 1):] 改成 action[start_ts:]，表面上只是少一帧，实际会改变每个训练样本的目标。
解决
主线固定 action shift=0，并对原始数据做 action[t] == qpos[t+1] 审计。任何对齐实验都用独立 run name、独立 stats 和独立 checkpoint，不能与模型规模、gripper loss 或数据采样同时改变。
9. 4090 欠费关机与 PRO 6000 迁移
现象
远程 4090 由于余额不足关机，训练与评测时间线被打断；临时申请/充值、重新开机、同步环境消耗了赛末窗口。云端 PRO 6000 还存在其他用户任务、磁盘空间和 GPU 归属约束。
工程缓解
- 运行时采用断点续传，并在迁移后做文件数、大小、SHA 和 import 门禁；
- 兼容 Python 3.10 / PyTorch / SAPIEN / MPlib / cuRobo 环境优先做可验证镜像，而不是截止前临时重建；
- 大数据、checkpoint 和日志分开存放，避免根盘被环境占满；
- 不强占其他用户任务，也不在同一 GPU 并发启动多个 SAPIEN evaluator。
结论
这是工程可用性问题，不是模型质量被某张 GPU“决定”的证据。之后应设置持久盘、余额告警、开机自启动恢复和每日可恢复 checkpoint。
10. 低分后的真正修复优先级
如果要重赛，优先级应是：
- 先锁定官方环境和 persistent evaluator；
- 重新审计 layout/object/pose/yaw joint coverage；
- 在 clean official code 上完整训练到预定 horizon；
- 对 rescue / retry / stock 做单变量 paired ablation；
- 对 gripper timing、lift/transport/release 阶段做失败聚类；
- 用独立 fresh seed panel 验证提升；
- 最后才打包提交。
不建议的路线是只把 epoch 从 1250 机械加到 2000、只看 loss、只挑一次 trace 高分，或同时改五个数据和模型变量。