日报 — 2026-03-04
今日概览
- 做了什么: 跨两台设备开展研究与工程双线工作:DCC 分析 QueST 论文以服务 MIHD 项目的跨样本查询设计;tianhe 推进错误恢复基准的文档对齐、性能诊断和训练基础设施建设。
- 怎么做的: DCC 通过多轮 WebFetch/WebSearch 获取论文 HTML 版本并提炼技术细节;tianhe 通过并行 Agent 探索代码库、对比文档与实现差异、使用 Edit/Write 工具更新文档并规划训练编排脚本。
- 有什么用: 形成 QueST 评估方法的结构化理解可直接借鉴到 MIHD 评估设计;错误恢复基准文档对齐度大幅提升,BC-RNN 零成功率根因定位为后续调优提供依据,an49 训练 Pipeline 规划完成为多任务训练落地铺路。
DCC
- 做了什么: 阅读分析 QueST(arXiv:2410.10652v3)论文:跨样本空间转录组 niche 查询框架的完整方法论与评估设计。
- 怎么做的: 先尝试 PDF 解析失败,转 HTML 版本获取架构细节;通过 WebSearch 和 Moonlight/GitHub 补充 v3 更新内容(因 v3 无 HTML 版本);用中文结构化总结图自编码器、对比学习、对抗去批次三模块与 WWL Kernel 评估方案。
- 有什么用: 明确了 QueST 使用 WWL Graph Kernel 构造 pseudo ground truth 进行跨样本 niche 查询评估的方法,为 MIHD 项目的评估指标设计提供了参考。
tianhe
- 做了什么: 完成错误恢复基准多项并行工作:更新项目全景总结.md(对齐实现细节 + 修正 M14 评估数据)、创建 zhaoganlong 训练指南文档、排查 BC-RNN 零成功率、规划 an49 全任务训练计划、修改数据准备脚本以启用全部 9 个任务。
- 怎么做的: 使用多个并行 Agent 探索代码库(error_framework 53 个文件、scripts 22 个脚本)与文档对比;直接读取 summary.json 获取实际评估数据;检查 GPU 利用率、数据集状态、checkpoint 存在性;通过 Edit 工具精准修改大型 Markdown 文档。
- 有什么用: 文档真实度大幅提升(M14 726 ep → 6474 ep,实现细节从空白到详尽);定位到 BC-RNN Normal SR=0% 是因观测键 bug(非模型能力问题);an49 训练计划完成,数据准备脚本修改为启用全部 9 任务奠定基础。
DCC 深度分析 QueST 空间转录组论文的跨样本查询与评估方法;tianhe 完成多项项目文档更新(错误恢复基准全景总结.md + zhaoganlong训练指南)、排查 BC-RNN 零成功率根因、规划 an49 全任务训练基础设施。
今日任务
架构与策略
- ✅ 更新项目全景总结.md — 对齐文档与实际代码 — Section 3.2 新增检测器/注入器/验证器/分类器/核心模块的详细实现描述;修正 VLA 支持模型(Pi0-FAST→Phoenix/Flare);更新代码统计(scripts 18→22,测试用例 109→122);更新 M14 评估数据(726 ep→6474 ep,实际 SR/RP);新增数据库 by_phase 和 by_severity 统计。
- ✅ 排查 BC-RNN 正常任务零成功率根因 — 用户反映 BC-RNN training rollout 与评估结果完全不同;AI 探索代码后发现是
object观测键 bug 导致 baseline_accuracy 评估 SR=0%;Pi0.5 Per-Task LoRA 在正常任务上表现良好(Stack_D0 ~95%),与 BC-RNN 0% 形成鲜明对比。 - ✅ 分析 QueST 论文跨样本查询方法与评估设计 — 阅读 arXiv:2410.10652(QueST)论文,提取跨样本 niche 查询的图自编码器架构、对比学习设计、对抗批次去除,以及使用 WWL Graph Kernel 构造 pseudo ground truth 的评估方法。用户追问评估部分并要求查看 v3 版本。
- ✅ 创建 zhaoganlong 训练指南文档 — 创建 docs/zhaoganlong_training_guide.md,涵盖 MPM→MCM 闭环框架概述、6 个训练阶段的完整命令与超参数、所有 checkpoint 的文件系统验证(Diffusion Policy / OpenPI Base / Pi0.5 Phoenix)、推理 pipeline 三种模式,以及完整路径参考。
- ✅ 规划 an49 全任务训练计划(zhaoganlong 6 阶段) — 撰写训练计划:GPU 分配(GPU 0 Diffusion Policy,GPU 1-4 LLaVA MPM/MCM,GPU 2-5 Pi0.5),数据准备 4 步 Pipeline,tmux session 管理,所有 9 个 MimicGen 任务,checkpoint 存储在 tangzijia 目录下。
- ✅ 更新核心 Pipeline 图为三路并行输入 — 用户指出原 Pipeline 图只有 Demo Dataset 一个入口,遗漏了 VLA/Policy Rollout 注入和自然失败捕获两条路径;AI 更新 Section 3.1 为三条并行路径全部汇入 ErrorSceneDatabase 的架构图。
实现与修复
- 🔄 修改数据准备脚本启用全部 9 任务 — 需要修改 4 个脚本(create_5hz_dataset_new_motion.py、create_speed_dataset.py、generate_llava_json_dataset.py、generate_render_llava_dataset.py)取消注释全部 9 个任务、移除 pdb 断点;同时复制 6 个缺失的 HDF5 文件到 origin_datasets/。计划已完成,实际执行被用户中断。
- 🔄 生成 Pi0.5 Visualization 视频 — 用户请求生成 Pi0.5 policy rollout 的可视化视频;AI 确认 outputs/pi05_eval_results/videos/ 目录为空,需要在 an49 启动 VLA server 再运行 visualize_policy_rollout.py;执行被中断未完成。
问题与解决方案
关键问题
1. BC-RNN 在所有正常任务上 SR=0%,与 training rollout 完全不符
解决方案: 通过代码探索定位到 baseline_accuracy 评估中 object 观测键 bug,导致策略接收到空观测;这不是模型能力问题,而是评估脚本的 bug
关键洞察: 在对比训练与评估结果差异时,应先检查观测空间是否一致(键名、维度),而不是直接假设模型没有学会
2. 文档描述的 Pipeline 与实际代码实现存在多处差异(VLA 模型类型错误、代码统计过时、M14 数据仅为早期结果)
解决方案: 系统性地启动 3 个并行 Agent 探索代码库各维度,收集实际数值(文件数、函数数、评估结果),逐条精确 Edit 文档
关键洞察: 大型项目文档容易与代码产生漂移;定期「文档 vs 代码」对齐是保持项目可读性的关键,且应以代码为权威
一般问题
3. 数据准备脚本中遗留 pdb.set_trace() 调试断点且只激活 coffee_d1 一个任务,无法批量运行全部 9 个任务
解决方案: 通过逐行 Read 4 个脚本,识别出 pdb 调用位置和注释掉的任务列表,使用 Edit 工具批量取消注释并移除断点
关键洞察: 共享代码库中遗留的调试断点会在自动化 pipeline 中导致静默挂起,应在实现计划时作为首要检查项
4. arXiv PDF 无法直接解析(FlateDecode 二进制流),v3 也无 HTML 版本(404)
解决方案: 先通过 WebSearch 找到 v1 HTML 版本获取架构核心,再通过 Moonlight 文献评论站和 GitHub 仓库补充 v3 差异内容
关键洞察: arXiv 论文并非所有版本都有 HTML 渲染;利用二手文献评论平台可以获取最新版修改摘要
5. 项目全景总结.md 超过 25000 tokens,单次 Read 工具无法获取完整内容
解决方案: 使用 offset+limit 分段读取,结合 Grep 精确定位需要修改的行,避免全量读取
关键洞察: 对于大型文档,分段读取+精确 Grep 比全量加载更高效;关键改动应先 Grep 确认行号再 Edit
人类思路 vs AI 思路
战略层面
BC-RNN 评估结果解读
| 角色 | 思路 |
|---|---|
| 人类 | 用户观察到自己做过很多 rollout 结果不尽相同,质疑 M14 评估中 BC-RNN 清一色 0% 的可信度;后来明确指出自己说的是 normal rollout SR,不是 error recovery SR |
| AI | AI 最初解释 M14 专门评估错误恢复场景所以 SR≈0% 是正常的,但没有主动区分 Normal SR vs Error SR;需要用户追问才澄清 |
差异分析: 用户保持对结果的怀疑精神(“我做过不同结果”),驱动了对 normal rollout baseline 的挖掘,最终发现 BC-RNN 有 observation key bug;AI 倾向于接受现有结果的合理化解释
发现 Pipeline 文档遗漏了 VLA Rollout 注入路径
| 角色 | 思路 |
|---|---|
| 人类 | 用户主动指出文档中的核心 Pipeline 图只有 Demo Dataset 一个输入,与实际想法不符——还需要支持在 VLA 模型 rollout 过程中注入错误并验证,三路来源都应汇入 ErrorSceneDatabase |
| AI | AI 描述了已有的三条路径(Demo注入 / Policy Rollout注入 / 自然捕获),但文档图中只画出了一条;未主动识别文档与用户意图的偏差 |
差异分析: 用户从系统设计层面发现了文档缺失,而 AI 只是准确地反映了现有文档状态;这是高层次架构认知 vs 文本准确性的差异
实现层面
QueST 论文从 v1 切换到 v3
| 角色 | 思路 |
|---|---|
| 人类 | 用户在 AI 引用 v1 分析后,直接指出"不要用 v1,有个 v3 版本有更新" |
| AI | AI 没有主动检查是否有更新版本,默认使用了 Google 搜索到的第一个 HTML 链接(v1) |
差异分析: 用户对文献版本的管理意识更强;AI 在检索论文时应默认检查是否有最新版本
zhaoganlong 训练计划的范围与目标
| 角色 | 思路 |
|---|---|
| 人类 | 用户明确选择全部 6 个 Stage、多任务数据、checkpoint 存放在 tangzijia 目录,这些都是具体的工程决策 |
| AI | AI 在通过 AskUserQuestion 询问确认后才开始设计,并基于代码库实际状态(GPU 占用情况、数据准备状态)调整了并行策略 |
差异分析: 用户提供了目标约束,AI 负责将约束转化为可执行的详细计划;配合较好
AI 局限性
重要局限
- 在解读 M14 评估结果时,倾向于为"所有结果为 0%“找合理化解释(错误恢复场景自然 SR 低),而不是主动追问用户的参照系(Normal SR vs Error SR),需要用户纠正才明确
- 未能主动识别文档与代码的系统性偏差,需要用户逐一指出才开始对齐;理想行为是在修改文档时先系统扫描所有数值和描述是否与代码一致
一般局限
- 多个并行 Agent 任务在同一 session 中超时(timeout 1122s),可能是远程文件系统 I/O 延迟导致;Agent 规划时应将大探索任务拆分为更小的读取粒度
- 检索论文默认使用搜索结果第一个链接(v1),未主动检查是否有更新版本(v3);需要用户提示才切换,且 v3 HTML 不存在时只能通过第三方渠道补充
- PDF 文件无法直接解析(返回二进制流),导致第一次 WebFetch 失败并需要用户确认;对于 arXiv PDF URL 应默认先尝试 /abs/ 页面或 HTML 版本
今日收获
核心收获
- QueST 的跨样本评估核心思路:不存在 niche 级别的 ground truth 时,用 cell type annotation + WWL Graph Kernel 构造 pseudo ground truth,再用 Pearson 相关系数量化模型相似度排序与 kernel 排序的一致性——这是一种在无监督嵌入空间中建立可比较基准的通用方法
- Pi0.5 Per-Task LoRA 与 Global Model 的性能差距极大(Stack_D0: ~95% vs ~24%),说明 Foundation Model 在专用任务上需要任务级微调才能发挥潜力;Global model 的 58.9% 平均 SR 掩盖了严重的任务不均衡
- Normal SR vs Error Recovery SR 的明确区分是错误恢复基准的核心指标设计要点:M14 的接近 0% Error SR 不是模型失败,而是 benchmark 要论证的核心观点(现有策略缺乏错误恢复能力),与 Normal SR 构成对比才能说明问题
- zhaoganlong 框架的三模块设计:Motion Prediction Module (MPM) 预测未来运动方向并编码为 37 维 codebook → Motion-Conditioned Diffusion Policy 接收 codebook 生成动作 → Motion Correction Module (MCM) 检测执行偏差并生成纠错指令,形成闭环自反思机制
实践收获
- 大型项目文档对齐策略:以代码为权威,用并行 Agent 从多维度(error_framework、scripts、outputs)收集实际状态,再系统性地对文档逐节 Edit——比逐行手动对比效率高 3-5 倍
会话摘要
MIHD
✅ 分析 QueST 论文:跨样本空间转录组 niche 查询方法与评估设计 22:21:12.826 | claude_code 用户请求分析 arXiv:2410.10652v3(QueST)如何实现跨样本查询,AI 首先遭遇 PDF 解析失败,通过 HTML v1 版本获取了完整技术细节(GIN 编码器+对抗去批次+余弦相似度检索)。用户进一步要求了解评估方法,AI 提炼出 WWL Graph Kernel 作为 pseudo ground truth、两个评估指标(Best Niche Match Accuracy + Pearson 相关)的设计。用户要求查看 v3 版本,但 v3 无 HTML,通过 Moonlight 评论站补充了方法概要。
Error Recovery Benchmark
✅ 更新项目全景总结.md:对齐文档描述与实际代码实现 03:04:05.254 | claude_code 通过并行 Agent 深度探索 error_framework(53 文件)、scripts、outputs 目录,识别出文档与代码的 5 处核心差异。完成了 5 项精确更新:Section 3.2 新增检测器/注入器/验证器/分类器详细实现描述;VLA 支持模型修正为 Phoenix/Flare;代码统计更新;M14 评估数据从 726 ep 更新为 6474 ep(含实际 SR/RP);数据库统计新增 phase 和 severity 分布。
✅ 排查 BC-RNN 零成功率:定位 observation key bug 并汇总 Pi0.5 正常任务性能
00:31:43.102 | claude_code
用户反映 BC-RNN training rollout 与评估结果差异巨大。AI 探索代码后定位到 baseline_accuracy 评估中的 object 观测键 bug,这是导致 BC-RNN Normal SR=0% 的根本原因而非模型能力不足。同时发现 Pi0.5 Per-Task LoRA 正常任务表现良好(Stack_D0 ~95%,整体 ~58.9%),与 Global model 的 4.22% 和 M14 Error Recovery 的 0% 形成鲜明对比,清晰区分了 Normal SR 与 Error Recovery SR 两个指标。
✅ 创建 zhaoganlong Motion-based Self-Reflection Framework 训练指南 22:23:48.001 | claude_code 用户希望了解 zhaoganlong 框架的训练方式和 checkpoint 状态。AI 通过 3 个并行 Agent 探索代码库后,发现框架包含 3 个可训练模块(MPM/MCM/Diffusion Policy)和 6 个训练阶段。创建了 docs/zhaoganlong_training_guide.md,包含完整训练命令、超参数、checkpoint 文件系统验证(Diffusion Policy 4×253MB 可用,LLaVA MPM/MCM 缺失,Pi0.5 Phoenix 180GB 可用),以及三种推理 Pipeline 模式。
🔄 修正核心 Pipeline 图:添加 VLA Rollout 注入和自然失败捕获路径 00:53:32.952 | claude_code 用户指出项目文档的 Pipeline 图只展示了 Demo Dataset 入口,遗漏了 VLA/Policy Rollout 注入和自然失败捕获两条路径。AI 更新了 Section 3.1 为三路并行输入全部汇入 ErrorSceneDatabase 的架构图。用户进一步质疑 ErrorSceneDatabase 设计,AI 深入分析了 database.py 和 core.py 的实现,解释了当前设计的结构与 API,并完成了全面的代码 vs 文档对齐工作(被拒绝 ExitPlanMode)。
🔄 了解 zhaoganlong retry/reset 框架模型训练方式并规划文档 21:24:32.032 | claude_code 用户询问 zhaoganlong 框架的训练方式和 checkpoint 状态。AI 启动 3 个 Agent 探索后因超时失败;重启后成功完成探索,设计了创建 zhaoganlong_training_guide.md 的计划(用户拒绝了 ExitPlanMode),为后续 22:23 session 的文档创建奠定基础。
🔄 实现 an49 全任务训练计划:修改数据准备脚本启用 9 个任务 22:56:14.823 | claude_code 用户提供了详细训练计划,AI 开始执行:并行读取 4 个数据准备脚本,确认当前只激活 coffee_d1 且存在 pdb 断点;验证了源 HDF5 文件(全部 9 个任务在 tangzijia/mimicgen_datasets/core/ 可用);检查了 origin_datasets/ 缺少 6 个文件。开始修改脚本启用全部任务并移除断点,但执行过程被用户中断。
❌ 生成 Pi0.5 可视化视频 00:26:04.288 | claude_code 用户请求生成 Pi0.5 rollout 可视化。AI 发现 outputs/pi05_eval_results/videos/ 目录存在但视频文件为空(未成功生成),需要在 an49 启动 VLA server 后再运行 visualize_policy_rollout.py –policy vla_pi05;因 session 中断未能完成视频生成。
✅ 询问如何下载项目全景总结.md 到本地 22:34:38.641 | claude_code 用户询问如何将 项目全景总结.md 下载到本地机器,AI 提供了 SCP、SFTP、VS Code Remote Explorer 和 FileZilla 四种方法及具体命令。
Token 用量
总览
| 指标 | 数值 |
|---|---|
| 总 Token | 21,258,501 |
| 输入 Token | 35,540 |
| 输出 Token | 77,340 |
| Cache 创建 | 1,428,509 |
| Cache 读取 | 19,717,112 |
| Cache 命中率 | 93.2% |
| 总费用 (USD) | $13.4929 |
模型明细
| 模型 | 输入 | 输出 | Cache 创建 | Cache 读取 | 费用 | 占比 |
|---|---|---|---|---|---|---|
| claude-opus-4-6 | 10,163 | 24,198 | 732,760 | 12,812,265 | $11.6416 | 86.3% |
| claude-haiku-4-5-20251001 | 25,377 | 53,142 | 695,749 | 6,904,847 | $1.8513 | 13.7% |
各设备用量
| 设备 | 总 Token | 输入 | 输出 | 费用 |
|---|---|---|---|---|
| DCC | 289,447 | 242 | 2,232 | $0.3474 |
| tianhe | 20,969,054 | 35,298 | 75,108 | $13.1455 |