第3讲 · 研究推进¶
2026年10月9日已授课
从研究问题到研究成果：构思、分析、实现、实验、反思¶
上一讲解决“研究问题从哪里来”，这一讲解决“问题怎么被解决并形成成果”。全流程是构思 → 分析 → 实现 → 实验 → 反思，每一步都留下可检查的产出。
本讲要点¶
- 研究问题的三个来源：增量改进类（在 SOTA 上提正确率、降开销）、场景迁移类（批处理改流式、静态改可更新、CPU 换 GPU）、提出新问题类（抽象共性问题、换一种建模或重新制定性能度量）。领域的盲区通常要靠前两类工作积累铺垫。
- 从机理出发构思解法：把解法里的技术名词全部划掉，还能说清“哪里不好、为什么不好、要改成什么”，才是真正找到了问题和解法。从一个实例或一组实验结果出发，由直观到抽象，往往比先搭概念框架更好走。
- 第一性原理：先列不可违反的条件——资源（时间、内存、带宽、算力、数据、人力）、约束（延迟上限、硬件、隐私、正确性、预算）、不变量、必要条件，再挑切入点。这样产出的设计选择保守，但踩坑少。
- 切入点决定贡献大小：干预点在哪一层，贡献就有多大；往下走一层，通常意味着换掉一个默认假设。
- 论证比代码先行：先做量级估算再动手。内存够不够、瓶颈在 I/O 还是计算、理论上能不能做到，这些问题花半小时算一遍，好过实现一学期后推倒重写。
- Amdahl 定律的例子：计算只占总耗时 20% 时，把它加速十倍，端到端只快 18%。优化之前先量清楚时间到底花在哪。
- 实现：精简与快速迭代：20% 的实现完成 80% 的功能。可以省掉完整 UI、云端部署和边界优化；不能省掉核心机制跑通、公平 baseline、正确性检查和多次运行。一次只改一个变量，否则说不清是哪个改动起了作用。
- 不要工程洁癖，也不能不严谨：代码可以糙，结论不能糙——基线调参强度、测量方法、随机种子都要规范。思路定型之后再全面严谨化，在那之前追求整洁，是在给一个可能被推翻的想法做装修。
- 实验设计四条：全面（覆盖代表性数据集与思路上有代表性的基线）、科学（控制变量、重复 3–5 次、报告均值方差并说清差了多少）、明确（写清硬件、软件栈、数据版本、随机种子和指标定义）、完整（每个论点都有对应实验，只报好的那一半，评审会自己补另一半）。
- 应对失败：大多数想法最后没做成，这不是例外而是常态。更难受的是“前路不明”——不是失败，而是不知道下一步往哪走。这时该做的是停下编程去复盘：哪些现象解释不通，原始假设哪一条可能错了。给导师或同学讲一遍，别人常常一句话指出你绕了远路。
- 分析与反思：说清自己在收敛性、复杂度、资源开销上相对已有工作的位置，是降了一阶还是常数项小一点，这决定结论能写多大。把没做到的逐条列出来，说明是没时间做还是这样做不了。
- 常见逻辑谬误：相关当因果、以偏概全、选择性汇报、不公平比较；更隐蔽的还有指标偷换、混杂变量、事后解释、缺少反证。交稿前自己反问五轮：这个结论在反问下还站得住吗？
- 研究成果汇报：听众没读过你读过的东西，前三页讲不清问题，后面全白讲；讲相关工作时讲思路和局限，不要念论文；自己的工作聚焦 2–3 个最能说明“为什么有效”的点；每张图表配一句话说明它证明了什么。
核心参考¶
- Jeff Dean, Numbers Everyone Should Know（Stanford CS295 talk, 2010）
- R. Jain, The Art of Computer Systems Performance Analysis, 1991
- J. Demšar, Statistical Comparisons of Classifiers over Multiple Data Sets, JMLR 2006
- D. C. Montgomery, Design and Analysis of Experiments, 9th ed.
- Booth et al., The Craft of Research, Ch. 4（写作即思考）
更多阅读材料见阅读材料。