机器学习实验可复现：从随机种子到数据版本的完整清单
机器学习实验可复现：从随机种子到数据版本的完整清单
一、复现失败通常不是模型错了，而是实验边界丢了
机器学习实验中，“我这里能跑”并不等于可复现。模型训练结果受随机种子、数据切分、依赖版本、硬件环境、预处理逻辑和评估脚本共同影响。若缺少记录，同一套代码隔几周再运行，指标差异可能无法解释。可复现实验的目标不是让每次结果完全一致，而是让差异来源可追踪、可解释、可控制。
实验复现首先要固定输入。数据集版本、清洗规则、训练验证测试切分、采样策略都应显式记录。很多论文复现失败，并不是模型结构写错，而是数据预处理细节不同。例如文本是否小写化、是否过滤短句、标签冲突如何处理，都会改变最终指标。
二、实验链路：数据、配置、权重和评估脚本必须绑定
flowchart TD A[原始数据] --> B[数据版本] B --> C[预处理脚本] C --> D[固定切分] D --> E[训练配置] E --> F[模型权重] F --> G[评估脚本] G --> H[实验报告]随机性也要分层控制。Python、NumPy、PyTorch、CUDA 都可能引入随机行为。即使设置种子，某些 GPU 算子仍可能存在非确定性。严格可复现会牺牲性能，因此应根据实验目的选择。如果是论文对比，优先确定性；如果是生产训练，可能更关注多次运行的均值和方差。
三、随机种子实现：减少无意识随机性
下面是一个常见的随机种子设置示例。它不能保证所有场景绝对确定，但能减少大部分无意识随机性。
import os import random import numpy as np import torch def set_seed(seed: int): if seed < 0: raise ValueError("seed must be non-negative") random.seed(seed) np.random.seed(seed) os.environ["PYTHONHASHSEED"] = str(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False四、取舍边界：确定性、速度和长期维护不能同时拉满
配置管理建议使用单独文件，而不是把超参数散落在代码里。学习率、batch size、优化器、warmup 步数、最大序列长度、模型版本和数据路径都应进入配置。实验报告中不仅要记录最优指标，也要记录失败实验，因为失败结果能帮助后续避免重复探索。
环境记录同样关键。Python 版本、CUDA 版本、PyTorch 版本、驱动版本和依赖锁文件都应保存。容器化能提高复现概率，但容器镜像也需要版本号和构建记录。没有环境记录的模型权重，长期来看很难维护。
还要记录多次运行的方差。单次实验指标高，并不一定代表方法更好；如果不同随机种子下结果波动很大，说明结论不稳定。对于科研复现，均值、标准差和失败样本同样重要。
实验产物也要分级保存。最终模型、最佳配置和评估报告应长期保留；中间 checkpoint 可以设置过期策略。否则实验越多，存储越难管理，后续查找真正有价值的结果会越来越困难。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型；指标至少覆盖成功率、超时率、重试次数和队列长度；必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。
五、总结
机器学习实验可复现需要同时管理数据、随机性、配置、环境和评估脚本。复现不是额外文档负担，而是让实验结论可验证、可比较、可长期维护的基础工程能力。