1. 课程导入

在机器学习与数据驱动的工程实践中，模型效果往往被归因于算法和超参数，但真正决定评测结论是否可信的，常常是数据本身以及数据版本的管理方式。同一份代码、同一组超参数，如果训练集、验证集或测试集发生了细微变化，指标就可能出现明显波动。更严重的是，当团队无法说清"这次评测到底用了哪一版数据"时，所有对比实验都会失去意义。本课程围绕数据集版本管理与可复现评测工程两条主线展开，帮助你把"数据"从不可控的变量，变成可追踪、可回滚、可审计的工程资产。

学习目标

完成本课程后，你应当能够达成以下目标：

• 理解数据集版本管理的基本概念，包括数据快照、版本标识、血缘关系与不可变存储。
• 掌握为数据集建立版本控制的核心方法，能够设计合理的目录结构、命名规范与元数据格式。
• 能够构建可复现的评测流水线，使"数据版本 + 代码版本 + 配置 + 环境"四要素可被完整记录与还原。
• 能够识别并规避常见误区，例如用文件名代替版本、评测集泄漏、指标口径不一致等。
• 能够为团队设计一套轻量但可落地的数据版本与评测治理规范。

核心概念

本课程涉及若干关键概念，它们构成了后续所有章节的基础。理解这些概念之间的关系，比记住定义更重要。

数据集版本（Dataset Version）：对某一时刻数据集内容与结构的唯一标识。它不仅包含样本文件本身，还应包含划分方式、标签定义、预处理脚本与统计信息。一个合格的版本应当满足"可定位、可还原、可比较"。

数据血缘（Data Lineage）：描述数据从原始来源经过清洗、标注、切分、增强等步骤，最终形成训练/评测集的完整链路。血缘让"这份数据从哪来、经过了什么处理"变得可追溯。

可复现评测（Reproducible Evaluation）：在给定数据版本、代码版本、运行环境和随机种子的条件下，任何人任何时间都能得到一致的评测结果。可复现不是"结果相同"这么简单，而是"过程可被完整重建"。

评测契约（Evaluation Contract）：团队对评测口径的约定，包括使用哪个测试集、采用哪些指标、如何处理边界样本、以什么统计方式汇报。契约一旦确定，就应随数据版本一起被固化。

整体框架

本课程的整体框架可以概括为"一条主线、三层结构、四个环节"。一条主线是让评测结论可信；三层结构分别是数据层、工程层与治理层；四个环节则是版本创建、版本存储、评测执行与结果审计。下图展示了这一整体框架中各模块之间的关系。

从图中可以看到，数据层负责把原始数据加工成可标识的版本快照；工程层负责把版本快照接入评测流水线，并锁定环境与随机性；治理层则通过规范、契约与审计机制，保证整个体系长期可维护。三层之间自上而下传递约束，自下而上反馈问题。

方法流程：从数据到可信结论

一个典型的可复现评测流程包含以下步骤：

1. 数据接入与清洗：记录原始数据来源、采集时间与清洗规则。
2. 版本创建：对清洗后的数据计算内容哈希，生成版本号并写入元数据清单。
3. 版本存储：将数据快照存入对象存储或版本库，保证不可变。
4. 评测执行：按评测契约加载指定版本，运行推理与指标计算。
5. 结果归档：保存指标、日志、配置与数据版本号，形成可审计记录。
6. 对比与回溯：当指标异常时，依据血缘与版本记录定位变化来源。

下面是一个版本元数据清单的示例，它记录了数据集版本的关键信息：

{
  "dataset_name": "sentiment_train",
  "version": "v2.3.1",
  "content_hash": "sha256:9f2c...a71d",
  "created_at": "2025-03-12T10:24:00Z",
  "split": {"train": 80000, "val": 10000, "test": 10000},
  "label_schema": ["negative", "neutral", "positive"],
  "preprocess": "clean_v3.py",
  "parent_version": "v2.3.0",
  "change_note": "修正标注错误 412 条"
}

案例场景：一次指标回退的排查

某推荐团队发现新模型上线后 AUC 从 0.812 降到 0.795，但代码改动很小。排查后发现，评测所用的测试集在两周前被重新切分过，新测试集包含更多冷启动用户。由于当时没有记录数据版本，团队花了三天才定位原因。引入数据版本管理后，同样的排查只需对比两个版本的元数据清单，几分钟即可确认差异来源。这个案例说明：数据版本管理不是额外负担，而是排障效率的基础设施。

常见误区与复盘