上一课算清了"要多少数据"。这一课解决"数据从哪来"——数据不是天上掉下来的。从 Common Crawl 的原始网页，到能喂给模型的干净 token，中间要经过采集、去重、过滤、配比、合成、评估六道工序。这一篇用 6 个问题把每一道工序在做什么、代价是什么算清。内容来自我做的 35 课大模型课程的第 8 课。
- 在线阅读（免登录、手机可看）：https://zhuangzhaoyeye.github.io/llm-course/
- 国内镜像：https://learn.taleverse.cn/
- 源码（MIT 许可）：https://github.com/zhuangzhaoyeye/llm_course
问题 1：抓下来的原始网页，能不能直接拿来训练？
先看事实：Common Crawl 是最大的公开网页语料库，每轮抓取超过 20 亿个网页，累计存档超 10 PiB，单轮原始体积在数百 TiB 量级。
它给三种格式，但没有一种能直接喂模型：
| 格式 | 内容 | 体积量级 | 能否直接训练 |
|---|---|---|---|
| WARC | 原始 HTTP 响应（含 HTML 标签） | 最原始、最大 | 不能 |
| WET | 抽取后的纯文本 | 比 WARC 小一个量级以上 | 仍不能（含模板文本） |
| WAT | 元数据（URL、时间、链接） | 小 | 不用于训练 |
第一步是正文抽取——用 trafilatura、resiliparse、cc_net 这类工具把"主要内容"从 HTML 里抠出来。之后还要过一组规则过滤的筛子：
| 工序 | 典型判据 | 作用 |
|---|---|---|
| 长度过滤 | 少于 50 个词或多于 10 万个词 → 丢 | 去掉碎片与超长噪声 |
| 字母词占比 | 非字母词占比 > 20% → 丢 | 去掉二进制、日志、代码混淆串 |
| 重复率过滤 | n-gram 重复 > 30% → 丢 | 去掉刷屏、模板化文本 |
| 语种过滤 | 非目标语种 → 丢 | 用 fastText 分类器判断语种 |
这些阈值来自 Gopher 等早期大规模语料工作（Rae et al., 2021），被后续管线广泛沿用。
把"存活率"算一遍，就知道"抓下来大部分不能用"是什么意思（数值为量级示意，不是某数据集的精确统计）：
| 工序级联 | 相对剩余量 |
|---|---|
| 原始抓取（HTML） | 100% |
| 正文抽取后 | 约 10%~20% |
| 去重后 | 再降至约 50%~70% |
| 叠加质量过滤后 | 最终远低于一半 |
一句话结论：原始语料的价值密度极低，几道工序后剩下的 token 只是零头——"数据不够"往往不是抓得少，而是没洗干净。
问题 2：为什么训练前要花大力气做去重？
直觉上"数据变少了应该更差"，事实相反——重复数据会让模型把"记住原文"当成"学会规律"。备考打个比方：同一道题抄 100 遍，你记住的是这道题的答案；做 100 道不同的题，你学会的是解题方法。
最自然的做法是用精确哈希（MD5/SHA256）去重，但它只认"一模一样"的字节：
| 方法 | 能发现什么 | 发现不了什么 |
|---|---|---|
| 精确哈希（MD5/SHA256） | 完全相同的文档 | 改了一个标点的同一篇文章 |
| 近似去重（MinHash+LSH） | 相似度 > 阈值的文档 | 语义相同但用词完全不同的改写 |
大规模网页抓取里，精确或近似重复的页面可占 30%~50%，而转载页往往只改一个标点或加一行页脚——精确哈希抓不到这一大类，所以必须上近似去重（MinHash + LSH）。
近似去重的核心价值在复杂度：
| 方法 | 两两比较次数（n 篇文档） | 复杂度 |
|---|---|---|
| 暴力两两比较 | n(n−1)/2 | O(n²)：n = 100 亿时 ≈ 5 × 10¹⁹ 次 |
| MinHash + LSH 分桶 | 只比同桶内的文档 | 近似 O(n)，随规模线性增长 |
把相似的文档放进同一个桶、只比桶内，就把 O(n²) 降到近似线性。具体流程是：shingling 切成 5-gram → 一组哈希函数得到签名 → LSH 分桶比较 Jaccard 相似度，超过阈值（常见 0.75~0.8）判为重复。哈希函数个数按精度需求定，公开实现里从 112 个（FineWeb）到约 9000 个（RefinedWeb）不等。
一句话结论：去重是"用数据量换数据多样性"的交易——砍掉 1/3 的 token，但换来同样算力下更广的覆盖。
问题 3：怎么判定一段文本是"好数据"？规则和模型各管什么？
去过重之后，语料里还有大量"语法通顺但毫无信息"的文本——比如产品页的参数罗列。筛它们要靠两类过滤器，各管一摊：
| 过滤器 | 管什么 | 成本 | 能筛什么 |
|---|---|---|---|
| 规则过滤 | 形式（太短、符号太多、重复率高） | 低、快 | 碎片、日志、刷屏 |
| 模型过滤 | 价值（"像教科书"才算好） | 高、要为全量跑推理 | 语法通顺但无信息量的段落 |
规则过滤可解释、可复算，但筛不出"价值"——产品页规格、SEO 拼凑文都语法通顺，规则一条都不触发。模型过滤用 fastText（176 语种分类）、质量分类器（高分 vs 低分）、有害内容分类器来补上这一层。
两者的收益是串联而不是二选一，DCLM 的对照实验把差距量化了出来：
| 数据集 | 模型规模 | MMLU 5-shot | 训练算力 |
|---|---|---|---|
| MAP-Neo（此前开源最佳） | 7B | 基线 | 基线 |
| DCLM-BASELINE | 7B | +6.6 个百分点 | 少 40% |
| Mistral-7B-v0.3 | 7B | 63% | — |
| Llama 3 8B | 8B | 66% | 比 DCLM 多 6.6 倍 |
DCLM-BASELINE 训出的 7B 模型在 MMLU 上到 64%，和 Llama 3 8B 的 66% 只差 2 个百分点，但算力只有它的约 1/6.6——差距完全来自数据筛选。（注意两个"6.6"不同：+6.6 个百分点是 MMLU 分数 vs MAP-Neo，1/6.6 是算力 vs Llama 3 8B。）
一句话结论：规则过滤管"形式"、模型过滤管"价值"，两者串联——先用规则砍掉大部分垃圾省推理成本，再用模型在剩余部分精挑。
问题 4：各领域的数据该按什么比例混合？
筛干净之后，剩下的"好数据"来自不同领域——网页、代码、论文、百科。它们该按什么比例混合？ 配比直接决定模型的能力分布，不能拍脑袋（配营养餐打个比方：配方错了，练得再多也补不到该补的地方）。
三种定配比的路线，成本差 30 倍：
| 路线 | 怎么做 | 代价 |
|---|---|---|
| 启发式 | 按各领域现有 token 量分配（The Pile 做法） | 零成本，但可能次优 |
| 面向下游任务调 | 在多个下游任务上搜最优权重 | 可能要训上千个模型；过拟合任务集 |
| 代理模型搜索（DoReMi） | 小模型自动搜权重，再放大模型 | 需一次代理模型训练 |
DoReMi（arXiv:2305.10429）用 Group DRO 训练一个 280M 代理模型自动搜索配比，再用该配比训练 8B 模型：
| 指标 | 基线（The Pile 默认配比） | DoReMi 配比 |
|---|---|---|
| 平均 few-shot 准确率 | 基线 | +6.5 个百分点 |
| 达到基线精度所需步数 | 1.0× | 1/2.6 |
关键假设是配比的优劣在小模型上已可分辨——代理模型参数量只有目标的约 1/30（280M → 8B），才让自动搜索变得划算。第二行那个 1/2.6 换算成算力，相当于省了近 60% 的预训练成本。
一句话结论：数据配比是被低估的算力杠杆——不改模型、不改算力，只调采样权重就能少跑 60% 步数达到同样精度，而代理模型把试错成本压到约 1/30。
问题 5：合成数据能补上数据缺口吗？为什么会有"模型崩塌"？
真实数据快用完了（上一课的数据墙），自然想到用模型生成数据来补。但这里有个坑，叫模型崩塌（Model Collapse）。
Shumailov 等在 Nature（2024, 631, 755-759）证明，不加区分地使用模型生成内容，会让模型出现不可逆缺陷——原始分布的尾部（罕见事件）被逐代抹掉。三种用法，三种结局：
| 方式 | 训练集构成 | 结局（理论结论） |
|---|---|---|
| 纯合成 | 第 N 代全部用第 N−1 代生成 | 必然崩塌 |
| 替换式混合 | 每代用新合成替换掉部分真实数据 | 逐步崩塌 |
| 累积式混合 | 真实数据不删，合成不断追加 | 可避免崩塌 |
差别不在"用不用合成数据"，而在真实数据是被留下还是被替换。为什么会丢"尾部"：稀有事件在采样样本里本来就欠代表，一代代只用自己生成的数据训练，偏差逐代累积，模型最后干脆忘记稀有事件存在。
一句话结论：合成数据是用法问题——替换真实数据必然崩塌，累积而不删真实数据才安全；工程铁律是永远保留一份人类撰写的真实数据作锚点，合成数据只做增量。
问题 6：怎么知道一份语料"变好了"？
把整条管线收口，最后一个问题：怎么判断一份语料真的变好了？ "洗得干净"本身不是目标——干净但没提升能力的语料毫无价值。判据必须来自模型层的对照实验。
两层指标：
| 层次 | 指标 | 特点 |
|---|---|---|
| 语料层 | 去重率、领域分布熵、平均文档长度 | 便宜、先跑，只能发现明显异常 |
| 模型层 | 固定模型+算力、只换数据集的 perplexity 与下游分数 | 贵，但唯一可信 |
关键在于只改一个变量：如果同时换了模型和数据集，就分不清收益来自哪里。DCLM（arXiv:2406.11794）正是用"固定 7B 模型、2.6T token、只换数据集"的对照实验，才量化出 +6.6 个百分点。
最后把代价算清——为什么不直接上大模型测：
| 方案 | 对照成本 | 结论可信度 |
|---|---|---|
| 用 7B 模型测每组语料 | 每次完整预训练（极高） | 高 |
| 用 400M~1B 小模型测 | 约 1/50~1/100（估算） | 中（趋势可信，绝对值不可外推） |
所以实践中是两级筛选：先用小模型淘汰明显差的方案，只对少数候选做全尺寸验证。
一句话结论：数据工程的闭环判据是"同一算力下模型是否更强"，而不是"语料是否更干净"——没有对照实验，就只是手工艺，不是工程。
小结
| 问题 | 结论 | 一个数字 |
|---|---|---|
| 原始网页能用吗 | 价值密度极低，几道工序后只剩零头 | 正文抽取后约 10%~20% |
| 为什么去重 | 用数据量换数据多样性，避免背答案 | 重复页面 30%~50% |
| 好数据怎么判 | 规则管形式、模型管价值，串联用 | DCLM 少 40% 算力高 6.6pp |
| 数据怎么配比 | 配比是被低估的算力杠杆 | DoReMi 1/2.6 步数追平 |
| 合成数据能用吗 | 替换→崩塌，累积→安全 | 纯合成必然崩塌 |
| 语料怎么评估 | 同一算力下模型是否更强 | 小模型约 1/50~1/100 成本 |
参考与说明
- Common Crawl 规模：官方 About 页 https://www.commoncrawl.org/about（20 亿网页/轮、10 PiB 累计）
- Gopher 语料过滤阈值：Rae et al., Scaling Language Models, 2021
- NeMo 过滤器（Adapted from Gopher）：https://docs.nvidia.com/nemo-framework/user-guide/25.07/datacuration/api/filters.html
- DCLM：Li et al., DataComp-LM, arXiv:2406.11794
- DoReMi：Xie et al., DoReMi: Optimizing Data Mixtures Speeds Up Language Model Pretraining, arXiv:2305.10429
- RedStone（117 个 64 位 MinHash 签名）：Chang et al., arXiv:2412.03398
- The Pile：Gao et al., 2020
- 模型崩塌：Shumailov et al., AI models collapse when trained on recursively generated data, Nature 2024, 631, 755-759
- 纯合成必然崩塌的理论结论：Seddik et al., arXiv:2404.05090；累积 vs 替换：Gerstgrasser et al., arXiv:2404.01413
- 文中算术均已用代码独立复算：
n(n−1)/2在 n=10¹⁰ 时 ≈ 5×10¹⁹、8B/280M ≈ 28.6、1/2.6 ≈ 0.385（省近 60%）、1/6.6 ≈ 0.15。标注「示意/估算」的数字（存活率量级、小模型 1/50~1/100 成本）为量级示意，不指向某数据集的精确统计。 - 两处来源未能逐字核到一手、保留"待人工核实"：① 卡 1 引的 Liang et al.《Data Preparation for Large Language Models》(JCST 2026) 题名与刊期；② 卡 3 引的 CuraWeb 编号。
- 说明：这套课程由 AI 在我设计的规则下生成，再经过脚本检查和独立审查；审查发现过不少问题，已写在仓库 README 里。发现错误欢迎提 Issue，写清位置，我逐条核实。
继续学
完整课程 35 课，这一篇是第 8 课。下一篇进入预训练全流程：拿到干净数据后，模型是怎么一步步被训练出来的。
- 课程：https://zhuangzhaoyeye.github.io/llm-course/
- 国内镜像：https://learn.taleverse.cn/
- 源码：https://github.com/zhuangzhaoyeye/llm_course ，觉得有帮助欢迎点个 Star
