有一件事让我卡了很久。
我最早训练一个 40 亿参数的模型时，把数据池里的 Common Crawl 换成了当月的新快照。换完第一个 epoch，loss 曲线漂亮得让人心情舒畅。结果两周后跑下游评测，两个任务崩了，其中一个掉了 9 个百分点。
我当时的反应很标准：先查代码——代码仓库有版本，没动过；再看 checkpoint，完好。然后查数据，没有人能给数据一个「版本」。几十 TB 的文件里，多了一批网页、少了一堆重复文本、清洗规则被某个运维悄悄改过一个阈值。没有 commit，没有 PR，没有责任人。
这件小事让我意识到，预训练数据版本的「不可追溯」，不是工程疏忽，而是这个领域一直存在的认知盲区。
模型对数据的响应，是「一滴水改一条河」
为什么数据版本的改变如此难以定位？因为预训练模型的响应，根本不是「改一行代码→改一行输出」的因果关系，而是全量、非线性、时变的。
预训练是在一个高维非凸的损失地形上做梯度下降。每一个 token 都参与塑造了整个优化轨迹。同一个词「银行」出现在语料第 1 个 batch，和第 1 万个 batch，对模型的影响完全不同——因为模型在读到第 1 万个 batch 时，已经长出了对「银行」的初步理解。先学到的意思会被固化，后出现的含义容易遭遇灾难性遗忘。
举例：如果你的语料前 100 亿 token 全是「银行＝存钱」，之后才开始出现「银行＝河岸」，模型学出来的「银行」表示，会被前段数据彻底锚定。同样的数据，顺序一换，模型的表现就迥异。这意味着，光记录「哪些文件参与了训练」远远不够，你还得记录「每份数据在训练时间轴上的位置」。
实际生产中，数据变化有三种常见类型，没有一种会有人主动通知你：
- 上游数据源改版：Wikipedia dump 每月重导，网页天天变。换的不仅是「新数据」，整个分布都漂了。
- 清洗管线参数微调：去重阈值从 0.8 调到 0.85，或加一条「剔除长度小于 20 的文本」。语料整体偏移，几乎不可见。
- 混合配比调整：为了提升代码能力加了 5% 代码语料，数学分数上去了，通用常识悄悄掉了几个点。
这些变化对一个几千亿 token 的数据池来说，都是「一滴水」。但它们在训练路径上的累积效应，足以改变一条河的流向。
行业现状：三个开源项目都只解决了「登记」，没解决「追溯」
先看看当前业界到底在数据版本管理上做了什么。
The Pile（EleutherAI）是最早把「数据配方」当成一等公民对待的数据集：800GB 级，22 个子集，每个子集的来源和比例公开固定，论文见 arXiv:2101.00027。它的聪明之处在于，把「难以描述的数据」变成「一张可以讨论的配方」。
Dolma（AllenAI，为 OLMo 系列准备的数据集）走得更远：每个文档自带 id / text / source / added / version 字段，构造管线完整公开，见 arXiv:2402.00159。你至少能知道一条数据什么时候进来的、从哪个来源进的。
LLM360（AMD 和 CMU）把「透明度」推到极致：训练代码、超参、中间 checkpoint 全部公开，arXiv:2311.17343 里明确说，完整的数据记录让复现成为可能。
但注意一个区别：这三个项目的核心是「登记」，不是「追溯」。打个比方，你给每个员工发了工牌、记录了入职日期，但这不等于你能说清上季度业绩下滑，究竟是谁的哪句话导致的。
| 维度 | Git 代码管理 | 数据版本管理现状 |
|---|---|---|
| 变更粒度 | 一次 commit 精确描述一次改动 | 几十 TB 级别的流式漂移，无法 diff |
| 可回滚性 | 随时 checkout 到历史任意状态 | 文件可回滚，但语义状态回滚不了——顺序和配比不可重放 |
| 归因能力 | 可单步调试，定位到行 | 模型行为是整体涌现，无法定位到「哪个 token 起了反作用」 |
| 重放一致性 | 同一 commit 可重现同一行为 | 同一数据，受 seed、优化器、并行策略影响，结果仍不同 |
一句话总结：Git 管的是「改动」，现有数据版本管理方案管的是「名分」。名分清楚，但改动语义缺失——这正是追溯不动的根源。
追溯难的本质：训练是一次不可逆的高维压缩
表格最后一行其实点到了根子上。
模型参数是几十亿浮点数的压缩表示，训练输入是几十 TB 的原始 token。压缩不可逆——你无法从参数里反推出「少了哪段数据」。模型不是一本大型笔记本，不是把每个 token 抄录下来；它是一个把统计规律揉成分布的压缩器。想通过检查参数来找出「哪滴水改变了河流」，在数学上就不成立。
所以数据版本管理真正要撞的墙，不是存储，不是 hash，而是因果归因。而且数据不是唯一变量：随机种子、优化器状态、并行策略、batch 顺序，任何一个变动都会引起下游指标波动。要分离出「数据」的功劳和罪过，在预训练这个量级下，成本高到几乎没人做。
学术界真正把手伸进数据黑箱的：DataComp
有没有人正面刚「数据怎么影响模型」？有，但路径和我们预想的不一样。
2023 年，华盛顿大学等机构发布了 DataComp 基准，核心玩法是「数据筛选竞赛」：给你固定训练流程和候选数据池，你设计数据筛选策略，统一评测、上排行榜。2024 年 DataComp-LM 把同一套玩法搬到语言模型。
DataComp 的价值是把数据配方从玄学变成可比较的实验指标。但它回答不了追溯问题——它告诉你哪份数据更好，却不告诉你上一次效果跳水是谁引起的。筛选比赛回答「更好」，追溯要回答「为什么」。相邻，但不同。
我后来想通了：别做后验追责，做前验观测
最后聊聊我自己怎么想通的。
我以前总觉得，版本管理做到极致，就能在效果崩了时定位凶手。现在我接受了一个更務实的看法：预训练数据的归因，在可预见的未来做不到精确后验；但你能做到的，比想象的多——把「追溯」换成「观测」。
具体是三件事：
- 训练前，冻结一份数据快照。记录每个文件的路径、大小、行数、sha256、清洗脚本版本、生成时间。这份清单回答「这份语料长什么样」。
- 训练中，记录数据混入曲线。每个 global step 记录当前 batch 来自哪个源、混合比例、是否重复采样。效果一崩，先把 loss 曲线的陡变点对齐到数据切换的时间点。
- 变化后，做单变量消融。怀疑哪个源，就单独把那个源退回旧版本，跑一个小模型复现。目的不是找全因，而是筛嫌疑犯。
这套做法不 fancy，但它回答了能回答的问题：每次数据改动，都会在训练日志里留下一条可对照时间轴的切片。
最轻量的起步方案：三个不变量和一份清单
如果现在就要动手，我给自己定了三个「不变量」：不换数据源、不改清洗参数、不调 mix 比例。任何数据更新，单独成为一个新 data snapshot，先在小模型上跑消融，确认无回归再合入主训练。manifest 长这样：
一份极简的数据快照 manifest（JSON）
{
"snapshot_id": "20250115_cc_clean_v3",
"sources": [
{
"name": "common-crawl",
"path": "s3://data/cc/2024-50/",
"files": 2104,
"tokens_est": 875200000000,
"sha256": "8f3a2f...",
"cleaner_version": "dedup_threshold=0.85;len_filter=20"
}
],
"mix_ratio": {"common-crawl": 0.6, "books": 0.15, "code": 0.25}
}这样一个 JSON 几百字节，但对回溯一次训练历史的价值，超过几十 TB 的原始数据。
回到开头的问题：数据集更新了，模型效果变了，怎么追溯原因？
我的答案是：全链路追溯做不到，分阶段定位可以做。做数据版本管理，要放弃软件工程里「diff + 责任到人」的执念，转向训练科学里「对照时间轴 + 单变量消融」的思路。研究界（比如 DataComp）最终会把「数据→效果」的映射推得越来越清晰，但在那之前，你至少要保证自己是那个知道数据何时换、换了什么的人。
这不算乐观的答案，但它真实。真实世界里你能抓到的抓手，不是更好的 hash，而是你亲手记录下来的时间轴。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/1959.html