版本、评测与发布

本节目标

用 immutable 原始候选、lineage、内容指纹、语义版本、Data Card 和发布 gate 管理合成数据的全生命周期。

直觉解释

如果 generator、提示或过滤器改变后仍叫“dataset-final.json”，旧结果就无法解释。版本化不是给文件名加日期，而是让每条样本和每次评测能追溯到生成与处理链。

核心概念

lineage：样本从来源、生成、过滤、复核到发布的处理关系。
immutable raw：原始候选只追加，不原地覆盖。
manifest：列出数据文件、schema、数量、哈希、split 和生成配置。
semantic versioning：用 major/minor/patch 表示兼容性；数据集需自行定义何种变化属于哪一级。
content fingerprint：规范化内容哈希，用于确认内容一致。
Data Card / datasheet：面向使用者的来源、意图、组成、处理、风险、维护和限制说明。
release gate：发布前必须通过的质量、隐私、许可、复现和审批检查。

发布包而不是单个数据文件

最小发布包包括：不可变数据文件、schema、manifest、Data Card、rejection/审计摘要、生成器与过滤器版本、划分映射、质量/效用/风险报告、变更日志和许可/访问说明。还要有来源—派生产物映射以及每个发布范围的来源/授权/隐私审查状态与证据引用；这些引用指向受控工件，不能为了“完整”把凭据、原始候选或敏感审计证据打包外泄。

发布决策需要优先级：来源或授权不明、关键标签错误、隐私硬门失败应先 BLOCK；重复率、覆盖、真实留出效用和小切片问题可按冻结规则进入 REVIEW；只有所有硬门通过才发布。哈希只证明输入字节与先前一致，不能证明来源真实、质量合格或批准有效。

分步骤方法

分开保存 raw candidates、processed dataset、rejection log 和 report。
每条样本保留 candidate ID、family、generator、prompt/template、seed 和处理版本。
manifest 记录 schema、条件矩阵、split、数量、内容哈希和依赖版本。
定义版本政策：例如改错误标签为 patch，新增兼容样本为 minor，改变 schema/任务含义为 major。
在新版本上重复 schema、去重、分层质量、真实留出效用、隐私和许可审查。
Data Card 说明动机、来源、生成方法、过滤、组成、预定/禁止用途、风险、访问和维护者。
发布变更日志与迁移说明；旧 Benchmark 结果不得自动与新 major 版本横比。
设置撤回、更正、删除请求和停止维护流程。

维护触发包括：generator/模型别名变化、提示或模板改版、发现污染/泄漏、真实分布漂移、标签规则变化、许可/政策变化和新的受影响群体反馈。每次触发先判断是否改变语义或比较边界，再选择 patch/minor/major；不要为了保持榜单连续而隐藏断点。

撤回、更正与删除请求运行手册

撤回不是“把最新文件删掉”。一旦发现来源、权限、隐私或标签问题，应按冻结流程：

停止新下载、索引、训练或评测消费，并把受影响 release 标成 withdrawn、under-review 或等价状态；不要静默替换同一版本号。
用来源—派生产物映射定位候选、已发布记录、family/split、向量索引与缓存、训练/评测输入、排行榜和派生报告。
保存必要的受控审计证据，执行删除/隔离或访问撤销；重建受影响索引和数据包，并重新跑质量与效用门。
发布新版本、变更/撤回说明与比较断点；历史结果可保留为带状态的证据，但不能继续作为当前数据的结论。
记录责任人、时间、影响范围、未能彻底移除的副本和后续检查。法律、合约或监管时限由相应负责人员确定，工程流程不替代其决定。

当数据集支撑一次模型或 Agent 发布时，数据集版本不能替代运行发布身份：使用 release_id 关联 suite/dataset/rubric/grader/harness 版本、逐 case 结果和审批状态，再将该 release_id 写入证据报告。对应的离线—线上证据术语与方向见离线到线上证据交接与回归闭环。

示例

一个最小 manifest：

{
  "dataset_id": "order-agent-synthetic-eval",
  "version": "1.0.0",
  "schema_version": "1",
  "generator": {
    "type": "template",
    "version": "template-pipeline-1.0.0",
    "seed": 13
  },
  "release_scope": "offline-teaching-only",
  "source_declaration": "author-designed fictional templates; no external or real records",
  "counts": {"raw": 14, "released": 12},
  "splits": {"dev": 4, "test": 8},
  "fingerprint": "sha256:...",
  "source_checked": "2026-07-14"
}

上例是面向可发布数据集的扩展清单。离线教学项目故意只输出其离线模板所需的最小 generator 声明，且明确不声称授权、隐私或公开发布资格；把教学 fixture 的 contains_real_data: false 误当成上例完整审查记录是错误的。

哈希变化说明内容不同，但不能自动告诉你差异合理。必须结合变更日志和重新评测。

常见错误与排查

只版本化最终 JSON：同时版本化 generator、提示/模板、过滤器和 schema。
修改错误标签但不升版本：旧结果已不可重现；发布 patch 和变更清单。
Data Card 只写优点：必须列非目标、缺口、风险和未验证项。
split 在每次导出时重新随机：固定 family→split 映射，避免评测漂移。
公开后无人维护：指定责任人、更新触发与退役日期/条件。

练习

为你的数据集定义 major/minor/patch 规则。
写一个包含十个字段的 Data Card 清单。
设计从真实故障加入新合成 family 到发布 minor 版本的审批流程。

自测

相同版本号但哈希不同是否可接受？除非有明确不可变性例外，否则这是版本纪律问题。
固定 seed 能否取代 manifest？不能，它不包含代码、模板、来源和处理链。
新增样本后旧分数还能直接比较吗？只有协议规定兼容且在相同冻结版本重跑；不同数据结果不能当同一测量。

小结与下一步

版本化让合成数据成为可重放、可审计、可撤回的工程资产。最后完成离线合成评测数据流水线，把契约、过滤、覆盖、划分、哈希和限制落实为代码。

参考资料

Data Cards 原始论文与官方页面（获取日期：2026-07-22）
Google Data Cards Playbook（获取日期：2026-07-22）
Datasheets for Datasets 原始论文（获取日期：2026-07-22）
NIST AI 600-1（获取日期：2026-07-22）

AI Agent Engineer

账户与学习进度

版本评测与发布