# Retro Experiment

> ML实验领域复盘——从实验设计、数据完整性、模型选择、结果可靠性、实用约束等维度深度挖掘

- Skill: `kaixin1seu/retro-experiment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kaixin1seu/retro-experiment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kaixin1seu/retro-experiment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kaixin1seu (https://skillmd.com/u/kaixin1seu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kaixin1seu/retro-experiment

---


# retro-experiment — ML实验复盘透镜

## 适用范围与边界

本 skill 覆盖 ML 实验的完整生命周期——实验设计、数据处理、模型训练、结果评估。

**与其它 skill 的区分**：
- 数据下载和预处理的具体问题 → `retro-data`
- 模型代码实现中的 bug → `retro-coding`
- 实验过程中的调试和排错 → `retro-debugging`

**不适用场景**：纯数据分析（无模型训练）、简单的脚本调参（无实验设计）、数据处理管道（用 retro-data）。

如果一个发现涉及多个领域，归入最相关领域深度复盘，其他领域在综合时简述。

## 评估维度

### 1. 实验设计
- 假设链是否清晰？（每个实验验证一个具体假设，还是一股脑试很多变量？）
- 消融设计是否合理？（变量控制是否干净？一次只改一个变量？）
- 基线是否公平？（有没有给基线同等的调参预算？）
- 有没有"为了解决不需要解决的问题"而设计实验？（先问：这个问题真的需要 ML 吗？）

### 2. 数据完整性
- 下载数据后是否验证了**文件大小**？（不只是文件数量！）
- 数据格式是否与模型/ pipeline 期望匹配？（KID-PPG 格式 vs 实际数据格式的教训）
- 标签是否正确？有没有手工抽查过？
- 数据划分是否避免了泄漏？（同一个人/同一设备的数据不能同时出现在 train 和 test 中）

### 3. 模型选择与复杂度
- 模型复杂度是否与数据规模和任务难度匹配？（小数据+大模型=过拟合）
- 有没有试过更简单的模型作为 baseline？（不是 SOTA，是最简单的能 work 的方案）
- 模型结构选择的依据是什么？（有消融吗？还是凭经验/流行度？）

### 4. 结果可靠性
- 是否多 seed 跑了？（至少 3 seed，报告均值±标准差）
- 方差大吗？（方差大说明不稳定，需要分析原因）
- 有没有过拟合迹象？（train 远好于 val/test）
- 单个指标好了是否就下结论了？（需要多个指标交叉验证）
- 高 AUC/Accuracy ≠ 模型有效（需要检查模型实际在看什么，是否有捷径学习）
- 超参搜索空间是否合理？搜索策略是否有效？baseline 和实验方法的调参预算是否对等？
- 这个结果对下一步行动的具体指导意义是什么？结论是否足够强到做出决策？

### 5. 实用约束
- 模型大小/推理延迟/内存占用是否在目标平台约束内？
- 训练成本（时间、算力）是否合理？是否随数据量可扩展？
- 如果这是用于嵌入式/MCU 的场景——INT8 量化损失可接受吗？Flash/RAM 够吗？

### 6. 可复现性
- 关键参数是否记录完整？（learning rate, batch size, seed, 数据预处理步骤）
- 数据处理步骤是否有文档？
- 别人（或未来的自己）能不能用这些信息复现结果？
- 有没有记录**失败的尝试**？（失败路径也是重要产出，避免后人踩坑）

### 7. 效率与方法论
- 根因分析路径是否高效？（先验证输入数据，再怀疑模型）
- 有没有在错误方向上花太多时间？（调参 vs 定位根因）
- "简单方法优先"原则是否被遵守？（先试最简单的 baseline，再逐步加复杂度）

## 常见反模式

| 反模式 | 检测信号 |
|--------|----------|
| 只看一个 seed 就下结论 | 对话中只出现一个数值结果，没有"均值±std" |
| 数据泄漏 | train/test 划分存在信息跨区——按时间划分用了未来信息、按组划分同组跨了 train/test、预处理从 test 集计算统计量、同一实体出现在两边 |
| 数据没验证完整性就开始实验 | 下载命令后直接跑训练，没有检查文件大小/格式 |
| 调参过拟合到 val 集 | val 指标一直涨但从未提到 test 集 |
| 把相关性当因果 | "用了 X 方法所以好了"但没有消融实验排除其他因素 |
| 没跑 baseline 就追 SOTA | 花大量时间复现复杂方案，但没先跑简单 baseline 作为性能下界参照 |
| 数据格式与模型期望不匹配 | 直接套用开源代码，没检查数据格式差异 |
| 预处理隐藏错误 | bandpass/decimate 参数不当反而引入噪声（用户真实教训） |
| 跨实验数据版本不一致 | 实验中使用了不同版本/来源的数据，未显式记录差异。后续无法回溯哪个版本产生了哪个结果 |

## 已固化模式

| 模式 | 适用信号 | 验证 | 来源 |
|------|----------|------|
| （待复盘时自动追加） | | | |

## 关键追问

### 挑刺式（找改进空间）
- 这个实验的核心假设是什么？验证了吗？
- 如果结果是正确的，什么可能导致它是假阳性？
- 有什么该做但没做的对照实验？
- 数据处理有没有隐藏的坑？（每个 transform 都验证过效果吗？）
- 这次实验的失败（如果有）最有价值的教训是什么？
- 降级/兜底方案是否被考虑？（如果这个方法不行，plan B 是什么？）
- 模型的选择有依据吗？有没有更简单但可能有效的方案被跳过了？

### 正向式（找值得复用的）
- 这次实验中做得最漂亮的环节是什么？下次怎么做能复现这个成功？
  （信号：某个做法被反复使用且每次都有好效果、某个步骤出乎意料地顺利、用户主动表扬了某个流程）
- 有没有某个做法或配置在当前场景下特别有效，值得固化为默认？
  （信号：换了场景/数据集后仍然有效、比之前的做法明显更好）
- 实验设计中有什么特别干净的地方？（变量控制得好、假设链清晰、结果解释力强）
- 结果分析中有什么洞察特别有价值，改变了后续方向或从根本上改变了某个假设？

### 反证条件指引
对于核心实验结论，追问：**什么具体实验结果会提示这个结论是错的？**
（引导写出可操作的反证条件——如"如果在新数据集上 MAE > 5.0"而非空洞的"如果结论不对"）