我这些年陪着不少团队从零搭预训练管线，发现大家一上来最容易压缩时间的环节，反而是最不该压缩的——大模型预训练数据集构建。模型结构可以抄开源，训练框架可以现装，唯独数据，必须自己一点一点抠出来。这篇是“大模型训练全流程实战指南”系列的第十六篇，我不打算讲教科书式的理论，就按实际动手的顺序，把预训练数据集怎么采集、清洗、过滤、去重、配比、切分，一直到上卡训练之前的所有步骤完整过一遍。你可以把它当成一份可以照着改的工程清单，而不是一篇泛泛而谈的概念介绍。
先说个结论：数据工作从来不是“收集得越多越好”，也不是“过滤得越干净越好”。一个能训出稳定模型的预训练数据集，核心就三件事——多样性够、重复率低、质量可控。后文我会围绕这三件事把每一步拆开讲，包括我踩过的坑和最终采用的方案。
1. 预训练数据集构建的整体设计思路
1.1 为什么说数据集是预训练的第一块多米诺骨牌
不少人觉得，模型训不出来是网络结构或者超参数的问题，实际上我见过太多案例，现象是loss不降、生成重复、中文英文混杂回答，追到最后都指向数据。一个有着几百万条重复文本的数据集，会让模型反复看到同一批句子，评估时指标很好看，一旦遇到真实输入就暴露出记忆化的问题。数据是整个训练流程里最靠前的输入，它一旦出问题，后面所有环节都在错误的基础上白费功夫。
我第一次独立负责预训练数据时，犯过一个特别蠢的错误。当时为了凑数据量，把同一份百科文本在不同的清洗版本里各保留了一次，没有做跨版本去重，结果模型在一个小众问答任务上表现异常好，仔细一查才发现测试集里的句子早就被模型“背”过了。从那以后，我把数据质量验证放在了跟模型训练同等的优先级上。
预训练数据集的特殊性在于：它不需要“标注”，但需要极其严格的“筛选”。标注讲的是对错，而筛选取决于质量、领域覆盖、噪声容忍度，甚至是语序风格。这套标准必须在一开始就定清楚，否则后面做出来的训练集可能是“大而不当”。
1.2 从原始语料到训练样本：完整流水线长什么样
预训练数据集的构建不是一个脚本跑完就结束，而是一条多阶段的流水线。我自己习惯把它分成八个阶段，每个阶段都有独立的输入输出和验证标准：
- 数据源规划：确定要哪些领域的语料，各自占比多少。
- 原始数据采集：爬虫、公开数据集、合作方数据、自建知识库。
- 内容解析与清洗：从HTML、PDF、代码仓库等格式中提取纯文本。
- 质量过滤：去掉机器翻译、乱码、无意义填充、低质内容。
- 数据去重：跨来源去除重复和近似重复，防止数据泄漏和重复学习。
- 数据配比与采样：按设计好的比例混合多源数据，控制模型能力偏向。
- 文本切分与打包：把长文档和短文本切成固定长度序列，组装成训练样本。
- 验证与版本管理：用小模型试训，确认数据没有致命问题后再正式上卡。
这个流程看起来简单，但每一步都有不少细节。尤其是第6步配比，它会影响模型最终是“通才”还是“专才”，也是很多团队忽略的地方。第8步验证看起来可以拖到最后，实际上应该从第4步开始，每个阶段都抽取样本做人工检查或自动化指标统计。
1.3 数据规模与模型规模的匹配逻辑
先解决最实际的问题：到底要准备多少数据？我在前面几篇里反复提过一个经验法则，来自DeepMind的Chinchilla研究——在计算量最优的情况下，模型参数和训练token数大致是1比20的关系。也就是说，一个70亿参数的模型，至少要准备1400亿token左右的训练数据。
我举个具体的计算例子。假设你打算训练一个7B参数模型，按1比20的法则，目标数据量是140B token。纯文本存储上，中英文混合语料每个token平均大约对应1.5到2个字节，所以大概需要250GB左右的原始文本。如果按token后存储为int32来算，140B token大概要占用560GB存储，实际工程中通常不会把所有token都落盘，而是流式打包成样本文件，这样能省不少空间。
这个法则只是一个起点，不是死规矩。实际项目中，如果卡时有限，可以用略多于10比1的数据配合多轮epoch；如果目标是通用能力，很多团队会把数据量拉到参数的30倍甚至更多。关键是先有一个明确的目标量，再去决定采集和清洗的规模，否则很容易陷入“先攒几十TB再想怎么用”的被动局面。
2. 数据采集与清洗：原始语料的“来”与“去”
2.1 数据源选型：广撒网还是精准捕捞
数据源规划决定了模型的上限。我的经验是，通用模型的语料最好覆盖以下几类：网页文本、书籍、学术论文、代码、百科、社区问答、新闻和垂直领域知识库。每一类都有不同的特点和坑。
网页文本是大头，能提供丰富的表达方式和世界知识，但噪声也最高。常见来源是Common Crawl这类公开网页快照，但它不能直接用于训练，必须经过正文抽取、去噪、语言筛选。书籍和论文文本质量高，适合补足模型的长文本能力和逻辑叙事能力。代码语料能提升模型的推理和指令执行能力，但必须做精确的文件级去重，否则模型会学会“复读”常用代码模式。
精准捕捞指针对自己的业务场景去采集垂直数据。比如做医疗问答模型，就需要医学论文、药品说明书、诊疗指南等；做法务模型，就要法律条文、裁判文书、合同模板。没有这些垂直数据，基础语料再多，模型在该领域的表现也只会是“泛泛而谈”。
选数据源时要考虑三个成本：采集成本、清洗成本、版权与合规成本。很多团队只看前两项，忽略了第三项，这是很危险的。公开数据集有各自的许可协议，个人博客和社区内容也有作者权益，商用前需要把来源梳理清楚，该拿授权的就拿授权，该排除的就排除。
2.2 清洗流水线的五个核心环节
从原始网页到干净文本，我一般会走五个核心环节，每个环节都有对应手段：
| 环节 | 主要手段 | 解决什么问题 |
|---|---|---|
| 文本提取 | Trafilatura、Readability、正文抽取模型 | 去掉导航栏、广告、评论区的噪声 |
| 编码修复 | ftfy、charset-normalizer、乱码检测模型 | 处理UTF-8乱码、错误解码导致的不可读字符 |
| 语言识别 | fastText的lid.176模型、LangDetect | 只保留目标语言，避免多语言混杂 |
| 格式规范化 | 统一换行、空格、全角半角、去除控制字符 | 保证模型看到统一的文本格式 |
| 低质过滤 | 长度过滤、标点比例过滤、重复率过滤 | 去掉无信息量的短句、机器生成的垃圾段落 |
每个环节都不是做一遍就完事，而是需要抽样检查效果。我第一次做清洗时，发现乱码过滤把数学公式里的特殊符号也当成了“不可读字符”，导致大量公式文本被误删。后来调整策略：先跑语言识别，再做编码修复，最后才做乱码过滤，误删率降了很多。
另一个容易忽略的问题是“解析错误比原始噪声更可怕”。爬虫解析HTML时，如果正文抽取器抽错了区块，可能把一篇完整的新闻抽成几条不完整的句子，这种错误文本人眼很难逐条发现，但模型会因此学到密密麻麻的断句模式。所以清洗管线里一定要有长度和完整性的检查，比如段落平均长度、句子数量占比等指标。
2.3 关于清洗管线的一个可落地配置参考
清洗管线可以写得很简单，也可以写得非常复杂。简单版就是读取原始文件、解析、过滤、输出；复杂版则要支持断点续跑、多线程/分布式处理、中间结果抽样可视化。
我常用的方案是Python写数据处理脚本，配合Ray或Spark做分布式执行。核心流水线如下：
- 读取原始文件，识别格式（HTML、PDF、纯文本、JSON）。
- 抽取出正文内容，记录来源信息。
- 执行编码修复和标准化。
- 执行语言识别，保留目标语言内容。
- 执行规则过滤（文本长度、句子完整度、符号密度、重复行占比）。
- 输出为JSONL格式，每行一条文档，附带质量分、语言、来源。
这一步不要试图把所有质量问题都靠脚本解决。脚本过滤的是机械性的问题，剩下的模糊质量判断建议用分类器或困惑度过滤来处理，也就是下一节要讲的内容。
3. 质量过滤、去重与数据配比
3.1 规则、分类器、困惑度：三条过滤路线怎么选
质量过滤没有完美方案，实际工程中要把规则过滤、分类器过滤、困惑度过滤搭配起来用。
规则过滤是最可控的，我对每条规则都要求可解释、可调整。常用规则包括：
- 文本长度低于200个UTF-8字符就丢弃。
- 一段文本中重复出现的n-gram比例超过阈值就丢弃。
- 标点符号占整段文本的比例异常高或异常低就丢弃。
- 出现大量连续无意义字符（比如“aaaaaa”或“的的的的”）就丢弃。
- 文档中没有完整句子，或平均句子长度小于3个词，就丢弃。
规则过滤可以把明显垃圾清掉，但拦不住那种“看起来正常但逻辑混乱”的内容。这时候就要上分类器。常见做法是：先建一个小规模的高质量语料库作为正样本，再把规则过滤出来的低质文本作为负样本，训练一个fastText或者轻量文本分类模型，对全量语料打分排序，低于阈值的文本丢弃。
困惑度过滤是最后一道可用的质量闸门。它基于语言模型对文本的“惊讶程度”打分，越流畅的文本困惑度越低。实际操作中，我会用一个小型预训练模型或者n-gram语言模型，对每条文档计算平均困惑度，然后设定上下界。注意不能只卡上限，困惑度过低反而要小心，因为那可能意味着文本过于重复或者直接来自模板。
我个人的推荐路线是：先用规则过滤完成粗筛，再用分类器完成质量排序，最后用困惑度做边界处理。三个阶段各有任务，不要在单一环节追求极端效果。
3.2 去重：精确、SimHash、MinHash该用哪个
去重是预训练数据集构建里最不能省的一步。我见过一个真实案例：团队从某公开数据集中抽取了2亿条文本，精确定重后就只剩下1.2亿条，其中将近四成是重复或近似重复内容。如果不去重，模型不仅浪费训练时间，还会在长文本生成上出现“车轱辘话来回说”的毛病。
去重有三个层次。精确定重最简单也最有效，对整篇文档或段落直接取hash，重复就丢弃。它适用于完全一样的重复文本，但对改了标题、加了广告尾巴的文章完全无能为力。
SimHash适合快速计算近似重复。其原理是对文档分词后加权哈希，得到64位指纹，再比较不同文档指纹的汉明距离。距离小于某个阈值就认为是近似重复。它速度很快，但对短文本不够敏感，更适用于网页文本的大规模去重。
MinHash可以根据内容重叠度估计文档之间的相似度，尤其是配合LSH算法后，可以高效地找相似文档簇。实现上，先对文档做n-gram切分，再用一组哈希函数生成最小哈希签名，最后把签名分桶比较。经验参数如下：
- n-gram大小设为5，对中文文本相当于5个字符的片段。
- MinHash签名数量设为128或256。
- 相似度阈值通常设为0.8左右，对应将数据分成16个band、每个band 8行或16行的组合。
从工程性能来说，百万级文档用SimHash就够，上亿文档建议用MinHash + LSH，同时配合Spark或Ray做分布式计算。精确定重永远作为第一道筛子，因为它的计算量最小，能快速砍掉海量完全重复的数据。
3.3 多源数据配比与采样策略
数据配比是决定模型能力偏向的关键。我见过有人简单地把所有数据源合并后取前多少条，结果热门网站的内容占了九成，模型最后只会模仿某类文风。正确做法是先设定目标配比，再按配比做采样。
一个通用型模型的数据配比参考如下：
| 数据类别 | 建议配比 | 作用 |
|---|---|---|
| 网页通用文本 | 50%~60% | 提供广泛知识与多样化表达 |
| 书籍与长文 | 15%~20% | 提升长文本连贯性、深层次逻辑 |
| 代码仓库 | 5%~10% | 增强推理、结构化和填空能力 |
| 学术论文与百科 | 10% | 提升精确知识和严谨表达 |
| 社区问答与论坛 | 5% | 补充口语化表达和指令风格 |
这只是起点，实际配比必须通过小规模实验调整。调整方法很简单：训练一个几百兆或几十亿参数的模型，改变某一类语料的配比，观察下游任务和loss曲线的差异。
配比确定之后要解决采样问题。不能简单地从每个数据源里均匀抽，因为不同数据源内部质量差异很大。我的做法是给每个数据源先按质量分分桶，高质量桶的采样概率更高；再通过“温度系数”控制配比的随机程度。温度越高，采样越接近均匀分布；温度越低，则越偏向大样本数据源。
4. tokenizer 与数据格式：打通训练入口
4.1 自己训练tokenizer还是直接用现成的
数据清洗完毕，下一步是把文本变成模型能吃的token序列。这里很关键的一步是决定用现成tokenizer还是针对自己语料重新训练。
对中文语料，我更建议自己训练tokenizer，至少也要做增量训练。很多开源英文tokenizer对中文不够友好，会出现一个汉字被拆成多个token的情况，导致训练效率低下。字节级BPE是目前的主流，它把输入按字节处理，天然能覆盖任意文本，不会出现OOV问题。中文场景下，我常用SentencePiece配合BPE或Unigram模型训练，词表大小一般选32k到64k，太小则压缩率差，太大则embedding参数太多，训练开销变大。
训练tokenizer不是直接拿原始文本一顿猛跑就完事。我先会做一次“语料抽样”，保证抽出来的文本覆盖所有目标领域，而不是集中在网页文本；然后设置分词粒度和词表大小，训练完成后一定要做人工检查，看看常用中文词是不是被完整地切出来了，标点、数字、英文是否合理。
我自己有个小技巧：用训练好的tokenizer对一小批文本做编码，统计平均每个汉字的token数。如果中文平均每个字超过1.5个token，就说明词表设计不合适，需要加大词表或调整训练语料中的中文比例。
4.2 文本切分、打包与样本格式
得到token序列后，需要把不定长的文档切成固定长度的训练样本。训练时常见序列长度有2048、4096、8192等，具体取决于模型架构和显存。
切分规则要优先保证“完整性”。一篇长文档超过序列长度，就截断；多篇短文档可以拼接进一个序列，用特殊分隔符隔离。我通常的做法是：
- 在每个文档前后加上特殊token，比如
<|endoftext|>。 - 按文档顺序拼接token流。
- 将token流切成固定长度的块，例如4096个token为一个样本。
- 如果最后一个块不足长度，则用padding补齐或直接丢弃，我一般选择丢弃，避免无效计算。
切分之后的数据格式，我建议直接转成Arrow格式或TFRecord格式。Arrow格式对随机访问和大小采样都很友好，可以直接用HuggingFace的datasets库加载；TFRecord则是TensorFlow生态的标准。无论选哪个，都需要保证dataloader可以快速随机读取任意位置的样本，而不是按顺序扫整个文件。小文件数量太多会导致数据加载成为训练瓶颈，建议每个数据文件至少压到512MB以上。
我在项目里有个硬性要求：训练样本的shuffle必须是全局的。很多人只做文件级别的shuffle，同一个文件里的样本还是连续出现，模型会在每个epoch内看到大量高度相关的文本片段。正确做法是把样本id全部打乱，或者用分布式shuffle工具把样本重新排列后再训练。
4.3 编码效率检查与数据存储成本
上卡训练之前，我会跑一个快速的编码效率测试：随机抽取1万条文档，用目标tokenizer编码，计算平均每个token对应的原始字节数和每个中文词的token消耗。这能帮你发现很多潜在问题。
如果你的目标是1TB的纯中文文本，按每个汉字约1.5个token估算，token数大约在1.5万亿这个量级。再按每个token用int32（4字节）存储，就需要6TB左右空间。所以生产环境很少把全量token数据直接落盘，而是用“边编码边打包”的方式，直接生成训练样本文件。原始文本经清洗后保存在对象存储或分布式文件系统中，训练时通过数据加载器在线编码。这样能省一大半存储，也更容易做数据版本切换。
还有一个容易忽视的点：重复的token编码会导致训练启动时CPU长时间满负荷。我的处理方式是在第一次编码后缓存中间结果，后续训练直接从切分好的token样本读取，避免重复算编码。
5. 验证闭环与常见问题排查
5.1 上卡之前先做小规模验证
数据做完不能直接喂给大模型训练，必须先用小规模验证拦截致命问题。我的标准流程是：先用1亿到10亿参数的模型，在全部数据的1%到2%上训练几千步，观察几个关键指标。
- 初始loss是否在合理区间，太高说明数据噪声严重或tokenizer有问题。
- loss下降曲线是否平滑，如果出现阶梯状剧烈抖动，通常意味着数据中存在大量重复片段或格式异常。
- 训练集和验证集的loss差距是否过大，如果验证loss远高于训练loss，大概率是去重不彻底或数据泄漏。
- 手动跑几个生成的样例，看模型是否频繁复读、是否出现乱码、是否出现跨语言混杂。
我在小规模验证上踩过一次重坑：当时烧了上万卡时训练一个30B模型，训到中期发现输出里频繁出现一段固定的新闻标题。整个团队追溯了很久，才发现数据清洗脚本在处理网络存档时，把一个站点的模板页错误解析成了正文，导致那篇标题被复制了几十万次。从那以后，我坚持先小规模训练几百步，把频繁出现的字符串统计出来，再决定是否上大规模训练。
5.2 常见问题速查表：症状、原因与排查手段
| 症状 | 可能原因 | 排查与解决手段 |
|---|---|---|
| 训练loss不降，稳定在很高位 | tokenizer词表不合适、数据中大量乱码 | 检查tokenizer对中文/代码的压缩率，检查清洗抽样结果 |
| loss周期性跳变 | 数据存在大量重复文档，或shuffle不彻底 | 做精确定重和MinHash去重，重做全局shuffle |
| 模型生成内容重复率高 | 近似重复太多，文档内重复也多 | 增加n-gram重复率过滤，设置单文档内重复阈值 |
| 中文效果差，每字被切成多个token | 词表以英文为主，或训练语料中文占比低 | 重新训练tokenizer或做中文语料增量学习 |
| 训练数据加载成为瓶颈 | 小文件太多、格式不适合随机读取 | 合并大文件，转Arrow/TFRecord，启用预取机制 |
| 验证集上指标虚高 | 训练数据泄漏到验证集 | 构建验证集时排除与训练集重复的文档 |
| 代码生成能力弱 | 代码数据不足或代码去重不彻底 | 增加代码语料占比，做代码文件级去重 |
这条速查表我是从多个项目里总结出来的，几乎每个团队都会撞上一两条。尤其是“验证集指标虚高”这个问题，它没有立竿见影的报错，只会让你在模型上线后产生落差感，最好在一开始就单独构建验证集，并跑一遍验证集与训练集的相似度扫描。
5.3 数据版本管理与迭代
数据构建不是一次性工作，我习惯用版本管理来追踪每一次清洗和配比的变化。每个数据集版本至少包含以下元信息：数据源清单及来源快照、清洗脚本git commit号、过滤规则参数、去重阈值、配比表、样本量统计、小规模验证结果。
记录这些信息的作用，是让后续定位问题时能快速复现。比如训练中期发现模型某种能力下降，如果知道数据版本A与B的差异是“减少了10%的代码语料”，就能迅速判断问题出在配比而不是模型结构。实践上，我会把每次数据版本命名成类似pretrain_v2.3_minhash08_code05这样的格式，一看就明白关键参数。
迭代数据时，也要尽量做“对比实验”。先改一个小维度，比如只调整困惑度阈值，其他条件不变，训练一个小模型看效果。不要同时改清洗、去重和配比，否则后续任何结果差异都没法归因。
6. 写到最后：几个我反复踩过的坑
如果只能从这篇里带走几条经验，我想单独拎出来说：
第一，数据清洗阶段要“留证据”。每个过滤规则删了多少文档、每条规则删掉的样例长什么样，都要保存下来。我见过有团队在调参后把过滤前后的数据量记在小本上，结果换了个同事就再也说不清当初为什么导入某条规则。不要靠记忆，要写成配置和文档。
第二，隐私和合规问题要前置。不是等数据都收集好了再想，而是在采集阶段就要过滤个人敏感信息，排除不该进入训练集的文本内容。漏掉这些内容，模型生成时出问题，后续补救成本远高于前期过滤成本。
第三，不要迷信“越干净越好”。数据过于干净会导致模型泛化能力下降，因为真实世界本来就是嘈杂的。我习惯在质量过滤时保留少量低质但真实的长尾文本，比如带错别字的社区讨论、口语化的问答，它们反而能让模型变得更皮实。
第四，数据工作是持续迭代的。大规模预训练数据集的构建，没有“一次搞定”的说法。模型训练一轮之后，要回到数据侧重新做分析：哪些任务数据不足，哪些领域模型能力偏弱，然后针对性补充和调整配比。我见过最成功的项目，数据团队和训练团队是坐在一起复盘loss曲线的。
这套流程讲下来的核心，还是那句老话：模型在学数据，数据不好，参数再新也白搭。希望这篇预训练数据集构建实战笔记，能帮你在一开始就把地基打稳。后续我还会接着写训练超参、分布式训练、指令微调和推理加速的实战细节，欢迎一起交流。
