08 端到端数据管道（综述 §2.3.7）

管道设计三要素（Principles 原文）

质量 vs 数量的取舍；
算子依赖顺序（文本提取必然在去重/过滤之前）；
效率编排（模型过滤这类计算密集步骤必须排在 URL 过滤这类轻量步骤之后）。

0 一图看懂：FineWeb 全管道（含逐工序削减，Figure 6 数字）

Common Crawl WARC（全量 100%）
  ↓ ① URL 过滤            −0.8%   （任何计算之前，最便宜的第一刀）
  ↓ ② 文本提取             −50.8%  ← 一刀砍一半！获取质量决定一切（弃 WET 从 WARC 重提）
  ↓ ③ 语言过滤             −28.5%  （fastText，CCNet 实现）
  ↓ ④ 启发式过滤           −6.2%   （MassiveText 三级 + C4 式 + 自定义）
  ↓ ⑤ 重复行过滤           −12.3%
  ↓ ⑥ 自定义过滤           −3.69%
  ↓ ⑦ 模糊去重             −48.8%  ┐ 对「幸存者」做，两项合计砍掉剩余量约 60%
  ↓ ⑧ 精确去重             −11.54% ┘ ——去重是最重的削减工序（[[03 去重]]）
  ↓ （C4 质量过滤 −5.82%、模型过滤 −6.81%，可选项）
最终语料：11.67%

通用骨架（三条管道的共同底座，差异全在后两个决策点）：

URL 过滤 → 文本提取 → 语言过滤 → 启发式过滤 → 去重 → [模型过滤?] → PII 处理
                                              决策点1:去重怎么做   决策点2:要不要ML过滤

1 框架层：三个通用处理框架

Data-Juicer（阿里系开源）

一句话：预构建算子库 + 可视化自动评估 + 分布式优化的「管道全家桶」——改管道能立刻看到数据反馈。

细节：算子库覆盖格式化/映射/过滤/去重；可视化和自动评估；分布式计算优化支持大规模数据集。

Dataverse

一句话：把管道做成「搭积木」——块状（block-based）ETL 界面，加/删/重排 block 自定义管道。

细节：预置算子含去重、去污（decontamination）、偏见缓解、毒性削减、多源数据接入；接 Apache Spark 分布式 + AWS 云扩展。

通用框架 [368]

一句话：处理 + 分析双模块——处理管清洗去重，分析管数据探针和自动评估。

细节：处理模块（数据重格式化、清洗——去 HTML 标签/翻译文本、过滤、MinHashLSH 去重）+ 分析模块（精细数据探针 + 自动评估）。

2 三条经典管道逐工序对比（Figure 6）

工序	RefinedWeb (MDR)	DCLM-Baseline	FineWeb
起点	Common Crawl WARC	同左	同左
第一道	URL 过滤（在任何计算密集步骤之前排除无关链接）	URL 过滤	URL 过滤
提取	warcio + Trafilatura	Trafilatura	Trafilatura（弃用现成 WET 格式，坚持从 WARC 重新提取——自定义性更强）
语言过滤	fastText（CCNet 实现）	fastText	fastText
启发式过滤	文档级 + 行级（删社媒计数器、导航链接等噪声）	启发式（毒性词、非法来源网页）	MassiveText 式过滤（段落/行/gram 三级）+ C4 式启发式（无标点行、政策声明）+ 自定义过滤
去重	MinHash 模糊 + Suffix Array 精确（CC 切 100 段逐段做 + URL 级跨段兜底）	Bloom Filter（保大集可扩展性）	每个 CC snapshot 独立 MinHash（实测追平 RefinedWeb 全局去重，全局归并无额外收益）
模型过滤	无（刻意不用 ML 过滤）	fastText top 10%（OH-2.5 + ELI5 指令格式数据训练）	无模型过滤，靠多层启发式
PII 处理	—	—	正则匿名化邮箱
最终保留	11.67%	1.4%	约 10% 量级

各自的设计哲学（原文三条，各配一句话）

RefinedWeb/MDR —— 一句话：scale first，用最透明便宜的手段从 CC 榨最大数据量。 ① scale first（从 CC 最大化数据量喂大模型）；② 严格去重（冗余清除对训练效率和泛化都关键）；③ 启发式过滤优先（规则过滤 bias 更小、更透明——刻意不选 ML 过滤）。
DCLM-Baseline —— 一句话：小而精，最贵的模型过滤只对处理后的小池子做。 轻量启发式 + Bloom 去重先干掉大头，fastText 模型过滤收尾——「贵的放最后」的教科书编排。
FineWeb —— 一句话：性能优先于简洁，多层过滤堆叠、每层都有与 C4/RefinedWeb 的实证对比背书。

3 管道编排的下一步：从经验到搜索

以上管道都靠经验设计。Data-Juicer Sandbox —— 一句话：把「调管道」变成系统化搜索——Probe–Analyze–Refine 工作流探索各数据操作及顺序对模型性能的影响，产出 data recipe。

细节：系统探索「各数据操作及其顺序」对模型性能的影响 → 把有效操作组合成 data recipe → 通过重复性分析和多样性分析优化数据利用率。已在 Mini-Gemini（图生文）、EasyAnimate（文生视频）上验证。

这是「管道设计从手艺走向科学」的第一步——但综述在挑战部分明确指出它还不够：FineWeb 验证管道决策（WARC vs WET、全局 vs 分片去重）训了 70+ 个 1B 模型、共 80,000 H100 小时（详见 10 LLM4DATA与未来挑战挑战 2）。

记忆锚点

三条管道 = 三种极端：RefinedWeb 求大（启发式+重去重）、DCLM 求精（模型过滤激进）、FineWeb 求稳（多层堆叠每层有实证）。
通用骨架可以背下来：URL 过滤 → 文本提取 → 语言过滤 → 启发式过滤 → 去重（→ 模型过滤）→ PII 处理。差异全在「去重怎么做、要不要模型过滤」这两个决策点上。
最狠的两个数字：文本提取一刀 −50.8%、去重合计砍剩余 ~60%——上游工序的质量和去重策略决定一切。

ychhh

端到端管道