我是肖加森。这篇的来由很简单：标题写了“AI的可复现性挑战（The AI Reproducibility Challenge）”，但真正让我坐下来的，不是这个概念本身，而是这些年反反复复出现在项目里的同一个尴尬场景。调好的模型昨天还能跑出预期指标，今天重跑一遍就差了两个点；论文里写的涨点，按作者给的仓库和配置一跑，结果对不上；团队里换个人接手实验，连数据从哪下载的都说不清楚。
如果你想把这些“玄学”从日常工作中清出去，这篇笔记可以当一份行动清单来看。它不解决模型设计的创意问题，只解决“结果能不能被完整还原”这个工程底线问题。下面所有内容，我都尽量按实操去写，能复现步骤的地方绝不只讲道理。
1. 可复现性不是洁癖，而是工程底线
先说个容易让人忽略的事实：机器学习模型不像普通软件那样天然可预测。你给一段普通程序同样的输入，只要环境大致一致，结果几乎必然是同一个。但训练一个神经网络，同一份代码、同一份数据，很多团队跑两遍，指标都能差出一个身位。可复现性挑战，本质上就是把“实验结果能否被回放”这个问题，从研究者的个人品质，变成一整套可执行的工程规范。
这个挑战之所以难，是因为它没有一个单点根因。它不是“你忘了设随机种子”这么简单，而是从随机性管理、依赖锁定、数据版本化到评估流程，任何一个环节漏掉，都会让整条复现链崩掉。站在工程角度看，真正的目的不是让每个数字都一模一样，而是让每一次实验都可以被解释、被回放、被接手。
1.1 重复、复现、稳健：三个容易搞混的标准
很多讨论把可复现性当成一个模糊的形容词，真到落地时就会吵起来。我把三个概念拆开讲，因为它们对应的考核方式完全不同。
- 重复性（repeatability）：同一份代码、同一环境、同一数据，在短时间内重复运行，结果应该接近一致。这是最严格的要求，也是很多团队默认的理解。
- 可重建性（reproducibility）：把同一份代码移植到另一台机器、另一种平台，或者换一套实现，仍能复现论文中报告的结论或趋势。这是更接近科研和交付的要求，通常允许数值在小范围内波动。
- 稳健性（robustness）：即便数据和环境在合理范围内变化，结论依然成立。这项工作更接近模型上线后的稳定性测试。
区分这三者的价值在于：不要在没锁环境的项目里强求“完全一致”，也不要在需要移植复现的场景里用“跑了三次差不多就行”来搪塞。明确定义标准，团队讨论时才不会鸡同鸭讲。
1.2 “能跑就行”才是最大的隐患
AI项目早期，一切都很美好。你在笔记本上跑通一个模型，损失函数下降，准确率符合预期，于是欣然关掉电脑。第二天想继续，却想不起来数据预处理脚本里那个参数到底是给谁用的。
“能跑就行”的隐患不是当下，而是在时间轴上累积。实验一旦多了，代码、配置、数据、日志混杂在一起，你根本无法说清哪个结果对应哪一串参数。更糟的是，当模型要交付给生产环境时，上游某个依赖被悄无声息地升级，模型行为开始漂移，你同事的第一反应往往是“测试环境有问题”，而不是“我们的实验从来没有被完整记录过”。
我见过最典型的翻车现场是：为了给客户演示，团队把训练好的模型备份到了新服务器，结果因为缺少某个系统级的并行计算依赖，服务跑出来的指标和验收报告对不上。排查了两天，最后发现是构建环境的差异。这件事完全可以避免，只要从第一天开始就把实验当成一个“可回放的操作”，而不是一次性的临时尝试。
2. AI实验不可复现的根源拆解
如果你已经受够了“复现不了就再加个随机种子”这种碰运气式做法，先花十分钟理解下面这几类根源。它们往往是叠加的，不是单一原因。
2.1 随机性很无辜，但失控的随机很致命
随机性是模型训练的一部分：数据打乱顺序、初始化参数、批采样、Dropout、数据增强，都依赖随机源。问题是，随机源的数量远比你想象得多。很多开发者只固定了某个主随机种子，结果数据加载器在多进程模式下依然各自独立地制造随机数；某些算法库有自己的随机发生器，你设了全局种子它也不理你。
我自己的习惯是把“随机性”当成显式变量来管理：入口处统一注册所有常见随机源，并预留扩展接口；当新接入一个组件时，第一件事不是跑通，而是确认它的随机行为能否被控制。这一点带来的收益，会在后续所有实验里持续体现。
2.2 硬件和浮点计算的“玄学”
即使你把所有随机种子都固定住，换一台GPU机器，结果依然可能不同。这背后的原因很硬核：浮点数运算不满足结合律，不同型号的GPU在并行归约时对累加顺序做了不同优化，最终结果在最后几位出现差异。梯度下降又是迭代过程，一步的微小差异会被后续几十个epoch放大。
同样值得警惕的是混合精度训练。在低精度路径上，矩阵乘法的中间结果会被分块累加，块大小不同，结果就会不同。所以，如果有人想严格重现一个结果，硬件型号、驱动版本、计算库版本都需要纳入记录范围；如果只是想复现“趋势性结论”，那么统计意义上的接近就够用。
2.3 数据和依赖版本才是大头
大多数结果复现不了，问题根本不在算法，而在数据和环境。数据在工作区里改了一版、新增了一个清洗步骤、删掉了某些异常样本，都可能让训练分布产生肉眼不可见的变化。压缩包从网上下载，没人校验哈希值；团队共享服务器上的数据目录被覆盖，历史实验从此失联。
依赖同理：今天跑通训练，三周后环境里某个库升了一个小版本，模型指标飘了。有些框架的底层算子会随着小版本更新而变化，这种变化不会出现在你的代码差异里，却切切实实地改变结果。数据版本、依赖版本、代码版本，这三样必须锁在一起，才算一个可引用的实验快照。
2.4 评估过程自带的隐性偏差
最容易被忽略的，是评估环节对结论的污染。常见操作包括：调参过程中反复用同一个测试集挑选结果，直到挑到一个“好看”的数字；在多次运行中只报告最好的指标；不同的对比模型用不同次数的评估来决定最终成绩。
这些做法会让结果看起来更漂亮，却严重损害可复现性。因为最终报告的那个数字，其实是经过了很多次隐性“人工选择”后的幸存者。正确的做法是定义好评估协议，固定运行次数、固定评估周期，在代码层面实现统一的指标汇总，让每个人看到的数字来自同一套客观流程。
3. 构建一套可落地的可复现实验流程
明白根源之后，接下来是把原则变成流程。我不会给出某个工具链的安装教程，而是描述一种不依赖具体平台的组织方式，你在自己的项目里可以照着改造。
3.1 项目结构：让代码、配置、数据、结果各有其位
一个典型的可复现项目，结构应该一眼能看懂。参考结构如下：
demo_repro/ ├── configs/ # 所有实验配置，一个实验一个文件 ├── data/ # 数据原始版本，尽量只读 ├── src/ # 业务代码，按功能拆模块 ├── scripts/ # 一键训练、评估、复现脚本 ├── notebooks/ # 只做分析，不承担训练 ├── logs/ # 训练日志，按实验ID归档 ├── results/ # 指标结果，按实验ID归档 └── env/ # 环境锁文件，包括版本快照这个结构的要点是“隔离”。配置不散落在代码里，结果不混在日志中，数据不允许被训练脚本随意修改。每一类文件各归其位，遇到问题就能顺着路径排查。
3.2 配置管理：把一切加工成可审查的输入
很多人用“改代码里的参数”来跑实验，这是可复现性的大敌。正确的做法是把配置从代码里剥离出来，做成独立的配置文件。我通常用类似下面的格式：
experiment: name: demo_repro_v1 seed: 42 data: version: "clean-20250601" path: ./data/train.parquet model: hidden_dims: [256, 128] dropout: 0.1 train: epochs: 50 batch_size: 128 lr: 0.001 stop_patience: 10 eval: metrics: ["loss", "f1"] repeat: 3配置文件里不仅要有参数，还要有实验版本、数据版本这类元信息。每次实验启动时，把当前配置的哈希值打印到日志里，之后无论谁来问“这个结果怎么来的”，都能直接定位到一条具体的配置记录。
3.3 随机性管理和环境锁定
随机性管理的核心不在于“随机数一样”，而在于“随机状态可控、可复原”。我通常在训练入口的最前面调用一个统一的种子设置函数，把能控制的随机源都设到固定种子：
# src/utils/seed.py import random import numpy as np def set_seed(seed: int) -> None: random.seed(seed) np.random.seed(seed) # 如果你使用的计算框架/库有独立随机源， # 这里还应调用对应的确定性接口，保证全链路可控环境锁定比随机性管理更容易被忽略。最简单的做法是，在每次实验开始时记录当前环境中所有依赖包的精确版本，并生成快照文件。这个文件不是摆设，它应该被提交到版本管理里，随实验的代码、配置一起归档。
3.4 数据版本化与预处理固化
数据版本化听起来麻烦，其实只需要一个原则：数据一旦进入实验流程，就不允许原地修改。可以增加新版本文件夹，但旧版本必须保留；下载下来的原始压缩包，要记录哈希值；每一步预处理脚本，都要有对应的输入和输出版本号。
很多复现失败其实发生在预处理环节：有人修了清洗逻辑，有人改了归一化方式，但数据文件名称没变，所有历史实验全部被污染。你可以简单地为数据产物增加一个版本字段，比如“clean-20250601”，并在配置中引用它。这样一来，训练脚本读的是哪个版本的数据，一眼就能看出来。
3.5 实验记录和结果留痕
有时候代码和环境都对，结果依然存在偶然波动。没事，这不是可复现性失败，而是统计特性。前提是我们要主动记录波动的范围。我习惯了把每个实验重复跑至少三次，用均值加减标准差来汇报指标，而不是只给一个孤零零的最大值。
实验记录也不只包括训练日志。我会在结果目录里保存这样几项：本次运行的启动命令、配置文件哈希、数据版本、代码提交号、依赖快照文件编号。看起来多花几十秒，但一次事故就能把这几十秒的收益放大几百倍。
4. 实操演示：从零搭建一个最小复现体系
下面用一个简化项目，完整走一遍搭建过程。这个过程足够小，你可以复制到自己的机器上做改造。
4.1 第一步：建立目录和配置模板
先在项目根目录创建前面列出的一堆文件夹。然后写第一个配置文件，把实验名、随机种子、数据路径、模型结构、训练周期、评估频率都放进去。粗颗粒配置先不用拆分太细，重点是让每个实验都有一份独立可读的配置。
这一步的关键是让“实验”成为一个命名的实体，而不是一堆散落的参数。从启动训练的第一天起，你就应该能说出“这个实验叫什么、跑哪份数据、用哪份配置”。
4.2 第二步：锁定训练入口和随机源
在训练脚本的入口处，第一时间加载配置、设置种子、记录环境快照。流程可以参考下面的伪代码顺序：
# scripts/train.py from src.utils.seed import set_seed from src.utils.logger import init_experiment def main(): config = load_config("configs/demo_repro_v1.yaml") set_seed(config["experiment"]["seed"]) init_experiment(experiment_name=config["experiment"]["name"]) # 记录数据版本和依赖快照 record_data_version(config["data"]["version"]) dump_dependency_snapshot() # 开始训练 train(config)训练逻辑本身不需要因为可复现性而改变，需要改变的是入口处的纪律：先设定环境，再开始计算。这个顺序一旦形成肌肉记忆，很多随机性灾难自然就消失了。
4.3 第三步：把环境依赖做成可恢复的快照
当训练脚本准备就绪，我会在当前环境里生成一份全量依赖清单：
# 把当前环境里包列表导出成可回放清单 # 不同包管理器的命令不一样，核心思路是导出全量精确版本 pip freeze > env/requirements-lock.txt这份文件随后提交到版本管理里。以后如果有人要复现，先把环境还原到这个快照，再运行训练入口。记住，依赖快照要和配置、数据版本一起归档，不要单独放。
4.4 第四步：做一次完整的复现验证
流程搭建完之后，我建议立刻做一次“复现演练”：跑一遍训练，保存全部日志和结果；然后清空输出目录，在同一个环境里再跑一遍，对比两次结果是否一致。如果一致，说明在当前环境里已经实现了重复性；如果不一致，优先去检查随机源和数据加载路径。
然后在另一台设备上再跑一次。这个实验可以帮你确认当前项目是“可重复”还是“可移植”。两种程度都比较重要，但标准不同，别把两个指标混在一起验收。我一般在结果记录表里留下三列：同一环境重复误差、跨环境误差、结论是否保持一致。
5. 常见问题与排查技巧实录
实操中会遇到一些高频问题，我把踩过的坑集中整理成一份速查。
5.1 固定了种子，损失还是不一样？
这是最常见的问题。固定一个全局种子，不等于控制住所有随机源。排查顺序是：先检查数据加载器是否有独立的随机状态，尤其是多进程模式下，每个进程都有自己的随机种子继承关系。再看计算库的算法级随机行为，某些并行算子不做确定性保证，需要开启专门的确定性模式。最后检查是否有自习写代码里自己调用了随机库，覆盖了你设置的种子。
5.2 换一台机器就翻车，正常吗？
如果两台机器的硬件型号、驱动版本、基础计算库都不一致，那翻车反而是正常的。关键是你是否提前预判了这种差异。我建议把“跨机器复现”分成两步。第一步先固定软件环境，比如同样版本的驱动和计算库，看结果差异；第二步再放开硬件限制，看模型是否保持统计上的同结论。如果换了硬件后指标波动在可接受范围，结论依然成立，那就说明你的实验足够稳健，不需要强求每个浮点数都一样。
5.3 到底该复现到“完全一致”还是“统计一致”？
这个问题没有标准答案，取决于实验目的。如果是在做严谨的基线对比，同一环境下最好做到能精确回放；如果在做模型选型或者业务验证，统计一致性足够。很多人失败的原因是把这两件事搞反了：在生产验证阶段苛求完全一致，在论文复现阶段却用“差不多”糊弄。
5.4 排查环境漂移的实用动作
当你怀疑一个实验被环境悄悄改动了，但找不到源头，可以试这三个动作。第一，对比当前环境快照和历史快照，找出所有变化过的依赖。第二，在复现命令中强制加载历史配置和旧版数据路径，排除“配置漂移”因素。第三，把训练过程中的输出特征保存一份摘要，比如中间层激活的分布，用来和旧日志做比对。这一步能定位很多肉眼看不出来的微小差异。
6. 我的踩坑复盘：三件小事，三次翻车
前面讲的是方法，下面聊几个真实发生过的小失误。这些案例都不复杂，但每个都让我花了不止一天时间。
6.1 数据增强里的隐藏随机
有一次我在复现一个图像分类实验，种子设置齐全，环境也锁了，但结果死活对不上。查了很久，才发现问题出在数据增强：增强脚本默认启用了一个随机旋转操作，而这个操作的随机源没有注册进全局种子。数据增强属于“预处理”，很多人默认它没有随机性，实际上它可能是最隐蔽的随机源。现在我的做法是给所有增强操作也提供种子可控的接口，并且在实验日志里明确记录增强参数。
6.2 升级了一个补丁版本，结果静默漂移
还有一次是为了修一个别的bug，顺手升级了某个基础库的补丁版本。当时没在意，等模型重新训练后，指标比之前明显下降。最初以为是自己改了代码，后来比对后发现代码完全没动，唯一的变化就是依赖里的补丁版本。这件事之后，我把“依赖版本变更”和“代码变更”放到同等重要的级别，任何一次版本变动，都必须跑一次基线实验验证影响。
6.3 日志里少打了一个关键参数
最后这个偏低级，但很常见。当时在做调参对比，日志打印了学习率和损失，却没有打印数据版本字段。三天后回看日志，两个实验看起来一模一样，但性能差了三个点。因为日志里没有数据版本，我无法确定是不是用了不同的数据文件。从那以后，我在所有训练日志的头部强制打印配置哈希和数据版本，让每一次运行都自带“身份证”。
写到这里，我想起最开始聊这个话题时那个朋友的一句话：把实验当成可以随时回放的时钟，而不是靠运气的转盘。这句话后来成了我做实验的基本态度。无论你是在校做研究，还是在公司做模型交付，只要有意识地给每个实验补上可追踪、可回放、可验证这三层信息，很多棘手问题根本不会发生。
我个人现在的习惯是，每跑一个实验前先问自己一句：两天以后的另一个我，能不能仅凭项目里留下来的记录，把这次结果完整还原出来？如果答案是不确定，那就先把缺口补上，再继续训练。这个方法听起来简单，帮我省下的返工时间，远超过搭建流程所花的那点成本。
