Open-source reproduction / LLM data pipeline

Mini-C4 风格网页预训练语料流水线

基于开源 Mini-C4 项目做复现与增强，在单机 CPU / WSL 环境下，把 Common Crawl WARC 处理成可训练 JSONL，并补齐阶段日志、留存漏斗、manifest 和一致性检查。

查看处理链路 查看实验结果

为什么网页语料不能直接训练

网页是大模型预训练的重要数据来源，但原始网页通常包含模板噪声、重复转载、多语言混杂、目录页、广告页和低信息密度内容。这个项目的价值，是把这些问题拆成一条可复现的数据处理链路，并让每一层过滤都有指标可复盘。

网页噪声高

导航、页脚、广告、脚本、评论和模板内容会挤占正文比例。第一步不是训练，而是把 WARC 里的 HTML 响应稳定转成正文候选。

重复内容多

转载、镜像站和模板页会放大重复文本，让训练分布倾斜。项目用 MinHash + LSH 做近重复去重，避免全量两两比较。

训练接口要求高

清洗后的文本还不是可交付数据集。训练侧需要确定性 train / val、manifest、hash、token 统计和一致性检查。

怎么做：三段式流水线

我把流水线按工程边界拆成三段：先把网页归档变成正文文本，再把正文文本治理成训练语料，最后把语料封装成训练系统可以消费和验收的数据产物。

01

网页归档 -> 正文文本

使用 warcio 流式读取 WARC response，筛选 HTML 响应，再用 trafilatura 提取主内容区域。

02

正文文本 -> 训练语料

串联启发式清洗、MinHash + LSH 去重、fastText 语种拆分和 KenLM 英文质量过滤。

03

训练语料 -> 训练交付物

输出 train / val / smoke_test JSONL、training_manifest、评估报告和一致性检查结果。

Common Crawl WARC -> HTML 正文 -> 粗清洗文本 -> 去重文本 -> 分语种子集 -> 高质量语料 -> train / val JSONL + manifest + reports
Mini-C4 数据管道三次迭代：从基础管道、噪声减少到质量收敛
这张图把项目叙事压缩成三次迭代：先让管道可跑，再减少网页噪声，最后收敛到可训练数据。

核心工程能力：4个关键点

每个关键点解决什么工程问题，以及为什么这么设计。

WARC 流式解析与正文抽取

用 warcio 逐条读取归档记录，避免一次性加载大文件；用 trafilatura 抽取正文，减少导航、页脚、模板内容带来的噪声。

MinHash + LSH 近重复去重

网页语料不能做全量两两比较。MinHash 把文本压成签名，LSH 把候选限制在相似桶里，降低比较成本。

语言拆分与分语言质量控制

使用 fastText 识别语种；英文侧使用 KenLM 做质量过滤，中文侧保留为后续质量模型增强点。

标准化训练交付

最终产物不是散乱文本，而是带 id、url、lang、text_sha1、estimated_tokens、split 的 JSONL，并配套 manifest 与检查报告。

MinHash 与 LSH 近重复去重流程：签名压缩、候选分桶、移除重复项
MinHash + LSH 的核心价值是减少候选比较范围，避免把去重做成不可扩展的两两比较。
fastText 语言识别后按英文、中文和其他语言拆分流水线
语种拆分让质量规则变成可扩展分支，而不是所有语言共用同一套粗糙阈值。

结果与复盘：用真实数字说话

本次 Mini-C4 复现实验留存漏斗：3008 条正文候选收敛到 231 条最终样本
阶段样本数相对 extracted 留存工程含义
extracted3008100.00%从 WARC 中拿到正文候选，只能说明“有文本”，不能说明“能训练”。
clean252283.84%基础清洗先压掉明显异常文本，为后续去重和质量判断节省成本。
deduplicated244381.22%去重收缩不剧烈，但改善训练分布健康度，减少镜像和模板重复。
final2317.68%进入最终训练集的数据需要同时通过语言、长度、重复度和质量门，代表这批样本已具备训练交付条件。

训练交付与验收闭环

训练交付物

  • train.jsonl：205 条训练样本。
  • val.jsonl：26 条验证样本。
  • smoke_test.jsonl：32 条快速调试样本。
  • training_manifest.json：记录样本数、token、路径和 split 信息。

我补充的增强

  • 环境检查：检查 fastText、KenLM 和模型文件。
  • 阶段日志：记录 10 个阶段的 return code、开始时间和耗时。
  • 可观测报告：汇总留存漏斗、过滤原因、训练输出和检查结果。
  • 一致性检查：覆盖文件完整性、split overlap、重复样本和报告一致性。
数据管道验证循环：脚本、数据产物、训练清单、评估清单和验证检查互相校验

验收闭环的价值是让代码、数据和报告互相对得上，减少数据漂移和报告失真的风险。

局限与下一步

我把这一版控制在单 shard、单机 CPU 的复现边界内，先验证方法闭环、质量指标和验收链路。后续如果扩展数据量，应先增强控制面和质量建模，再扩大处理规模。

当前局限

  • 中文质量过滤仍偏弱，英文侧有 KenLM，中文侧更多依赖启发式规则。
  • 当前只验证单 shard、单机 CPU 环境，不代表全量 Common Crawl 生产系统。
  • LSH 去重索引当前适合小规模复现，大规模多 shard 需要外部索引后端。
  • 缺少前置域名质量治理，低价值站点会进入后续处理链路。

下一步优化

  • 增加域名黑白名单和站点质量画像。
  • 引入中文网页质量模型或中文困惑度评分。
  • 将去重索引迁移到 Redis / Cassandra 等外部存储。
  • 增加可观测控制面板，展示吞吐、耗时、过滤原因和样本抽检。

复现入口

仓库中保留完整环境说明。核心路径是先检查依赖，再运行流水线，最后生成可观测性报告。 

python scripts/check_env.py
python scripts/run_pipeline.py
python scripts/build_observability_report.py
查看 GitHub 仓库

这个项目想证明什么

通过这次复现，我把 LLM 网页语料任务拆成了可执行、可验证、可复盘的数据工程链路，也明确了当前单机原型的边界和后续扩展路径。