★ FEATURED ARTICLE 我见过太多类似的一幕论文里写着87.3%的准确率项目代码就挂在开源仓库里可你把完整流程跑完拿到手的却只有84.6%。这就是“AI的可复现性挑战The AI Reproducibility Challenge”最真实的写照——它不是一个框架的Bug也不只是“忘记设置随机种子”这种细节问题而是环境、数据、训练过程和评测口径之间一套复杂的联动工程。这篇分享不讲大话只想回答一个实际问题当你说“我的实验能复现”时你到底需要锁住哪些东西我自己在多个项目里反复踩过坑也帮同行排查过不少“复现失败”的案例下面写的基本都是能直接照着做的方法。适合正在做深度学习实验的研究者、需要把模型交接给同事的算法工程师以及那些被“别人跑不出你的结果”折磨过的朋友。1. 可复现性挑战到底在“挑战”什么1.1 从“跑不通”到“跑得通但数字对不上”很多人以为可复现性挑战就是“代码跑不通”。真跑起来才发现更普遍也更折磨人的情况是代码能跑指标也能出但出的数字和原报告差了一截。要定位这个差异得先把可复现的几个层次分清楚。层次含义我遇到的典型场景可重复同一脚本在同一台机器上多跑几次结果稳定一致本地连续复跑同一个训练脚本可复现代码和环境保持不变在另一台机器上能跑出可比指标同事拿到你的仓库换一台机器重跑实验可迁移环境、硬件有变化时实验的相对结论仍然成立换一批显卡、升级一个Python包后模型对比的优劣不变很多“复现失败”并不是第一层出了问题而是卡在第二层和第三层。换句话说自己机器上怎么跑都稳定一换机器、一换环境数字就开始漂。漂得少还可以用随机性解释漂得多就会直接动摇结论。1.2 为什么AI项目尤其容易“翻车”在复现上AI项目的复现难度比传统软件开发高很多核心原因是整个流程里塞满了“隐性状态”。传统程序输入固定、逻辑确定输出大概率可预期但一个深度学习实验至少包含数据增强的顺序、模型初始化的随机源、训练时的浮点累加顺序、验证集的评测细节——任何一环没被记录别人就只能在猜测中复现。我印象很深的是一次做图像分类基线复现论文报告了83.2%的准确率我严格按正文描述跑出来只有80.1%。折腾了两天才发现对方训练代码里额外启了一组数据增强还在测试阶段开了测试时增强而这两条都没有写进论文正文。这种“隐藏步骤”就是可复现性挑战最典型的来源。所以我把可复现性挑战理解为一份实验记录能否让一个理性、细心的第三方在合理时间内重建出与原文接近的结论。它考验的不是某个人的记忆而是实验报告的系统性和完备性。2. 随机种子固定了但没有完全固定2.1 一通操作该锁的都锁了为什么结果还是漂应对随机性绝大多数人的第一反应是设随机种子。这当然没有错PyTorch项目里我一般会写这样一段import random import numpy as np import torch def set_seed(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这段代码能解决Python内置随机、NumPy随机和PyTorch随机这三条主链路但它并没有“锁死”所有随机性来源。实测下来以下几个地方照样会让结果漂移随机性来源锁定方法翻车场景Pythonrandomrandom.seed(seed)数据顺序敏感的流程NumPynp.random.seed(seed)参数初始化、采样PyTorch CPU/GPUtorch.manual_seed/torch.cuda.manual_seed_all模型初始化、dropoutDataLoader 多进程worker 内设置种子或设num_workers0数据加载顺序随机化非确定性算子部分GPU算子如原子加法、scatter等特定网络层浮点累计顺序变化真正让“固定了种子还是不固定”的元凶主要是三类第一类是DataLoader的worker进程shuffle在多个子进程里并行执行随机数生成器的状态很难完全一致第二类是非确定性GPU算子它们在底层涉及到并行原子操作小数值的累加顺序每次可能不同第三类是混合精度训练FP16的截断和累加顺序变化会让loss和梯度发生微小但可观察的差异。我做过一个很直观的测试在完全相同的代码、完全相同的种子上同一台机器、同一张显卡连续跑5次。结果最好的情况和最差的情况验证集准确率能差0.4个百分点。这个幅度在很多论文里已经足以改变一个“消融实验”的结论。2.2 把“多次运行”当作正确的复现粒度既然固定种子不能做到bit级稳定那就不能把“单次运行结果”当作唯一的复现基准。我现在更倾向一套“多种子”的实践同一个配置至少跑3到5个不同种子报告均值加减标准差而不是只报最好的一次。原因很简单。神经网络训练本质上是带随机性的统计过程单次运行只是一个随机样本。假设你比较A模型和B模型A在seed0下比B高0.5个点但把种子换成1、2、3之后A可能反而低0.3个点——这时候单次结果没有任何说服力。只有看多个种子的均值和方差才能判断差异是来自模型本身还是来自运气。我踩过一次很深刻的教训在某分类项目里比较两个结构时单次运行显示新结构比基线高0.3个点我以为捡到了便宜结果补跑4个种子后发现新结构的均值反而略低之前完全是被随机种子“选中”了。从那以后我的经验是固定种子只是为了加速调试和保证单机可重复最终结论一定要用多seed验证。若多个seed在不同机器上仍能保持排序一致这才算真正“复现成功”。3. 环境指纹与数据版本两个“看着小实则致命”的变量3.1 环境证明不止是 requirements.txt可复现性挑战里最“阴”的一类问题来自环境漂移。很多人会用pip freeze requirements.txt记录环境但这个文件的问题在于它只锁定直接安装的包不一定能锁住依赖树里所有子依赖而且一旦某个子依赖版本悄悄变化结果就可能不同。更常见的场景是三个月前跑实验时用的是torch 1.13三个月后新环境装成了2.1结果同样的代码、同样的数据指标降了1.2个点。你以为代码坏了其实是底层算子的数值实现变了。这类问题在图像领域特别明显因为OpenCV、Pillow这些图像库即使主版本号不变次版本的插值算法和像素处理细节也会影响数据读取。我现在的环境记录标准按严格程度分三档最低要求记录conda env export或requirements.txt并注明安装日期。推荐做法用conda-lock或uv生成完整的锁定文件确保依赖可以被原样重建。终极方案每次实验用Docker镜像保存完整环境并给镜像打上“实验名日期”的tag镜像保留在内部仓库里。第三档听着麻烦但遇到过一个惨痛教训之后我就认了。某个项目训练完当时图省事没有留存镜像三个月后想复现完整结果发现基础镜像的latesttag已经被新镜像覆盖老依赖无论如何都装不回来只能一点一点猜。所以我的原则是镜像可以不用但训练结束前一定docker commit并保留一个有辨识度的tag。3.2 数据版本的确定性与数据污染环境之外数据也是复现失败的高发区。这里说的不只是“图片文件变了”这种明显情况还有一些非常隐蔽的坑。首先同一个数据文件用不同库读取可能得到不同内容。比如同一张JPEG图片Pillow和OpenCV读出来的RGB通道顺序和像素插值结果就不完全一样。如果你的训练代码里固定用Pillow而复现时换成了OpenCV模型看到的数据已经悄悄改变了。其次数据集的划分也要被当成“数据版本”的一部分。训练集、验证集、测试集的划分如果依赖某个随机数生成器那么生成器的种子也必须记录否则你无法确认别人复现时用的验证集和你用的验证集是不是同一批图片。更严重的是数据污染。我帮某开发者复查过一个图像分类项目对方报告新版本模型提升了1.5个点但排查下来发现新数据集的构建脚本不小心把一部分旧验证集图片复制进了新训练集。模型等于见过“测试答案”指标自然虚高。换成干净的划分后提升基本消失。这类问题的排查方法并不复杂对数据文件计算校验值并记录在实验日志中或者直接用DVC这样的工具做数据版本管理。数据量大时不必全员上DVC但至少要有“数据快照文件指纹”的思路。我现在的习惯是每份数据都生成一份data_manifest.txt记录文件数量、总大小和整体MD5训练前先校验一遍再开始。4. 评测口径结果明明跑出来了为什么对不上4.1 一个指标多种算法源码、环境、数据全都对上了还有最后一道坎评测口径。很多“复现不出原论文结果”的情况最后发现是双方计算指标的代码不一致。这一点在分类任务里尤其常见。同样是准确率有的实现是“所有样本里预测正确的占比”有的实现是“每一类先算准确率再取平均”。在类别不均衡的数据上这两个数字可能相差一个百分点以上。同理F1分数有micro和macro之分多标签分类还有不同的阈值选取方式这些都会改变最终数字。还有一个高频问题出在checkpoint的选择规则上。训练时你可能会看验证集指标然后取“最优epoch”的模型但报告里如果只写“最终准确率”别人复现时通常会取最后一个epoch的模型。偶尔这两个checkpoint相差好几个epoch指标自然不一致。所以每次实验记录里至少要写明两件事选checkpoint的规则、以及选了第几个epoch。测试阶段的细节同样不能漏。训练时开了数据增强测试时是否关闭这一点很多人会忘记加model.eval()或者测试时是否做TTA测试时增强都会直接影响最终指标。真实复现时对方如果不知道你评测时做了什么预处理哪怕训练部分完全一致数字也不一样。4.2 写给三个月后的自己最小可复现信息清单为了避开评测口径的坑我建议把下面这张表当成实验收尾的“最低配置”。每次训练结束前把字段填完存进一个REPRODUCE.md放在实验目录里。记录项示例训练命令python train.py --config exp_0425.yaml代码库 commitgit rev-parse HEAD环境镜像或依赖锁docker img:exp-2024-0425或env.yml数据集版本data_manifest.txt的 MD5随机种子0, 1, 2, 3, 4检查点选择规则验证集最优epoch47评测脚本版本eval.pycommit硬件与GPU驱动A100 某版本驱动最终指标验证集准确率 84.72±0.13这张表看起来平平无奇但它能解决实际复现中的九成问题。我有一个习惯把评测脚本和训练脚本放在同一个仓库里入口命令统一避免“训练脚本用一版评测脚本用另一版”这种混乱。别小看这点很多人复现失败最后定位到的原因就是评测脚本改了轮次、忘了记录。5. 从一次“复现失败”里提炼出的检查流程5.1 一次真实翻车的完整排查链路我在帮某开发者复查一个图像分类项目时对方很郁闷地说“我用你记录的流程重新跑了一遍结果只有线上模型报的80%都不到。”我们当时一起排查过程大致是这样的。第一步先比对代码版本。git rev-parse HEAD一查发现线上模型所在的commit和当前检查分支的commit差了13个版本中间经历了多次重构。这是复现失败最常见的原因先排除它总没错。第二步检查环境。对方用pip freeze比对时发现torch版本已经从1.13变成了2.1虽然代码没有使用新API但算子的底层实现已经变化。我们把环境切换回旧版本后部分指标差距就缩小了。第三步校验数据。我们算了一遍数据集的MD5结果发现和原始记录对不上。进一步检查目录结构后问题更严重验证集目录里混进了一部分训练集图片。这说明数据构建脚本在某个环节跑错了一次。把数据重新清理并锁定版本后对方的复现指标恢复了。这次排查里没有用到任何复杂工具就是靠着“代码版本、环境版本、数据版本、评测口径”四项逐一核对。排查顺序很关键先看代码commit再看环境依赖然后校验数据最后检查评测逻辑。如果一开始就去调模型参数那只会越调越乱。5.2 我现在的标准流程与工具取舍经过那次折腾后我把自己的标准流程固定下来了。每次实验开始前先建独立的实验目录目录里预置好REPRODUCE.md模板训练命令、代码commit、环境信息、数据校验值、种子列表、最终指标全部写进去。目录结构大体长这样experiment_0425/ ├── config.yaml ├── train.log ├── eval.log └── REPRODUCE.md训练结束后立刻生成一份run.sh作为复现入口脚本里除了命令本身还要输出环境指纹#!/usr/bin/env bash set -euo pipefail LOG_DIR$(pwd) echo commit: $(git rev-parse HEAD) $LOG_DIR/reproduce.txt echo env: $(conda env export -n $CONDA_DEFAULT_ENV) $LOG_DIR/reproduce.txt echo seed: $SEED $LOG_DIR/reproduce.txt nvidia-smi --query-gpuname,driver_version --formatcsv $LOG_DIR/reproduce.txt说到工具我的观点是不要为了用而用。DVC适合管大数据集MLflow或WB适合团队记录指标。如果团队规模不大一个规范实验目录加一份REPRODUCE.md已经能覆盖大部分需求。基建再漂亮如果没人填记录一样等于零。5.3 最后一点个人感受可复现性挑战不是某个人的能力问题它本质上是一套实验习惯的沉淀问题。我现在的习惯是动手做任何实验前先问自己一句三个月后回来我最需要知道什么把这个问题的答案写进REPRODUCE.md每一步操作都留痕。这样复现才真正从“别人的挑战”变成了固化的流程。这确实不浪漫也不尖端但它是让AI实验结果真正经得起检验的底层功夫。很多花哨的技术最终会被时间淘汰而“能被人重建的实验记录”永远是资产。
阅读完成 · 觉得有帮助？
