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尖峰对应的数据批次单独检查清洗逻辑合规审计不通过数据来源记录不全部分来源缺乏授权建立数据来源台账做一轮全量来源合规复核再分享一个经常被忽略的排查手段把数据管线里各个阶段的“中间结果”都保留一份抽样。做得好的团队管线里每个模块都会输出一份“处理前和处理后的抽样对比”一旦后面出现指标异常可以沿着管线逐级回溯快速定位是哪一环节出了问题。数据处理的管线非常容易变成“黑盒”——进去一堆数据出来一堆数据中间发生了什么完全要靠日志记录来还原。所以日志和采样对比不是可选项是必选项。另外有个经验是关于“过滤率”的监控。每个清洗和过滤模块都会有一个输出量与输入量的比例。如果这个比例突然发生明显变化说明输入数据的分布可能发生了变化。比如你换了一个新的数据源或者原网站改版导致页面结构大变这时候爬下来的数据质量可能已经在悄悄变化了。建立过滤率的告警机制是数据管线长期稳定运行的关键一环。在配比调优方面我倾向于记录每一次的配比配置和对应的评测结果以一版一版的方式沉淀下来。实验做混了会非常痛苦只有数据配比的版本管理做好了后面调优才有参照系。不少团队用的是预训练数据配比表加上评测结果表格管理实验版本的方式简单有效比记在文档里强十倍。实际做下来数据准备这个环节在整个人工智能系统中承担的是“基础质量”的角色。前面模型结构再先进、训练框架再高效喂进去的数据有问题最后的结果都会打折扣。而处理数据的各个环节可标准化的部分格式清洗、去重算法、过滤规则占到七成剩下三成靠对数据本身的理解和经验判断。我的体会是团队里一定要安排专门的数据工程师来做这件事而不是让做模型算法的同学“顺便处理一下数据”——这两者的思维方式和关注点完全不一样。数据工程师对数据的“直觉”是经过大量脏活累活磨出来的不是什么天赋纯粹是练出来的。重复几轮之后你会发现模型的性能上限很大程度上早就在数据准备阶段就决定了。
