1. 全流程思路拆解：数据准备到底在做什么
很多刚接触大模型训练的朋友，第一反应是去研究Transformer架构、注意力机制、分布式训练框架，结果真到要训练一个模型的时候，发现卡在第一步——数据。我见过不止一个团队，代码写得漂漂亮亮，训练脚本调得一帆风顺，结果喂进去的数据垃圾一堆，训练出来的模型要么胡言乱语，要么知识面窄得可怜。这不是模型结构的问题，是数据准备这个“前置环节”没做好。
预训练数据准备，说白了就是把互联网上那些乱七八糟的文本，变成模型能“吃”的干净、有序、有营养的“食物”。这个过程之所以被称为“炼金术”，是因为它既有标准化流程，又有大量需要靠经验判断的地方。同样的原始语料，不同团队处理出来的结果可能天差地别，最后模型的效果也就天差地别。
整个流程通常分为六个环节：数据采集、数据清洗、去重、质量过滤、数据配比、数据评估验证。听起来不复杂，但每个环节里面都有大量细节。比如清洗的时候，HTML标签怎么去、乱码怎么识别、广告导航文本怎么剔除；去重的时候，是用MinHash还是SimHash，阈值设多少；质量过滤的时候，是用规则还是用分类器，正负样本怎么标。这些都不是靠一个通用的开源脚本就能解决的，需要结合你自己的数据来源和模型定位来定制。
另外要提醒的是，数据准备不是一个“一次性”的工作。很多团队在第一个版本模型训练完之后，回头来复盘效果不好，发现是数据配比出了问题或者某些低质量数据没滤干净，于是重新清洗、重新配比，再来一轮。所以从一开始就应该把数据管线的各个模块拆开设计好，让每一部分可复用、可单独调参，否则后期想优化只能推倒重来。
2. 数据采集与来源：语料不是越多越好
2.1 主流的语料来源类型
数据采集听起来简单——去网上爬不就行了？实际上远没那么简单。大模型预训练数据的来源通常分为几大类：
第一类是通用网页语料。这类数据覆盖面最广，百科、新闻、论坛、博客什么都有，是模型学习“世界知识”和语言能力的基础。通用网页数据的量大，但噪声也大，而且不同网站的文本质量差异明显。比如百科类内容质量普遍较高，而论坛、评论区的内容经常夹杂大量无意义的口水话。
第二类是结构化知识源。包括百科条目、学术论文、书籍、代码仓库等等。这类数据质量高，知识密度大，但总量相对有限，需要专门处理。比如书籍类数据要考虑版权问题，能用的其实很有限；学术论文需要处理PDF转文本带来的格式错乱。
第三类是垂直领域语料。如果你想训练一个代码模型，就要收集大量的代码仓库数据；如果你想训练一个数学推理模型，就要收集大量的数学题目和推导过程。这部分数据的获取和处理，通常是定制化的，需要针对领域特点专门设计清洗逻辑。
2.2 采集时容易忽略的几个问题
一个是版权和合规问题。国内对数据合规的要求越来越严格，采集数据的来源、用途都要有清晰的记录，不能想怎么爬就怎么爬。我的建议是建立一张数据来源清单，记录每个来源的域名、内容类型、采集时间、许可协议，后面如果出了合规问题，至少能追溯。
另一个是“偏科”问题。很多团队为了省事，只采几个大型网站的语料，结果训练出来的模型说话一股“某个论坛味”。数据来源一定要多样，不同网站、不同领域的语料都要有，模型的语言风格才会自然、知识面才会广。
还有一个坑是时间覆盖。互联网上每天都有海量新内容产生，但有些旧内容会下线或者被修改。如果你采集的语料集中在一段时间内，模型对那段时间之后的事件就一无所知。很多团队会在训练完后做一次知识覆盖测试，发现模型对某些时间段的知识严重缺失，回查之后才发现语料的时间分布不合理。
3. 清洗、去重与质量过滤：决定模型“智商下限”的三道门槛
3.1 文本清洗的先后顺序与操作要点
文本清洗是整个流程里最琐碎、最不显山露水但直接影响后续所有环节的工作。我自己的经验是，清洗要按“先粗后细”的顺序来做。
第一轮是格式归一化：统一换行符、去掉多余的空白字符、把全角标点转半角（中文场景要保留全角标点，这里要区分处理）、消除不可见字符和控制字符。这轮通常用一些现成的文本处理库就能搞定，但要注意处理速度，因为你面对的是TB级别的数据，每多一个正则表达式，跑一遍的时间可能就多几个小时。
第二轮是内容级清洗：去掉HTML标签（如果语料是从网页爬取的）、去掉JavaScript代码残留、识别并剔除乱码文本。乱码识别的常规做法是统计字符分布，如果一段文本里生僻的Unicode字符占比过高，基本可以判定为乱码。还有一类常见噪声是“广告和导航文本”，像“点击这里下载”“上一篇下一篇”“版权所有”这类重复出现的模板文本，需要通过规则匹配去掉。
第三轮是语言识别和过滤。如果你的语料是混合语言环境，可以使用语言识别工具按语言分流。中英文语料最好不要混在一起，因为后续的tokenizer训练和配比都跟语言强相关。
我做清洗时踩过最深的一个坑是：不要为了追求“干净”而把文本截得太碎。有些团队的清洗规则过于激进，把正文里的段落都被当噪声过滤掉了，导致语料的语义完整性很差。清洗的底线是保持文本的自然语义边界——段落要完整，上下文要连贯。宁可留一些无伤大雅的噪声，也不能把好好的内容切碎了。
3.2 去重：为什么需要重复检测与几十种实现方案的选择
互联网语料有一个显著特点：重复内容非常多。一篇文章被多个网站转载、一条新闻被多家媒体报道、一段代码被复制到无数个仓库里——如果不做去重，模型会大量地“记住”这些重复内容，导致两方面的后果。
泛化能力下降：模型过于“自信”地输出训练集中重复出现的句式，而面对真正多样化的表达时表现不佳，俗称“背答案”而不是“学知识”。训练效率降低：重复数据会拖慢收敛速度，因为模型在反复学习同一个样本，梯度更新被重复内容“稀释”了。
去重的核心是相似度检测，常用的方案有MinHash和SimHash两种思路。MinHash适合大规模语料的长文本去重（比如文档级去重），先把文本转成若干shingle（连续片段），再通过哈希和MinHash签名来估计文本间的Jaccard相似度。SimHash更适合短文本和特征向量的相似度比较，通过加权特征哈希得到指纹，再比较汉明距离。
实际工程中，我更推荐结合两种方案：先用SimHash做第一轮快速过滤，把明显重复的文本剔除掉；再用MinHash做精确去重，把相似度在阈值附近的文本处理掉。重复检测的阈值一般设置在相似度0.7到0.85之间，具体要根据你的语料特点来调。如果语料里转载类内容多，阈值就要设得更严格。
还有一个容易被忽视的维度是“子串重复”。有些文本整体不重复，但内部包含大量重复的段落，比如法律条文在不同文章里反复被引用。这部分可以利用滑动窗口做段落级的重复检测，又是一个独立工程。
3.3 质量过滤：规则+分类器的双轨策略
清洗和去重解决的是“脏”和“重复”的问题，质量过滤解决的是“水”的问题——文本本身是合法的、不重复的，但内容空洞、无信息量、胡说八道，或者带有明显的低质特征。
质量过滤的常规做法是规则+分类器双轨并行。规则层面有几种常见信号：
- 文本长度：过短的文本通常缺乏完整语义，比如少于一定字符数（常见阈值是50到100字符）直接丢弃。
- 标点符号密度：正常的文章标点密度在一个合理区间，过高或过低都说明结构异常。
- 重复字符比例：比如连续的“哈哈哈哈”或“。。。。。。”这类文本。
- 特殊字符比例：如果一段文本里除了字母数字之外的特殊字符占比异常高，很可能是代码残留或噪声。
规则过滤之后，还需要一个分类器模型来打“质量分”。常见做法是用一个小规模的BERT类模型（别用来做预训练，太重了）做二分类：输入一段文本，输出是“高质量”还是“低质量”。训练这个分类器需要人工标注一批样本，正例是那些你觉得“这段文本适合模型学习”的内容，负例是“低质内容”。标注样本量一般在数万到数十万这个量级，具体取决于你的语料分布。
分类器过滤的好处是可以持续迭代。你训练出第一个版本分类器，用它过滤完一批数据之后，抽样看那些被滤掉的内容里有没有误杀的“优质内容”，收集误杀样本，再优化分类器。这个过程可以循环好几轮，把分类器的准确率逐步提上来。
3.4 敏感内容与隐私信息处理
这部分是质量过滤里绕不开的，尤其在国内合规要求下更要谨慎。预训练语料里如果包含个人隐私信息（身份证号、手机号、地址等）或者敏感内容，不仅会给模型带来合规风险，还会造成在线上使用时出现严重问题。
工程上的做法是：先做一个正则规则库，把明显的个人信息模式识别出来（手机号、身份证、邮箱、银行卡号等），做脱敏或者剔除；再用关键词列表+分类器的方式过滤有害内容。需要注意的是，这部分过滤规则的覆盖面和精确度要不断更新迭代，定期用最新的负面样本去测试过滤效果。千万不要觉得“用一个人人都知道的关键词列表就够了”，现实中能绕过关键词规则的写法非常多，需要配合模型分类器来处理。
4. 数据配比与Tokenizer训练：预训练的“秘方”核心
4.1 配比为什么是“炼金术”的关键所在
清洗完、过滤完的数据，到了配比这一步，才真正体现“炼金术”的含金量。配比就是决定不同来源的数据各占多少比例。不同的比例组合，训练出来的模型能力边界完全不同。
常规的经验是：通用网页语料占大头（50%-70%），百科和书籍类高质量知识源占10%-20%，代码数据占10%-15%（如果要做代码能力），多语言平行语料按需配置。但具体怎么调，跟你训练的目标高度相关。
如果目标是通用对话模型，你需要保证语料中有充足的对话场景数据，比如论坛帖子、问答社区、客服聊天记录；如果目标是推理模型，数学和逻辑推导类的数据比例就要提上去。
实际调配比的过程中，我习惯从“困惑度”和“下游任务验证集”两个维度来观察效果。困惑度看的是模型对语料的拟合情况，下游任务验证集看的是实际能力表现。比如你调高了代码数据的比例，代码生成的评测分数上去了，但通用问答的分数可能下降，这里就要找一个平衡点。
还有一个常见的误区是“堆量”。数据量不是越大越好，互联网上的低质重复内容会把高质量数据的信号淹没掉。我做过一个对比实验：只用清洗后的300GB高质量数据训练，效果比用原始1TB数据直接训练还要好。这个结果让团队把“先求量”的思路彻底改掉了，现在内部统一的标准是“先求质，再求量，配比要反复试”。
4.2 Tokenizer训练：决定模型语言基础的隐形工程
Tokenizer是把文本切成token序列的工具。大多数人容易忽略这个环节，认为直接拿一个开源tokenizer用就行。实际上，tokenizer训练是预训练数据准备里不可跳过的一环，因为它直接决定模型对不同语言的编码效率。
一个典型的例子是中文和多语言场景。如果用纯英文语料训练的tokenizer来处理中文，中文文本会被切得非常碎片化，导致序列长度膨胀，训练和推理效率都大幅下降。
Tokenizer训练的数据同样是从清洗后的语料中抽样，但要注意几个点：一是按最终配比来抽样，保证各语言的tokenizer训练数据比例跟你的预训练配比大致一致；二是要预留一部分“通用文本”来保证tokenizer的普适性；三是词表大小的选择要综合考虑压缩率和模型规模——词表太大，embedding参数会膨胀，训练成本变高；词表太小，压缩率不够，序列长度变长。
我一般会训练多个候选tokenizer（词表大小、采样策略不同），然后计算它们在验证语料上的压缩率和OOV（未登录词）比例，再做决定。压缩率评估的指标不复杂，就是平均每个token对应的原始字符数，越高说明压缩效率越好。
5. 数据评估与验证：一条被很多人跳过的生死线
5.1 为什么必须做数据评估
很多团队在数据准备好之后就急吼吼地开始训练，结果训练到一半发现loss不对劲、训练集准确率忽高忽低，才回头查数据问题。实际上，在投入大量算力之前，花几天时间做一次全面的数据质量评估，省下的可是几十万甚至上百万的算力成本。
数据评估要回答的核心问题是：这批数据到底能不能支撑训练出一个好模型？具体来说分几个层面：
- 统计层面：数据量是否符合预期；各来源比例是否跟配比要求一致；语言分布是否合理；重复率是否在可接受范围内。
- 语义层面：抽读一批文本，看内容是否连贯、是否有明显错误、是否符合模型的目标能力方向。
- 模型层面：用一个小规模的参考模型，或者用一个现有的开源模型，在这批数据上做一小段增量训练或者困惑度评估，看数据分布是否合理。
5.2 可视化与指标监控的实操建议
数据量到了TB级别，靠人去“看数据”是不现实的，必须建立一套可视化的监控指标。我建议至少包含以下指标：
数据量统计指标（来源分布、语言分布、平均文本长度、token总数）、质量指标（重复率、噪声比例、过滤率、分类器打分分布）、训练影响指标（在验证集上的困惑度曲线、下游任务抽样评测）。
可视化指标不要求做到多花哨，关键是能在一张仪表盘里看到全局，并且能够按来源、按语言、按时间段下钻查细节。我见过团队做了一套非常复杂的可视化系统，结果真正排查问题时还是靠写SQL查原始表。所以系统的实用性比美观重要得多。
5.3 小规模试训：算力投入的“最小可行验证”
正式全量训练之前，花小算力做一次few-step试训是性价比极高的做法。具体操作是：从准备好的数据中采样一个小批次（比如1万到5万个样本），用一个小配置跑几步训练，观察loss的下降曲线和数据特征的分布。
试训能发现的典型问题非常多，比如数据里有大量错位文本（上一段的内容串到下一段）、批量采样时某种语言的数据集中在一起导致分布不稳、部分文本存在隐藏的乱码等。这些问题在全量训练时往往要很久才能暴露，试训几天就能发现。
我自己的习惯是：每个版本的数据管线改动之后，都会跑一次小规模试训再进全量。这个流程看起来多花了两三天，但避免的坑可以说不计其数。
6. 常见问题与排查技巧实录
数据准备过程中，有些问题是你一定会在某个时间点碰到的。我把高频出现的问题和排查方法写下来，方便大家直接查漏。
| 现象 | 可能原因 | 排查与解法 |
|---|---|---|
| 训练时loss下降缓慢 | 数据重复率高，模型反复学同一批内容 | 检查去重环节阈值；用MinHash重新跑一遍，看重复率占比 |
| 模型对某些语言或领域完全不会 | 对应语料比例不足，或清洗时被误过滤 | 按来源和语言维度拆分统计，定位缺失；调整配比并恢复误杀的数据 |
| 模型输出胡言乱语 | 语料中大量低质垃圾文本，规则和分类器漏判 | 抽读被过滤前后的样本，核对分类器质量；提高质量阈值，补充负面样本 |
| tokenizer切词的压缩率异常 | 训练tokenizer的数据配比与预训练配比不一致 | 重新按最终的预训练配比采样训练tokenizer |
| 训练集上出现异常的尖峰loss | 某一时间窗口的数据存在整体性坏点（如爬虫故障导致的半截文本） | 按时间窗口切分数据，定位loss尖峰对应的数据批次，单独检查清洗逻辑 |
| 合规审计不通过 | 数据来源记录不全，部分来源缺乏授权 | 建立数据来源台账，做一轮全量来源合规复核 |
再分享一个经常被忽略的排查手段：把数据管线里各个阶段的“中间结果”都保留一份抽样。做得好的团队，管线里每个模块都会输出一份“处理前和处理后的抽样对比”，一旦后面出现指标异常，可以沿着管线逐级回溯，快速定位是哪一环节出了问题。数据处理的管线非常容易变成“黑盒”——进去一堆数据，出来一堆数据，中间发生了什么完全要靠日志记录来还原。所以日志和采样对比不是可选项，是必选项。
另外有个经验是关于“过滤率”的监控。每个清洗和过滤模块都会有一个输出量与输入量的比例。如果这个比例突然发生明显变化，说明输入数据的分布可能发生了变化。比如你换了一个新的数据源，或者原网站改版导致页面结构大变，这时候爬下来的数据质量可能已经在悄悄变化了。建立过滤率的告警机制，是数据管线长期稳定运行的关键一环。
在配比调优方面，我倾向于记录每一次的配比配置和对应的评测结果，以一版一版的方式沉淀下来。实验做混了会非常痛苦，只有数据配比的版本管理做好了，后面调优才有参照系。不少团队用的是：预训练数据配比表加上评测结果表格管理实验版本的方式，简单有效，比记在文档里强十倍。
实际做下来，数据准备这个环节在整个人工智能系统中承担的是“基础质量”的角色。前面模型结构再先进、训练框架再高效，喂进去的数据有问题，最后的结果都会打折扣。而处理数据的各个环节，可标准化的部分（格式清洗、去重算法、过滤规则）占到七成，剩下三成靠对数据本身的理解和经验判断。我的体会是：团队里一定要安排专门的数据工程师来做这件事，而不是让做模型算法的同学“顺便处理一下数据”——这两者的思维方式和关注点完全不一样。数据工程师对数据的“直觉”，是经过大量脏活累活磨出来的，不是什么天赋，纯粹是练出来的。重复几轮之后你会发现，模型的性能上限，很大程度上早就在数据准备阶段就决定了。
