1. 可复现性为什么成了AI圈的心头痛
前阵子和一个做NLP研究的朋友聊天，他说自己惨遭“论文复现滑铁卢”——照着顶会论文的代码仓库一步步跑，环境装了又卸、卸了又装，折腾两天，出来的指标和论文报告的数字差了将近八个点。他把这个经历发到技术社区，评论区瞬间炸出几百条共鸣：“你不是一个人”“我们实验室也这样”“这论文到底怎么过的审”。
这就是AI圈最尴尬的现状：论文发得越来越快，模型刷榜越来越猛，但真正能复现出原作者结果的人越来越少。有人调侃说，AI研究的可复现性已经成了“薛定谔的复现”——你不跑的时候，结果好像都在；你一跑，就塌缩成了各种奇奇怪怪的数值。这个现象背后，就是肖加森在“AI的可复现性挑战”里系统讨论的核心问题：为什么深度学习实验这么难复现？我们到底还能不能信任那些刷爆榜单的SOTA数字？
这篇文章不打算灌鸡汤，也不打算空谈什么“科研诚信”的大道理。我结合自己这几年踩坑、填坑、又踩新坑的经历，把AI可复现性这个事儿从原理到实操拆开揉碎，聊聊那些论文里从来不写、但实验里天天踩的细节。如果你是做算法研究的、跑论文复现的、或者给企业做模型落地的，这篇内容应该能帮你省下不少无用功。
2. 可复现性这事，到底难在哪
2.1 第一层难：伪随机带来的“真随机”
先说最基础也最容易被忽视的问题。深度学习训练几乎离不开随机性——参数初始化要用随机数，数据打乱要随机，Dropout要随机，数据增强的裁剪翻转平移也要随机。绝大多数框架默认用伪随机数生成器（PRNG）来管理这些随机源，也就是说只要你固定了种子（seed），理论上整个训练过程就是确定性的。
但问题恰恰出在这个“理论上”上。PyTorch、TensorFlow这类框架的随机数生成器，并不是只有一套全局的，而是分布在CPU、GPU还有各个第三方库里面。你固定了torch.manual_seed()，可能忘了固定NumPy的种子；你固定了NumPy，可能没管CUDA那边的随机数；你啥都固定了，DataLoader开了多进程，子进程的随机状态又不一样了。任何一个环节漏掉，训练过程就会在某个节点“脱轨”，后面再怎么复现都是白搭。
我当时复现某个语义分割模型的时候，就栽在这个坑里。代码里明明写了设置种子，但每次跑出来的mIOU都在上下浮动一个点左右。后来一行行排查才发现，源码里没有给CUDA设置torch.cuda.manual_seed_all()，而模型里恰好用了CUDA上执行的torch.nn.functional.dropout。就这一行代码的缺失，让整个实验的随机性完全失控。
2.2 第二层难：硬件和框架的“隐形差异”
就算你把所有随机种子都钉死了，换个GPU跑同一个代码，结果依然可能对不上。这不是玄学，而是浮点运算本身的特性。GPU并行计算的时候，不同的硬件架构、不同的并行归约顺序，会导致浮点数加法的结合顺序发生变化。A卡和N卡不一样，V100和A100不一样，甚至同一张卡上驱动版本不一样，计算结果在最后几位都可能存在差异。
这些差异单看微乎其微，但在深度学习的反向传播过程中会被层层放大。一个epoch里几百万次浮点运算，每次都在小数点后六七位埋下微小的噪声，几十个epoch下来，模型参数路径早就和原始实验分道扬镳了。更扎心的是，这种分道扬镳并不会让结果差得离谱，通常只是几个点的性能波动——但恰恰是这几个点，决定了你复现出来的结论和原论文“显著不同”还是“基本一致”。
框架版本的差异就更不用说了。同一个模型，PyTorch 1.8和2.0的实现细节就有不少变动，比如某些算子的底层kernel换过、某些op的默认参数变过。你把老代码搬到新环境，表面上没改任何东西，但跑出来的loss曲线就是和原来不一样。
2.3 第三层难：数据和预处理的“隐形埋雷”
如果说随机性和硬件差异还属于“技术性误差”，那数据管线的混乱就是“人为性灾难”。很多论文对数据集的描述极其简略，只写“我们在ImageNet上训练了120个epoch”，但训练集和验证集怎么划分的？图片resize到多少？归一化的mean和std用的哪组数值？数据增强有哪些操作、顺序如何？这些细节往往被当成“众所周知”的常识省略掉。
实际情况是，这些预处理细节对最终精度的影响，有时比模型结构本身还大。我之前尝试复现一个图像分类模型，原报告top-1精度是78.4%，我死活只能跑到76.9%。反复排查之后发现，原实现里训练时用了某组标准化参数，而验证时误用了另一组——这属于作者自己写岔了，但评测基准已经定下，后续复现的人如果不仔细扒代码，根本发现不了。
数据清洗也是个大坑。很多公开数据集本身存在坏图、重复图、标签错误，不同研究团队清洗的方式又不一样。这个清洗了100张，那个清洗了500张，虽然都是“同一个数据集”，但训练集早就不是同一份了。这种数据层面的偏差，用再好的随机种子也无法弥合。
3. 把“随机”焊死：一套标准化的固定随机性方案
既然问题出在多个随机源，那解决方案就是对所有随机源逐一封锁。我在自己的实验环境里总结了一套“五步锁随机”流程，跑过很多次验证，把同配置下多次实验的偏差压到了可以忽略的水平。
第一步，固定所有语言级随机种子。包括Python内置的random.seed()、NumPy的np.random.seed()、以及深度学习框架的种子，一个都不能漏。第二步，固定框架内部的随机源。PyTorch里要同时设置torch.manual_seed()和torch.cuda.manual_seed_all()。第三步，处理DataLoader的随机性，把generator参数传给DataLoader，确保每个epoch的数据打乱顺序是确定的。第四步，给卷积层和BN层设置确定性算法——把torch.backends.cudnn.deterministic设为True，同时把torch.backends.cudnn.benchmark设为False，让CuDNN选择固定算法而不是动态挑选最快算法。第五步，设置环境变量PYTHONHASHSEED，避免Python字典迭代顺序受哈希随机化影响。
这套方案的核心逻辑，是把Python运行时、NumPy、深度学习框架、数据加载、底层CUDA这五个层面的随机性全部统一到同一个种子体系下。任何一层缺失，都可能成为复现链路上的“断点”。
不过我得说句实话：这套锁随机方案能解决“同一环境下多次运行结果一致”的问题，但解决不了“不同环境下结果一致”的问题。换个GPU型号，换个CUDA版本，前面再怎么锁也是白锁。应对这种情况，更务实的做法是接受硬件层面的微小差异，把目标定为“复现出与原论文在合理误差范围内的结果”，而不是“完全逐位的复现”。
我个人的判断标准是：图像分类任务里top-1精度偏差在±0.3%以内，目标检测任务里mAP偏差在±0.5以内，就可以判定复现成功。要是偏差更大，基本可以断定实验里藏着未被发现的实现差异。
4. 环境即代码：把实验环境固化到“骨灰级”
4.1 版本锁定不是选修课，是必修课
环境依赖的问题，是无数复现事故的头号元凶。很多开源项目只给一个requirements.txt，里面不锁版本，甚至只写包名不写版本号。这在项目发布时是“方便用户”，但到了复现时就是“灾难现场”。
举个例子：某个项目依赖numpy，你没锁版本，安装时自动拉到了最新版。而某个深度学习库的底层实现依赖了早期NumPy的行为，新版NumPy把这个行为改了。结果就是同一个代码，在项目作者的环境里跑得好好的，在你的环境里直接报错或者数值漂移。
正确的做法是养成版本锁定的习惯。Python项目用pip freeze生成完整的环境快照，或者用poetry.lock来管理精确版本。深度学习项目中，除了Python库版本，还要记录CUDA版本、cuDNN版本、甚至GPU驱动版本。这些信息不是“锦上添花”，而是复现实验的必要条件。
我习惯在每次跑通一个实验后，额外记录一份运行环境清单，包含操作系统版本、GPU型号、驱动版本、CUDA版本、Python版本、每个关键库的精确版本。记录这份清单只需要几分钟，但能在几个月后重新翻出这个实验时，少花几个小时的排查时间。
4.2 Docker与虚拟环境的正确用法
很多团队已经意识到环境锁定的重要性，开始用Docker来固化环境。但Docker用得不对，同样会翻车。正确的方式是：在拉取基础镜像后，安装依赖时要用带版本号的pip命令或conda命令，然后把整个镜像的配置冻结下来，通过docker commit保存为当前项目的标准镜像。这样，任何人在任何机器上拉取这个镜像，跑出来的环境和原始环境就是同一个。
但Docker并不是万能的。GPU环境的容器化比纯CPU环境要麻烦得多，nvidia-docker的版本兼容、CUDA运行时和宿主机驱动之间的依赖关系，都可能让容器在别的机器上跑不起来。我遇到过几次容器在A机器上运行正常、推到B机器上直接报CUDA driver version mismatch的情况。这个问题的根源在于容器内的CUDA版本和宿主机的驱动版本不匹配，解决思路是尽量在容器内安装与主流驱动兼容性最好的CUDA版本，同时在项目文档里明确标注宿主机的驱动版本要求。
对于轻量级项目，用conda创建独立虚拟环境就够用了。conda env export可以把环境导出为YAML文件，这个文件里记录了所有依赖包的精确版本，是轻量复现场景下的标准方案。无论Docker还是conda，核心思路都是一样的：环境本身就是实验的一部分，必须像代码一样被版本管理。
5. 数据和模型管理的可复现闭环
5.1 数据版本化的实操方案
代码有Git管理，环境有Docker管理，数据却常常被忽视。但在我看来，数据才是可复现性链条里最脆弱的一环。
数据管理的基本要求有以下几点。第一，数据集要记录来源，包括原始名称、下载地址、版本信息。第二，预处理后的数据要验证一致性，可以通过计算数据集的哈希值或样本数量来确认没有意外改动。第三，数据切分方式要固定下来，训练集验证集测试集的划分方式应该作为一个可复现的流程记录，而不是每跑一次就重新随机分割一次。
我在实际项目中常用的做法是：为每个数据集构建一个独立的预处理脚本，输入是原始数据，输出是标准格式的中间数据。这个脚本本身被Git管理，任何人都可以通过运行同一脚本得到同一份数据。中间数据计算一个哈希值记录到实验笔记里，后续每次实验前都校验一下哈希，防止数据被意外覆盖或篡改。
这套做法看起来繁琐，但遇到“过了三个月发现自己数据被同事重新预处理过”这种场景时，你就会庆幸当初做了这个校验机制。
5.2 模型权重与实验记录的三位一体
模型管理同样不容忽视。很多项目训练完模型，只在本地留下一堆.pth文件，文件名是什么model_final.pth、best_model.pth，隔了一个月连自己都分不清哪个对应哪组参数。
我的习惯是给每个模型的权重文件打上结构化的命名：项目名_模型结构_数据集_主干网络_训练日期_精度的组合。同时，每个权重文件配套一个训练配置的JSON文件，里面记录这次训练的全部超参数、数据路径、预处理方式、随机种子、环境版本。权重文件、训练配置、实验日志三位一体，形成一个可追溯的最小单元。
这套东西放到团队协作里尤其重要。团队里任何一个人想复现另一个人的实验，只需要找到权重对应的配置JSON，就能精确重建训练环境；想在此基础上继续优化，也不需要问来问去。这比在聊天软件里翻聊天记录找配置要靠谱一个量级。
6. 论文复现的拆解方法论
6.1 复现前的情报侦察
拿到一篇论文想复现，别急着克隆代码库开跑。先把“情报侦察”做扎实，后续能省掉大量返工时间。
第一，论文本身要精读三遍以上。标注出所有涉及超参数的地方——学习率、批次大小、优化器参数、学习率调度策略、训练轮数、权重衰减系数。把这些参数整理成一张表格，这是复现的第一个基准。第二，检查论文是否提供了补充材料。很多论文的补充材料里藏着关键的实现细节——比如BN层的momentum设置、特殊的数据增强策略、学习率warmup的轮数。这些细节在正文里一字不提，却对实验结果有决定性影响。第三，研究官方代码仓库。没有官方代码的论文，要重点寻找第三方复现版本，但务必注意第三方复现版本不一定和论文描述完全一致，需要交叉验证它们之间的差异。
做完这三步侦察，你对这个实验的“真实面貌”已经有了比较完整的认知。接下来再动手跑，每一步的预期结果都心里有数，就不会两眼一抹黑地瞎跑。
6.2 分阶段验证的复现节奏
复现最忌讳的操作，是直接把全部训练流程跑完，然后发现结果不对，再回头找问题。这时候训练已经消耗了大量算力，而且哪里出了问题往往毫无头绪。
正确的复现节奏应该是分阶段验证。第一阶段，把小规模的训练跑起来，比如用少量数据先跑几个迭代，确认前向传播、反向传播、loss计算、优化器更新这些基础流程没有报错。第二阶段，用完整数据但缩短训练轮数，比如只跑五个周期，观察loss下降趋势是否符合预期。如果loss曲线形态不对，说明模型结构、学习率或数据管线大概率有问题。第三阶段，跑完整训练，保持和论文一致的超参数和训练轮数，记录最终指标。
我在复现时还会额外做一件事：在训练过程中定期保存checkpoint，比如每五个epoch保存一次。这样做的好处是，如果完整训练跑了五十个epoch后发现结果不对，可以通过检查中间checkpoint来判断是从哪个阶段开始偏离预期的。这在排查复杂问题时是极其有效的定位手段。
6.3 结果对不上的排查顺序
当你跑完完整训练、指标和论文对不上时，千万别急着调超参数。按优先级从高到低排查以下问题。
第一优先排查数据管线。数据预处理是否和论文完全一致？归一化参数、缩放尺寸、增强策略，这些都对上了吗？很多时候指标差几个点，根因就在数据预处理细节上。第二优先排查损失函数和优化器。损失函数的实现细节、优化器的参数设置、学习率调度策略，一个标点符号的差异都可能改变训练路径。第三优先排查模型结构。你的模型和论文的模型在通道数、卷积核大小、激活函数、归一化层上有无差异？第四优先排查训练配置。batch size是否一致？梯度累积步数是否一致？混合精度是否开启？这些配置项影响极大。最后才考虑随机性和环境差异。如果前面所有因素都排除后，结果仍然不一致，才应该怀疑硬件或框架层面的微小差异。
这个排查顺序的逻辑是：先查确定性最高的因素，再查随机性最高的因素。数据管线和损失函数是“改一个点就全盘改变”的因素，优先级最高；随机性和环境差异是“影响相对较小”的因素，优先级最低。按照这个顺序排查，效率最高。
7. 团队协作与实验追踪的机制化建设
个人复现是能力问题，团队复现是管理问题。AI研发团队想要系统性地提升可复现性，不能只靠每个人自觉，要配套相应的机制。
实验追踪工具的引入是第一步。现在市面上的实验管理平台不少，核心功能类似——记录每次运行的超参数、代码版本、环境信息、指标曲线、模型权重。团队的每个成员都在平台上登记实验，后续任何人想复现某个实验，一键就能拿到完整的配置和权重。这个机制对于三人以下的微型团队，用简单的表格加网盘也能勉强覆盖；但团队一超过五人，实验数量一多，表格就彻底失控了。
代码评审中加入可复现性审查是第二步。每次代码合并前，要求提交者提供完整的运行配置、环境锁定文件和实验追踪链接。代码评审人除了看代码逻辑，还要检查这些“复现三件套”是否齐全。这一步看似增加了流程负担，实际上能大幅压低后人踩坑的概率。
知识沉淀是第三步。每个项目跑完后，由主要负责人整理一篇内部技术纪要，内容包括项目的核心实验结论、关键实现细节、复现注意事项、踩过的坑。这份纪要沉淀在团队知识库里，是所有后来者的第一手学习材料。我见过太多团队，同一类坑反复踩，就是因为知识没有沉淀下来，每个新人都靠自己的血泪教训重新摸索一遍。
8. 可复现性这件事，往深了想
我自己在实操中越来越觉得，可复现性并不仅仅是一个技术问题，它实际上反映了我们对AI实验的理解深度。一个能完美复现的实验，意味着研究者对自己系统的每一个环节都有精确的掌控；一个无法复现的实验，往往藏着未被理解的黑盒。
所以说，可复现性挑战的本质，就是推动我们把AI研究中那些“说不清”的部分逐步变成“说得清”的部分。这个过程中，无论是锁随机种子、固化环境、数据版本化，还是实验追踪机制的建立，本质上都是同一个动作——用工程化的方式压缩科学研究中的不确定性。
最后分享一个小技巧：每当你准备开始一个新实验时，先花十分钟写下一份“实验预期记录”，内容包括这个实验想验证什么假设、预期什么结果、哪些因素会影响结果、实验失败的可能原因是什么。实验结束后再回头对照这份预期记录，你会对自己实验的理解有一个质的提升。这个方法我从一个老前辈那里学来，实践了两年，比任何工具都更能帮助我建立清晰的实验逻辑。
AI的可复现性挑战短期内不会有完美答案，硬件差异永远存在，框架更新永远会带来微小变化，但只要我们在每个环节都把确定性推到极致，就能让每一次实验都经得起时间的考验。
