上个月我翻出一个半年前跑过的训练脚本，准备把那时候的效果复现出来，给下一版基线用。结果代码还是那份代码，数据也还是那份数据，我信心满满地敲下启动命令，Loss曲线却从一开始就对不上，最后测试集上F1差出去将近8个百分点。

这个场景相信很多算法工程师都不陌生。AI领域的可复现性挑战，说的就是这个问题：一个实验结果，为什么很难被原作者自己、更不用说其他人重新跑出来？模型代码明明写出来了，数据集也在，论文里超参数都写了，可是别人按步骤操作下来，结果就是不稳，甚至完全不一样。

我这两年陆陆续续踩了不少这方面的坑，也慢慢建立了一套自己的“防复现翻车”流程。这篇文章把我的思考、实操方法、常见坑位和排查经验全部整理出来。适合正在做实验复现、写论文跑实验、或者在公司里反复训练模型调基线的同学，希望能帮你在“结果打架”这件事上少浪费几个星期。

1. 可复现性为什么是AI圈的“老大难”

先聊一个最容易让人沮丧的事实：可复现性差，很多时候不是某一个人的问题，而是深度学习这套技术栈本身的特点决定的。我把它拆成四个维度来看，搞清楚这四件事，你才能明白为什么实验结果会“漂”。

1.1 环境依赖：同一个模型，换了机器就跑不动

深度学习的运行环境极其敏感。Python版本、CUDA版本、cuDNN版本、PyTorch或者TensorFlow的编译方式、GCC版本、甚至OpenMP的线程库实现，任何一个环节有差异，都可能导致浮点运算结果出现微小偏差。

这些偏差在单次前向、反向传播中看起来无所谓，但在几万步迭代中被不断累积和放大，最后体现出来的就是Loss曲线轨迹不同，收敛点不同，最终指标也不同。

我印象最深的一件事：同一个模型，我用pip安装的PyTorch和同事用conda安装的PyTorch，虽然版本号一模一样，跑出来的数据就对不上。检查了半天，发现conda装的包链接的底层BLAS库和pip安装的不一样，矩阵乘法顺序变了，浮点结果自然就变了。

另一种很常见的情况是换了GPU型号之后，同样的代码结果漂移。比如在A卡上训练和N卡上训练，或者同一家厂商不同架构的卡，因为卷积算子选择不同、归约顺序不同，结果也会有差异。很多人没有意识到，所谓的“同样代码”，其实从来没有真正“同样”过。

1.2 随机性：每次训练结果都不同

深度学习训练过程本身就是随机算法的大集合。权重初始化是随机的、数据加载和shuffle是随机的、Dropout是随机的、数据增强的裁剪翻转是随机的。只要任何一环没有被固定，整个训练过程就会走向不同的轨迹。

不过这个还容易理解，真正隐蔽的是GPU计算过程中的非确定性。即使在PyTorch里设置了同样的随机种子，训练过程中有些算子在GPU上执行时也不是严格确定的。典型的就是某些并行归约操作，多个计算单元同时算一部分结果，先到先合并，合并顺序每次都可能不同，最后相加的结果就有一点微小的差异。

这一点差异在单步里可能只有小数点后很多位才有区别，但深度学习的优化过程是混沌的，初始哪怕只有一个极微小的扰动，经过几万步的迭代放大，最后模型权重可能差距相当明显。这也是为什么很多人发现“明明设置了seed，第二次跑还是不一样”。

1.3 数据和代码版本：最容易被忽视的“隐形炸弹”

实验做多了之后，最容易失控的是数据和代码的版本。

数据方面，我见过太多这样的情况：文件夹一开始叫“dataset”，然后改了预处理逻辑，新数据存成“dataset_new”，后来又改了图像尺寸，存成“dataset_final”，再后来又忘了是哪一版数据训练出当前这个模型了。数据和模型之间的对应关系一旦断裂，复现就是白日做梦。

代码方面同样如此。很多人训练脚本里写了这样几行：

transform = transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(...) ])

今天把Resize的插值方式从Bilinear改成了Bicubic，明天又把Normalize的均值方差调了一下，结果模型效果变了，但代码文件没有版本记录，到最后谁也说不清线上模型是用哪一版代码训出来的。类似的还有数据增强的顺序、文本tokenization的细节、多模态数据对齐的方式，这些隐藏逻辑才是复现的最大杀手。

1.4 记录缺失：人脑不是数据库

即使代码和数据的版本都对，还有一个致命问题：超参数没有记录清楚。

很多人的训练参数直接硬编码在脚本里。这次学习率是3e-4，下次为了调参改成了5e-5，训练完之后又改回去或者忘了改回来。等到三个月后再想复现当时的实验，打开脚本一看，根本不知道跑出那个漂亮指标的脚本到底长什么样。

我见过有人用一个叫“final_config.py”的文件记录配置，里面包含十几个版本的被注释掉的参数，没有时间戳，没有commit记录，没有任何说明。这种记录方式等于没有记录，因为人类大脑根本无法从中提取出“当时到底用的是什么”。

可复现性挑战，本质上不是某一个技术问题，而是环境管理、随机数管理、数据管理、信息管理四座大山叠加在一起形成的系统工程问题。

2. 把可复现性落到实操：四个层面的解决方案

问题拆解清楚以后，解决方案其实也就浮出水面了。我不追求那种理论上的“完美可复现”，因为深度学习这东西，想做到逐比特一致确实很难。我给自己定的标准是：让别人按照我写好的步骤，能够在一个合理范围内得到相同结论；让自己三个月后还能原样跑出同一份结果。下面这四招是我一直在用的。

2.1 固定随机种子：看似简单，门道不少

先说最基础的。固定随机种子是所有复现工作的地基，但我发现很多人固定得不够彻底。多数人只知道torch.manual_seed(42)，或者np.random.seed(42)，却不知道Python解释器的hash随机化也在影响结果。

推荐直接写一个统一的种子设置函数：

import os import random import numpy as np import torch def set_seed(seed: int = 42): random.seed(seed) os.environ["PYTHONHASHSEED"] = str(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False

这里有几个细节很多人搞不明白。先把PYTHONHASHSEED设置成固定值，是确保字符串哈希的顺序稳定；再设cudnn.deterministic = True，是告诉cuDNN只选择确定性算法；cudnn.benchmark = False是为了关闭“根据输入尺寸自动寻找最快算法”的逻辑，因为自动搜索选出来的算子在不同机器上和不同输入下可能都不一样。

不过这里要特别提醒，就当“固定种子”这件事是个保底方案，别以为加了这几行就万事大吉。它保证的是Python和大多数PyTorch算子的随机性可控，但GPU上某些并行归约操作仍然是不确定的。真要彻底固定，得给DataLoader单独生成一个torch.Generator对象：

g_cpu = torch.Generator() g_cpu.manual_seed(seed) train_loader = DataLoader( dataset, batch_size=32, shuffle=True, generator=g_cpu, num_workers=4, worker_init_fn=seed_worker )

这里面的逻辑是：DataLoader如果开了多进程加载数据，每个worker的启动顺序和样本采样顺序会受系统调度影响，不单独固定generator的话，shuffle出来的样本顺序每次都可能不同。我用这个方法解决过好几次“固定了seed结果仍然漂移”的疑难杂症。

2.2 环境锁定：从requirements到Docker

随机种子搞定之后，下一步是锁定环境。这一步很多团队做得非常粗糙，最常见的做法是写一个requirements.txt，但里面写的是torch>=2.0这种范围版本。这在可复现的角度几乎等于没写，因为2.0.0和2.0.1之间可能就差了一个修复崩溃的补丁，但浮点行为照样可能有差异。

我的建议很简单，精确到小版本：

numpy==1.24.3 torch==2.0.1 torchvision==0.15.2 transformers==4.35.2 scikit-learn==1.3.2

如果是用conda管理的环境，训练结束后顺手导出一份完整的环境快照：

conda env export > environment.yml

这个命令会把conda环境里所有包以及版本号完整导出来。虽然文件会很长，但它是你最可靠的环境还原依据。

如果项目要交付给别人复现，终极方案是直接上Docker。把整个训练环境构建成镜像，别人pull下来就能跑，从根本上绕开环境不一致的问题。我一般会在项目的根目录放一个Dockerfile，结构大概是：

FROM python:3.10-slim WORKDIR /workspace COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . .

如果涉及GPU训练，还需要在基础镜像中预装对应的CUDA版本相关的PyTorch预编译包。实际用下来，Docker不是“可选项”，而是“别人能不能顺利复现你实验”的关键一环。哪怕你自己不做，也至少应该把requirements的版本锁得死死的。

2.3 数据版本管理：给每份数据一个身份证

数据和代码同等重要，但大部分人在数据版本管理上几乎没有投入。一个很简单的做法是：为每一版数据生成一份校验清单，把每个文件的哈希值记录下来。

我用的是最朴素的命令：

find data/ -type f -print0 | sort -z | xargs -0 sha256sum > data_manifest.sha256

然后把这个.sha256文件跟代码一起提交进版本控制。以后不管谁想确认“这份数据是不是当初那份”，跑一下校验就知道了。成本几乎为零，但很多人不做。

再系统一点，可以用DVC之类的数据版本控制工具。DVC的核心理念是把数据文件的元信息（通常是一个小的.dvc文件）提交进Git，实际的大文件放到本地磁盘或远端存储。这样切代码分支的时候，数据也跟着切换版本，模型、代码、数据的对应关系就固定下来了。

还有一个实操中非常重要的点：所有数据预处理必须脚本化。千万不要手工改数据，今天手动删除几行，明天在Photoshop里旋转一批图片。只要是人手工动过的数据，就没有任何复现的可能。我自己要求项目里所有数据从原始格式到训练格式之间，必须有一条可执行的pipeline命令，任何人拿到原始数据，运行同一个命令，能生成完全一样的训练数据。

2.4 实验记录规范：让一切有迹可循

最后是实验信息管理。我见过太多人训完模型就只保存一个model.pth，至于这个模型是用什么超参数、什么数据处理方式、哪一段代码训出来的，全部不记录。这种习惯不改，可复现性无从谈起。

我的做法是把所有超参数写进一个独立的配置文件，用最常见的YAML格式：

experiment_name: baseline_v3 seed: 42 dataset: name: image_cls version: data_manifest_20240601.sha256 train_path: /data/train model: name: resnet50 dropout: 0.2 training: epochs: 30 batch_size: 64 lr: 1e-3 weight_decay: 1e-4 scheduler: cosine warmup_epochs: 3

训练脚本启动的时候只读取这个配置文件，不把参数写在代码里。训练结束之后，把这份yaml文件连同最终模型一起保存，文件名带上实验ID。

实验ID建议用带时间戳的随机串，比如baseline_20240601_1530_a3f2这种。模型保存目录结构可以设计成：

runs/ ├── baseline_20240601_1530_a3f2/ │ ├── config.yaml │ ├── model_best.pth │ ├── train.log │ ├── metrics.json │ └── git_commit.txt

git_commit.txt里记录当前代码的commit hash，这样就算代码后来改得面目全非，也能随时切回当初那个版本。如果你用更专业的实验管理工具，比如MLflow或者Weights & Biases，这些信息会被自动收集下来，查起来更方便，但原理和上面说的完全一致。

3. 复现实验的完整流程与关键节点

前面说的更多是“静态的规范”，接下来我想把一次完整的、具备可复现性的训练实验从头到尾走一遍，包括每一个关键节点需要做哪些动作。这部分非常实操，可以直接照着搭。

3.1 一套标准的可复现训练流程

我现在的标准流程大概是下面这个顺序。

第一步，先初始化环境。从conda创建一个干净环境，然后严格按照.yaml锁定的版本安装依赖。这个时候不要图省事用pip install -r requirements.txt之外的手段手动装环境，任何手动安装都可能引入没记录在案的差异。

第二步，固定随机种子。调用前面写的set_seed函数，实测下来这个函数能够解决95%以上的“同一个脚本跑两次结果不同”问题。

第三步，确认数据版本。训练启动前先跑一遍数据校验：

sha256sum -c data_manifest.sha256

如果校验失败，说明当前数据跟当初记录的不是同一份，这时候就必须停下，而不是心存侥幸继续训练。

第四步，启动训练并记录所有信息。我把训练脚本写成支持传入一个配置文件的入口形式，大致如下：

python train.py --config configs/baseline_v3.yaml

训练脚本内部会把配置文件、commit hash、命令行参数、硬件环境等信息全部记录下来，然后在输出目录下生成当次运行的快照。

第五步，训练过程中定期做检查和存档。每训练完一个epoch，记录下当前的评估指标；每5个epoch保存一次checkpoint；每个checkpoint都要在内部写入当时的超参数和epoch序号。这样万一后面发现某个中间结果特别好，也能回头去找对应状态。

第六步，训练结束后，把最终的模型、配置、指标、日志整合成完整的run目录。然后我在本地记一个简单的索引表，里面包含实验ID、日期、目标指标、备注信息。这个索引表就是我的“实验档案库”，三个月后翻它，总能在30秒内定位到任何一次实验的完整信息。

3.2 超参数和配置管理的实操细节

关于超参数管理，我要特别强调一个很多人会忽略的细节：配置文件必须保存在“当次运行”的目录里，而不是只在总目录里保留一份。

举个例子，你的项目下有一个configs/文件夹，里面存着各个实验的配置。如果你把配置文件改了，但忘了存档，那原配置就被覆盖了。所以我要求train脚本启动时，必须把配置文件复制一份到当次运行目录：

cp configs/baseline_v3.yaml runs/baseline_20240601_1530_a3f2/config.yaml

这看起来很简单，却救过我很多次。有一次我把baseline的配置改成实验配置之后，忘记备份，原配置文件被覆盖，导致无法复现基准实验。从那以后，这个“运行时复制配置”的动作被我固定成流程的一部分，不加都不行。

另一个细节跟随机种子有关。同样的超参数下，不同seed的结果会有波动。我建议每个关键配置至少跑3个seed，取均值和方差来评估，而不是一个seed定生死。这也算是从“能复现”到“结论可信”的一个跨越。

3.3 结果对比与稳定性评估

当你可以稳定复现同一个实验后，下一个挑战是：如何判断“这次复现成功”？

我见过有人复现别人的开源项目，跑出来指标比论文低0.5个点就大喊“复现失败”。但实际上0.5个点可能完全在随机波动范围内。很多时候不是人家论文造假，而是你只跑了一个seed，运气不够好。

正确的做法是把复现结果看作一个分布，而不是一个精确值。比如我复现某个模型的图像分类准确率，我会跑5个不同的seed，记录各自的准确率，然后比较“均值±标准差”。如果原论文报告是88.2%，我复现出来是87.9%±0.4%，那基本可以判定复现成功，因为差异在噪声范围内。

这样一组结果算出来，均值是87.94%，标准差约0.29%。原论文的88.2%落在这个范围内，那就可以放心地说结果可复现。

要注意的是，如果多个seed之间波动已经大于模型之间的差距，那“我比你高0.2个点”这种结论就完全没有统计意义。这个认知在做模型对比时非常关键，否则你会花大量精力去调一个只是运气好的配置。

4. 常见问题与排查技巧实录

在把可复现流程跑顺之前，我遇到过非常多的诡异问题。这部分我把最典型的几个问题、排查思路和处理方法整理成一个速查表，再挑几个重点展开讲。

4.1 最典型的“坑”：固定了种子还是不稳定

这个问题我遇到不下5次。排查看下来有两种主要情况。

第一种是DataLoader的问题。我给工位旁边的小朋友调过一次模型，他信誓旦旦说已经固定了所有种子，但每次跑出来的指标都会跳。我帮他检查后发现，他给的DataLoader配置里num_workers大于0，但没有给每个worker设置固定的随机种子。多进程加载时，每个worker的shuffle状态是独立的，主进程的种子固定了，worker内部的顺序却没有。

解决办法就是前面提到的，给DataLoader单独创建一个generator，或者设置一个worker_init_fn：

def seed_worker(worker_id: int): np.random.seed(seed + worker_id) random.seed(seed + worker_id)

第二种是非确定性GPU算子。这个比较难排查，因为只有某些特定操作才会触发。常见的元凶包括某些形态学操作、插值操作、以及部分损失函数的并行归约实现。可以用PyTorch的torch.use_deterministic_algorithms(True)来强制程序报错并提示哪些算子非确定，然后针对性替换或绕开。

4.2 复现别人的论文：从源码开始，而不是从论文开始

论文复现这件事，单独的坑就够写一篇文章。核心原则是：尽量找到作者公开发布的实现代码，以代码为准，论文为参考。论文里写的参数一般都会简化，或者漏掉细节，这些细节恰恰决定实验结果。

我复现过某篇知名度很高的图像分类论文。按照论文给的超参数去跑，准确率总是差2个多点。后来去看官方开源代码，发现源码里的数据增强多了一个细节——随机擦除的概率是0.25，而论文里完全没提。加上这个细节之后，结果一下就对齐了。

所以在复现别人工作的时候，我建议按下面的优先级来排查：

1. 环境是否一致，尤其是PyTorch/CUDA/torchvision版本；
2. 数据预处理和增强是否完全一致；
3. epoch数、batch size、学习率调度是否一致；
4. 是否漏掉了EMA、梯度裁剪等隐藏设计。

项目主页的issue区往往藏着大量“复现对不上”的讨论，别人踩过的坑很可能就是你正要踩的。我每次复现一个新项目，都会先花半小时浏览issue区的高赞问题，收益远超想象。

4.3 排查技巧：让实验“开口说话”

排查问题的时候，最怕的是信息不完整。为了少走弯路，我给自己定了一条规矩：任何一次实验，都要能拿出完整三件套——当次运行的完整日志、精确的依赖环境列表、以及代码commit hash。

很多“复现不了”的问题，最后查下来都是这三个信息缺失导致的。比如有人找我说“我的代码跑不出和以前一样的结果了”，但问他是哪一次结果、当初用的什么环境、代码有没有改动，全都不记得。这种情况下，再厉害的调试技巧也救不了。

我现在每次启动训练都会自动生成一份环境报告：

import platform import torch import sys with open("run_environment.txt", "w") as f: f.write(f"platform: {platform.platform()}\n") f.write(f"python: {sys.version}\n") f.write(f"pytorch: {torch.__version__}\n") f.write(f"cuda_available: {torch.cuda.is_available()}\n") if torch.cuda.is_available(): f.write(f"gpu: {torch.cuda.get_device_name(0)}\n")

几十行代码的成本，换来的是排查问题时的一个可靠坐标。

5. 只做到“能复现”还不够

走到这个程度，“复现出同样的结果”已经不是问题。但我想再往前推一步，聊一聊对可复现性更深一层的要求。

5.1 从“结果复现”到“结论稳健”

很多人在做实验对比的时候，只跑了一个seed，然后拿一个指标就下结论：A模型比B模型高0.5个百分点，所以A更好。

这个结论在严格的科学研究视角下是非常脆弱的。如果B模型换一个seed比A还高0.8个百分点呢？两个模型的真实差距可能只是噪声。

可复现性挑战的深层含义，不仅仅是“能不能重新跑出来”，还包括“这个结论是否在合理扰动下依然成立”。我在自己项目里已经习惯性地把所有关键对比实验都跑至少3个seed，并报告均值±标准差。遇到两个方案指标差距小于标准差的情况，我会明确注明“差异不显著”，绝不硬吹某一个方案更好。

这么做一开始会觉得自己“亏了”，因为有些实验结论不再那么漂亮。但从长期看，这种“敢于报告不确定性”的方式，反而让结果更可信。无论是内部评审还是对外公布，数据更禁得起追问。

5.2 可复现性带来的长期价值

最后聊点实际的。养成可复现的习惯，短期看起来是“多花了时间”——固定环境要花时间，记录配置要花时间，跑多个seed要花时间。但这些时间投入到长期来看，回报极其可观。

我最大的体会是：可复现性本质上是在对抗“历史债务”。每次实验都留好完整记录，两个月后接新需求，你只需要对着记录把曾经的效果找回来，而不是从头调参调上两星期。每次模型上线之后被人质疑“这个指标怎么来的”，你能30秒之内拿出完整证据链，而不是语焉不详地解释“当时好像效果不错”。

如果你现在正被“结果复现不出来”折磨，我给一个最小可行的起步建议：从下次训练开始，在代码里加set_seed()这一步；训练结束之后，把配置文件复制一份和模型放在一起。就这么简单，先做起来，后面再逐步补全环境锁定、数据版本管理那一套。

我自己也是在踩了无数个“复现不出来”的坑之后，才痛定思痛把流程固定下来的。现在回头看，真正让我工作轻松起来的，不是什么高深的算法能力，而是这些看起来不起眼、但每一步都在消除不确定性的小习惯。你可能要控制一下自己“先跑起来再说”的冲动，多花10分钟记录，换来的是一整个季度的省心，这笔账无论如何都划算。