3. 核心概念与术语
在模型开发文档与可重复性审计的语境中，术语混用是导致审计失败、责任边界模糊和返工成本上升的首要原因。很多团队把“可重复”与“可复现”当作同义词，把“版本控制”简单理解为“代码上传”，把“环境锁定”误认为“写一个 requirements.txt”。这些模糊认知在真实审计场景中会直接转化为证据链断裂。本节将逐一拆解六个关键术语，并给出可操作的判定标准。
一、核心原理：从“同一实验”到“同一结论”的语义分层
可重复性、可复现性、可复制性三者构成一个递进但不等价的语义阶梯。理解它们的差异，是设计审计方案的前提。
- 可重复性（Repeatability）：同一团队、同一环境、同一代码与数据，在短时间内重复执行，能否得到一致结果。它检验的是“操作稳定性”，通常用于内部质量门禁。
- 可复现性（Reproducibility）：不同团队或不同人员，依据文档与制品，在独立环境中执行，能否得到与原始结论一致的结果。它检验的是“文档与制品的完备性”，是审计的核心对象。
- 可复制性（Replicability）：使用新数据、新样本或新场景，独立开展研究，能否得到与原始结论方向一致的结果。它检验的是“结论的泛化能力”，属于科学层面的验证。
审计中最常见的误判：把“可重复”当作“可复现”。前者只需脚本能跑通，后者要求另一个人在没有口头传承的情况下也能跑通并得到相同指标。
二、方法流程：审计追踪、版本控制与环境锁定的协同
三个工程术语分别对应“记录什么”“管理什么”“固定什么”。它们不是孤立工具，而是一条证据链的三个环节。
| 术语 | 核心问题 | 最小可审计要求 | 常见缺失 |
|---|---|---|---|
| 审计追踪 | 谁在何时改了什么、为什么改 | 不可篡改的变更日志，含操作人、时间戳、变更前后值、审批记录 | 仅记录结果，不记录中间决策与参数变更 |
| 版本控制 | 代码、数据、模型、配置的精确版本 | 每次实验可映射到唯一 commit、数据快照与模型权重哈希 | 只管理代码，数据与模型权重游离在外 |
| 环境锁定 | 依赖、系统库、硬件与随机种子是否固定 | 锁定到具体版本号与哈希，记录 CUDA、驱动、OS 与种子 | 使用浮动版本号，未记录随机种子与硬件差异 |
一个可复现的最小实验记录应包含如下元数据。审计时，检查这些字段是否完整，比检查代码风格更有价值。
experiment_id: exp-2024-0517-001
code_commit: a3f9c2e
data_snapshot: s3://bucket/data/v3.2/2024-05-01
model_hash: sha256:9f2b...
env_lock: conda-lock.yml@sha256:7c1d...
random_seed: 42
hardware: NVIDIA A100 80GB x2, CUDA 12.1, Driver 535.104
metrics: {auc: 0.873, f1: 0.791}
operator: zhangsan
approved_by: lisi
三、案例/场景：一次“看似可复现”的审计失败
某风控模型团队提交审计材料，包含完整代码仓库、README 和一份 requirements.txt。审计方在独立环境执行后，AUC 从 0.873 降至 0.841。排查发现三个问题：第一，requirements.txt 中 scikit-learn>=1.0 未锁定小版本，独立环境安装了 1.4，导致默认参数行为变化；第二，数据预处理中的缺失值填充使用了当前时间戳作为随机种子，未记录；第三，模型训练依赖一块特定型号 GPU 的浮点行为，文档未提及硬件信息。
这个案例说明：可复现性不是“代码能跑”，而是“结论能对齐”。审计追踪缺失了参数变更记录，版本控制缺失了数据快照，环境锁定缺失了硬件与种子，三者同时失效，导致审计失败。
建议在项目启动时即建立“审计四件套”：代码 commit、数据快照、环境锁文件、实验元数据。不要等到审计前补录，补录的记录在审计中可信度极低。
四、误区/复盘：术语混淆带来的真实代价
- 误区一：把版本控制等同于 Git。 Git 管理代码，但数据、模型权重、特征工程中间产物需要额外方案（如 DVC、对象存储版本、模型注册表）。
- 误区二：环境锁定只写 Python 包版本。 系统库、CUDA、驱动、编译器、甚至 CPU 指令集都可能影响结果，必须记录到可追溯的粒度。
- 误区三：审计追踪等于日志。 日志是技术记录，审计追踪要求可归因、可审批、不可篡改，通常需要与工单或变更管理系统联动。
- 误区四：可复制性可以替代可复现性。 两者目标不同。审计关注的是“同一结论能否被独立验证”，而不是“结论是否在新数据上成立”。
在受监管行业，术语定义往往直接写入合规条款。混淆“可重复”与“可复现”可能导致提交材料被判定为不完整，进而触发整改甚至处罚。建议团队在文档模板中固定术语表，并在每次评审中核对。
复盘上述案例，可提炼出一条判定链：先确认审计目标是可重复还是可复现；再检查版本控制是否覆盖代码、数据、模型、配置四类制品；然后验证环境锁定是否包含依赖、硬件、种子；最后核对审计追踪是否记录了变更原因与审批。四步全部通过，才具备可复现性的基础证据。