research-experiment

# 实验设计与诊断 **改进方法 = 对 idea 做 SGD。** 目标函数 `|| Experiment(idea) − Target result ||`， **"分析实验为什么不 work" 就是求梯度**。 由此得到唯一的效率判据：**每次循环是否产出了一条经过验证的本质技术原因。** 没有 → 这次循环的梯度是随机的，下一次改动等于掷骰子。 失败的实验不是浪费——它排除了一条路径，前提是那条路径被**写下来**了 （落进 `experiments/LOG.md`，见 `research-project`）。 ## 一、设计实验 ### 核心原则：减少 exploration points 一次实验里的未知量越多，结果越不可归因。两种分解，通常同时用： | 分解 pipeline | 分解实验设置 | |---|---| | 把 idea 拆成组件，从**可控的**部分开始，逐步加入探索性模块 | 从**简单 setting** 开始，逐渐增加难度，最后进入真正的 setting | ### 简单实验：只存在 core technical challenge ``` 明确解法要解决的 core technical challenge → 找出当前数据里还有哪些额外的 technical challenge → 寻找或构建不含这些额外 challenge 的数据 → 在这样的数据上验证解法 ``` 好处是成本低、且**没有其他 challenge 的干扰**，能干净地判定解法本身是否 work。 顺序：简单数据验证正确性 → 简单数据上改进 → 真实数据上调 work。 ### 探索性实验的最小可行性三步 **第一步：定义二元的可行性标准。** 这个实验要验证什么？成功标准是什么？**必须是二元、明确、可测量的**（是/否）。 写不出二元标准 = 还没想清楚要验证什么，此时做实验是浪费。 **第二步：设计最小的实验。** 用这句话倒逼： > **"如果只有一天时间，我能做的最简单的验证是什么？"** **第三步：对照标准判定，只导向三个方向之一。** | 结果 | 下一步 | |---|---| | **成功** | 设计更严谨、更大规模的实验巩固；开始增加复杂度 | | **失败** | 用最小成本排除了一条路径。分析是想法错还是实现错，据此 pivot 或终止 | | **模糊** | **实验设计得不够好，标准没定清楚。**回第一步重定义 | 第三行最常被处理错：拿到模糊结果时**不要"再多跑几个 setting"**， 模糊结果重复几次仍然是模糊的。 ## 二、诊断实验为什么不 work ``` 表面原因 → 本质技术原因 → 用实验验证这个原因 ``` 三步都要走完。**只有确认真的是"技术原因"，改算法才有意义。** **第 1 步 · 表面原因**：哪个变量一改就变差（换了数据 / 加了 module / 改了参数）。 方法是**对比 work 与不 work 的两组**，列出它们的具体差异。 **第 2 步 · 本质原因**：对表面原因问"为什么"，**列出尽量多的候选**。两类： 1. **代码有 bug** 2. **"xx 算法"在"xx 数据"上确实有问题**：超参没设对 / 缺了几个 tricks / 算法本身不行 区分第 2 类的手段：**看相关论文为什么能 work、用了什么 tricks** （`literature-review` 检索 → `pdf-explore` 读实现细节）， **给相关论文的算法做 ablation** 看哪部分是关键。 有些 idea 单独拿出来不 work，加上 tricks 才 work（NeRF + positional encoding）。 **第 3 步 · 验证**：设计实验逐个证伪。**跳过验证直接改算法 = 猜的梯度。** ### 输出模板 用户说"实验不 work"时，**不要直接给改进建议**。先产出这张表； 缺哪一格就去补，补不出来就明说"这一格需要你提供 X"。 ```markdown ## 诊断：<一句话现象> **表面原因**：<哪个变量一改就变差> **对照**：work = <配置>　　不 work = <配置>　　**差异**：<具体列出，不写"设置不同"> | # | 候选本质原因 | 支持证据 | 反对证据 | 怎么用一个实验证伪 | |---|---|---|---|---| | 1 | 代码 bug：<具体哪里> | | | | | 2 | 超参：<哪个> | | | | | 3 | 缺 tricks：<论文 X 用了 Y> | | | | | 4 | 算法本身不行：<为什么> | | | | **下一个实验**（只验证一条，exploration points = 1） - 验证第 <N> 条　- 二元标准：<若…则该原因成立>　- 最小设计：<一天能做完的版本> **还需要你提供**：<看不到的信息，如训练日志、baseline 配置> ``` 自检：**"下一个实验"是从表里推出来的，还是先想好再倒填的？** 后者说明在合理化直觉，不是在求梯度。 填满的实例：[references/diagnosis-example.md](references/diagnosis-example.md) （depth prior 监督后掉点的完整诊断）。它示范三件事： "差异"一格要写到具体配置、候选原因里必须有"代码 bug"这一类、 以及候选的**执行顺序按排查成本排而不是按可能性排**——十分钟能排除的先做。 ## 三、论文需要哪些实验 实验规划倒推自论文要回答的三个问题： | 问题 | 实验 | |---|---| | 怎么证明方法比已有方法强？ | **comparison**：和相关的、**较新的** baseline 比。任务太新没有 baseline 时，构造自己方法的 variants | | 怎么证明各 module 有效？ | **ablation**：①一个大表+可视化，列 core contributions 与重要 components 的影响；②若干小表，每个覆盖一个 module 的 design choices（对超参敏感性、对输入质量敏感性、去掉某 choice 的影响） | | 怎么展示方法的上限？ | **在更有挑战性的数据上做 demo** | 第三项决定影响力，判据是： > **面向下游研究群体做 demo——做给会引用这篇论文的人看，不是做给自己或大众看。** 算法在目标数据上 work 之后，**尽量在更新、更难的数据上跑，把算法推到极限**。 "大家都想看一个算法能做到什么程度"本身就是很大的贡献。 反事实：Neural Body 若没做街舞数据，拿不到 best paper candidate。 缺 ablation / 缺重要 baseline / 缺重要 metric / 数据太简单——这四条都是常见拒稿理由， 见 `paper-self-review`。 ## 衔接 诊断结论与下一个实验回写 `experiments/LOG.md` 和 `PROJECT.md` §4（`research-project`）。 方案本身有问题（而非实现问题）时回到 `research-ideation`。