AI可复现性挑战：深度学习实验复现的工程化解决之道-平芜编程栈

最近在圈子里被讨论得越来越多的一个说法，是「肖加森：AI的可复现性挑战（The AI Reproducibility Challenge）」。很多人刚看到这个标题时以为又是一次对某个具体项目的吐槽，但真正在算法岗、科研组里待过的人，多读两遍就会笑不出来：它几乎精准踩中了我这几年最头疼的问题——你不是不会做模型，而是你做完的东西，连自己都快没法原样重跑一遍。

我前后遇到过好几类典型场景：论文里写的结果，按作者公开的代码和数据去复现，跑出来差了一大截；几个月前调好的模型，今天想在另一台机器上重新训练，loss曲线和精度完全对不上；团队里两个人用同一份代码训练，居然因为CUDA版本不同，得到的是两份“不同的实验结果”。这些问题单看都像偶然，串在一起就是整个AI开发方式的结构性隐患。这篇文章我想把题目拆开揉碎，从问题根源、工程解法到实际排查，把我踩过坑之后沉淀下来的一套方法完整写出来。

1. 别急着训模型：先解剖“AI可复现性挑战”里最常吃人的四个坑

可复现性问题之所以难缠，是因为它从来不是单一原因造成的。我自己的经验是，凡是“复现不了”的现场，往下挖基本都能找到四个坏味道之一，只是很多时候它们同时出现、互相掩盖。

1.1 环境不一致：昨天能跑，今天不能跑的经典剧本

环境问题是我见过最多、也最容易被人忽略的复现杀手。你以为的“同一份代码”，在不同机器上根本不是同一个东西：Python解释器版本、pip依赖树、CUDA版本、cuDNN版本、GPU驱动、甚至操作系统底层的数学库，都会影响数值计算结果。

举个例子，一个项目依赖列表里写着numpy>=1.20，初看没问题，但你没法保证别人装到的是1.20还是1.26。两个版本里许多线性代数运算的底层实现都不同，浮点累加顺序一变，loss曲线在训练初期可能差不明显，跑到几百步之后，误差会像滚雪球一样越滚越大。再到PyTorch小版本变化，某些算子在GPU上的实现也会重写，同样的seed跑出来就不一样。

以前踩过一个很典型的坑：对方提供的是TensorFlow 1.x时代的代码，结果我在Python 3.9上硬装旧版本依赖，编译半天失败，最后发现项目只支持Python 3.6。这类事情不是少数，而是复现工作的日常。所以环境锁定的第一原则不是“差不多能用”，而是“完全一致”：Python版本、CUDA、cuDNN、每个包的精确版本号，一个都不能含糊。

1.2 随机性失控：种子没固定，结果像开盲盒

第二个坑是随机性。很多人以为设置一个random.seed(42)就万事大吉，实际上现代深度学习训练流程里的随机源多到吓人：Python的random模块、numpy的RandomState、PyTorch的CPU和GPU随机数生成器、数据集shuffle、Dataloader多进程采样、dropout，甚至某些算子的非确定性实现。

如果只固定了其中一个随机源，训练过程仍然是随机的。有一次我复现一个项目，作者在代码里写了全局种子，但Dataloader开了四个worker进程，每个worker在获取数据时都在独立进程里做shuffle，主进程的种子根本没传进去，导致每次启动训练拿到的数据顺序都不一样。结果就是同一个模型、同一份代码，两次训练精度差了两个点。

更隐蔽的是GPU计算本身的不确定性。cuDNN在卷积计算时可能会根据输入尺寸选择不同算法，这些算法在浮点累加顺序上有差异，结果就会在最后几位上不同。日常训练可能不在乎这点差异，但一旦你要精确复现某个实验结果，它就是一个不可控变量。

1.3 数据和配置只活在文档里

第三个坑是数据和配置管理不到位。模型代码往往只是一个很小的部分，真正的复现成本藏在数据准备流程里：你用的是哪个版本的原始数据集？预处理是“先裁剪后缩放”还是“先缩放后裁剪”？归一化用的mean和std是哪个文件算出来的？训练集、验证集、测试集是怎么划分的？这些信息如果只写在论文或README的一句话里，基本等于没有。

我拆解过一个项目，它的README写的是“使用公开数据集，train/val/test按8:1:1随机划分”。这句话看着清楚，但实际上别人根本复现不了：随机划分用什么随机种子？划分之后有没有做去重？图片的resize方式用的是双线性还是最近邻？这些都是指标差异的来源。

配置项也是重灾区。学习率、batch size、weight decay、warmup策略、优化器的epsilon、混合精度开关，任何一个参数变了，结果都会偏离。最怕的是config直接硬编码在代码里，还不在显眼位置，你想找都找不到。

1.4 评估口径不一致：同一个项目，两种“最优结果”

最后一个坑是评估口径混乱。哪怕是同一个模型，评估时你用验证集还是测试集？用训练过程的最后一个权重还是验证集上指标最好的那个权重？模型有没有在评估前切换到eval模式？图片预处理和训练时用的是否完全一致？这些细节都会让数字差出一截。

我见过不少论文在写作时会选择“看起来最好的那组数字”来做报告，但又不说明选的是哪次运行。有人用验证集最好的结果，有人用测试集跑一次的结果，还有人用了多次运行里指标最高的那一次，评估口径完全没法对齐。复现这类结果，结局往往就是你跑出来的数字和论文对不上，然后开始怀疑自己的代码有问题。

2. 为什么AI项目比传统软件更难实现可复现

做过传统软件工程的人可能会疑惑：版本管理、构建系统、测试用例这些方法用了这么多年，不就是为了保证可复现吗？为什么到了AI项目里，这套思路就不太够用？因为机器学习的复现链条比传统软件长得多，而且每一环都可能放大差异。

2.1 数据准备到模型输出，每一步都在放大差异

传统软件的行为通常是确定性的：给定相同的输入，程序输出基本相同。但机器学习是一个多阶段随机过程，数据预处理、参数初始化、样本采样、梯度计算，每一层都有随机性。这些随机性像混沌系统里的微小扰动，前期看不出来，等训练推进到一定轮次，就会表现为完全不同的收敛路径。

哪怕每一次的误差只有1e-6，经过几千步的反向传播和参数更新，结果也可能被放大到肉眼可见的程度。我经常把训练过程比作一场接力赛：数据处理是一个选手，初始化是一个选手，优化器状态又是一个选手，任何一位选手的状态变了，最后交到终点线的成绩都会不一样，而且你很难说清楚到底是哪一棒出了问题。

2.2 传统方法论在模型训练里失灵

传统软件开发有单元测试来锁定“小输入的确定性”，但模型训练很难这么干。你可以写一个测试来验证某个函数输出固定值，但你没法简单断言“整个训练流程是正确的”，因为训练结果不是一个确定性的函数，而是一个随机优化过程的终点。你只能靠指标判断它“好还是不好”，这本身就允许了很大的波动范围。

代码评审在传统工程里能发现很多逻辑错误，但在AI项目里，代码逻辑正确不代表结果可复现。很多“正确”的代码，因为漏掉了一个随机源，或者因为依赖了一个不确定的算子，在别人机器上跑出来的结果就是不一样。这种问题靠肉眼review很难发现，必须靠工程手段去约束。

2.3 团队协作与时间跨度成了隐藏变量

还有一个容易被忽略的因素是时间。模型代码是活的，框架版本会更新，数据集可能被重新整理，操作系统补丁也会改变数学库的行为。你和同事在同一周内复现一个结果可能还行，但三个月后再回来看，环境中很多东西已经不是当初那套了。

更别提不同成员各自维护自己的实验环境，有人用conda，有人用venv，有人直接全局安装。表面上大家都在跑“同一个项目”，实际依赖树早已分叉。等出了问题再凑到一起对环境，每个人都觉得自己的环境没问题，最后发现谁也没错，只是大家手里的“同一份项目”根本不是同一个执行环境。

3. 把确定性拿回自己手里：一套可复现的工程方案

既然问题这么多，那我们能做什么？下面这套方法是我在实际项目中反复调整后沉淀下来的，不敢说解决全部问题，但至少能让“自己复现自己”的概率从“看运气”变成“基本稳”，也让别人复现你的项目时不用靠猜。

3.1 第一层：把Python环境锁死，越具体越好

环境锁定的目标是让依赖完全一致。我推荐的做法是，项目里同时维护：

requirements.in：只写顶层直接依赖，比如torch、transformers、timm，方便他人理解项目需要什么。
requirements.txt：由pip-tools或pip freeze生成的精确版本锁定文件，里面每一个间接依赖都固定到具体版本号。

实际操作时，先用pip-compile requirements.in生成锁定文件，再执行：

python -m venv .venv source .venv/bin/activate pip install -r requirements.txt

如果是GPU项目，CUDA和cuDNN的版本也建议记录在文档里。更保险的做法是用conda导出一个完整的环境文件：

conda env export > environment_full.yml

这份文件包含所有包和系统依赖，别人可以直接用conda env create -f environment_full.yml重建环境。团队里如果统一用这套文件，很多“在我电脑上明明能跑”的争论都可以消失。

3.2 第二层：把随机数种子管到每一个角落

环境锁死还不够，还得控制随机性。我通常会在项目入口统一执行一个seed_everything函数：

import random import numpy as np import torch def seed_everything(seed: int): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False

这里有两个容易被忽略的点。第一是torch.backends.cudnn.benchmark = False，如果不关闭，cuDNN会在每个输入尺寸下自动寻找最合适的算法，而这个“寻找”过程本身可能带来不确定行为。第二是Dataloader的worker进程，必须单独处理，否则每个worker都会重新生成自己的随机状态：

def worker_init_fn(worker_id): np.random.seed(2024 + worker_id) random.seed(2024 + worker_id) DataLoader(..., worker_init_fn=worker_init_fn)

在训练脚本里调用seed_everything(2024)之后，同样的代码、同样的环境，就能稳定复现出基本一致的结果。但要说明，开启确定性模式会牺牲一点性能，尤其在某些GPU卷积算法上会更慢，这属于“可复现性换速度”的取舍，对于正式实验来说非常值得。

3.3 第三层：数据、配置和代码全部“定稿”

数据版本化是整个体系里最容易偷懒、但影响最大的一环。我现在的做法是，在项目目录里维护一个数据清单，至少记录数据集名称、来源地址、下载时间、文件数量、文件大小和校验值。比如我用一个简单的JSON文件：

{ "dataset": "example_dataset_v2", "url": "https://example.com/dataset_v2.zip", "md5": "a1b2c3d4e5f67890abcdef1234567890", "samples": 50000, "note": "official release, no post-processing" }

下载后先做MD5校验，校验不符就说明数据不对，后面的训练结果都不用讨论。预处理代码和训练代码不要混在一起，且数据切分逻辑要固定：最好把train/val/test的sample索引直接存成文件，而不是每次运行都重新随机划分一次。

配置管理我建议用一个独立的YAML文件统一存放超参数：

model: name: resnet50 num_classes: 10 train: lr: 0.001 batch_size: 64 epochs: 30 weight_decay: 0.0001 data: root: ./data image_size: 224

在训练脚本里用yaml.safe_load读取这个配置，并把整个配置文件原样保存到输出目录。这样每个实验结果都自带一份配置快照，几个月后回来看，也不会忘了当初用了什么参数。

3.4 第四层：用实验跟踪工具记录整个生命周期

超参数、指标和权重文件如果用文件夹手工管理，时间一长一定会乱。我现在的习惯是引入实验跟踪工具，把每组实验的参数、指标、模型输出文件自动归档。

一个比较省事的方案是使用MLflow，它允许你记录每个run的params和metrics，并把权重保存为artifact：

import mlflow with mlflow.start_run(): mlflow.log_params(config["train"]) mlflow.log_metric("val_acc", val_acc) mlflow.log_artifact("output/model.pth", "models")

这样做的好处是，每一次实验结果都自带完整上下文。你可以随时回答“那组跑出87.4%的实验到底用了什么学习率”这种问题，而不是靠翻聊天记录。

如果你习惯更轻量的方案，也可以用类似wandb的在线服务；但如果公司不允许数据外传，那就优先考虑本地部署或私有化部署的跟踪系统。工具本身不重要，重要的是“实验上下文被结构化记录”这件事。

3.5 第五层：评估也要讲“可对比协议”

最后要约束的是评估方式。我自己定了一套简单但严格的报告规则：

每个实验至少跑3个不同随机种子，报告均值加减标准差，而不是只报最好的一次。
明确说明指标用的是验证集还是测试集。
明确说明权重保存策略：是取最后一个epoch，还是取验证集最优时刻。
评估前必须调用model.eval()，并包裹torch.no_grad()。
输入数据的预处理必须完全复用训练时的流程，包括插值方式、归一化参数。

这样出来的数字虽然没有“单次最高结果”好看，但经得起推敲，别人照着这个协议复现，也能更容易理解你的结果边界在哪里。

4. 被别人漂亮的结果“毒打”之后：复现一个项目的完整实操流程

以上讲的是如何让自己交付的项目具备可复现性。但现实中更多场景是反过来：我们要去复现别人公开的项目。下面这套流程是我反复试错后总结出的，从接到一个项目到跑出结果，踩坑最少的一条路线。

4.1 接手项目先盘点：代码、数据、环境一个都不能少

别急着clone完就跑。先花20分钟做静态盘点：README里有没有环境安装说明？有没有requirements或environment文件？有没有预训练权重下载链接？数据集是本地文件还是需要脚本下载？如果README只给了一句“请自行准备数据集”，那后面大概率要折腾。

我会做一份简单的清单来记录项目初始状态：

代码仓库最后一个commit的hash。
requirements文件中的核心依赖版本。
README中标注的Python版本和CUDA要求。
数据集的下载地址和本地存放路径。

这些信息是后面排查问题时的“基准线”。如果复现不出来，第一反应不是怀疑自己，而是回去对照这份基准线，看哪里偏离了原始项目的说明。

4.2 搭环境：能用镜像就不要硬编译

根据项目说明，选择合适的Python版本创建独立环境。如果项目提供了environment.yml，直接用：

conda env create -f environment.yml

如果没有，就手动创建并安装精确版本：

conda create -n repro python=3.9 pip install -r requirements.txt

GPU环境里，CUDA版本最好和作者标注的一致。如果找不到旧版本CUDA镜像，可以尝试用Docker方式，把作者环境直接封装成镜像，避开本机冲突。能用现成镜像就不会耗时去编译源码，这是我在踩过“编译源码三小时、最后失败”的坑之后学到的教训。

4.3 先“跑通”再“跑准”，顺序千万别反

复现实验最常见的错误是一上来就要求“结果必须和论文一模一样”。实际上应该分两步：先跑通全流程，再逼近原结果。

跑通阶段建议大幅缩短训练量：把epoch设小、数据子集缩小、关闭数据增强，目标是确认“代码逻辑没有bug、loss确实在下降”。如果小配置都跑不通，那继续追求精确数字毫无意义。

跑通之后再恢复完整数据和完整训练流程。如果想省时间，也可以直接下载作者提供的预训练权重，先验证推理结果是否一致，再决定要不要重新训练。很多复现项目其实只需要完整训练一遍，因为作者的结论依赖整套训练过程。

4.4 对不上结果时，按这条排查链路一层层剥

如果最终结果差异明显，我会按固定顺序排查：

先检查数据：文件是否一致，划分方法是否一致，预处理顺序是否一致。
再检查权重加载：加载的是纯模型权重还是包含了优化器状态的checkpoint，加载后有没有意外覆盖。
接着检查随机性：是否固定了所有随机源，Dataloader的worker有没有设置种子。
然后检查环境：依赖版本是否有偏差，尤其是torch、cuda、numpy这种核心包。
最后检查评估：模型是否在eval模式、resize方式是否一致、是找验证集最优还是最后一个epoch。

这条链路至少能把我遇到过的90%复现问题定位到某一层。

5. 常年复现之后，我整理出的排查清单与几条心得

这一节是纯干货，相当于把零散经验压缩成一份可以拿来就用的检查表。我每次新接手一个项目、或者在项目交付给其他人之前，都会拿这张表过一遍。

5.1 高复现率的发布检查清单

环境与依赖

[ ] Python版本已指定
[ ] requirements.txt已锁定到精确版本
[ ] CUDA/cuDNN版本已记录
[ ] 使用Docker镜像时，镜像tag已固定并记录

随机性与训练

[ ] 所有随机种子已固定
[ ] Dataloader worker随机状态已处理
[ ] cuDNN确定性模式已开启
[ ] 清理了所有非确定性算子或已明确记录

数据与配置

[ ] 数据集已校验，MD5或文件数一致
[ ] train/val/test划分索引已存档
[ ] 配置文件独立于代码保存
[ ] 预处理代码和训练代码完全解耦

实验记录

[ ] 每次运行都记录参数、指标、输出文件路径
[ ] 最终结果至少报告多次运行均值±标准差
[ ] 权重文件与对应config一起归档

文档

[ ] README包含“从零复现”的完整命令序列
[ ] 文中写明评估协议：验证集还是测试集、最后一个epoch还是最优epoch
[ ] 数据下载地址失效时，有备选获取渠道

5.2 例外：确定性做不到了怎么办

需要诚实面对的一点是，有些情况没法做到完全确定性。分布式的多卡训练、某些GPU非确定性算子、带有大量浮点聚合的运算，都可能让你在“源码级一致”的前提下仍然得到略有不同的结果。

我遇到这类情况时，会降低预期：不追求每个浮点完全一致，而是要求多次运行之间的误差在一个可接受范围内，比如top-1精度差异小于0.2%。然后在报告里明确记录这种波动范围，并给出不同seed下的最好和最差结果。这种量化的不确定表达，比假装“完全可复现”更能提供真实价值。

5.3 时间维度：几个月后的你，也是“别人”

最后还有一个心态建议。做可复现性不是为了应对某个评审，而是为了改变工作方式。我把每一次实验都当成“三个月后一个完全陌生的人要接手这个项目”来做记录，这个陌生人也包括未来的自己。事实证明，我对一个项目最绝望的时刻，永远是“我上个月到底怎么把模型训出来的”这种灵魂拷问，而最安心的时刻，则是翻开实验记录发现每一步都有迹可循的时候。

我现在越来越觉得，AI项目的交付物不只是代码和权重，更重要的是“一套可重放的过程”。过程和结果一起交付，项目才能真正沉淀为团队的资产。如果你也有过复现失败的痛苦经历，不妨从今天起，先把种子固定、把环境锁死、把配置存档，这三件小事做起来。等你下次隔三个月再打开项目时，就会回来感谢这个好习惯。