章节导航 第 4 章 / 共 30 章
数据获取与多源采集
网页、代码、书籍、论文、多语料的多源采集策略与可得性权衡。
“15 万亿 token 不是从天上掉下来的。它们来自互联网的每一个角落——有人类知识的精华，也有信息污染的沼泽。”
预训练数据工程的入口，是从原始字节到纯文本的转换。这一步的产出质量，直接决定了后续所有环节的”地基”是否稳固。
预训练数据的”地基”工程，本质是多源采集——既要回答”从哪里采”，也要回答”怎么把原始字节变成干净文本”。本章以数据源的分类体系为主干：先确立以 Common Crawl 为代表的网页语料基石，再依次展开书籍、学术、代码、问答等高质量垂直源，进而讨论多语言、合规与新兴挑战；与此同时，把采集与解析的工程实操（WARC 下载、HTML 抽取、PDF 解析、采集架构）嵌入每一类数据源的落地环节，使”分类体系”与”工程流水线”两条线索交织成完整的获取图景。
4.1 Common Crawl：大模型的基石与工程实战
几乎所有主流大模型的预训练数据都有一个共同的底层来源：Common Crawl（CC）。它既是”量”的保证，也是整套采集工程的技术起点。本节以 CC 的数据结构、快照规模与下载分发为骨架，融入实战所需的 WARC 解析、S3 分发与工业级流水线。
4.1.1 CC 是什么
Common Crawl 是一个由非营利组织运营的开放网络爬虫项目。自 2008 年以来，它持续爬取互联网上的公开网页，并将爬取结果以 WARC（Web ARChive）格式免费开放。
规模：
- 截至 2026 年，CC 存档了超过 3000 亿 个网页，跨越 15 年（2008 起），每月新增 30–50 亿页面，被 10,000+ 论文引用
- 体积口径上 CC 存档超过 250 PB 的原始网页数据
- 所有数据托管在 AWS S3 上，可以免费下载
需要注意统计口径的差异：早期 CC 快照的”30–40 亿页面”是包含重复 URL 和重定向的原始页面计数，而去重 URL 数通常在 20 亿左右。
4.1.2 快照规模与 HuggingFace Storage Bucket 分发
CC 每月发布一次快照。以 2026 年中为例：
- 主锚点：CC-MAIN-2026-39（2026-09-04 至 2026-09-17 爬取，2026-09-19 发布）包含 2.17B（21.7 亿）网页、361.4 TiB 未压缩内容，数据来自 4040 万 host / 3320 万 registered domains，含 5.872 亿此前未访问过的新 URL
- 比较参考：CC-MAIN-2026-34（2026-08-07 至 2026-08-20 爬取，2026-08-24 发布）包含 2.14B（21.4 亿）网页、360 TiB 未压缩内容，数据来自 4020 万 host / 3310 万 registered domains，含 7 亿此前未访问过的新 URL
- 比较参考：CC-MAIN-2026-17（2026-04-10 至 2026-04-23 期间爬取）包含 2.19B（21.9 亿）个 web pages、379.2 TiB 未压缩内容，数据来自 4320 万 host / 3540 万 registered domains，含 6.605 亿此前未访问过的新 URL
- 单快照约有 100,000 个 WARC 文件（每个约 0.85GB 压缩）
CC-MAIN-2026-39 文件清单：Segments 100；WARC 100,000 个 / 82.79 TiB；WAT 100,000 / 14.16 TiB；WET 100,000 / 5.89 TiB；Robots.txt files 100,000 / 0.15 TiB；Non-200 responses 100,000 / 2.70 TiB；URL index 302 / 0.23 TiB；Columnar URL index 900 / 0.20 TiB。本章数据核于 2026-10-08。
📌 漂浮指针提示：CC 每月发一版，任何写成”最新快照""截至本章写作时”的表述都会在几周内腐烂。本章此后凡引用快照，一律写快照号 + 爬取窗口 + 核于日期三元组；读者读到本章时若已过数月，请以
data.commoncrawl.org的 Latest Crawl 页为准重新锚定，不要沿用本章的数字。
⚠️ 数据更正（2026-09-18 编辑核）：本章早期版本在「比较参考」行写作「2.19 亿个 web pages」。CC 官方公告为 2.19 billion（21.9 亿），379.2 TiB 为未压缩口径；与之对应的 WARC 压缩体积为 85.05 TiB。原文与紧邻上一行的「2.10B（21 亿）」相差一个数量级，属内部自证的数量级错误，已按官方公告更正。
体积口径提示：CC 公告同时给出未压缩内容体积（如 2026-08 为 360 TiB）与 WARC 压缩体积（84.78 TiB），两者相差约 4 倍。做带宽与存储预算时务必区分——本章后续凡出现「TiB」，除特别说明外均指官方的 WARC 压缩体积。
分发渠道的变化（2026 起）：从 CC-MAIN-2024-51 起，CC 数据主要托管在 AWS S3 公开桶 s3://commoncrawl/；而从 2026-04 快照起，CC 已通过 HuggingFace Storage Bucket 分发，为研究者提供更便捷的拉取入口（同时 S3 原始通道仍保留）。生产环境建议跟踪最新快照，并在多快照间做跨期去重。
WARC 规范变更（2026-04 起）：从 CC-MAIN-2026-17 快照起，WARC revisit records 的 Content-Type 从 message/http 变更为 application/http;msgtype=response（对齐 iipc/warc-specifications#55）。这是一项对下游解析工具的破坏性变更——历史解析器（基于固定 Content-Type 字符串匹配）会丢失新快照的 revisit 记录，需要检查工具兼容性，解析时须同时兼容两种格式。
4.1.3 三种格式对比：WARC / WAT / WET
CC 提供三种格式的数据，工业级流水线首选 WARC——自己控制解析质量，不依赖 CC 的预提取。WET 虽然方便，但 CC 的 trafilatura 版本可能落后，且无法做精细的正文/导航/页脚切分。
| 格式 | 内容 | 大小（单快照） | 用途 |
|---|---|---|---|
| WARC | 完整响应（含 HTTP 头 + HTML + 元数据） | ~100TB | 主流选择，信息最完整，需自己做文本提取 |
| WAT | 提取的链接和元数据 | ~30TB | 链接分析、PageRank、数据规划 |
| WET | 预提取的纯文本 | ~20TB | 简化使用，但解析质量一般 |
实操建议：使用 WARC 格式 + 自选的文本提取工具（如 trafilatura）。CC 自带的 WET 提取质量一般——它使用的提取器比较老旧，经常包含导航栏、广告等噪声文本。FineWeb 的实验证实，用 trafilatura 从 WARC 重新提取可以显著提升数据质量。
4.1.4 WARC 文件结构
WARC 是行式存储的容器格式，每条记录由 header + payload 组成：
WARC/1.0
WARC-Type: response
WARC-Record-ID: <urn:uuid:...>
WARC-Date: 2024-12-15T08:30:00Z
WARC-Target-URI: https://example.com/article
Content-Type: application/http; msgtype=response
Content-Length: 8456
HTTP/1.1 200 OK
Content-Type: text/html
...
<html><head>...</head><body>...</body></html>
WARC/1.0
WARC-Type: response
...4.1.5 WARC 下载与 S3 分发代码
# CC 的 WARC 文件按月发布在 AWS S3 上
# 路径：s3://commoncrawl/crawl-data/CC-MAIN-<YYYY>-<WW>/segments/.../warc/CC-MAIN-<timestamp>-<index>.warc.gz
# 示例快照：CC-MAIN-2026-39 (2026-09 采集，2.17B 网页，361.4 TiB 未压缩 / WARC 82.79 TiB 压缩) <!-- edit: 2026-10-08 快照锚点前移：2026-34 → 2026-39 -->
# 自 2026-04 快照起，CC 已通过 HuggingFace Storage Bucket 分发，S3 通道仍保留
# CC-MAIN-2024-51 仍可用作示例，生产环境建议跟踪最新快照
import boto3
import gzip
import io
from warcio import ArchiveIterator
def download_warc_list(snapshot="CC-MAIN-2026-39"):
"""获取某个月 CC 快照的 WARC 文件路径列表"""
s3 = boto3.client('s3')
paginator = s3.get_paginator('list_objects_v2')
paths = []
for page in paginator.paginate(
Bucket='commoncrawl',
Prefix=f'cc-index/collections/{snapshot}/indexes/'
):
for obj in page.get('Contents', []):
paths.append(obj['Key'])
return paths
def stream_warc_and_extract(warc_path, output_queue):
"""
流式读取 WARC.gz，逐条记录解析
采用流式是为了避免单文件解压占用过多内存
"""
s3 = boto3.client('s3')
response = s3.get_object(Bucket='commoncrawl', Key=warc_path)
# 流式解压 + WARC 迭代器
for record in ArchiveIterator(response['Body']):
if record.rec_type != 'response':
continue
uri = record.rec_headers.get_header('WARC-Target-URI')
content_type = record.http_headers.get_header('Content-Type', '')
# 只处理 HTML 响应（注意 2026-04 起 Content-Type 兼容两种格式）
if 'text/html' not in content_type:
continue
html_bytes = record.content_stream().read()
# 推入下游解析队列
output_queue.put({
'url': uri,
'html': html_bytes,
'warc_date': record.rec_headers.get_header('WARC-Date')
})4.1.6 工业方案：NeMo Curator
以上手动 WARC 解析提供了原理理解，但工业级场景推荐使用 NVIDIA NeMo Curator 的 CommonCrawlDownloadExtractStage（NeMo Curator 26.04，基于 Nemotron-CC 流水线开源）。
版本双轨说明（2026-10-08 补）：NeMo Curator 有两套并行的版本命名体系，引用时必须写明是哪一套。本章正文所用的”26.04”是 NVIDIA 容器版本线（与 NGC 镜像 tag 同步）；PyPI 包名
nemo-curator的版本线则是独立的语义化版本号，当前最新为 1.3.0（2026-07-27），中间还有 1.2.0（2026-05-14）。也就是说，本章”26.04 新增能力”清单对应的是容器版本线，1.2.0 与 1.3.0 两个 minor 发布晚于本章所引的 26.04，清单内容在这两个 minor 中是否仍然成立本轮未核。⚠️ Python 版本上界：
nemo-curator的requires_python为>=3.11,<3.14，即 Python 3.14 被排除在外。本章与第 7 章 §7.8.4 都建议”锁定版本”，这个上界是锁定策略必须知道的信息——把一个不支持 3.14 的包锁进 3.14 环境，是版本锁定里最容易踩的一种坑。本条核于 2026-10-08。
三阶段流水线（26.04 架构）：
- URL 生成：根据 CC 快照索引自动生成 WARC 文件 URL 列表
- 下载：支持 HTTPS 和 S3 双模式（
use_s3=True可直接从 S3 传输，避免 HTTPS 限速），可自动 fallback - 迭代抽取：流式迭代 WARC 记录 → 内置抽取，内存友好；内置三种抽取器——
jusText（通用）、resiliparse（高速）、trafilatura（高质量），可按需切换
26.04 新增能力：
- 自动语种识别（LID），无需单独调用 fastText
- PDF 流水线（Nemotron-Parse Xenna）：四阶段 PDF 解析，基于 pypdfium2
- vLLM 嵌入去重：语义去重默认启用，模型从 all-MiniLM-L6-v2 切换为 google/embeddinggemma-300m
- 与 NeMo Curator 后续质量过滤流水线无缝集成
- 分布式处理支持（Dask/Spark）
# NeMo Curator Common Crawl 流水线示例
from nemo_curator import Sequential
from nemo_curator.download import download_common_crawl
from nemo_curator.datasets import DocumentDataset
# 单行启动 CC 下载 + 抽取 + 语种识别
pipeline = Sequential([
download_common_crawl(
snapshot="CC-MAIN-2026-39",
output_dir="./cc_output",
extractor="trafilatura", # 或 "jusText" / "resiliparse"
download_method="s3", # 或 "https"；use_s3=True 直接 S3 传输，避免限速
language="en,zh", # 自动 LID 过滤
seed=42
),
])
dataset = pipeline.run()
print(f"下载完成：{len(dataset.df)} 篇文档")对于从头搭建流水线的团队，直接使用 NeMo Curator 可以跳过大部分手动编码，将精力聚焦于数据策略而非工程实现。
4.1.7 工程参数：下载并发控制
CC 单快照有约 100,000 个 WARC 文件（CC-MAIN-2026-39 快照 WARC 合计 82.79 TiB 压缩，约 0.83GB/文件）。下载时需要注意：
# 推荐的 S3 并发下载配置
S3_CONFIG = {
'max_pool_connections': 50, # S3 连接池
'multipart_threshold': 8 * 1024**2, # 8MB 以上启用分片
'multipart_chunksize': 8 * 1024**2,
}
# 千万别用 requests 直接下载 CC——AWS S3 限速会让你怀疑人生
# 必须用 boto3 + s3 transfer manager踩坑经验：CC 的 WARC.gz 是单文件 gzip，不能 seek。如果想并行处理单文件，需要先解压再分块，或者用 warcio 的流式接口。
4.1.8 CC 快照之间的质量差异
一个很容易被忽视的事实是：不同时间的 CC 快照质量差异巨大。原因包括：
- 爬虫策略变化：CC 的爬取策略在不同时期有调整，某些时期可能更偏向某类网站
- 互联网内容的变化：垃圾网站的占比在逐年上升，SEO 内容越来越多
- JavaScript 渲染页面的增加：2020 年后，越来越多的网站使用 JavaScript 框架，CC 无法正确爬取这些页面
- AI 生成内容的泛滥：2023 年后，大量 AI 生成的低质量内容充斥互联网
值得关注的趋势：2024 年之后的快照中，AI 生成内容的占比持续攀升。在CC-MAIN-2026-39（2026-09 采集）分析中，.com 域名占比持续领先，而 .cn 域名占比偏低，反映了 CC 爬取的语言和地域偏差在该快照中仍然显著。
关于”AI 生成内容占比”的量级，本书第 3 章 §3.3.1 给出了可复核的锚点：Stanford HAI《AI Index Report》口径下，超过 50% 的新增网络文本已由模型生成（垂直领域普遍更高），且该报告同时指出合成数据尚未在预训练阶段替代真实数据。因此这里的谨慎建议是——把”AI 内容占比上升”当作需要每期实测的趋势来对待，而不是直接引用某个固定百分比；每接入一个新快照，建议用第 3 章给出的检测方法重新估一次占比，再决定是否纳入。
实操建议：
- 不要盲目使用最新的 CC 快照——新快照中的 AI 生成垃圾内容可能更多
- 对不同时间段的快照分别评估质量
- 早期快照（2013–2018）的网页质量可能更高（AI 生成内容少），但技术知识可能过时
- 混合使用多个时间段的快照，在时效性和质量之间取平衡
4.1.9 CC 的固有偏差
语言偏差：英文内容占 CC 总量的 40–50%，中文约占 10–15%。很多低资源语言的占比 < 1%。
地域偏差：美国、欧洲的网站爬取最充分，亚洲和非洲的很多网站覆盖不足。
类型偏差：新闻网站、商业网站被大量爬取，但很多高质量内容（如付费论文、书籍、私有知识库）不在 CC 中。
时效偏差：CC 的爬取频率对不同网站不同——热门网站可能每月被爬取多次，小众网站可能一年才被爬取一次。
4.1.10 CC-INDEX 列式索引与选择性下载
逐文件列举 WARC 路径（4.1.5 的 download_warc_list）只能拿到”整批”文件清单，但工业采集很少需要下载全部 100,000 个 WARC。CC 同时提供 列式索引（columnar index），让团队在下载之前就用 SQL 精确圈定目标网页，大幅节省带宽与算力。
索引以 Parquet 格式发布在：
s3://commoncrawl/cc-index/collections/CC-MAIN-<snapshot>/indexes/*.parquet每行对应一个 WARC 记录，关键字段包括 url、url_host_registered_domain、url_host_tld、content_language、mime_type、warc_filename、warc_record_offset、warc_record_length 等。借助 AWS Athena 的 cc-index-table（或本地 DuckDB/Polars 读取 Parquet），可直接查询：
-- 仅圈定英文、主域为 wikipedia.org 的 HTML 页面，并返回其在 WARC 中的位置
SELECT url, warc_filename, warc_record_offset, warc_record_length
FROM cc_index
WHERE crawl = 'CC-MAIN-2026-39'
AND url_host_registered_domain = 'wikipedia.org'
AND mime_type = 'text/html'
AND content_language = 'eng'
LIMIT 1000;查询得到的 warc_record_offset 与 warc_record_length 支持对单个 WARC.gz 做 range GET（HTTP Range 头或 boto3 Range 参数），跳过整文件下载、只拉取目标记录——这对”按域名/语种采样”的场景极为关键。实际流水线中，常见做法是：先用列式索引做轻量筛选，再用 range GET 精准抽取，整体成本可比全量下载降低一到两个数量级。
经验法则：全量训练才需要 100,000 个 WARC 全量下载；如果是领域微调、语种子集或消融实验，务必先用 cc-index 圈定再 range 抽取。CC 的免费额度依赖 AWS 公开访问，但跨区下载仍会计费，range GET 是控制成本的核心手段。
4.1.11 WARC revisit 记录与增量去重
CC 为节省存储，对”内容未变、仅 URL 变化”的页面使用 revisit 记录（WARC-Type: revisit），其 payload 不含完整 HTML，而是指向一个之前已抓取的”profile”（通过 WARC-Refers-To 关联）。解析器若只认 response 类型，会漏掉这部分页面——但更重要的是，revisit 记录本身就是天然的”同内容多 URL”信号，对后续 URL 级去重极具价值。
因此，工业解析器通常：
- 同时处理
response与revisit两类记录； - 对 revisit 记录，沿
WARC-Refers-To回溯到 profile 的文本内容（或仅保留 URL 映射，用于去重计数）； - 结合 4.6 的数据溯源，记录每条 URL 的”首次出现快照”，使跨快照去重（坑 1）有迹可循。
4.2 高质量语料源：从”量”到”质”
CC 是”量”的保障，但”质”需要额外的高质量数据源来补充。下表汇总了预训练数据的”主流来源”，后续小节逐一展开：
| 数据源 | 内容类型 | 规模（tokens 级别） | 质量 | 关键挑战 |
|---|---|---|---|---|
| Common Crawl (CC) | 网页快照 | 100T+ | 参差不齐 | HTML 清洗、去重、低质过滤 |
| GitHub | 代码仓库 | 1T+ | 中-高 | 许可证、低质代码过滤 |
| arXiv | 学术论文 | 100B+ | 高 | PDF 公式解析 |
| Wikipedia | 百科 | 4B+ | 高 | 多语种平衡 |
| Books (Books3/Gutenberg/PBLLM) | 书籍 | 200B+ | 高-中 | 版权、PDF 解析 |
| StackExchange | 问答 | 100B+ | 中-高 | 答案质量、投票排序 |
| OpenWebMath | 数学网页 | 10B+ | 高 | LaTeX 公式还原 |
以 Llama3 的 15T tokens 为例，典型配比：
Common Crawl 清洗后: 60-70% (10T+)
GitHub 代码: 10-15% (1.5T)
Books: 5-10% (1T)
arXiv: 3-5% (500B)
Wikipedia: 1-2% (200B)
StackExchange: 1-2% (200B)
其他(数学/多语/合成): 5-10% (1T)核心结论：Common Crawl 是绝对主力，但代码、论文、书籍贡献了”高密度知识”的绝大部分。
4.2.1 维基百科（Wikipedia）
价值：
- 知识密度极高——每篇文章都是由社区编辑审核的结构化知识
- 覆盖面广——300+ 种语言，超过 6000 万篇文章
- 格式规范——标题、段落、列表、引用的结构清晰
数量：
- 英文维基约 40–50 亿 token
- 中文维基约 10–15 亿 token
- 在万亿 token 的训练集中，维基百科的占比通常 < 1%
处理要点：
- 去除维基标记语法（MediaWiki markup）
- 保留文章正文，去掉编辑历史、讨论页面
- 注意处理模板、信息框（infobox）——这些结构化内容是否保留取决于你的目标
- 某些维基百科文章质量差（stub 文章只有几句话）——需要做长度过滤
局限：
- 风格单一——“百科全书腔”
- 知识有时效性——更新可能滞后
- 中文维基的覆盖度远不如英文
4.2.2 书籍语料
Books3 / Gutenberg / 自建书籍语料
书籍是最高质量的长文本来源之一。一本书通常有几万到几十万词，段落连贯，逻辑清晰，语言规范。
价值：
- 长上下文学习：书籍是训练模型处理长文本的天然数据
- 知识深度：书籍对一个主题的讲解通常比网页深入得多
- 写作质量：经过编辑和出版流程的文本，质量有保障
主要来源：
- Project Gutenberg：公版（public domain）书籍，约 7 万本。主要是 1920 年代之前的英文文学作品。免费且无版权问题
- Books3（争议中）：约 20 万本现代书籍，包含大量受版权保护的作品。因版权诉讼（如 NYT vs OpenAI）而引发争议
- 中文书籍：公开来源非常有限。可以考虑中文古典文学（二十四史、诸子百家等古籍已进入公版）和部分开放获取的现代作品
版权风险：
- Gutenberg 的内容是安全的——这些书的版权已经过期
- 现代书籍的版权问题是当前最大的法律风险之一
- 建议：在合规要求严格的场景下，只使用明确的公版或开放许可的书籍
书籍数据集的工程细节：除来源差异外，书籍语料的工程化还有几处要点：
- PG19 / Project Gutenberg 衍生集：DeepMind 的 PG19 是从 Gutenberg 中筛选的、版权清晰、以 19 世纪英文长篇小说为主的约 28GB 语料，常用于长程依赖（long-range dependency）评测；其价值不在训练体量，而在”干净长文”的基准意义。
- 公版时间线差异：不同司法管辖区的公版年限不同（作者去世 +50/70 年），跨国使用需按最严口径处理；中文古籍（二十四史、诸子）虽已公版，但多为繁体/竖排/无标点，需先做繁简转换与标点恢复。
- 扫描版书籍：大量现代书籍只有扫描 PDF，无法用 LaTeX 流程，必须走 MinerU / Nougat 的 OCR 路线，且需处理版心切分、页眉页脚噪声。
- 长上下文价值：书籍章节天然呈现跨千字乃至跨万字的论证链，是训练模型”长程一致性与逻辑推进”的最佳来源之一；与网页短文的随机跳转相比，书籍对长上下文预训练的贡献是结构性的。
4.2.3 学术论文与 PDF 解析
来源：
- arXiv：预印本论文库，主要覆盖物理、数学、计算机科学、生物学等。约 250 万篇。
- Semantic Scholar Open Research Corpus (S2ORC)：大规模学术论文语料，覆盖多个学科。约 1.36 亿篇论文的元数据，其中约 1200 万篇有全文。
- PubMed / PMC：生物医学领域的论文。
- 中文学术论文：CNKI（知网）等来源，但多数有版权限制。
处理要点：
- PDF → 文本的转换质量是关键挑战。学术论文的排版复杂（双栏、公式、图表、参考文献），OCR 和 PDF 解析工具的效果差异很大
- LaTeX 公式的处理：保留 LaTeX 源码还是转换为文本？对于训练数学能力，保留 LaTeX 源码更有价值
- 参考文献列表：通常应该被过滤掉（大量重复且信息密度低）
- 作者信息和致谢：包含 PII，需要处理
PDF 解析工具对比（论文与书籍的核心挑战）：PDF 是为打印设计的，不是为文本提取设计的。
| 工具 | 公式还原 | 表格 | 速度 | 多栏 | 适用 |
|---|---|---|---|---|---|
| PyPDF2 / pdfminer | 无 | 差 | 快 | 差 | 简单 PDF |
| Grobid | 部分 | 中 | 慢 | 好 | 学术论文 |
| Nougat (Meta) | 强（LaTeX） | 中 | 慢(GPU) | 好 | arXiv 论文 |
| Marker | 强 | 好 | 中(GPU) | 好 | 通用 PDF |
| MinerU | 强（LaTeX） | 强 | 中(GPU) | 好 | 论文+书籍+复杂版式 |
| docling | 中 | 好 | 快 | 好 | 工业文档 |
论文 PDF 首选 Nougat 或 MinerU；书籍 + 复杂版式首选 MinerU。
MinerU 实战：MinerU（OpenDataLab, 2024）是当前最强的开源 PDF 解析器。2025-06 的 2.0 版本完成架构重构：输入范围从 PDF/图片扩展到 DOCX/PPTX/XLSX/网页，新增化学论文解析（分子结构识别、化学反应提取，与 A4Chemistry 合作），综合解析准确率较前代提升约 22%，核心模型约 0.9B 参数（decoupled 视觉-语言双编码器），GitHub 星标截至 2026-08 已破 81K。支持公式 → LaTeX 还原、表格 → HTML/Markdown 还原、多栏阅读顺序识别、图表与正文分离。
注意：MinerU 2.0 起包名由
magic-pdf更名为mineru，命令行工具同步变更；推理后端由单一模式扩展为三引擎（pipeline / vlm / hybrid）。
版本锚点（2026-09-18 补，2026-10-08 更新）：MinerU 迭代很快，本章正文描述与代码示例以 2.0（2025-06-13 发布） 为基准。截至 2026-10-08，PyPI 上
mineru的最新版本为 4.0.10（2026-09-29）；4.0.0 于 2026-09-16 发布，此后 11 天内又发布了 8 个补丁版本（4.0.3 至 4.0.10）；此前的 3.x 线代表性版本为 3.4.5（2026-08-14）。版本演进路径为 2.0（2025-06）→ 3.x（2025 下半年—2026-08）→ 4.0（2026-09）。这个速率本身就是结论。上文说”解析器的输出格式变化会直接污染下游语料，属静默退化风险最高的环节之一”，那不是抽象警告——4.0 线在 13 天内发了 11 个版本，是观测到的实际迭代频率。因此生产接入的建议要收紧：
pip install mineru==<锁定版本>之外，升级前必须用固定样本集重跑解析结果并 diff。补丁级更新同样可能改变输出格式，而在高频补丁线上，“我们没改代码，只是升了个小版本”恰恰是最难追溯的污染路径。⚠️ 4.x 的 CLI 参数与 Python API 兼容性本轮仍未逐项实测，代码不改。⚠️ 兼容性提示：4.x 为大版本升级，命令行参数与部分 API 可能与本章示例不一致。本章的 CLI/Python 示例未按 4.x 重写——生产接入前请以
pip install mineru==<锁定版本>固定版本，并对照官方 4.x 文档核验参数。版本锁定的实践理由见下：解析器的输出格式变化会直接污染下游语料，属”静默退化”风险最高的环节之一。
# MinerU 通过命令行调用，最简用法（2.0 起 CLI 由 magic-pdf 更名为 mineru）
# mineru -p input.pdf -o output/
# 工业级批量处理脚本
import subprocess
from pathlib import Path
def batch_parse_pdfs(pdf_dir, output_dir, gpu_id=0):
"""
批量解析 PDF 为 Markdown
MinerU 2.0 三引擎：pipeline（纯 CPU 可跑）/ vlm-engine（vLLM/LMDeploy）/ hybrid-engine（默认推荐）
"""
pdfs = list(Path(pdf_dir).glob('*.pdf'))
for pdf in pdfs:
cmd = [
'mineru',
'-p', str(pdf),
'-o', f'{output_dir}/{pdf.stem}',
'-m', 'auto', # 自动选择模式
'-d', str(gpu_id), # GPU 设备
'--lang', 'en,zh' # 多语种
]
try:
result = subprocess.run(
cmd, capture_output=True, timeout=300, text=True
)
if result.returncode != 0:
log_error(pdf, result.stderr)
except subprocess.TimeoutExpired:
log_error(pdf, 'Timeout after 300s')Nougat 与公式还原：Nougat 是 Meta 开发的基于 ViT 的 PDF 解析器，特别擅长公式还原，直接将 PDF 转为 Markdown + LaTeX。
# Nougat 直接将 PDF 转为 Markdown+LaTeX
# 输入：paper.pdf
# 输出：paper.mmd（Mathpix Markdown）
# 命令行：nougat path/to/file.pdf -o output_dir
# 一个解析后的样例：
"""
# Attention Is All You Need
## Abstract
We propose a new simple network architecture, the Transformer,
based solely on attention mechanisms, dispensing with recurrence
and convolutions entirely.
$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$
where $Q \in \mathbb{R}^{n \times d_k}$ ...
"""踩坑经验：Nougat 对扫描版 PDF（图片型）效果差，需要先用 OCR 处理。MinerU 的 auto 模式可以自动切换。
arXiv 采集与 LaTeX 源码：arXiv 提供 bulk access（S3 上公开），且大部分论文有 LaTeX 源码，比 PDF 解析更准确。
# arXiv S3 bucket
aws s3 ls s3://arxiv/pdf/ --recursive | head
# 完整下载约 2.5 TB，含 240 万+ 篇论文
# 推荐方式：用 arxiv-oai-mcp 工具或 kaggle 的 arxiv datasetdef parse_arxiv_latex(source_tarball):
"""
从 arXiv tarball 提取 LaTeX 源码，转纯文本
比从 PDF 解析质量高 10 倍以上
"""
with tarfile.open(source_tarball) as tar:
# 找到主 tex 文件
tex_files = [f for f in tar.getnames() if f.endswith('.tex')]
main_tex = find_main_tex(tex_files)
# 提取内容
content = tar.extractfile(main_tex).read().decode('utf-8')
# 去除 LaTeX 命令，保留文本（推荐用 pylatexenc 或 panflute）
from pylatexenc.latex2text import LatexNodes2Text
text = LatexNodes2Text().latex_to_text(content)
return text踩坑经验：arXiv 的 LaTeX 源码格式极其混乱（每个作者风格不同）。建议先尝试 LaTeX 源码，失败再回退到 PDF（Nougat/MinerU）。
4.2.4 代码数据
来源：
- GitHub：最大的开源代码托管平台。The Stack 数据集从 GitHub 收集了 TB 级的代码
- The Stack v2：覆盖 600+ 种编程语言的去重代码数据集
- StarCoder Data：BigCode 项目整理的高质量代码数据
处理要点：
- 许可证过滤：只使用允许用于训练的开源许可证（如 MIT、Apache 2.0、BSD）。GPL 等 copyleft 许可证有争议
- 质量分层：
- Tier 1：高 star、有完善文档和测试的项目
- Tier 2：中等 star、有基本文档
- Tier 3：低 star、无文档
- 过滤掉：自动生成的代码、配置文件、数据 dump
- 编程语言比例：Python 通常占比最大（与用户需求匹配），但也需要其他语言来保证多样性
- 代码上下文的价值：不只是代码本身——README、docstring、commit message、issue discussion 都是有价值的训练数据
GitHub 代码采集策略（工程实操）：
# GitHub API 限制：5000 req/h，所以要用 GH Archive + 仓库快照
# 推荐用 Google BigQuery 的 GH Archive 数据集
# 高质量代码仓库筛选标准
REPO_FILTERS = {
'min_stars': 10, # 至少 10 star
'min_commits': 5, # 至少 5 次提交
'exclude_fork': True, # 排除纯 fork
'exclude_template': True, # 排除模板仓库
'exclude_size_kb': 1, # 排除小于 1KB 的
'exclude_size_mb': 10, # 排除大于 10MB 的（避免单文件巨无霸）
'languages': ['Python', 'Java', 'C++', 'JavaScript', 'Go', 'Rust']
}
# 文件级过滤
FILE_FILTERS = {
'exclude_paths': [
'node_modules/', 'vendor/', '.git/',
'test/', 'tests/', '__pycache__/',
'docs/', 'examples/' # 这些通常质量低
],
'exclude_extensions': ['.min.js', '.lock', '.svg', '.png'],
'exclude_licenses': ['GPL-3.0', 'AGPL-3.0'] # 视团队合规而定
}代码数据许可证：
| 许可证 | 是否可用（参考） |
|---|---|
| MIT | ✅ |
| Apache-2.0 | ✅ |
| BSD-3-Clause | ✅ |
| GPL-3.0 | ❌（传染性） |
| AGPL-3.0 | ❌（网络传染） |
| 无 LICENSE 文件 | ❌（默认”All rights reserved”） |
4.2.5 百科 / 问答类
来源：
- StackOverflow / StackExchange：高质量的问答数据。问题-回答-投票的结构天然适合 SFT 数据
- 知乎：中文高质量问答平台（但使用需注意版权）
- Quora：英文问答平台
价值：
- 天然的”问题-回答”格式，对模型学习问答能力很有帮助
- 社区投票机制提供了天然的质量信号
- 覆盖极广的主题
处理要点：
- 高赞回答 vs 低赞回答的质量差异很大——可以用投票数作为质量过滤的信号
- 过时的回答（如 5 年前的编程问题回答）可能已经不准确
- 需要处理问答的格式标记
4.2.6 开源清洗数据集：一种新的数据获取范式
上述数据源都是”原始数据源”——你需要自己做提取、清洗、去重等一系列工作。但近年来，一种新的数据获取方式正在兴起：直接使用社区或机构构建的、已经过高质量清洗的即用数据集。
代表性数据集：FineWeb2（HuggingFace, 2026）
HuggingFace 发布的 FineWeb2（ICLR 2026）是目前最大规模的开源多语言清洗数据集：
- 规模：20TB 文本，约 50 亿文档，基于近 100 个 CC 快照构建
- 语言覆盖：1000+ 种语言——这对低资源语言的预训练来说是一个里程碑
- 核心创新：
- 可自动适应任意语言的数据处理流水线（无需为每种语言手写规则）
- 基于重复计数和质量信号的数据重平衡策略
- 在 9 种语言上进行了完整的消融实验验证
- 许可：ODC-By（开放数据许可），可自由用于训练
2026 年主要开源预训练数据集全景：除 FineWeb2 之外，开源社区已形成多套互补方案，下表对比 2026 年中节点的主要数据集：
| 数据集 | 规模 | 维护方 | 许可证 | 关键特点 |
|---|---|---|---|---|
| RedPajama 2 | ~30T raw | Together AI | 多 | 84 个 CC 快照，最大原始数据 |
| FineWeb 2 | ~10T / 20TB | Hugging Face | ODC-By | 1000+ 语言，下载量最大 |
| Common Pile | ~1T (8TB) | Allen AI + EleutherAI | 宽松 | 完全合规标杆，训练 Comma v0.1-1T/2T；OLMo 2 另用 Dolma 3 |
| Nemotron-CC | ~6.3T | NVIDIA | 多 | 商用级质量，4× 优于 DCLM 基线 |
| Dolma 3 | ~6T | Allen AI | ODC-By | OLMo 2 训练用，可复现管线 |
| Zyda 2 | ~5T | Zyphra | 宽松 | 跨源去重 + 模型质量过滤（DCLM/FWE3/Dolma/Zyda-1） |
| DCLM | ~3.8T | 社区+Apple+AI2 | CC-BY-4.0 | DCLM-Baseline 标杆 |
选型建议：
- 若优先合规 → Common Pile（1T tokens / 8TB 完全合规，训练 Comma v0.1-1T/2T）
- 若优先规模 → FineWeb 2 中文/特定语种子集 或 RedPajama 2 原始数据
- 若追求极致质量 → Nemotron-CC（注意 NVIDIA 商业限制）
- 若想从源头规避 AI 内容污染 → Common Pile（明确剔除疑似 AI 生成来源的开放许可数据）
为什么这很重要？ 传统做法是每个团队各自从 CC 出发，重复做提取→清洗→去重→质量过滤的全套流程。FineWeb2 这类数据集将社区的最佳实践固化为可直接使用的高质量数据，大幅降低了预训练数据工程的门槛——尤其对于缺乏大规模数据处理基础设施的团队。
需要注意的是：使用这类第三方清洗数据集意味着你的数据处理依赖于别人的质量判断。建议在使用时仍然进行采样抽检，确认其质量标准与你的需求一致。
4.2.7 数据配比与可得性权衡
有了上述数据源全景，紧接着要回答的是”每种源各取多少 token”。配比不是拍脑袋，而是可得性（能采到多少干净 token）与目标能力（模型要擅长什么） 两者的折中。结合 4.2 开头的 Llama3 配比与各家数据全景，可归纳出几条工程经验：
- 网页是底盘，但质量密度低：CC 清洗后常占 60–70%，是因为它量足够大、且只有靠体量才能铺满”通用知识覆盖面”；但它单 token 的知识密度远低于书籍/论文。若模型定位是”通用助手”，网页占比不能低；若定位是”深度推理”，应相对提高书籍/论文/代码占比。
- 垂直源按能力目标加权：代码占比高 → 编程强（DeepSeek V3 路线）；书籍占比高 → 长文连贯与叙事强；论文占比高 → 科学/数学严谨性强。配比本质是”想让模型像谁”的能力映射。
- 可得性设上限：中文可用干净数据仅约 1–3T token（4.4.1），想做 7B 中文通用模型冲 3T，单靠 CC 中文部分不够，必须叠加 CCI3.0-HQ、Chinese FineWeb Edu、百度百科、知乎授权等（练习 3 的缺口正源于此）。配比要先算”天花板”，再谈”目标”。
- 合规源单独成池：完全合规集的体量按来源差异很大——Common Pile 约 1T（8TB），而 Common Corpus 已达 2.27T（2026 年全球化更新后，见 4.6.4），二者均已达到万亿级，“合规就没数据”的旧前提已不成立。若产品要商用且无法承担诉讼风险，应把合规池作为”保底底座”，非合规高质源作为”增强层”，二者分桶管理、分别记录 provenance（4.6.5）。
- 去重后才是真实配比：跨快照/跨源去重（坑 1、4.1.11）会显著改变实际得到的 token 量——报”原始 30T”与”去重后可用 10T”是两回事，配比规划必须以去重后口径为准。
一句话原则：先用”目标能力”定方向，再用”各源可得性天花板”定上限，最后用”去重后真实体量”定配比，合规池单独保底。
4.3 HTML 正文抽取：网页语料的工程核心
HTML 解析的目标：从一坨带导航/广告/页脚的 HTML 中提取真正的正文内容，去除模板化噪音。这是把 CC 的 WARC 字节变成可用文本的关键一步。
4.3.1 主流工具对比
| 工具 | 准确率 | 速度 | 多语种 | 公式/LaTeX | 推荐场景 |
|---|---|---|---|---|---|
| trafilatura | 高 | 快(500 docs/s) | 支持 | 弱 | 通用网页正文 |
| resiliparse | 高 | 极快(2000 docs/s) | 支持 | 弱 | 大规模批处理 |
| boilerpy3 | 中 | 快 | 一般 | 无 | 简单网页 |
| readability-lxml | 中 | 快 | 一般 | 无 | 新闻类文章 |
| html2text | 低 | 极快 | 支持 | 无 | 粗提取 |
| MinerU-HTML v1.1 | 极高 (0.9001 ROUGE-N F1) | 快(VLLM GPU) | 支持 | 强 | 高质量正文抽取（SLM 驱动） |
工业级首选 trafilatura（HuggingFace FineWeb 同款），双路 fallback 可用 resiliparse。
分数口径提示（2026-09-18 补）：表中 MinerU-HTML 的 0.9001 ROUGE-N F1 与本书第 5 章 §5.1 表中同一工具的 0.840 不是同一个评测口径——两者出自不同的基准集与工具版本，属”同源工具、异口径分数”，不可直接横向比较，更不能据此判断哪一章有误。使用时的正确做法是：回到各自基准的定义，确认评测集、指标（ROUGE-N F1 与其他 F1 变体不同）与工具版本是否可比；若要做工具选型，应在自己的语料上重跑一份对照，而不是跨表引用分数。SLM 驱动的抽取器随模型版本迭代分数漂移明显，这一点在第 5 章同样适用。
4.3.2 多抽取器 Union：2026 年新共识
Apple、Stanford 和 UW 联合团队在 2026 年 2 月发表的研究（arXiv:2602.19548，“Beyond a Single Extractor”）颠覆了”选一个最好的抽取器就够了”的假设。核心发现：
- 不同抽取器覆盖的网页子集高度互补——仅 39% 的网页能被多个抽取器同时保留
- trafilatura、resiliparse、jusText 各有”擅长”的网页类型：resiliparse 在 WikiTableQuestions 上比 trafilatura 高 10.3pp；代码块抽取器选择导致 HumanEval 差 3pp
- 取 Union（trafilatura ∪ resiliparse ∪ jusText） 在 DCLM-Baseline 流水线下 token yield 提升 71%（去重后仍提升 58%），且不牺牲 benchmark 性能
工业最佳实践更新：
| 场景 | 推荐策略 |
|---|---|
| GPU 可用 | trafilatura ∪ MinerU-HTML ∪ resiliparse（三抽取器 Union） |
| CPU 场景 | trafilatura ∪ resiliparse（双抽取器 Union） |
| 资源受限 | trafilatura（首选）+ resiliparse（fallback，仅当 trafilatura 产出 < 200 字符时启用） |
多抽取器 Union 的核心代价是引入更多重复内容（需在后续去重环节统一处理），但 token yield 提升远超去重损失。
4.3.3 trafilatura 实战
版本声明（2026-09-18 补） 以下代码基于 trafilatura 1.x / 2.x 早期版本的配置写法。升级到 2.x 前请回官方 migration 文档核对
settings.use_config、EXTRACTION_TIMEOUT、MIN_EXTRACTED_SIZE、MIN_OUTPUT_SIZE、MAX_FILE_SIZE以及extract(..., favor_recall=True, deduplicate=True)等接口是否仍然有效——本处只提示风险，不改写代码。生产环境请pip install trafilatura==<锁定版本>固定版本。
⚠️ 挂了两轮的实证缺口，以及一条比等官方文档更快的自证路径：上面点名需要核对的六个接口（
settings.use_config、EXTRACTION_TIMEOUT、MIN_EXTRACTED_SIZE、MIN_OUTPUT_SIZE、MAX_FILE_SIZE、extract(..., favor_recall=True, deduplicate=True)）至今没有实测结论，卡在”项目 CHANGELOG 路径返回 404”上。与其继续等官方补文档，读者可以直接自证：pip install trafilatura==2.3.1后，在自己的语料样本上把上述六个接口各跑一遍，与 1.x 下的输出逐项 diff——这条路径比等 CHANGELOG 更快，也更贴合自己的实际语料，建议直接放进本章的动手环节。（第 5 章 §5.1 的同一提示需同步更新。）
from trafilatura import extract
from trafilatura.settings import use_config
# 必须调整配置，否则会过度删除"看起来像导航"的正文段落
config = use_config()
config.set('DEFAULT', 'EXTRACTION_TIMEOUT', '0') # 不超时
config.set('DEFAULT', 'MIN_EXTRACTED_SIZE', '200') # 至少 200 字符
config.set('DEFAULT', 'MIN_OUTPUT_SIZE', '100') # 至少 100 字符输出
config.set('DEFAULT', 'MAX_FILE_SIZE', '10000000') # 10MB 上限
def extract_html(html_text, url=''):
"""
带 fallback 的 HTML 正文抽取
"""
# 第一路：trafilatura（推荐）
text = extract(
html_text,
url=url,
config=config,
output_format='txt', # 纯文本输出
include_comments=False, # 去掉评论
include_tables=True, # 保留表格
favor_recall=True, # 偏向召回（宁可多留也不漏）
deduplicate=True # 模板去重
)
if text and len(text) > 100:
return text, 'trafilatura'
# 第二路：resiliparse fallback
from resiliparse.extract_html2text import extract_preserve_structure
text_fallback = extract_preserve_structure(html_text)
if text_fallback and len(text_fallback) > 100:
return text_fallback, 'resiliparse'
return None, 'rejected'4.3.4 解析质量检查
抽取后的文本必须经过质量检查，否则会留下大量”半解析”的脏数据：
def check_extraction_quality(text):
"""
检查抽取质量，返回 True/False
"""
if not text or len(text) < 200:
return False
# 1. HTML 标签残留检查（解析失败的标志）
html_tag_ratio = count_html_tags(text) / len(text)
if html_tag_ratio > 0.05: # 5% 以上 HTML 残留
return False
# 2. JS 代码残留检查
if 'function(' in text or 'var ' in text[:500]:
return False
# 3. 模板化检查（导航菜单类）
lines = text.split('\n')
short_lines = sum(1 for l in lines if len(l) < 30)
if short_lines / len(lines) > 0.7: # 70% 短行 = 导航
return False
# 4. 字符分布异常（乱码检查）
ascii_ratio = sum(c.isascii() for c in text) / len(text)
if ascii_ratio < 0.6 and ascii_ratio > 0.3: # 既不是纯英文也不是纯中文，可能是乱码
return False
return True4.3.5 HTML 抽取算法谱系
理解不同抽取器的行为差异，需要先看清它们背后的算法家族，这也是”多抽取器 Union”（4.3.2）之所以互补的根本原因：
- 基于包装器的规则法（如 readability-lxml、boilerpy3）：依赖常见模板启发式（
<article>、<main>标签，或”链接密度低、文本密度高”的区块）。速度快、对新闻类规整页面好，但面对非标准版式容易漏正文或留噪声。 - 基于密度的内容法（如 jusText、density-based 变体）：以段落为单元计算”文本密度 / 链接密度 / 标点密度”，把低密度块判为样板（boilerplate）。对论坛、列表页更友好，但可能误删短而重要的定义。
- 基于全文特征的学习法（trafilatura）：综合 URL、元数据、格式树、语言模型打分等多信号，对”真正正文”做联合判别，鲁棒性最好，代价是计算稍重。
- 基于视觉/语言模型的法（MinerU-HTML v1.1、SLM 驱动）：用小型语言模型直接判断”哪些 token 属于正文”，对 LaTeX/公式/表格的保留能力最强，但需要 GPU 推理支持。
互补性的来源：规则法在”强模板”页面上精准，密度法在”散乱列表”页面上稳健，学习法在”弱结构长文”上最强——三类算法各自偏爱的网页子集只有约 39% 重叠（见 4.3.2），因此 Union 能显著提升 token yield，而非简单叠加。
4.4 多语言数据的特殊挑战
4.4.1 中文数据源的现状
中文预训练数据面临的挑战比英文更严峻：
量的挑战：
- CC 中的中文数据约占 10–15%，远少于英文
- 经过质量过滤后，可用的高质量中文数据可能只有 1–3T token
- 中文维基百科的规模远小于英文版（约 130 万 vs 690 万篇文章）
- 中文高质量书籍的数字化程度较低
质的挑战：
- 中文互联网的 SEO 垃圾和营销内容比例较高
- “自媒体”时代大量标题党、低质量内容
- 2023 年后 AI 生成的中文内容急剧增加
- 中文简体/繁体的处理需要额外关注
主要中文数据源：
| 来源 | 估计量级 | 质量 | 特点 |
|---|---|---|---|
| CC 中文部分 | 5-10T tokens | 中 | 量最大但质量参差 |
| 中文维基百科 | ~15 亿 tokens | 高 | 量少但质量好 |
| 中文书籍（古典） | ~50 亿 tokens | 高 | 文言文为主 |
| 百度百科 | ~100 亿 tokens | 中-高 | 质量不如维基但量更大 |
| 知乎 | ~200 亿 tokens | 中-高 | 问答格式，需要授权 |
| 中文新闻 | ~500 亿 tokens | 中 | 时效性强，模板化严重 |
| 中文论坛/社区 | ~1T tokens | 低-中 | 多样性好但噪声大 |
| CCI3.0-HQ（智源） | ~2500 亿 tokens | 高 | 专用质量分类器筛选的中文互联网数据，总量 500GB |
| Chinese FineWeb Edu（OpenCSG/清华） | — | 高 | 面向教育领域的高质量中文语料 |
后两个数据源是近年来中文预训练领域最重要的开源贡献。特别是 CCI3.0-HQ，其核心创新是训练了专用的中文质量分类器，在区分高质量中文内容方面显著优于通用开源分类器，为中文数据质量过滤提供了新的基准线。
4.4.2 低资源语言的数据增强策略
对于训练数据极其稀少的语言（如很多东南亚语言、非洲语言），常见的增强策略：
- 翻译增强：将高质量英文数据翻译为目标语言。但机器翻译的质量限制了这个方法的上限。
- 跨语言迁移：利用相关语言的数据。如用普通话数据辅助粤语、用印尼语数据辅助马来语。
- 调整采样权重：在多语言训练中，对低资源语言做过采样（oversampling），使其在训练中被看到更多次。
- 利用开源多语言清洗数据集：如 FineWeb2 覆盖了 1000+ 种语言的高质量清洗数据，可以直接获取低资源语言的预训练语料，避免从零开始构建数据处理流水线。
4.4.3 跨语言平衡的策略差异
不同模型在多语言策略上的选择差异很大，反映了不同的产品定位：
Llama 3（Meta）：英文为主（~85%），多语言支持有限
- 定位：主要服务英文市场
- 结果：英文能力极强，中文能力弱
Qwen 2.5（阿里）：中英平衡（各~40%），覆盖 29+ 种语言
- 定位：全球化的多语言模型
- 结果：中英文能力均衡
DeepSeek V3：代码和数学占比高，中英文均衡
- 定位：技术能力导向
- 结果：代码/数学能力突出，中英文均可
这些差异不是技术能力的差异，而是产品策略和数据策略的差异。
4.4.4 语种识别与脚本处理
多语言采集的落地前提是准确的语种识别（LID），而 LID 本身的工程陷阱常被低估：
- 工具选型：fastText LID（支持 170+ 语言）是工业基线；但若覆盖低资源语言，需补充 GlotLID 或 CommonLID（109 语言基准，更适合评测 LID 自身的覆盖盲区）。NeMo Curator 26.04 已内置 LID，无需单独调用 fastText（见 4.1.6）。
- 脚本与编码：同一语言可能跨多种书写系统（如塞尔维亚语用西里尔/拉丁双写），抓取时需统一 Unicode 规范化（NFC/NFKC）并清洗 mojibake（乱码多来自错误的解码而非内容本身）。
- 代码混合（code-switching）：社交与论坛文本常在中英文间夹杂，单标签 LID 会判错；对这类数据，要么保留原始混合，要么在下游按句切分再标注，避免把”中文为主但含英文术语”的优质内容整体丢弃。
- 采样权重的工程实现：过采样低资源语言时，要在 parquet 分区（4.5.1 schema）中保留
lang字段，并在训练侧用 loss weighting 或 replay 控制，而非简单复制——盲目复制会放大重复、削弱去重效果。
4.5 数据采集系统架构与解析时序
把前几节的采集与解析动作组织成工业级系统，需要明确的架构与解耦设计。
4.5.1 采集架构图
工业级数据采集系统的典型架构：
┌─────────────────────────────────────────────────────────────┐
│ 采集调度层 (Airflow) │
│ 定时任务 → CC 快照监控 → GitHub 爬取 → arXiv 同步 → ... │
└──────────────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 下载队列层 (Kafka) │
│ topic: cc.warc.url, github.repo.url, arxiv.id, ... │
└──────────────────────────────┬──────────────────────────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker N │
│ (S3下载) │ │ (S3下载) │ │ (S3下载) │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└───────────────┼───────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ 解析集群 (Ray/Spark) │
│ WARC → HTML 抽取 → 纯文本 │
│ PDF → MinerU/Nougat → Markdown+LaTeX │
└──────────────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 原始文本存储 (S3/HDFS) │
│ parquet 格式，按 source/date/hash 分区 │
│ schema: source, url, html, text, lang, parsed_at, ... │
└─────────────────────────────────────────────────────────────┘4.5.2 关键设计原则
- 解耦：下载、解析、存储三层独立扩缩容
- 幂等：每个 URL/文件可重试，避免重复处理
- 可追溯：保留 WARC 原始字节，方便重新解析
- 背压：下游处理慢时，上游自动暂停下载
4.5.3 解析时序图
单条数据从下载到产出的时序：
时间轴 →
下载层: [S3 GET WARC.gz]──────────[stream 1MB chunks]
│
解析层: ▼
[warcio 迭代器]──[record 1]──[record 2]──...
│
▼
[trafilatura]
│
▼
[质量检查]
│
▼
[语种识别 fastText]
│
┌───────────┴───────────┐
▼ ▼
[zh 文本] [en 文本]
│ │
▼ ▼
[S3: zh/raw] [S3: en/raw]
parquet 分区 parquet 分区4.5.4 性能基准
在 32 vCPU + 64GB 内存节点上：
| 阶段 | 吞吐 | 单节点日处理量 |
|---|---|---|
| WARC 下载 | 200 MB/s | ~17 TB |
| HTML 抽取 | 500 docs/s | ~43M 文档 |
| PDF 解析(MinerU GPU) | 5 docs/s | ~430K 文档 |
| 完整流水线 | 300 docs/s | ~26M 文档 |
PDF 解析是瓶颈——MinerU 单 GPU 5 docs/s，处理 100 万篇 arXiv 论文需要约 50 GPU·天。
4.5.5 各层技术栈详解
把 4.5.1 的架构落到具体组件，每个分层都有成熟选型：
- 调度层：Airflow / Dagster 负责快照发布监听（CC 每月在
commoncrawl桶更新 manifest）、增量触发、失败重试；关键是”发现新快照即触发”，避免手工盯版本号。 - 队列层：Kafka / Pulsar 承载
url → worker的任务分发，天然提供背压（consumer lag 高时 producer 限速）；小规模可用 Redis Stream 替代。 - 下载层：Worker 用 boto3 transfer manager（4.1.7 配置）做 S3 并发拉取，或 range GET（4.1.10）精准抽取；跨境带宽用 HuggingFace Storage Bucket（2026-04 起）就近拉取。
- 解析层：Ray / Spark 横向扩展抽取作业，单任务内用 warcio 流式迭代 + trafilatura/resiliparse Union；PDF 走独立 GPU 池（MinerU/Nougat），与文本抽取隔离扩缩。
- 存储层：parquet 按
source/date/lang/hash分区，schema 至少含source, url, html, text, lang, parsed_at, license, quality_score；hash 字段服务于下游去重（见坑 1 的跨快照去重）。
可追溯性工程：WARC 原始字节 Prod 中保留（冷存储），warc_filename + offset + length 三元组写入元数据，使任一条解析失败或质量标准变更时，可”重放”单条记录而不必全量重抓——这是 4.1.11 revisit 溯源与 4.6 数据溯源的共同基础。
4.6 数据许可与法律合规
这是一个不能回避的话题。训练数据的法律合规性正在成为大模型公司面临的最大风险之一。
4.6.1 当前的法律环境
AI 训练数据的法律环境在 2025–2026 年发生了剧烈变化，多起诉讼产生了实质性裁决，正在塑造行业的法律框架。
关键诉讼与裁决：
| 案件 | 状态 | 关键法律原则 |
|---|---|---|
| Bartz v. Anthropic | 15 亿美元和解；2025-09-25 初步批准，2026-07-20 终审批准并以”不得再诉”结案 | 训练数据使用可能属合理使用，但存储盗版副本构成侵权 |
| Kadrey v. Meta | 部分裁定（2025） | 即使底层数据来源非法，LLM 训练本身仍可能属合理使用（但分发行为不受保护） |
| NYT vs OpenAI | 多区合并诉讼，进入取证阶段 | 法院要求 OpenAI 交出数千万条输出日志，预计 2026 年底或 2027 年初出判决 |
| Thaler v. Perlmutter | 美国最高法院拒绝审理（2025） | 确认纯 AI 生成作品不受版权保护 |
| 音乐出版商 v. Anthropic（2026-10-08 补） | 均为指控阶段，无判决、无和解基金 | 歌词是网页爬取语料的高频内容类型，需单独识别与处置 |
为什么歌词这条比书籍更贴近日常实践：上表其余四行全部围绕书籍与新闻，但从数据类型看，歌词是被爬取网页中的高频内容类型——论坛、歌词站、歌曲百科里到处都是。因此对第 4 章的读者而言，音乐出版商这条战线的含义不是”又一起诉讼”，而是一条具体的工程要求：在本章 4.2 的数据源分类里，把”歌词/歌曲文本”单列为需要许可证识别的一类，与代码（§4.6.3 的许可证过滤）同等对待。⚠️ 上述均为指控阶段，尚无判决。
Bartz v. Anthropic 的落地细节（2026-09-18 补） ：
- 规模与对价：最终 Works List 收录 482,460 部作品；截至 2026-04-16 已有 440,490 部提交认领，认领率 91.3%（集体诉讼中极高的比例）。和解金 15 亿美元（non-reversionary，即不因认领不足而回流），扣除律师费与费用前每部作品约 3,000 美元。法院最终裁定律师费 101,561,111 美元，显著低于原告律师请求的 1.875 亿美元。
- 时间边界：和解的免责范围（release）仅覆盖截至 2025-08-25 的”输入端”既有索赔——即”把书搬到服务器上”这一复制行为。不覆盖模型输出端的侵权索赔，也不覆盖 2025-08-25 当日及之后的行为。换言之，这份和解是一次性的历史清算，不构成未来训练或输出的授权。
- 销毁义务：Anthropic 必须销毁其从 Library Genesis 与 Pirate Library Mirror 下载的原始文件及其衍生副本，并在终审判决后 30 日内完成、向原告律师出具书面证明。注意边界：该义务不要求删除公司合法采购并扫描纸质书所得的数字副本。
- 未认罪：Anthropic 在和解中未承认过错（no admission of liability）。
- 付款节奏（2026-10-08 补）：15 亿分四期支付——$300M（2025-10-02）、$300M（终审批准后不久）、$450M（2026-09-25）、$450M（2027-09-25）；首批付款预计不晚于 2026-11-15，首轮每本约 $2,203.56（作者与出版商分成前）。
- 仍有未决上诉（2026-10-08 补）：两桩上诉已立案于第九巡回，案号 Nos. 26-5391 与 26-5455，性质为仅涉律师费（fee-only）。
- Anthropic 的关键陈述（2026-10-08 补）：和解要求 Anthropic 销毁相关书籍；Anthropic 并陈述称 LibGen / PiLiMi 数据集不在其任何已商业发布模型的训练语料中。
⚠️ 对数据工程的含义：这组细节把 4.6.1 抽象的”训练 vs 存储”原则落成了一条可执行的工程约束——“输入端的历史复制”可以用钱结清，“存储盗版副本”本身必须物理销毁，而”输出端”的风险完全没有被结清。因此本章 4.6.5 的”解析后即删原始字节、仅留溯源三元组”不是可选的洁癖，而是与本案销毁义务同构的做法：把”保留原始字节”这一行为从流水线上消除，就从源头消掉了最难辩护的那一项。
正在形成的法律共识：
- “训练 vs 存储”的区分正在成为核心法律原则——使用数据训练模型（转化性使用）和直接存储/复制数据是不同的法律行为
- 合理使用分析中，“市场损害”因素的权重在上升——如果模型输出直接替代了原作品的市场，侵权风险显著增加
- 许可交易模式正在兴起：越来越多的内容方选择与 AI 公司签署授权协议，而非走诉讼路线
监管框架：
- 欧盟 AI Act（2024 生效）：要求 AI 系统提供者披露训练数据的来源和使用的版权作品摘要。对”通用目的 AI 模型”有特别的数据透明度要求。
- 中国《生成式人工智能服务管理暂行办法》（2023）：要求训练数据合法、不侵犯知识产权、不含违法违规内容。
对从业者的实操建议：
- 维护详细的数据溯源记录——一旦涉诉，“你知不知道数据来自哪里”将成为关键问题
- 避免直接存储受版权保护的原始文本副本（Bartz 案的教训：和解条款要求 30 日内销毁盗版来源原始文件及衍生副本，见上文落地细节与 4.6.5 的保留期策略）
- 关注训练数据是否会导致模型输出”实质性相似”的原作品片段
- 在有条件的情况下，优先使用已获得许可或明确开源的数据
4.6.2 Robots.txt 的实际约束
网站通过 robots.txt 文件声明哪些内容不允许被爬虫访问。但：
- CC 在爬取时并不总是严格遵守
robots.txt（虽然它声称会） robots.txt的法律约束力在不同司法管辖区不同- 很多网站在 AI 时代之后才更新了
robots.txt来排除 AI 训练爬虫——但历史快照中的数据已经存在
上面三条”但书”指向同一个工程难题：无法核查。你能看到站点今天的 robots.txt，却看不到它在被抓取那一刻声明了什么——而这个差别在法律上是决定性的。这一条在 2026 年出现了转机。
CC 现在把抓取时点的 robots.txt 与拒绝响应单独发布。除 WARC / WAT / WET 三类经典格式外，CC 快照同时以一级路径清单发布 robotstxt.paths.gz（100,000 个 / 0.15 TiB） 与 non200responses.paths.gz（100,000 个 / 2.70 TiB），与 segment / warc / wat / wet 并列。（CC-MAIN-2026-39 口径；更早的 CC-MAIN-2026-34 同样已含这两类，分别为 0.14 TiB 与 2.63 TiB。）
这让”无法核查”变成部分可核查：可以按抓取时点回溯每个 host 当时实际声明了什么，而不是依赖采集后的站点现状。三个具体用途：
- 为 opt-out 提供时点证据（服务于 4.6.3）：某站点在快照采集时是否已声明退出，现在有据可查，不必再靠”站点今天写了什么”倒推。
- 写进 provenance schema：建议在 4.6.5 的 parquet 溯源表里新增
robots_directive字段，并同时记录该声明的抓取时点——只记”允许/禁止”而不记时点，等于把这份档案的价值丢掉一半。 - 量化快照质量差异（服务于 4.1.8）：
non200responses有 2.70 TiB，量级不小，可用来统计被拒/失效 URL 在不同快照间的分布差异，把”这期快照质量差一点”从感觉变成一个可算的维度。
⚠️ 待核实：本轮未逐条读 CC 官方对这两类产品的说明文档，其覆盖范围（是否每个 WARC 段都有对应的 robots.txt 记录）与字段结构（non200 是否包含 403 / 451 等拒绝码）未确认，写入生产 schema 前请回官方文档核一次。
4.6.3 合规策略
- 数据溯源（Data Provenance）：记录每条训练数据的来源 URL、爬取时间、许可证信息
- Opt-out 机制：提供渠道让内容所有者要求移除其数据
- 许可证过滤：对于代码数据，只使用宽松许可证（MIT、Apache 2.0、BSD）的内容
- 去标识化：移除可识别的个人信息和版权标记
- 审计日志：保留完整的数据处理日志，以备合规审查
4.6.4 合规数据集的实践：Common Corpus 与 Common Pile
“合规”是否意味着”只能用很少的数据”？Common Corpus（ICLR 2026 Oral）给出了有力的反例。
Pleias 联合多方发布的 Common Corpus 包含 2.27 万亿 token，是目前最大的完全合规开源文本数据集。它的所有内容均来自公有领域或宽松许可（Apache 2.0），数据来源覆盖六大类：
| 来源类别 | 内容 | 示例 |
|---|---|---|
| OpenCulture | 公版书籍、报纸 | Project Gutenberg、数字化历史报纸 |
| OpenGovernment | 法律、金融等政府文档 | 法律文书、监管文件 |
| OpenSource | 高质量开源代码 | GitHub 宽松许可项目 |
| OpenScience | 开放获取学术论文 | PubMed OA、arXiv |
| OpenWeb | 开放知识平台 | 维基百科、StackExchange |
| OpenSemantic | 语义结构化数据 | Wikidata |
Common Corpus 当前覆盖 33 种语言（每种超过 10 亿 token），并有 8 种语言超过 100 亿 token（英、法、德、西、意、波、希腊语、拉丁语）。
全球化更新已落地（2026-09-18 补） ：初版 Common Corpus 明显偏向欧洲（Pleias 所在地）与美国，并非真正通用的基础设施。2026 年的全球化更新把它从”欧美语料”变成”全球语料”——新增的 2700 亿 token 中超过一半来自非西方国家，中文、日文、韩文、阿拉伯文等此前缺失的语种被补入。
“开放数据悖论”（open data paradox）——一条比”合规与规模兼得”更强的论据：
Pleias 在构建过程中发现了一个反直觉的事实：开放许可内容的绝大多数，并不在标准预训练数据混合里。具体而言，与 Common Corpus 相比，基于爬取的代表性数据集 FineWeb 只有不到 2% 的”公共内容”处于开放状态。这意味着——合规化的主要动作不是”删掉受版权保护的数据”，而是往预训练公共域里添加此前根本没被收录的新数据。
之所以会这样，是因为一段文本要能被爬进数据集，必须同时满足四个条件：已数字化（digitized，发展中国家大量内容在此就被排除）、可访问（accessible，数字基础设施比想象中脆弱——Pleias 曾因对应的压缩包消失而放弃整合大部分中国台湾地区判例；另一个主要来源只靠两位个人做种者才保住）、可读（readable，爬虫主要面向网页，PDF 长期因处理与存储成本被排除，且这个变化不溯及既往）、可发现（findable，爬虫只索引能找到的内容，倾向于有反链或列入 sitemap 的页面，而开放数据高度集中在索引稀疏的大型基础设施上）。
为什么这条论据重要：它把”合规 = 牺牲规模”这一流行论断反转了。真正的瓶颈不是”开放数据不够多”，而是”开放数据没被索引到”。对数据工程团队，可操作的推论是：与其在爬取语料上做越来越激进的版权过滤，不如把一部分工程预算投到开放数据的发现与收录（政府公报、司法判例、文化遗产数字化、开放获取论文、Wikidata 语义三元组等）——这是一条别人还没走、但 token 供给并不小的路。它证明了：通过系统化地整合公有领域和宽松许可的数据源，完全可以在严格合规的前提下构建万亿级的预训练数据集。
Common Pile（Allen AI + EleutherAI, 2025–2026）——8TB（~1T tokens）的完全合规开源预训练数据集，是当前规模最大的”已明确版权清理”选项。训练出 Comma v0.1-1T/2T（OLMo 2 另用 Dolma 3 训练），标志着”合规 + 规模”不再是矛盾命题。建议在生产环境优先评估 Common Pile 的可商用范围。
4.6.5 数据溯源与生产级合规工具
合规不是”一次性声明”，而是贯穿采集全流程的可审计能力：
- Provenance 落地：在 4.5.5 的 parquet schema 中固化
source / crawl_date / license / opt_out_flag，使任一条训练样本都能回溯到”哪个快照、哪个 URL、什么许可”。 - Opt-out 机制对接：Spawning 的 Have I Been Trained?、Data Provenance Initiative 等提供了创作者”选择退出”的注册入口；生产系统应在采集前用这些清单做 URL/域名过滤，避免纳入已声明退出的内容。
- copyleft 的实务边界：代码数据过滤不能只看仓库 LICENSE 文件——依赖树里的传递依赖、单文件级
SPDX-License-Identifier才是真正的边界；GPL/AGPL 在企业商用场景下普遍回避，但”仅用于内部研究”与”对外发布模型权重”的法律后果不同，需法务逐场景界定。 - 审计日志与保留期：完整保留”下载 → 解析 → 过滤 → 去重 → 入训”的日志链路，并设定原始副本的最短保留/最短销毁策略（Bartz 案的核心教训是”存储盗版副本”本身即侵权，而非训练）；对高敏来源，倾向”解析后即删原始字节、仅留溯源三元组”。
4.7 新兴数据来源与挑战
4.7.1 AI 生成内容的污染
自 ChatGPT 发布（2022 年末）以来，互联网上的 AI 生成内容急剧增加。这对未来的预训练数据构成了一个严峻的挑战：
- 如果你用 2024 年后的 CC 快照训练模型，数据中可能包含大量 GPT/Claude/Gemini 生成的内容
- 用 AI 生成的内容训练 AI，可能导致”模型坍缩”（model collapse）——分布逐渐退化
实证数据：He et al. (2026) 在医疗领域进行了大规模实验（80 万+ 合成数据点），量化了 AI 数据污染的实际危害：
- 关键病理特征被”平均化”——罕见发现逐渐消失
- 人口统计特征偏向中年男性（多样性丢失）
- 虚假安抚率从约 13% 激增至 40%
- 仅经过两代训练，AI 文档即变得在临床上无用
虽然这是医疗领域的实验，但其揭示的退化机制（多样性丢失、分布向”平均”坍缩）对通用文本场景同样具有警示意义。
应对策略：
- 使用 2023 年之前的 CC 快照可以避免大部分 AI 生成内容
- 真实数据 + 质量感知过滤的组合是目前最有效的缓解方案——单纯增加合成数据量无法防止模型退化（He et al. 2026）
- AI 内容检测器的进展：Buttaro & Amerini (2026) 的比较研究表明，监督学习检测器（如基于 Transformer 的分类器）在跨语言和跨领域场景下表现优于商业工具（ZeroGPT、GPTZero 等），展示出更好的稳定性。但大规模应用仍面临计算成本和误判率的挑战
- 实操建议：对于 CC 快照的 AI 内容预过滤，建议使用基于监督学习的检测器而非商业工具。在规模化场景下，可以先用 fastText 分类器做粗筛，再用监督学习检测器做精筛，控制计算成本
- LID 基准参考：CommonLID（109 语言识别基准）提供了更广泛的语言覆盖评估，可作为 fastText lid 和 GlotLID 的基准测试参考
- 开源社区的对策：Common Pile 在数据选择阶段就排除了疑似 AI 生成来源（仅采用开放许可数据）；Nemotron-CC 在质量过滤阶段使用分类器集成并加入合成数据重述（1.9T 合成 token）来提升质量；Zyda 2 通过跨源去重 + 模型质量过滤避免低质内容传播
4.7.2 Soft Contamination：语义级 benchmark 泄漏的新威胁
2026 年 2 月发表的 arXiv:2602.12413 揭示了一种新型 benchmark 污染形式：Soft Contamination（软污染）——训练数据泄漏了 benchmark 测试题的语义近重复（sentences with equivalent/near-equivalent content but not close in string space）。
传统 n-gram 去污染无法检测这类泄漏，因为：
- 字符串层面差异很大（可能只有 30–40% n-gram 重叠）
- 但语义完全等价（如”如何重置密码？” vs “忘记密码怎么办？”）
- 模型通过浅层模式匹配而非真正的分布外推理来”作弊”
对数据工程师的启示：数据清洗管线必须增加 embedding 相似度检测层（阈值建议 0.85–0.90），专门捕获语义级重复。这对合成数据占比越来越高的 2026 年尤为重要。
4.7.3 多模态数据
虽然本书聚焦于文本数据，但需要指出：多模态数据（图文对、视频字幕等）正在成为预训练数据的重要补充。
- 图文对：LAION-5B、DataComp 等数据集提供了数十亿的图文对
- 视频字幕：YouTube 等平台的视频字幕提供了大量的口语化文本
- 科学图表：论文中的图表+描述是训练科学理解能力的宝贵数据
4.7.4 模型坍缩的机理直觉
“模型坍缩”并非玄学，其机制可用分布视角直观理解：真实人类文本的分布 包含大量长尾（罕见术语、边缘群体、非常规表述）。当模型在”自身生成 + 少量真实”的混合分布上迭代训练，每一代都会把分布向高概率区”收缩”——稀有但真实的特征因采样不到而逐渐消失，生成分布 与 的 KL 散度逐代增大。He et al. (2026) 医疗实验中的”虚假安抚率 13%→40%、两代即临床无用”，正是这一收缩在垂直领域的高倍放大。
对数据工程师的可操作含义：
- 源头隔离：优先使用 2023 年前快照、或 Common Pile 这类”剔除了疑似 AI 来源”的开放许可集（4.2.6、4.6.4）；
- 质量感知过滤优先于增量：单纯掺入更多合成数据无法抵消坍缩，真实 + 高质过滤的组合才有效；
- 监测信号：在持续预训练中，定期用长尾特征覆盖率（如罕见实体、低频 n-gram 占比）作为”坍缩早期预警”，而非只看 perplexity。
4.8 工程踩坑经验总结
坑 1：CC 单快照不够，必须跨快照去重
某团队用 1 个快照（100TB）训练，发现大量数据是同一个网站的不同时间快照。必须跨多个快照做去重，且时间戳靠后的优先。
坑 2：HTML 抽取把广告当正文
某团队用 html2text 抽取，结果模型生成的内容里全是”点击这里”、“立即购买”。必须用 trafilatura 或 resiliparse 做严格的正文/模板分离。
坑 3：PDF 表格被解析成乱序文本
某团队用 pdfminer 解析财报 PDF，表格被拆成一坨。复杂版式 PDF 必须用 MinerU/Marker，简单文本 PDF 才用 pdfminer。
坑 4：GitHub 代码含测试数据
某团队从 GitHub 抓代码，没过滤 test/ 目录，结果训练数据里混入了大量 JSON/CSV 测试数据。模型生成代码时经常吐出一坨测试数据。代码采集必须做路径过滤。
坑 5：解析后的文本长度过滤太激进
某团队过滤掉了所有 <500 字符的文本，结果丢失了大量列表页、表格、定义。长度过滤推荐 <200 字符，而不是 <500。
4.9 本章要点回顾
- Common Crawl 是预训练数据的基石，但不同快照质量差异大——不要盲目使用最新快照（本章主锚点为 CC-MAIN-2026-39，2026-09 采集、约 2.17B 网页 / 361.4 TiB 未压缩，AI 内容占比持续攀升；2026-04 起新增 HuggingFace Storage Bucket 分发）
- 高质量数据源是”质”的保障：维基百科（知识密度）、书籍（长文本连贯性）、学术论文（专业知识）、代码（推理能力）、问答社区（交互格式）
- 开源清洗数据集（如 FineWeb2）正在成为新的数据获取范式——降低数据工程门槛，尤其利好低资源语言
- 中文数据面临更严峻的量和质的双重挑战——CCI3.0-HQ、Chinese FineWeb Edu 等开源数据集正在改善这一局面
- 多语言配比反映产品策略——Llama 英文为主、Qwen 中英均衡、DeepSeek 技术导向
- 法律合规格局在 2025–2026 年发生剧变——“训练 vs 存储”的区分成为核心法律原则，Common Corpus / Common Pile 证明了合规与规模可以兼得
- AI 生成内容的污染有了量化证据——两代训练即可导致模型退化，“真实数据 + 质量感知过滤”是最有效的缓解方案
- 工程落地要点：WARC + trafilatura 抽取 + 多抽取器 Union + 解析质量检查；PDF 解析（MinerU/Nougat）是最大瓶颈；采集系统需下载-解析-存储三层解耦
4.10 采集策略决策清单
把全章要点收敛为一线的可执行检查单，供搭建采集流水线时逐项核对：
一、数据源与快照选择
- 是否明确了目标能力 → 据此定网页/书籍/论文/代码的基础配比方向（4.2.7）？
- CC 是否混合了多个时间段快照，而非盲目追最新（4.1.8）？是否跟踪到 2026-09 的 CC-MAIN-2026-39（2.17B 网页 / 361.4 TiB 未压缩，核于 2026-10-08）并评估 AI 内容占比？
- 是否优先评估完全合规池（Common Pile / Common Corpus）作为保底底座（4.6.4）？
- 中文/低资源语言是否核算了可得性天花板，缺口是否用 CCI3.0-HQ、FineWeb2、CCI 等开源集填补（4.4.1–4.4.2）？
二、下载与解析
- WARC 是否走 WARC 格式 + 自选抽取器，而非直接用 WET（4.1.3）？是否兼容 2026-04 起
application/http;msgtype=response新 Content-Type（4.1.2/4.1.4）？ - 大规模采样是否先用 cc-index 列式索引圈定 + range GET 精准抽取，控制成本（4.1.10）？
- revisit 记录是否被正确处理以支持跨快照去重（4.1.11）？
- HTML 抽取是否采用多抽取器 Union（trafilatura ∪ resiliparse ∪ jusText），并配置质量检查（4.3.2–4.3.4）？
- 论文/书籍 PDF 是否按版式选 MinerU（复杂）或 Nougat（公式），arXiv 优先用 LaTeX 源码（4.2.3）？
- 代码采集是否做了仓库 star/license 过滤与路径过滤（排除 test/、node_modules 等）（4.2.4）？
三、系统架构
- 下载-解析-存储是否三层解耦、可独立扩缩（4.5.1–4.5.2）？
- 是否保留 WARC 原始字节与
warc_filename+offset+length溯源三元组，支持单条重放（4.5.5）？ - PDF 解析是否独立 GPU 池，避免拖累文本抽取吞吐（4.5.4）？
四、合规与污染
- 是否维护了
source/crawl_date/license/opt_out_flag的 provenance schema（4.6.5）？ - 是否对接了 opt-out 注册清单，避免纳入已声明退出内容（4.6.5）？
- 是否在清洗管线中加入 embedding 相似度层，捕获 Soft Contamination 语义级泄漏（阈值 0.85–0.90）（4.7.2）？
- 是否用真实数据 + 质量感知过滤组合抵御 AI 内容污染，并监测长尾特征覆盖率作为坍缩预警（4.7.1、4.7.4）？