3. 可复现评测基础
在数据集版本管理体系中，评测不是“跑一次看结果”的临时动作，而是一项需要被工程化管理的可复现实验。可复现评测的核心目标是：给定相同的数据集版本、代码版本、环境依赖和随机种子，任何人在任何时间、任何机器上都能得到统计意义上一致的结果。这句话包含四个约束条件，缺一不可。很多团队只关注“模型准确率是多少”，却忽略了“这个数字是在什么条件下得到的”，导致后续无法复现、无法对比、无法归因。
一、可复现性的三层定义
可复现性并非单一概念，工程上通常分为三个层次，理解它们的差异有助于确定评测工程的投入边界。
- 可重复（Repeatability）：同一人在同一环境下，用相同代码和数据重复执行，结果一致。这是最低要求，主要受随机种子、非确定性算子影响。
- 可复现（Reproducibility）：不同人、不同机器，依据完整记录重建环境后，得到一致结果。这是评测工程的主目标，依赖环境锁定与数据版本锁定。
- 可复刻（Replicability）：使用不同实现或不同数据采集方式，仍能得出相同结论。这是最高层次，通常用于科研结论验证。
二、评测指标：从单一数值到指标契约
评测指标不只是准确率、F1、BLEU 这样的数字，而是一份“指标契约”，需要明确计算口径、聚合方式、阈值和边界条件。例如同样是准确率，是 micro 还是 macro，是否忽略特定类别，是否对样本加权，都会导致结果差异。因此，评测指标必须与数据集版本绑定，并写入评测配置。
| 指标要素 | 说明 | 示例 |
|---|---|---|
| 指标名称 | 明确任务与计算方式 | macro-F1、AUC、ROUGE-L |
| 计算口径 | 聚合方式与忽略规则 | 按类别平均，忽略空标签 |
| 数据切分 | 评测集版本与划分 | test-v2.1，固定 5000 条 |
| 阈值/容差 | 判定通过的标准 | F1 ≥ 0.82，波动 ≤ 0.005 |
| 随机种子 | 控制采样与初始化 | seed=42，固定 3 次取均值 |
三、实验记录：让每次评测可追溯
实验记录是可复现评测的“黑匣子”。它需要记录的不只是最终指标，还包括输入、配置、中间产物和运行上下文。推荐使用结构化日志或实验管理工具，将每次运行写入唯一 run_id，并与数据集版本、代码 commit 关联。
{
"run_id": "eval-20240612-003",
"dataset_version": "sentiment-test-v2.1",
"dataset_hash": "sha256:9f2c...a1",
"code_commit": "git:7d3e9b1",
"env_lock": "conda:env-20240610.yaml",
"seed": 42,
"metrics": {
"macro_f1": 0.834,
"accuracy": 0.861,
"latency_ms": 23.4
},
"artifacts": ["predictions.jsonl", "confusion_matrix.png"]
}实验记录应遵循“可查询、可对比、可回放”原则。可查询指能按数据集版本、指标区间筛选；可对比指能并排查看两次运行的差异；可回放指能依据记录重建运行环境并重新执行。
四、环境依赖：锁定不确定性的源头
环境依赖是评测不可复现的最常见原因。Python 包版本、CUDA 驱动、系统库、甚至 CPU 指令集都可能影响数值结果。工程上通常采用三层锁定策略：
- 依赖清单锁定：使用 requirements.txt 或 environment.yaml 固定所有包及其精确版本。
- 容器镜像锁定：将操作系统、驱动、运行时打包为镜像，通过 digest 固定。
- 硬件与随机性锁定：固定随机种子、关闭非确定性算子、记录 GPU 型号与驱动版本。
五、案例：一次“指标下降”的复盘
某团队发现新模型 F1 从 0.834 降到 0.821，初步判断为模型退化。但通过实验记录对比发现：两次运行的数据集版本不同，新评测使用了 test-v2.2，其中新增了 300 条困难样本；同时环境依赖中 transformers 从 4.36 升级到 4.38，tokenizer 行为有细微变化。最终结论是：指标下降并非模型变差，而是评测集难度提升与依赖升级共同导致。若没有完整的实验记录和环境锁定，这次归因将无法完成。
六、可复现评测的最小工程闭环
将上述要素串联，可形成如下最小闭环：数据集版本 → 环境锁定 → 评测配置 → 运行记录 → 指标产出 → 对比归因。每一步都应有唯一标识和校验值。只有闭环完整，评测结果才能作为模型迭代、数据版本升级和上线决策的可信依据。
总结来说，可复现评测不是额外负担，而是数据版本管理体系的“质量底座”。只有把可复现性定义清楚、把评测指标契约化、把实验记录结构化、把环境依赖锁定化，评测结果才具备跨时间、跨团队、跨机器的可信度，后续的数据版本对比和模型迭代才有坚实依据。