日报 — 2026-03-20
今日概览
- 做了什么： 在DCC和tianhe两台HPC设备上同步推进机器人操作与空间转录组两大方向：前者涵盖error recovery benchmark的数据质量修复、训练场景并行批量生成和Pi0.5-base LoRA微调流水线搭建；后者完成STAIG超参数公平对比修复和10x Visium数据分析脚本开发。
- 怎么做的： 通过系统性GPU诊断脚本定位并修复假阳性阈值问题；将串行场景生成改造为32 worker ThreadPoolExecutor并行（4 GPU round-robin）；完成HDF5→LeRoBot格式转换和norm stats计算；通过日志与缓存交叉验证修复实验命名误导；将Visium可视化迁移至scanpy原生API。
- 有什么用： drop_in_transit假阳性率从80%降至0%，场景生成速度提升约10倍（973 scenes/41分钟），Pi0.5训练前置数据全部就绪；STAIG建立公平基准；Visium 6张可视化图正确产出。Slurm interactive job到期导致训练进程中断，需通过sbatch重新提交。
DCC
- 做了什么： 在MIHD项目修复STAIG超参数扫描的公平对比问题，并在claude-demo项目完成10x Visium 151676样本的scanpy分析脚本开发与可视化修复。
- 怎么做的： 通过读取日志和缓存文件发现pca_uni2_staig_fusion实际使用UNI而非UNI2；修改消融脚本支持gene/vision编码器参数配置；将Visium可视化从plt.savefig改为scanpy原生save参数保存。
- 有什么用： 建立PCA+UNI vs PCA+UNI2公平基准对比（ARI均值0.47），Visium 6张空间转录组图（QC、PCA、UMAP、空间表达）正确生成。
tianhe
- 做了什么： 诊断修复drop_in_transit_D0假阳性问题，将6任务训练场景生成从串行改造为32 worker并行（973 scenes/41分钟），完成Pi0.5-base LoRA微调流水线的数据准备，并短暂启动coffee/stack训练（因Slurm job到期中断）。
- 怎么做的： 编写GPU诊断脚本定位min_hold_height阈值问题；创建generate_training_scenes_parallel.py（ThreadPoolExecutor，4 GPU round-robin）；通过SSH+tmux在an49/an50节点执行HDF5→LeRoBot转换、norm stats计算和训练启动；交叉分析parallel_logs与opportunity map完成失败根因文档。
- 有什么用： drop_in_transit假阳性消除（D0成功率10%→50%），973个训练scene就绪；Pi0.5的6任务数据流水线准备完成；失败根因文档为后续validator修复提供清晰方向；训练因Slurm限制中断需重提sbatch作业。
在DCC和tianhe两台HPC设备上同步推进四条主线：修复error recovery benchmark的drop_in_transit假阳性问题并以32 worker并行生成6任务973个训练场景（41分钟），搭建Pi0.5-base LoRA六任务合并数据集微调流水线（数据转换与norm stats完成，训练因Slurm job到期中断），修复STAIG超参数扫描不公平对比建立PCA+UNI/UNI2基准（ARI 0.47），以及开发10x Visium空间转录组scanpy分析脚本。
今日任务
架构与策略
- ✅ drop_in_transit_D0假阳性诊断与修复 — 通过GPU诊断脚本确认min_hold_height=0.85导致8/10机会为假阳性（物体在桌面z≈0.88>0.85），将5个error skill文件和config阈值统一提升至0.93（桌面0.80+物体高0.08+余量0.05），假阳性从80%降至0%，D0成功率从10%提升至50%（4/8）。
- ✅ 6任务训练误差场景并行批量生成 — 将串行脚本改造为支持–subtypes过滤参数的并行版本，创建generate_training_scenes_parallel.py（32 worker，4 GPU round-robin分配），在an50节点以nohup后台运行，41分钟生成973 scenes（128/130 worker成功），速度较串行提升约10倍。
- • Pi0.5-base LoRA合并数据集微调流水线搭建 — 重定向openpi05 conda环境.pth文件、向config.py添加12个merged configs（6任务各含finetune/inference），完成5任务HDF5→LeRoBot数据转换（coffee/stack/stack_three/three_piece_assembly 2000条，threading 1000条）和norm stats计算。在an49 tmux中启动coffee/stack训练，因Slurm interactive job到期所有进程被杀，需通过sbatch重新提交。
- ✅ 训练场景生成失败根因分析与文档 — 通过parallel_logs日志、opportunity map分布、meta.json交叉分析，识别5大根因（gripper_closed_norm异常P0级、drop碰撞检测不足、OSC位移响应不足、物体物理约束、threading phase不匹配），写入training_scene_failure_analysis.md，为后续validator修复提供可操作参考。
- ✅ STAIG超参数扫描公平对比修复 — 发现ablation脚本使用raw HVG 3000d而非PCA输入，且实验名称具有误导性（实际使用UNI而非UNI2）。修改脚本支持–gene_encoder和–vision_variant参数，分别以PCA+UNI和PCA+UNI2跑pseudo_k sweep，ARI均值均约0.47，建立公平基准。
- 🔄 pick_place作为第6个任务添加至训练流水线 — 修改train_pi05_merged.py、config.py和MimicGen配置（2000条D0，无D1变体）。数据生成在an49 GPU 0启动后因Slurm job到期中断（完成184/2000）。
实现与修复
- ✅ 10x Visium数据分析脚本开发与可视化修复 — 为151676样本编写scanpy分析脚本（QC、归一化、HVG、PCA/UMAP、空间可视化），修复spatial_gene_expression.png只有H&E背景无基因点的问题：将plt.savefig改为scanpy原生save参数，6张图正确生成。
- ✅ openpi Docker镜像构建与保存指南 — 阅读openpi的docs/docker.md、serve_policy.Dockerfile和compose.yml，汇总5个Dockerfile用途及对应build命令，以及docker save/load完整流程。
问题与解决方案
关键问题
1. drop_in_transit_D0仅生成极少有效场景，经诊断确认min_hold_height=0.85阈值过低，导致物体在桌面（z≈0.88）被误判为空中持有，80%机会为假阳性
解决方案: 将min_hold_height从0.85提升至0.93（桌面0.80+Milk物体高0.08+余量0.05），同步修改5个error skill文件和config；假阳性消除，D0成功率从10%提升至50%
关键洞察: pick_place任务中物体放在桌面上的z高度可超过简单设定的min_height，设计持握检测阈值必须考虑「桌面高度+物体自身高度」叠加并留足余量
2. 训练场景生成脚本完全串行，collision_eef_object subtype成功率极低（10分钟仅5个scene），6任务预计需6+小时
解决方案: 为脚本添加–subtypes过滤参数，创建ThreadPoolExecutor并行启动器（32 worker，4 GPU round-robin），41分钟完成全部973 scenes
关键洞察: MuJoCo EGL渲染是CPU密集型任务，同一节点可运行32+独立进程不冲突；subprocess-based并行比多线程更稳定，可充分利用48核CPU
3. Slurm interactive job到期后，通过SSH启动的训练进程和数据生成进程全部被杀，已进行的训练时间浪费
解决方案: 需通过sbatch提交正式job，或在allocated job内使用tmux保证进程持久性；pam_slurm_adopt策略会在job结束时kill所有相关进程，SSH nohup无法绕过
关键洞察: HPC集群Slurm资源隔离机制会强制清理job内所有进程，包括SSH连接的子进程；长时间训练任务必须用sbatch，不能依赖interactive job
4. 128/130 workers完成后仍有29个task×subtype组合完全缺失，threading仅生成3/29 subtype
解决方案: 交叉分析opportunity map与生成日志，区分两类失败：opportunity scan阶段未发现机会点 vs 生成阶段validator拒绝；优先修复gripper_closed_norm=0.00异常（P0级，可解锁8个组合）
关键洞察: 场景生成失败分为两阶段：opportunity scan（can_inject永为False）和validator拒绝；前者改can_inject条件，后者调阈值或注入参数，需区分处理
5. STAIG超参数sweep基线ARI(0.23)与聚类消融ARI(0.58)差距异常，实验名称’pca_uni2_staig_fusion’具有误导性：实际使用UNI而非UNI2，ablation脚本使用raw HVG而非PCA输入
解决方案: 修改ablation脚本新增–gene_encoder和–vision_variant参数，以PCA+UNI/UNI2重新跑sweep，ARI均值约0.47（合理范围），建立公平基准
关键洞察: 实验命名约定必须严格对应实现；命名误导会导致长期理解错误；需通过读取日志而非仅看实验名来确认实际实现
6. PickPlace任务没有MimicGen D1变体，无法按原计划生成D0+D1合并数据集
解决方案: 直接生成2000条D0数据，以总量等效替代D0+D1合并方案
关键洞察: 不同robosuite任务在MimicGen中的变体数量不一致，多任务数据策略需逐任务确认可用变体，总量等效是可行的工程决策
一般问题
7. Visium sc.pl.spatial生成的图片只显示组织H&E背景，没有基因表达点叠加
解决方案: 将sc.pl.*的保存方式从plt.savefig改为scanpy原生save参数（sc.settings.figdir + save参数），由scanpy内部pipeline处理spot渲染
关键洞察: scanpy的spatial plot必须通过其内部保存机制，绕过matplotlib直接保存会跳过spot渲染步骤
8. MUJOCO_EGL_DEVICE_ID=0与CUDA_VISIBLE_DEVICES=1不匹配导致import失败
解决方案: 将MUJOCO_EGL_DEVICE_ID改为与CUDA_VISIBLE_DEVICES一致（均设为1）
关键洞察: MUJOCO_EGL_DEVICE_ID必须是全局物理GPU ID，而非CUDA_VISIBLE_DEVICES映射后的序号
人类思路 vs AI 思路
战略层面
系统资源利用与效率优化的主动性
| 角色 | 思路 |
|---|---|
| 人类 | 用户主动察觉串行进程运行缓慢（10分钟仅5 scenes）并主动提出「现在完全可以做到32+并行」；同时察觉训练数据量仅1条异常并要求深入调查；从系统资源全局视角（48核CPU、4 GPU、充裕内存）主动驱动效率优化决策。 |
| AI | AI按串行计划执行，发现运行缓慢后仅设置30分钟定时检查并等待；对数据量异常需用户指出才启动诊断；缺乏对整体吞吐量和系统资源的主动评估。 |
差异分析: 人类从系统资源和整体效率视角主动提出优化方案；AI专注于当前任务完成性，缺乏对「可以做得更好」的主动评估意识
HPC进程持久性策略（Slurm机制理解）
| 角色 | 思路 |
|---|---|
| 人类 | 明确指出nohup via SSH不可靠，要求用tmux或Slurm保证terminal关闭后进程仍能运行，具备实际HPC使用经验，了解pam_slurm_adopt机制。 |
| AI | 最初使用nohup + & 通过SSH启动进程，没有考虑Slurm job到期的进程隔离机制。 |
差异分析: 人类了解HPC资源管理底层机制；AI只考虑了shell级别的进程后台运行，忽略了Slurm资源隔离
实验设计公平性与数据策略的直觉判断
| 角色 | 思路 |
|---|---|
| 人类 | 主动察觉ARI差距不合理（0.23 vs 0.58），直接质疑实验公平性并提出具体修复方案；在pick_place无D1变体时快速决定用2000条D0等效替代，不需要穷举技术可能性。 |
| AI | 未主动发现实验不公平性，被指出后才通过日志取证；在数据策略决策上倾向于探索更多可能性后再决策，比较保守。 |
差异分析: 人类凭实验设计全局视角快速做出实用决策；AI在执行层面应对但缺乏主动审查和快速决策意识
失败分析的目标导向深度
| 角色 | 思路 |
|---|---|
| 人类 | 要求将所有error的detector/injector/validator详细写入文档，目标是为后续修复提供可操作参考，以修复者视角要求分析深度。 |
| AI | 提供了失败subtype的统计列表和根因分类，但未主动将代码层实现细节整合进可操作的修复参考文档。 |
差异分析: 人类以「后续如何修复」为目标驱动文档内容；AI停留在现象描述层面
AI 局限性
重要局限
- 多次未能主动识别效率瓶颈并提出优化方案：串行场景生成缓慢时仅设定定时检查并等待（未提并行化）；nohup SSH启动进程时未考虑Slurm job到期的资源隔离；均需用户主动指出后才改正，造成实际时间浪费。
- 未能主动发现实验配置与命名的不一致（‘pca_uni2_staig_fusion’实际使用UNI），以及meta.json统计（当前运行）与磁盘文件（历史积累）的差异，均需用户质疑后才通过日志取证确认。
一般局限
- 多次出现工具/API使用细节错误：scanpy spatial plot使用plt.savefig绕过内部渲染导致图片缺失；tyro布尔flag使用–resume=True格式导致训练脚本崩溃；MUJOCO_EGL_DEVICE_ID与CUDA_VISIBLE_DEVICES不匹配导致import失败。
- 在资源/工具不可用时（HuggingFace代理不稳定、TaskOutput工具调用失败、进度轮询）缺乏快速fallback策略，尝试多种方式失败后才给出替代建议，消耗较多时间。
今日收获
核心收获
- Slurm HPC集群的pam_slurm_adopt策略会在job结束时强制kill所有相关进程，SSH nohup无法绕过；长时间训练任务必须用sbatch提交正式job，不能依赖interactive job。
- 机器人操作场景生成的高度阈值设计必须考虑「桌面高度+物体自身高度」的叠加区间，简单设定min_height而不考虑具体物体堆叠高度会产生大量假阳性，导致有效场景极少。
- MuJoCo EGL仿真是CPU密集型任务，同一节点可运行32+独立进程不冲突；训练场景生成失败分为两阶段（opportunity scan阶段can_inject永为False vs validator拒绝），需区分处理：前者改can_inject条件，后者调阈值或注入参数。
- 实验命名约定必须严格对应实际实现；命名不一致（如’pca_uni2’实际用UNI）会导致长期实验理解错误，需通过读取日志而非仅看实验名来确认实际配置。
- MimicGen的D0/D1变体数量因任务而异（如PickPlace只有D0）；设计多任务数据策略时需逐任务确认可用变体，总量等效（如2000条D0替代D0+D1各1000条）是可行的工程决策。
- 诊断数据生成问题时需区分「当前运行meta.json统计」与「磁盘历史积累文件数量」——两者差异巨大时说明问题在当前运行逻辑，而非历史遗留；并行任务日志建议每worker写独立文件，便于grep快速定位失败。
实践收获
- Scanpy的sc.pl.spatial等空间转录组可视化函数必须使用sc.settings.figdir + save参数保存，直接用plt.savefig会绕过内部图层渲染导致图片不完整。
会话摘要
Error Recovery Benchmark（场景修复与并行生成）
✅ drop_in_transit_D0假阳性修复 + 6任务训练场景串行改并行生成 + 失败根因分析 00:55:55.225 | claude_code 诊断确认min_hold_height=0.85导致大量假阳性（物体在桌面被误判为空中持有），将阈值提升至0.93后D0成功率从10%提升至50%。规划并执行6任务训练场景批量生成：先按串行方案执行发现极慢（10分钟5 scenes），用户提出并行化后AI改造为32 worker ThreadPoolExecutor（4 GPU round-robin），41分钟生成973 scenes（128/130 worker成功）。通过交叉分析parallel_logs与opportunity map识别5大失败根因（gripper_closed_norm异常P0级、drop碰撞检测不足等），输出training_scene_failure_analysis.md。
Error Recovery Benchmark（Pi0.5训练流水线）
🔄 Pi0.5-base LoRA合并数据集微调流水线：环境配置、数据转换与训练启动 01:08:53.326 | claude_code 全面调研openpi副本结构和现有数据集后，按计划执行：重定向openpi05 conda环境.pth文件、向config.py添加12个merged configs（6任务×finetune/inference）、完成5任务HDF5→LeRoBot转换和norm stats计算。在an49 tmux中启动coffee/stack训练，pick_place数据生成进行至184/2000，均因Slurm interactive job到期被杀。threading_d1因HuggingFace代理不可用暂以d0-only替代（加TODO注释）。
MIHD空间转录组
✅ STAIG超参数扫描公平对比修复：发现命名误导与gene输入不一致 14:40:59.838 | claude_code 用户发现超参数sweep基线ARI(0.23)与聚类消融(0.58)差距异常，AI通过读取日志确认pca_uni2_staig_fusion实际使用UNI而非UNI2，且ablation脚本使用raw HVG而非PCA输入。修改脚本支持–gene_encoder和–vision_variant参数后，以PCA+UNI和PCA+UNI2各跑pseudo_k sweep，两者ARI均值均约0.47，建立了公平基准。
claude-demo（Visium分析）
✅ 10x Visium 151676样本scanpy分析脚本开发与可视化修复 14:55:05.867 | claude_code 完成项目初始化（CLAUDE.md创建 + 修复错误symlink），为151676 Visium样本开发完整scanpy分析脚本（数据加载、QC、归一化、HVG、PCA/UMAP、空间可视化）。发现spatial_gene_expression.png只有H&E背景无基因点后，将所有sc.pl.*保存方式从plt.savefig改为scanpy原生save参数，6张图全部正确生成。
openpi VLA
✅ openpi项目Docker镜像构建与保存方法查询 04:50:34.000 | claude_code 阅读openpi的docs/docker.md、serve_policy.Dockerfile和compose.yml，整理了5个Dockerfile的用途及对应构建命令，以及docker save/docker load的完整导出加载流程。
Token 用量
总览
| 指标 | 数值 |
|---|---|
| 总 Token | 91,266,639 |
| 输入 Token | 55,409 |
| 输出 Token | 195,151 |
| Cache 创建 | 4,302,013 |
| Cache 读取 | 86,714,066 |
| Cache 命中率 | 95.3% |
| 总费用 (USD) | $61.6229 |
模型明细
| 模型 | 输入 | 输出 | Cache 创建 | Cache 读取 | 费用 | 占比 |
|---|---|---|---|---|---|---|
| claude-opus-4-6 | 29,725 | 121,342 | 3,083,310 | 71,441,071 | $58.1775 | 94.4% |
| claude-haiku-4-5-20251001 | 25,684 | 73,809 | 1,218,703 | 15,272,995 | $3.4454 | 5.6% |
各设备用量
| 设备 | 总 Token | 输入 | 输出 | 费用 |
|---|---|---|---|---|
| DCC | 5,601,785 | 1,456 | 12,539 | $4.3744 |
| tianhe | 84,460,618 | 53,908 | 180,837 | $56.3994 |
| TzJsDesktop | 1,204,236 | 45 | 1,775 | $0.8491 |