想象你是奶奶家最会做红烧肉的传人。亲戚们都说你的手艺绝了，可他们回到自己家照着记忆复刻，端出来的根本不是那个味道——因为奶奶的菜谱上写的是“盐少许”“料酒适量”“焖至入味”。少许是多少？适量是几勺？入味要到什么程度？每个人心里都有一套自己的答案。AI 实验和红烧肉一模一样：你论文里的模型效果惊艳，代码也开源在 GitHub 上，可别人 clone 下来一跑，数字对不上。不是你骗人，而是你的“菜谱”里藏了太多“少许”和“适量”——随机种子没写、依赖版本没锁、环境没有固化。可复现性，就是把含糊的“少许”变成精确的“盐 6 克、冰糖 15 克、生抽 30 毫升”，让任何一个厨房都能端出同一道菜。

岗位关联

对 AI 从业者来说，可复现性不是锦上添花的修养，而是科研诚信的底线：它决定你的结果是“可验证的知识”还是“一次性的巧合”，直接影响论文录用、团队协作与模型迭代的信任基础。

目录
  1. 可视化演示
  2. 可复现性概念
  3. 版本控制
  4. 随机种子固定
  5. 环境锁定
  6. Docker容器化
  7. 配置与自动化
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示AI研究可复现性保障流程从版本控制到Docker容器化的完整链路、随机种子多源固定机制及环境锁定策略，切换模式掌握复现性核心要点。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI实验可复现性保障流程 版本控制锁定代码版本，随机种子固定随机性，环境锁定依赖版本，Docker封装运行环境 每一步都不可或缺，缺少任何环节都可能导致结果不可复现 Code + Seed + Env + Docker = Reproducible 可复现性是科研诚信的底线和AI研究可信度的基石

可复现性概念

我家传了三代的红烧肉，只有一个版本能原样复刻，因为奶奶把菜谱写成了精确配方：盐 6 克、冰糖 15 克、生抽 30 毫升、电磁炉 1300 瓦炖 40 分钟。而亲戚们的“记忆版菜谱”全是“少许、适量、入味”，端出来的自然南辕北辙。AI 论文就是一份菜谱，可复现性就是检验这份菜谱是否真的能“在别人的厨房里复刻出同一个味道”。

学术界的“可复现性”定义很朴素：给定同一位作者公开的代码、数据与运行环境，另一位研究者能独立跑出论文中报告的核心指标。2016 年《自然》杂志的一项调查显示，超过七成研究人员无法复现他人的实验——这就是著名的“复现危机”。它不代表大家都在造假，而是说明很多论文的“菜谱”根本没有精确到可以照做。

一个实验结果从来不是凭空冒出来的，而是三个变量共同作用的结果：代码定义了模型和训练流程，数据决定了学习内容的分布，环境（依赖库版本、硬件、驱动的组合）决定了每一步计算的细节。三者中任何一个和论文不一致，数字就可能对不上。可复现性差，本质上是知识的传递链路断了——别人无法验证你的结论，也就无法信赖你的结论。

把“结果”想象成红烧肉的入口口感：菜谱、食材、灶具三者缺一不可。奶奶能复刻，是因为她把三个自变量都写死了；你的实验能被复现，同样得把代码、数据、环境这三样“端到别人面前”。

结果=F(代码, 数据, 环境)\displaystyle \text{结果} = F(\text{代码},\ \text{数据},\ \text{环境})
这个等式说：实验结果不再是“玄学”，而是代码、数据、环境这三个输入经过实验流程函数后的确定输出。
  1. 结果论文中汇报的一切数字与指标，它是整道菜出锅时的“口感”：
    RR
  2. 实验流水线函数数据预处理、模型训练、评估推理串起来的一条完整流水线：
    F(⋅)F(\cdot)
  3. 三个自变量代码、数据、环境共同决定结果，任何一个与论文不一致，结果都可能对不上：
    (代码, 数据, 环境)(\text{代码},\ \text{数据},\ \text{环境})
  4. 等式的复现含义想得到相同结果，就必须把右边三个输入原样交给另一个人：
    R′=F(代码′, 数据′, 环境′)R' = F(\text{代码}',\ \text{数据}',\ \text{环境}')

版本控制

奶奶的厨房里有一本“菜谱账本”，每改一次配方都要记一行：哪年哪月把冰糖从 20 克减到 15 克，因为那年她查出血糖偏高。所以无论后来配方怎么演化，全家人都能翻回 2018 年中秋节那锅肉的味道——这就是版本控制。代码比菜谱更容易“悄悄改变”：今天改了数据清洗逻辑，明天调了学习率，后天换了损失函数。AI 实验最怕的就是“出结果时想不起是哪个版本的代码跑出来的”。

Git 就是科研人员的菜谱账本，它记录每一次改动，并为每一次改动生成一个独一无二的哈希值（commit hash）。每次提交等于一份完整快照，里面包着当前所有文件的指纹、父提交的哈希，以及你写的提交信息。三样东西搅在一起算出来的哈希，就是这版代码的“身份证号”。你说“我用 c3 跑出了 91.4% 的准确率”，别人就能精确拿到同一份代码，而不是猜你指的是哪一版。

实践中有三条纪律：第一，小步提交，每次只改一件事，提交信息写清“为什么改”，而不是“改了一下”；第二，跑重要实验前打一个 tag，比如 v1.0-release，方便日后精确定位；第三，做一张实验日志表，把每次实验的 commit 哈希、启动命令、关键指标记在一起。这样拿到一张结果表，就能反查“这道菜出自哪一版菜谱”。

下次开会别人问“你这版结果怎么来的”，你翻出账本：某年某月某 commit，清清楚楚。这比“好像是上上周跑的那版”有说服力得多。

commit=SHA1(快照∥父提交∥提交信息)\displaystyle \text{commit} = \mathrm{SHA1}(\text{快照} \mathbin{\|} \text{父提交} \mathbin{\|} \text{提交信息})
提交哈希是把“快照、父提交、提交信息”三段内容搅在一起后算出的指纹，任何人改动一个字符，指纹都会彻底改变。
  1. commit（提交）菜谱账本里的一行记录，代表某个时刻代码的完整状态：
    CC
  2. SHA1 哈希一段指纹算法，把任意内容压缩成 40 位十六进制，内容差一个字符指纹就完全不同：
    SHA1(⋅)\mathrm{SHA1}(\cdot)
  3. 快照与父提交当前文件树快照拼接上父提交哈希，新提交的身份由它们共同推出：
    S∥PS \mathbin{\|} P
  4. 提交信息人写的改动说明，例如“降低学习率并修复数据清洗 bug”，是留给未来自己的线索：
    MM

随机种子固定

奶奶做红烧肉有个祖传仪式：搅拌时一定顺时针转三圈。小时候以为那是玄学，后来才明白，那是把操作顺序固定下来——如果哪次手一抖先放了生抽、再放糖，口感就飘了。训练 AI 也有这种“手抖”：随机性在训练流程里无处不在，而随机种子就是给手装上的稳定器。

计算机的“随机数”其实不是真随机，它是从一个初值出发、按固定规则生成的一串数字。只要初值相同，这串数字就完全相同。在代码里写 seed=42，等于告诉计算机：“从第 42 个动作开始，每一步都照着剧本走。”模型初始化参数、数据打乱顺序、dropout 的掩码，全部来自这串剧本数字。这样两次训练拿到的“手气”一模一样，训练曲线自然就重合了。

千万注意：深度学习里有多个独立的随机源——Python 内置的 random、NumPy 的 np.random、PyTorch 的 torch.manual_seed、TensorFlow 的 set_random_seed，还有数据加载器的 shuffle 以及多进程 worker 的随机数。只固定其中一个，其他水龙头照样漏水。标准做法是写一个 set_seed 函数统一固定所有源，必要时还要设置 PYTHONHASHSEED 环境变量，把字符串哈希也钉死。

固定种子解决的是“厨师手不抖”：同一个厨师、同一份配方、同样的操作顺序，两次做出来的肉才可能是同一个味道。但请注意——手不抖只是第一步，锅没换、料没变同样重要，这正是后面两节的事。

xn+1=(a⋅xn+c) mod m\displaystyle x_{n+1} = (a \cdot x_n + c) \bmod m
这是经典随机数生成器（LCG）的递推公式：给定同一个种子 x₀，后面生成的整串随机数必然完全相同。
  1. 种子 x₀随机数序列的初始值，seed=42 就是把起点定在第 42 号动作：
    x0=seedx_0 = \text{seed}
  2. 递推规则下一个随机数由上一个严格计算得出，中间没有任何“自由发挥”：
    xn+1=f(xn)x_{n+1} = f(x_n)
  3. 固定参数 a、c、m算法内置的常数，它们让序列在统计上“像随机”，但对同样的初值永远给出同样的轨迹：
    a,c,ma, c, m
  4. 同种子同序列起点相同、规则相同，整条数列必然相同——厨师手不抖的关键：
    seed=s⇒∀n, xn 一致\text{seed} = s \Rightarrow \forall n,\ x_n \text{ 一致}

环境锁定

菜谱上写“盐少许”，十个家庭有十个“少许”；写“中盐深井盐 6 克”，所有厨房都能精确复刻。代码依赖库也是一样：numpy>=1.20 是“一撮盐”，numpy==1.24.3 才是“盐 6 克”。版本差一位小数字，行为可能天差地别——某个 API 的默认参数变了，某个算子在特定长度下有 bug，都会让训练曲线悄悄变形。

AI 项目的依赖是一张密密麻麻的网：Python 版本、NumPy、PyTorch、transformers、CUDA……任何一个库的版本漂移，都可能改变数值计算结果。所以复现要求“环境锁定”：把每个关键依赖钉死在精确版本上，而不是留一个区间让别人猜。锁定的范围越窄，复现的厨房就越多；精确到点，全世界都能做出同一锅肉。

实操上有三个层次：第一层，手工维护一份精简的 requirements.txt，只写核心直接依赖加精确版本号；第二层，用 pip freeze 或 conda env export 生成全量快照作为二级保险，记录下所有间接依赖；第三层，把 Python 版本和 CUDA 版本也写进文档。如果你的实验涉及系统级依赖，最好直接把这些东西一起打包成 Docker 镜像——那才是真正意义上的“带着配料表上门”。

当别人拿到你的项目，pip install 时不再需要猜“少许”到底是多少。依赖版本从“范围”收成“点”，复现的厨房从几家变成全世界。

[1.0, 2.0)⟶1.2.3\displaystyle [1.0,\ 2.0) \longrightarrow 1.2.3
环境锁定的本质，就是把一个“装哪个版本都行”的范围约束，收敛成一个“必须是它”的精确版本点。
  1. 版本区间numpy>=1.0,<2.0 允许安装无数个版本，每个版本的行为都可能不同：
    [1.0, 2.0)[1.0,\ 2.0)
  2. 精确锁点numpy==1.2.3 把不确定性收敛到一个点上：
    1.2.31.2.3
  3. 箭头转换环境锁定的本质，就是把“一撮盐”翻译成“盐 6 克”：
    范围约束→精确版本\text{范围约束} \to \text{精确版本}

Docker容器化

菜谱精确到克，就能在所有厨房复刻吗？不行——隔壁用的是铁锅，你家用的是不粘锅；隔壁是燃气灶，你家是电磁炉。导热差异照样让肉糊一层。最稳妥的办法是把整套厨房装进集装箱，到你家直接把集装箱接上水电。Docker 就是这样一间“带轮子的标准厨房”。

Docker 用镜像（image）打包整个运行环境：操作系统基础层、系统依赖、Python 库、项目代码，全部封进一个只读模板。从镜像启动一个容器（container），就是在这间标准厨房里开火。别人不关心你的代码在他机器上会不会缺库，因为镜像里已经自带一切。镜像由一层层不可变的内容叠加而成，每一层都有哈希，任何人 pull 下来的都是同一间厨房。

写 Dockerfile 就像写厨房搭建说明书：FROM 指定基础镜像（选什么锅）、RUN 安装依赖（备料）、COPY 把代码拷进镜像（把菜放上案板）、CMD 声明启动命令（开火）。构建好的镜像推到镜像仓库（如 Docker Hub），同事执行 docker pull 就能原样运行。论文附录里放一行镜像地址，比写三段“环境配置说明”可靠得多。

有了集装箱，论文的“环境”部分从一段含糊描述变成一行 docker pull 命令。奶奶的菜谱从此可以连锅带灶一起打包，端出来的味道，终于不再取决于谁家的灶台。

镜像=BUILD(FROM, RUN, COPY, CMD)\displaystyle \text{镜像} = \text{BUILD}(\text{FROM},\ \text{RUN},\ \text{COPY},\ \text{CMD})
Dockerfile 的四个核心指令，分别对应搭厨房的四件事：选锅、备料、上案板、开火，最终产出一个只读的镜像。
  1. 镜像一个只读的大集装箱，装好了操作系统、依赖与代码，任何人拿到它都等于拿到同一间厨房：
    II
  2. FROM选定基础镜像，决定这间厨房用哪口锅：
    FROM python:3.10-slim\text{FROM}\ \text{python:3.10-slim}
  3. RUN 与 COPYRUN 负责安装依赖（备料），COPY 把代码放上案板：
    RUN pip install -r requirements.txt\text{RUN}\ \text{pip install -r requirements.txt}
  4. CMD声明容器启动时执行的命令，也就是“开火”信号：
    CMD [python, train.py]\text{CMD}\ [\text{python},\ \text{train.py}]

配置与自动化

全家人都抄了奶奶的配方，唯独堂姐做得最像。差别不在手艺，而在她把这套流程做成了一张“傻瓜流程卡”：几点泡肉、几点下锅、几点关火、用哪个锅、每一步的预期颜色，全部写死，闭着眼照做。AI 研究也需要这样一张流程卡——这就是配置与自动化。

配置文件（如 YAML）记录一切“不该被猜”的信息：数据路径与版本、模型结构、全部超参数、随机种子、实验编号。训练脚本只负责执行，不藏任何隐含默认值。别人拿到项目后，不需要问你“学习率是多少”“用哪份数据”，打开 config.yaml 一目了然。配合一键脚本，复现流程变成一条命令：拉取指定 commit 的代码 → 构建 Docker 镜像 → 读取配置 → 运行训练评估 → 输出指标报告。

收尾用一份“可复现检查清单”：代码版本是否可追溯？所有随机源是否固定？依赖环境是否锁定？配置能否完整重现超参数？四项全绿才算合格。团队还可以把这份清单写进持续集成（CI），每次实验提交都自动校验，把可复现性从个人自觉升级成工程规范。到这一步，你的实验不再依赖“某个记得所有细节的人”，而是依赖一套任何人照做都能成功的流程。

流程卡做出来之后，奶奶终于可以退休了——因为“做得最好吃的那个版本”已经不再是某一个人手上的记忆，而是任何拿到卡片的人都能端上桌的确定性。

可复现=版本固定∧种子固定∧环境锁定∧配置完整\displaystyle \text{可复现} = \text{版本固定} \wedge \text{种子固定} \wedge \text{环境锁定} \wedge \text{配置完整}
四个必要条件用“且”连接：缺了任何一个，整体就不成立。可复现是组合拳，不是单点技巧。
  1. AND 运算四个条件用“且”连接，任何一个为假，整体结果就为假：
    ∧\wedge
  2. 版本固定代码与数据都能通过提交哈希回溯到唯一版本：
    VcV_c
  3. 种子与环境随机源被钉死、依赖库被锁点，实验结果不再依赖运气：
    Vs∧VeV_s \wedge V_e
  4. 配置完整超参数与路径写入配置文件，杜绝“隐含默认值”：
    VpV_p

AI 应用场景

论文投稿前的可复现性自检

阶段：实验收尾与论文撰写

解决的问题：审稿人或读者按照论文描述复现不出结果，是撤稿和信用危机的高发原因。AI 的方法：投稿前在干净的机器上按“四要素清单”完整跑一遍复现流水线，把复现脚本、Docker 镜像地址、commit 哈希写进论文附录，就像把完整菜谱附在红烧肉照片旁边。

具体案例：一位博士生在投顶会前，用一台无缓存的新机器执行 reproduce.sh，发现原报告的 F1 从 89.3 掉到 87.9。顺藤摸瓜找到数据清洗顺序未固定的 bug，修复后数字重新对齐，论文得以顺利送审。

复现他人论文作为对比基线

阶段：实验设计与竞品分析

解决的问题：复现基线不准，后续所有对比实验都会失真。AI 的方法：固定 clone 的 commit、按论文锁定依赖版本、用作者提供的随机种子跑三遍取稳定结果，确认基线可信后再开始自己的方法。

具体案例：一位算法工程师复现某 3D 检测论文，直接 clone 最新 main 分支跑出的 mAP 比论文差了 5 个点，一度怀疑对方造假。改用论文附录里的 commit 哈希加官方 Docker 镜像后，数字与原文对齐——原来最新分支引入了未发布的改动。

线上模型回溯排障

阶段：模型运维与迭代

解决的问题：模型效果突然下降，无法判断是数据漂移、代码改动还是环境更新导致的。AI 的方法：每次训练打上“commit 哈希 + 配置文件 + Docker 镜像”的三件套标签，出问题时切回旧镜像快速复现线上行为，把排查范围瞬间缩小。

具体案例：推荐团队发现 CTR 连续一周下滑，排查两天无果。后来发现某次依赖小版本升级悄悄改变了 tokenizer 的分词行为，回滚到旧镜像后指标立即恢复——如果当初没有留 Docker 镜像，这个问题几乎不可能定位。

Python 演示

python47 行
"""演示：固定随机种子后，两次实验轨迹完全一致"""import randomimport hashlibimport numpy as np TORCH_OK = Falsetry:    import torch    TORCH_OK = Trueexcept ImportError:    pass def set_seed(seed: int) -> None:    """同时固定 Python、NumPy、PyTorch 的随机源"""    random.seed(seed)    np.random.seed(seed)    if TORCH_OK:        torch.manual_seed(seed)        torch.cuda.manual_seed_all(seed) def simulate_run(seed: int, epochs: int = 6) -> list:    """模拟一次带随机噪声的训练，返回 loss 序列"""    set_seed(seed)    loss_trace = []    for epoch in range(epochs):        noise = np.random.rand() * 0.08        loss = 1.0 / (epoch + 1) + noise        loss_trace.append(round(loss, 6))    return loss_trace def trace_fingerprint(trace: list) -> str:    """把 loss 序列压缩成指纹，方便比对两次实验"""    text = "|".join(str(x) for x in trace)    return hashlib.sha1(text.encode()).hexdigest()[:12] def main() -> None:    run1 = simulate_run(42)    run2 = simulate_run(42)    run3 = simulate_run(7)    print("run1(seed=42):", run1, trace_fingerprint(run1))    print("run2(seed=42):", run2, trace_fingerprint(run2))    print("run3(seed=7):", run3, trace_fingerprint(run3))    same = trace_fingerprint(run1) == trace_fingerprint(run2)    print("同种子两次实验指纹一致:", same) if __name__ == "__main__":    main()
目的：模拟两次随机训练，用 SHA1 指纹证明“同种子同轨迹、异种子异轨迹”——这正是可复现性里随机种子固定的最小演示。
  1. def set_seed(seed: int) -> None:把散落在各库的随机源集中到一个“防手抖”入口
  2. random.seed(seed)固定 Python 内置随机数生成器
  3. np.random.seed(seed)固定 NumPy 的随机数生成器
  4. if TORCH_OK:检测到 PyTorch 时再固定 torch 与 CUDA 的随机源
  5. noise = np.random.rand() * 0.08模拟训练中每轮迭代的随机扰动
  6. return hashlib.sha1(text.encode()).hexdigest()[:12]把整条 loss 序列压缩成指纹，同种子才能对上

常见误区

误区我明明在代码开头写了 np.random.seed(42)，为什么两次跑出来的 Loss 还是不一样？肯定是框架有 bug。

正解深度学习流程里至少有四路“随机水龙头”：Python 内置 random、NumPy、PyTorch/TensorFlow 各自的生成器，还有 DataLoader 的 shuffle 和多进程 worker 的随机数。任何一路没拧紧，结果都会飘。正确做法是写一个 set_seed 函数一次性固定所有源，并在启动前用环境变量 PYTHONHASHSEED 固定字符串哈希。

为何常见：教程大多只演示 np.random.seed 一行代码，初学者自然会误以为“固定种子 = 一行命令”。

误区我执行 pip freeze > requirements.txt 了，别人 pip install -r 一下，一定能复现我的实验。

正解pip freeze 会把当前环境里所有包全量导出，包括与实验毫无关系的工具库；换一台机器时还缺系统级依赖（CUDA、编译器）。更稳妥的做法是：手工维护一份核心依赖清单并锁定精确版本，系统层用 Docker 固化，requirements 只负责 Python 依赖那一层。

为何常见：freeze 命令的输出看起来权威又全面，默认“全量快照”的心态让人误以为越全越可靠。

误区我种子、代码、数据集都固定了，为什么同事还是复现不出我的准确率？

正解种子只解决“随机性”这一个变量。代码版本、数据版本、依赖环境、硬件与驱动，每一个都可能让结果漂移。可复现是四要素的组合拳：版本固定、种子固定、环境锁定、配置完整，四者用“且”连接，缺一个整体就为假。

为何常见：人脑天然喜欢找“万能开关”，种子恰好是最显眼的一个开关，于是被过度神化。

误区我把训练好的 .pth 文件打包发过去了，对方加载直接报错，还要我远程调环境，真麻烦。

正解权重文件只是“红烧肉的成品照片”，不是菜谱。复现要求对方能重新走完“数据 → 训练 → 评估”的完整流程。正确姿势：把代码提交哈希、数据版本、Docker 镜像地址、配置文件一起附上，让对方一条命令跑到底。

为何常见：科研里“交付成果”的习惯是交结果文件，而复现要求的恰恰是交“流程”，这两者的思维惯性不容易转过来。

面试题

Q1. 可复现性最准确的含义是什么？

单选题 · easy

  • A.代码结构清晰易读
  • B.别人能复现论文结果← 正确答案
  • C.训练损失降到最低
  • D.模型参数量更少

答案：B。可复现性的核心是“别人按你的代码、数据、环境能跑出同样的结果”，好比别人照你的菜谱能否端出同一道菜。代码清晰、损失低、参数少都可能是有益的品质，但都不是可复现性的定义。

Q2. 固定随机种子（如 seed=42）的直接作用是？

单选题 · easy

  • A.让模型精度大幅提升
  • B.让训练速度变得更快
  • C.让随机序列可重复← 正确答案
  • D.让数据集自动变大

答案：C。随机种子是伪随机序列的起点，起点相同、规则相同，整条序列必然相同。它不会提升精度、加速训练或改变数据量，只是让“随机”变成有剧本的“确定”。

Q3. 深度学习训练中，常见的随机源包括哪些？

多选题 · mid

  • A.NumPy 随机数生成器← 正确答案
  • B.PyTorch 模型初始化← 正确答案
  • C.数据加载器的打乱← 正确答案
  • D.磁盘物理读写速度

答案：ABC。训练中的随机源很多：NumPy、框架的模型初始化、DataLoader 的 shuffle、多进程采样等，固定种子要逐一拧紧所有水龙头。磁盘读写速度只是性能因素，不决定训练结果的数值序列。

Q4. Git 中能唯一标识一次代码快照的是？

单选题 · mid

  • A.分支名的长度
  • B.提交的哈希值← 正确答案
  • C.作者的邮箱地址
  • D.文件的总行数

答案：B。提交哈希由快照内容、父提交和提交信息共同算出，是定位代码版本最可靠的身份证。分支名、邮箱、行数都可能重复或含糊，无法作为唯一标识。

Q5. 用 pip freeze 锁定环境的主要局限是什么？

单选题 · mid

  • A.会连带锁定无关依赖← 正确答案
  • B.生成的版本不够精确
  • C.无法在 Linux 上运行
  • D.会导致代码体积增大

答案：A。pip freeze 会把当前环境所有安装的包全量导出，包括与实验无关的工具；更稳妥的是手工维护核心依赖并锁定精确版本。它生成的版本号本身是精确的，与操作系统无关，也不会增大代码体积。

Q6. 一个完整可复现的实验方案应当包含哪些？

多选题 · hard

  • A.固定所有随机来源← 正确答案
  • B.记录代码提交哈希← 正确答案
  • C.锁定依赖环境快照← 正确答案
  • D.仅保留最终模型权重

答案：ABC。完整方案 = 固定随机源 + 记录代码提交 + 锁定依赖环境 + 数据版本固定。只保存权重文件就像只留成品照片，无法让人重走训练流程，自然也谈不上复现。

Q7. Docker 相比于虚拟机的核心优势是什么？

单选题 · mid

  • A.能模拟不同操作系统
  • B.共享宿主机内核更轻量← 正确答案
  • C.自动扩充 GPU 显存
  • D.无需编写任何配置

答案：B。Docker 容器共享宿主机内核，只隔离文件系统、进程等用户态资源，因此镜像更小、启动更快。“模拟操作系统”是虚拟机的领域，Docker 也并不会有求必应地扩显存或免写 Dockerfile。

Q8. 同一种子两次训练结果仍不同，最可能的原因是什么？

单选题 · hard

  • A.训练样本数量太少
  • B.未固定全部随机源← 正确答案
  • C.模型隐藏层数过多
  • D.损失函数定义错误

答案：B。同种子仍不同步，最典型的原因是随机源没固定全，比如只设了 np.random.seed 而没设 torch.manual_seed，DataLoader 的 shuffle 也没固定。样本少、层数多、损失函数定义属于另一类问题，与“同种子异结果”没有直接因果关系。

Q9. requirements.txt 中哪种写法最适合复现？

单选题 · easy

  • A.指定最低版本
  • B.锁定精确版本← 正确答案
  • C.给出版本区间
  • D.保持默认最新

答案：B。可复现要求依赖版本精确到点（==），区间和下界都会留下“猜测空间”。版本一漂移，数值行为就可能漂移。锁定精确版本，才等于菜谱里的“盐 6 克”。

Q10. 关于“固定种子等于可复现”的说法，正确的是？

多选题 · extreme

  • A.只固定种子就够了
  • B.代码版本也要锁定← 正确答案
  • C.数据版本也要固定← 正确答案
  • D.依赖环境也要锁定← 正确答案

答案：BCD。种子只解决随机性一个变量，代码、数据、环境的任何漂移都会让结果偏离。可复现是四要素的“且”关系：版本固定、种子固定、环境锁定、配置完整。四者缺一不可，只固定种子远远不够。