Retro data

retro-data — 数据处理复盘透镜

适用范围与边界

本 skill 覆盖数据获取、预处理、管道管理和完整性验证。

与其它 skill 的区分：

• 实验中的数据处理选择（如选择了哪种归一化）→ retro-experiment
• 数据处理代码的 bug → retro-coding
• 数据异常导致的调试过程 → retro-debugging

不适用场景：纯数据可视化/报表生成、数据库选型决策、API 设计中的数据格式定义（用 retro-design）。

评估维度

1. 数据完整性验证

• 下载/获取数据后，是否验证了文件大小？（不只是文件数量！这是用户真实踩过的重大坑）
• 行数是否与预期一致？（源 vs 目标）
• 是否有截断文件或缺失分区？
• 关键字段是否有非预期的 NULL？

2. 数据格式与匹配

• 数据格式是否与下游（模型/算法）期望匹配？
• Schema 是否一致？（列名、类型、编码）
• 特殊字符、分隔符是否正确处理？
• 时间戳/日期格式是否统一？时区是否正确？

3. 管道可靠性

• 管道是否可能静默成功？（状态显示成功但数据实际有问题）
• 上游 schema 变更是否会被及时发现？（列被重命名/增删后管道还是"成功"的）
• 部分失败是否会导致整体状态仍为"成功"？
• 增量逻辑是否正确？（> vs >= 的边界）

4. 预处理正确性

• 每个预处理步骤的效果是否经过验证？（不是"应该有效"，而是"验证过有效"）
• 抗混叠/LPF 等信号处理参数是否匹配数据特性？（用户教训：decimate 前的抗混叠有效，bandpass 反而有害）
• 归一化/标准化的统计量是否从正确的集合计算？（train 的统计量，不能从 test 算）

5. 数据来源与质量

• 数据来源是否可靠？
• 许可证/使用权限是否清楚？
• 数据时效性是否符合要求？（是否过期？）
• 训练/测试分布是否一致？

常见反模式

反模式	检测信号
只看文件数量不看文件大小	下载后立即说"数据下载完成"，没有检查文件大小
数据格式不匹配就直接训练	套用开源代码不检查数据格式差异（用户 KID-PPG 教训）
静默的数据处理错误	预处理后没有抽样检查中间结果
管道"成功"但数据不对	只看管道状态不看实际数据内容
训练/测试数据泄漏	预处理在划分之前做，或用到了测试集的统计信息
SSL/下载问题被忽略	下载失败但脚本继续执行，产生空文件
数据来源不可靠/过期	未检查数据来源的可信度、时效性和使用许可证
增量边界错误	增量拉取时 >/>= 边界定义不清，导致行重复或遗漏
数据版本未记录	处理后未保存原始数据版本号/快照，后续无法回溯到同一状态
硬编码路径/配置	换个环境就跑不了

已固化模式

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

关键追问

挑刺式（找改进空间）

• 数据下载后做了哪些完整性验证？（数量？大小？格式？）
• 数据处理链路的每一步，有没有检查中间输出？
• 如果数据有问题，是不是能尽早发现？（越早发现成本越低）
• 下个实验开始前，需要先检查哪些数据假设？
• 这次有没有"数据看起来没问题但实际上有问题"的情况？
• 数据版本是否被记录？（下次能否回到完全一样的数据状态？）

正向式（找值得复用的）

• 这次数据处理哪个环节做得特别靠谱？有什么做法下次可以直接复用？ （信号：某个检查步骤在关键时刻拦截了问题、某个预处理 pipeline 被多次复用无故障）
• 有没有发明了某个好用的检查/验证方法，值得固化为流程？ （信号：这个方法在不止一个数据集上被验证有效、比之前的检查方法更省时/更可靠）
• 数据管道的哪部分设计/结构特别经得起折腾？（换了数据源、加了新字段也没出问题）

反证条件指引

对于数据的完整性假设，追问：什么具体信号会提示数据实际有问题？ （引导写出可操作的反证条件——如"如果下次文件大小偏差 > 10%"而非空洞的"如果数据有问题"）