1. 大模型训练的第一道门槛：为什么数据准备决定了模型能力的上限
很多人对大模型训练的理解停留在"堆显卡、调参数、跑起来"这个层面，觉得只要算力够、框架对，模型就能变聪明。实际做过一轮完整训练的人都知道，真正决定模型最终能力天花板的，往往不是训练阶段那几行超参数，而是数据准备这一步。我见过不少团队在训练框架上反复折腾，换了一版又一版并行策略，结果模型效果始终上不去，最后回头一查，问题出在语料本身——重复率高、噪声大、领域分布严重偏斜。
大模型的训练流程大致可以拆成四个阶段：数据准备、预训练、监督微调、对齐优化。这一篇只聊第一步，但这一步的工作量在整个项目里能占到六成以上。一个典型的预训练语料工程，从原始数据采集到最终产出可训练的token序列，中间要经过采集、清洗、去重、过滤、配比、分词、打包等一长串环节，每个环节都有各自的坑。
这篇文章适合两类人看：一类是刚接触大模型训练、想知道"数据到底怎么从一堆网页变成训练样本"的入门者；另一类是自己动手做过小规模训练、但效果不理想、想回头排查数据问题的实践者。我会尽量把每个环节的"为什么这么做"讲清楚，而不是只丢一堆工具名。毕竟数据准备这件事，工具会过时，但判断标准和处理逻辑是相对稳定的。
需要先说明一点：下面涉及的具体参数、阈值、工具选型，都是基于业界常见实践给出的参考值，不同团队、不同目标模型会有差异，你要根据自己的实际情况调整，不要照搬。
2. 原始语料的来源构成与采集策略
2.1 通用语料的三大来源类型
大模型的"知识底座"来自预训练语料，而预训练语料的来源通常可以归为三类。第一类是网页文本，这是体量最大的一块，覆盖了新闻、博客、论坛、百科、文档站等各种公开内容。第二类是书籍与论文，包括各类电子书、学术文献、技术手册，这类数据质量高、逻辑性强，但获取和版权处理都比较麻烦。第三类是结构化与半结构化数据，比如代码仓库、问答社区、百科条目、字幕文本等，它们格式相对规整，清洗成本低。
这三类数据的价值不一样。网页文本胜在广度和时效性，但噪声极大；书籍论文胜在深度和连贯性，但领域覆盖有限；代码和问答类数据胜在格式规范，但对自然语言理解能力的贡献相对窄。一个健康的预训练语料配比，通常是网页文本占大头，书籍论文和结构化数据作为补充，具体比例要看目标模型偏向通用能力还是垂直能力。
采集策略上，常见做法是先划定一个种子集合，再通过链接扩展的方式滚雪球。这里有个经验：种子站点的选择直接决定了语料的质量基线。如果种子站点本身内容杂乱、广告泛滥，后面清洗再狠也救不回来。我一般会优先选那些内容审核严格、排版规范的站点作为种子，宁可初始规模小一点，也要保证源头干净。
2.2 采集过程中容易被忽略的合规与去重前置
采集阶段有两件事必须在动手前就想清楚，否则后面会返工。第一是合规边界。哪些内容可以采、哪些不能采、采下来怎么存、存多久，这些都要有明确规则。很多团队是采完才想起来处理，结果发现一大批数据不能用，白白浪费了带宽和存储。
第二是去重前置。很多人习惯把所有数据先堆进一个大池子，等清洗阶段再去重。这个做法在小规模下没问题，但语料上到TB级别后，全量去重的计算成本会高得离谱。更合理的做法是在采集阶段就做一层粗去重，比如按URL指纹、按文档哈希先过滤掉明显重复的抓取结果，把精确去重留到清洗阶段。这样能把后续处理的数据量压下来一大截。
提示：采集阶段建议同时记录每条数据的来源、抓取时间、原始URL等元信息。这些元信息在后续做数据配比、溯源排查、质量评估时非常有用，丢了就很难补回来。
3. 从原始文本到干净语料：清洗流水线的设计逻辑
3.1 清洗不是"删脏东西"，而是"保留有效信号"
很多人对数据清洗的理解是"把垃圾去掉"，这个说法对但不完整。清洗的真正目标是最大化有效信号、最小化噪声干扰。同样一段文本，对某个任务可能是噪声，对另一个任务可能是宝贵数据。所以清洗规则的设计必须和目标模型的能力需求挂钩，不能一刀切。
举个具体例子：网页里的导航栏、页脚、广告位，这些对语言模型来说是纯噪声，必须去掉。但网页里的评论区、用户讨论，虽然格式乱，却包含了大量口语化表达和真实对话，对模型的对话能力有帮助，这类内容就不该简单删掉，而是应该单独抽取、单独处理。所以清洗流水线的第一步不是动手删，而是先分类，把不同来源、不同结构的内容分流到不同的处理通道。
3.2 正文抽取：规则、模板与模型三条路线
正文抽取是清洗流水线里技术含量最高的一环。常见做法有三条路线。第一条是基于规则的抽取，比如按HTML标签密度、按文本块长度、按标点分布来判断哪块是正文。这条路快、可控，但对页面结构变化敏感，站点一改版规则就失效。
第二条是基于模板的抽取，针对高频站点人工写抽取模板。准确率高，但覆盖有限，适合种子站点固定的场景。第三条是基于模型的抽取，训练一个分类器或序列标注模型来判断每个文本块是不是正文。这条路泛化好，但需要标注数据，冷启动成本高。
实际工程里通常是三条路线混用：高频站点用模板，中频站点用规则，长尾站点用模型兜底。我自己的经验是，规则和模板能覆盖八成以上的流量，模型主要用来处理剩下那两成难啃的页面。不要一上来就上模型，成本高且不一定比规则准。
3.3 质量过滤的几道常用筛子
正文抽出来之后，还要过几道质量筛子。常用的筛子包括：
- 长度过滤：太短的文本（比如少于50个字符）信息量不足，太长的文本（比如超过10万字符）往往是拼接错误或异常页面，都要处理。
- 重复度过滤：句内重复、段内重复、文档内重复，用n-gram重复率或压缩比来衡量。
- 语言过滤：用语言识别模型判断文本主语言，过滤掉与目标语种不符的内容。
- 困惑度过滤：用一个小的参考语言模型给文本打分，困惑度异常高或异常低的都值得怀疑，前者可能是乱码，后者可能是模板化文本。
- 敏感与低质内容过滤：按规则和分类器过滤掉明显不合规、无意义的内容。
这几道筛子的阈值不是拍脑袋定的，而是要在小样本上先跑一遍，看过滤前后的分布变化，再决定阈值。我一般会保留过滤日志，记录每条数据被哪道筛子拦下，方便后续分析是不是误杀。
| 过滤类型 | 常用指标 | 参考阈值 | 主要拦截对象 |
|---|---|---|---|
| 长度过滤 | 字符数 | 50 至 100000 | 碎片文本、异常拼接 |
| 重复度过滤 | n-gram重复率 | 高于0.3需复核 | 模板页、复制粘贴内容 |
| 语言过滤 | 主语言置信度 | 低于0.8需复核 | 多语言混杂页 |
| 困惑度过滤 | 参考模型PPL | 两端各截5% | 乱码、模板文本 |
4. 去重：大模型语料工程里最容易被低估的环节
4.1 重复数据为什么对模型有害
重复数据在大模型训练里是个隐形杀手。表面上看，重复数据只是浪费算力，但实际上它的危害更深。模型在训练中会反复看到同样的内容，导致对这些内容的"记忆"过强，一方面容易在生成时逐字复现训练数据，带来合规风险；另一方面会挤占其他数据的训练权重，让模型的能力分布变得畸形。
有研究做过对比，同一份语料去重前后训练出来的模型，在下游任务上的表现差距可以到几个百分点。这个差距在预训练阶段可能不明显，但到了微调和推理阶段会被放大。所以去重不是可选项，是必选项。
4.2 精确去重、模糊去重与语义去重的取舍
去重分三个层次。精确去重是最简单的，按文档哈希或段落哈希比对，完全相同就删。模糊去重是处理"几乎相同"的情况，比如只改了几个词的转载文章，常用MinHash加局部敏感哈希来做。语义去重是最狠的，用向量表示判断两段文本语义是否高度相似，能抓到改写得比较彻底的重复内容，但计算成本最高。
实际工程里的顺序通常是：先精确去重压量，再模糊去重抓转载，最后视算力情况决定要不要上语义去重。我见过一些团队一上来就做语义去重，结果算力全耗在去重上，训练反而没资源了。合理的做法是分层处理，把最贵的操作留给最需要的那部分数据。
4.3 去重粒度：文档级、段落级还是句子级
去重的粒度选择也很关键。文档级去重最粗，能去掉整篇重复的文章，但抓不到"文档不同、段落相同"的情况。段落级去重能抓到跨文档的段落复用，是性价比最高的粒度。句子级去重最细，能去掉高频套话和模板句，但容易误伤正常表达。
我的建议是文档级和段落级都做，句子级视情况做。句子级去重特别适合处理那些"每篇都有一大段相同免责声明"的网页，去掉之后语料干净很多。但句子级去重的阈值要调好，太激进会把正常的常用表达也删掉，反而损害语言的多样性。
注意：去重之后一定要重新统计语料的规模、领域分布、长度分布。去重会显著改变这些统计量，如果不去重就做配比，配比结果会失真。
5. 数据配比与课程学习：让模型按合理的顺序"吃饭"
5.1 领域配比不是拍脑袋，要有依据
语料清洗干净之后，下一步是决定各类数据按什么比例混合。这个比例直接决定了模型的能力偏向。如果网页文本占比过高，模型的知识面广但深度不足；如果书籍论文占比过高，模型逻辑性强但对话能力弱；如果代码数据占比过高，模型编程强但自然语言表达可能变差。
配比的依据通常来自三个地方：一是目标模型的能力需求，比如要做通用助手，就要保证对话类、知识类数据的比例；二是消融实验，小规模训练几组不同配比的模型，看下游表现；三是参考公开的配比方案，作为起点再调整。我一般会先定一个基线配比，然后在小模型上做几轮消融，确认方向后再放大到全量训练。
5.2 课程学习：先学什么后学什么
课程学习是近几年比较受关注的一个点。核心思想是让模型先学简单、干净的数据，再逐步引入复杂、噪声较多的数据。这样模型在早期能建立稳定的语言基础，后期再适应真实世界的多样性。
具体操作上，可以把语料按质量分档，高质量数据在前几个epoch集中使用，低质量数据在后几个epoch逐步加入。也可以按领域分阶段，先通用后垂直。课程学习的效果在不同任务上差异较大，不是所有场景都适用，但作为数据准备的一个可选策略，值得在小规模上先验证。
5.3 配比失衡的典型症状与排查
配比失衡在训练早期不容易发现，但有一些典型症状可以帮你判断。比如模型在某个领域表现异常好、其他领域异常差，可能是该领域数据占比过高；模型生成内容风格单一、缺乏变化，可能是语料多样性不足；模型频繁输出某些固定表达，可能是某类模板数据占比过高。
排查方法是做数据侧和模型侧的对照分析：统计语料的领域分布、长度分布、重复率，再统计模型在不同领域测试集上的表现，两边一对照，问题往往就浮出来了。这个过程比较费时间，但比盲目调参有效得多。
6. 分词与序列打包：数据进入模型前的最后一道加工
6.1 分词器的选择与训练
分词是把文本转成token序列的过程，分词器的好坏直接影响模型的训练效率和生成质量。常见的选择有BPE、WordPiece、Unigram等算法，各有适用场景。BPE在英文和多语言场景下表现均衡，Unigram在中文等语言上有时更优。
分词器的词表大小是个关键参数。词表太小，序列变长，训练和推理都变慢；词表太大，嵌入矩阵变大，低频token学不好。常见的中文大模型词表在5万到15万之间，具体要看语料规模和语言分布。训练分词器时要用和预训练语料同分布的数据，否则会出现大量未登录词，浪费词表容量。
6.2 序列打包的几种策略
分词之后要把token序列打包成固定长度的训练样本。最简单的策略是拼接加截断，把多条短序列拼到目标长度，超长的截断。这个做法实现简单，但会引入跨文档的注意力污染，模型可能学到不相关的文档间关联。
更精细的做法是使用注意力掩码，在拼接时记录每条原始文档的边界，训练时用掩码阻止跨文档注意力。这样既保证了打包效率，又避免了污染。还有一种做法是按文档长度分桶，把长度相近的文档放在一起打包，减少填充浪费。实际工程里通常是几种策略结合，先分桶再拼接加掩码。
6.3 打包效率与训练稳定性的平衡
打包策略还影响训练稳定性。如果打包后的样本长度分布极不均匀，训练时的显存占用和计算量波动会很大，容易导致训练不稳定。所以打包之后要统计长度分布，尽量让每个batch内的样本长度接近。
另外，打包时的随机打乱也很重要。如果语料按来源顺序打包，模型会连续看到大量同源数据，导致训练震荡。正确的做法是在打包前充分打乱，让每个batch内的数据来源尽量分散。这个细节看起来小，但对训练稳定性影响不小。
7. 数据准备阶段的质量验证与常见返工点
7.1 怎么判断数据准备做到位了
数据准备做完之后，不能直接开训，要先做一轮质量验证。验证的维度包括：语料规模是否达标、领域分布是否符合预期、重复率是否降到合理区间、长度分布是否健康、抽样人工检查是否有明显噪声。
人工抽检这一步不能省。自动化指标再全，也可能漏掉一些只有人眼才能发现的问题，比如语义不通、事实错误、格式错乱。我一般会随机抽几百条样本，逐条看，记录问题类型和比例，如果问题比例超过可接受范围，就要回头调整清洗规则。
7.2 几个高频返工点
根据我的经验，数据准备阶段最常见的返工点有这么几个。第一是去重不彻底，训练到一半发现模型开始复读，回头查才发现语料里有大量重复。第二是配比失衡，模型在某些任务上表现异常，排查后发现是某类数据占比过高。第三是分词器与语料不匹配，导致序列长度远超预期，训练成本飙升。第四是打包策略不当，训练loss震荡严重，调了半天超参才发现是数据打包的问题。
这些返工点的共同特点是：在数据阶段花一小时能解决的问题，拖到训练阶段可能要花一天甚至更久。所以数据准备阶段的验证和自查，投入再多都不为过。
7.3 数据版本管理：别让语料变成一笔糊涂账
最后说一个容易被忽略的点：数据版本管理。语料在清洗、去重、配比过程中会经历多次变换，如果不做版本管理，过一段时间你根本说不清当前用的语料是哪一版、经过了哪些处理。这在排查问题时会非常痛苦。
建议的做法是给每个处理阶段产出的语料打上版本号，记录处理参数、处理时间、数据量、抽样样本。这样任何时候都能回溯到任意一版语料，对比不同版本的效果差异。这个习惯在单次训练里可能感觉不到价值，但一旦项目进入迭代阶段，价值就体现出来了。
我在实际项目里踩过最深的坑，就是早期没做数据版本管理，后来模型效果波动，想对比不同语料版本的影响，结果发现旧版本已经被覆盖，只能从头重跑一遍清洗流程。那次之后，我把数据版本管理写进了流程规范，再也没犯过同样的错误。数据准备这件事，做的当下觉得繁琐，但它决定了后面所有环节的天花板，值得认真对待。
