2. 可重复性基础
在数据驱动的科研实践中，“可重复”常被当作一个笼统口号，但它实际上包含三个层次不同、责任主体不同、验证方式也不同的概念：可重复研究（Repeatable Research）、可复现性（Reproducibility）与可重复生成（Reproducible Generation）。混淆这三者，会导致团队在评审、交接和论文投稿时对“结果能否被信任”给出错误判断。本节先厘清定义，再讨论它们在科研中的真实价值。
一、核心原理：三个概念的定义与边界
可重复研究指同一研究者、在同一环境下、使用同一份数据与同一套代码，能够再次得到相同结果。它关注的是“我自己能不能再做一遍”，是最低门槛，也是实验记录、脚本命名、参数留存等日常规范要解决的问题。
可复现性指其他研究者依据论文、代码仓库与数据说明，在独立环境中能够重建出与原文一致或统计上等价的结论。它跨越了人与机器的边界，考验的是文档完整性、依赖声明、数据可获得性与方法描述的精确度。
可重复生成则更进一步：它要求从原始数据到最终图表、指标、报告的整条链路，能够通过一条命令或一个流水线自动重建，且结果具备版本锁定能力——即代码版本、数据版本、依赖版本、随机种子都被固定并可追溯。它不依赖人的记忆，而依赖工程化机制。
二、方法流程：从“能跑”到“可锁定”的演进路径
把一项研究从“能跑通”推进到“可重复生成”，通常经历四个阶段，每个阶段都有明确的交付物与检查点：
- 记录阶段：保存原始数据、脚本、参数与运行日志，确保同一人可重跑。交付物是带时间戳的实验记录。
- 封装阶段：将依赖写入配置文件，把数据路径、随机种子、环境变量显式化。交付物是可安装的环境描述文件。
- 流水线阶段：用构建工具把数据清洗、特征工程、建模、评估、绘图串成有向无环图，支持增量执行与失败重试。
- 版本锁定阶段：对代码、数据、依赖、容器镜像分别打版本标签，并记录其哈希值，使任意历史结果都可精确回溯。
下面是一个典型的版本锁定配置片段，用于固定依赖与随机性来源：
# environment.lock.yaml
python: 3.11.7
packages:
pandas: 2.2.1
scikit-learn: 1.4.0
numpy: 1.26.4
seed: 20240517
data_version: raw-2024-05-01
code_commit: a3f9c21
container_digest: sha256:7b1e...
当上述信息被写入流水线入口，任何一次运行都可以被复算。若缺少其中任意一项，结果就退化为“当时能跑”，而非“永远可重建”。
三、案例/场景：同一份研究在三种标准下的表现
假设某团队完成了一项基于公开问卷的回归分析，并投稿至期刊。我们可以用一张对比表看清三种标准下的差异：
| 维度 | 可重复研究 | 可复现性 | 可重复生成 |
|---|---|---|---|
| 执行主体 | 原研究者 | 独立第三方 | 自动化流水线 |
| 环境要求 | 同一台机器 | 可不同，但需文档 | 容器或锁定环境 |
| 数据要求 | 本地留存即可 | 需可获取或说明 | 数据版本与哈希固定 |
| 验证方式 | 手动重跑 | 按文档重建 | 一条命令重建全部产物 |
| 典型失败原因 | 忘记参数 | 依赖缺失、路径写死 | 未锁定版本、随机种子漂移 |
在这个案例中，团队若只做到“可重复研究”，审稿人无法验证；若做到“可复现性”，但未锁定依赖，半年后自己也无法重建；只有做到“可重复生成”，才能同时满足投稿、评审、教学与后续扩展的需求。
四、误区与复盘：为什么“我电脑上能跑”不等于可重复
复盘时可用以下清单自查：
- 是否记录了数据获取日期与版本标识？
- 是否声明了所有直接与间接依赖的精确版本？
- 是否固定了随机种子，并说明其在哪些步骤生效？
- 是否将中间产物与最终产物分离，避免手工修改污染链路？
- 是否能在全新机器上，仅凭仓库与说明完成一次完整重建？
在科研中，这三层能力的重要性并不相同：可重复研究保障日常效率；可复现性保障学术信任；可重复生成保障长期资产价值。数据集与代码一旦具备版本锁定能力，就能被反复引用、审计与再分析，从而把一次性成果转化为可持续积累的研究基础设施。