1. 大模型训练的第一步为什么是数据而不是模型结构很多人第一次接触大模型训练脑子里想的都是Transformer架构、注意力机制、参数量怎么堆到千亿级别。但真正进过训练流程的人都知道模型结构在今天的工程实践中反而相对标准化了真正决定一个模型聪不聪明、稳不稳、能不能用的是喂进去的数据。我见过太多团队在模型结构上反复折腾结果换了一批数据之后效果直接翻倍也见过结构平平无奇的模型因为数据质量过硬而在评测中碾压对手。数据准备这件事说白了就是给模型准备教材。你让一个学生学数学结果教材里全是错题、重复题、超纲题他再聪明也学不出来。大模型也一样它的全部知识、语言习惯、推理模式几乎都是从训练数据里读出来的。所以当我们说训练一个大模型的时候第一步永远不是写模型代码而是搞清楚我要用什么数据、这些数据从哪来、怎么清洗、怎么配比、怎么喂给模型。这一篇聚焦在数据准备阶段把整个流程拆开讲透。适合两类人看一类是想系统理解大模型训练全流程的技术爱好者另一类是正准备动手做小规模训练或微调、需要知道数据该怎么处理的开发者。我不会只给你一个先清洗再分词的流水账而是把每一步背后的原因、常见的坑、以及实际工程中怎么取舍都讲清楚。先建立一个整体认知。一个完整的大模型训练数据流程大致会经过这么几个阶段数据采集与来源确定、数据清洗与去重、质量过滤、数据配比与混合、分词与序列化、以及最终的数据打包与加载。这几个阶段不是严格线性的实际工程里经常来回迭代比如配比调完发现某类数据质量不行又得回到清洗阶段。下面逐个展开。2. 数据从哪里来来源选择决定了模型的能力天花板2.1 通用语料、专业语料与指令数据的定位差异大模型的训练数据按用途大致分三层。第一层是通用预训练语料包括网页文本、书籍、百科、新闻、论坛帖子等它的作用是让模型学会语言本身——语法、常识、世界知识。第二层是专业领域语料比如代码、论文、法律文书、医学文献用来给模型注入特定领域的深度知识。第三层是指令与对齐数据也就是问题-回答对用来教模型怎么按照人类期望的方式回应。这三层不是随便混在一起的。预训练阶段主要用前两层而且量级极大动辄几万亿token指令微调阶段才大量使用第三层量级小得多但质量要求极高。我见过新手把指令数据直接混进预训练语料里结果模型学得四不像——既没有扎实的语言基础指令遵循也做不好。原因很简单预训练的目标是预测下一个词它需要的是海量、多样、自然的文本而指令数据是高度结构化的混进去会破坏预训练的数据分布。选择来源时有个核心原则来源的多样性比单一来源的规模更重要。一个只爬了某几个网站的数据集哪怕有几千亿token模型也会严重偏科。理想情况下通用语料应该覆盖尽可能多的领域、文体、语言风格。这也是为什么很多公开数据集会刻意混合网页、书籍、代码、学术文本等多种来源。2.2 网页数据采集中的现实约束网页数据是预训练语料的主力通常占一半以上。采集网页数据最直接的方式是爬取公开网页但这里有几个现实问题必须提前想清楚。第一是版权与合规。不是所有网页都能随便拿来训练。实际工程中团队通常会优先选择明确允许使用的公开数据集或者只采集那些robots协议允许、且不涉及敏感内容的页面。这一块没有捷径合规是底线踩了线后面全是麻烦。第二是数据的时间分布。网页数据天然带有时间戳如果全用最近一年的数据模型对历史知识就会很薄弱如果全用十年前的数据又会缺失新知识。常见做法是让数据在时间上尽量均匀分布同时对时效性强的领域如科技新闻适当加权。第三是语言与地域分布。如果你的目标模型主要服务中文用户那中文语料的比例就要足够高但也不能完全没有英文——因为很多技术概念、代码、学术内容在英文世界里更丰富。我个人的经验是中英混合训练时英文比例控制在20%到40%之间比较稳妥具体看目标场景。2.3 专业语料的获取门槛与处理难点专业语料的价值在于密度。一段代码、一篇论文里面包含的有效信息量远高于一段普通网页文本。但它的获取门槛也高。代码可以从公开代码托管平台获取但要注意许可证论文可以从公开学术数据库获取但要注意版权和格式解析法律、医学文本往往涉及隐私和合规处理起来更复杂。专业语料最大的难点是格式解析。PDF、扫描件、公式、表格这些非结构化内容要转成纯文本中间会损失大量信息。我处理过一批学术PDF直接提取文本后公式全变成了乱码表格结构也全丢了。后来只能针对性地做版面分析把公式和表格单独处理。这一步没有通用方案必须根据数据源的特点定制。提示专业语料不要贪多。一个领域里精挑细选的高质量文本效果往往好过大量粗筛的低质文本。宁缺毋滥在专业语料上体现得特别明显。3. 清洗与去重决定模型干净程度的关键工序3.1 为什么原始数据几乎不能直接用刚从网页或文档里拿到的原始数据脏得超出很多人的想象。里面混杂着HTML标签、导航栏文字、广告、乱码、重复段落、无意义的符号串。如果直接拿去训练模型会把这些噪声当成正常语言来学结果就是生成的内容里夹杂各种奇怪符号或者动不动就输出网页导航文字。清洗的目标不是把数据变得完美而是把明显有害的噪声去掉同时尽量保留有效信息。这里有个度的问题清洗太狠会把有价值的短文本、特殊表达也删掉清洗太松噪声又会影响训练。实际工程中清洗规则通常是逐步迭代出来的先上一批基础规则看模型效果再针对性调整。3.2 文本清洗的常见操作与取舍基础清洗一般包括这几类操作。去除HTML标签和特殊符号把网页文本还原成纯文本。去除重复的模板内容比如每个页面都有的页脚、版权声明。过滤过短或过长的文本太短的没有信息量太长的可能是拼接错误。处理乱码和编码问题统一转成UTF-8。去除个人隐私信息比如电话号码、身份证号这类内容。这些操作听起来简单但每一条都有坑。比如过滤长度阈值定多少我试过用50个字符作为下限结果把很多有价值的短句、代码片段也删了。后来改成按语言和数据类型分别设阈值中文短文本下限放到20字代码片段单独处理。再比如去重简单的完全匹配去重只能去掉一模一样的文本但网页里大量存在改了几个词的近似重复这就需要更复杂的相似度算法。3.3 去重从精确匹配到语义近似去重是大模型数据准备里技术含量最高的环节之一。重复数据会带来两个严重后果一是模型对重复内容过度学习导致输出单一、缺乏多样性二是浪费训练算力同样的内容学很多遍没有额外收益。去重一般分三个层次。第一层是精确去重用哈希值比对完全相同的文本只保留一份。这个最简单但只能解决一小部分问题。第二层是近似去重用MinHash、SimHash这类算法找出内容高度相似但并非完全相同的文本。这一层能去掉大量网页转载、轻微改写的重复内容。第三层是语义去重用向量相似度判断两段文本在语义上是否重复这一层计算成本高通常只在高价值数据集上使用。实际工程里近似去重是性价比最高的。我通常会用MinHash加局部敏感哈希的方式对文档做指纹然后按相似度阈值聚类每个簇只保留质量最高的一份。阈值设多少很关键设太高去重不彻底设太低会误删不同但相似的内容。经验值是在0.8到0.9之间具体要看数据特点。去重层次方法计算成本适用场景精确去重哈希比对低所有数据的第一道过滤近似去重MinHash/SimHash中网页数据的主力去重手段语义去重向量相似度高高价值数据集精筛3.4 质量过滤怎么判断一段文本值不值得学质量过滤是清洗阶段最主观也最考验经验的部分。什么叫高质量文本没有绝对标准但有一些可操作的信号。语言流畅度用小型语言模型给文本打分困惑度低的通常更通顺。信息密度看实词比例、句子平均长度、是否包含具体事实。结构完整性看是否有完整的句子和段落而不是碎片。来源可信度来自权威来源的文本通常质量更高。我常用的做法是训练一个轻量级的质量分类器用人工标注的一小批高质量和低质量样本让它给全量数据打分然后按分数过滤。这个方法比纯规则灵活但需要标注数据。如果没有标注条件退而求其次可以用规则加统计特征比如过滤掉符号占比超过30%的文本、过滤掉重复词过多的文本、过滤掉句子长度方差过大的文本。注意质量过滤不要一刀切。有些看起来不流畅的文本其实是特定领域的正常表达比如代码、数学公式、方言。过滤规则要按数据类型分开设计否则会误伤。4. 数据配比不同来源怎么混才合理4.1 配比失衡会带来什么后果数据配比是很多人容易忽略、但影响极大的环节。假设你的数据里90%是新闻10%是代码训练出来的模型写新闻很溜但一碰到编程问题就胡言乱语。反过来如果代码占比过高模型可能会在日常对话里莫名其妙地输出代码片段。配比失衡的典型症状包括模型在某个领域表现异常好、其他领域异常差生成内容风格单一对某些话题过度敏感或过度回避。这些问题在训练后期很难纠正必须在数据阶段就处理好。4.2 常见的数据配比策略配比没有万能公式但有一些被广泛验证的经验。通用网页数据通常占大头50%到70%保证语言基础和知识广度。书籍和学术文本占10%到20%提供深度和长文本能力。代码占5%到15%看目标模型是否强调编程能力。专业领域文本占5%到15%按目标场景调整。多语言数据按目标用户分布配置。这里有个反直觉的点高质量数据的占比不一定要很高但一定要存在。哪怕只占1%到2%的极高质量数据也能显著提升模型在对应能力上的表现。这就像做菜放盐量不大但缺了不行。4.3 配比调整的实操方法配比不是拍脑袋定的而是通过小规模实验调出来的。我的做法是先定一个初始配比用较小规模训练一个模型在多个评测集上看表现然后针对性调整。比如发现代码能力弱就提高代码比例发现长文本理解差就增加书籍和论文。每次只调一个维度观察变化避免多变量同时动导致无法归因。还有一个技巧是动态配比。训练前期多用通用数据打基础后期逐步提高高质量数据和指令数据的比例。这样模型先学会语言再学会特定能力效果通常比固定配比好。5. 分词与序列化把文本变成模型能吃的数字5.1 分词器为什么不是随便选一个就行模型不认识文字只认识数字。分词器的作用就是把文本切分成一个个token再映射成数字ID。分词器的选择直接影响模型的效率、词表大小、以及对不同语言的支持。常见的分词算法有BPE、WordPiece、SentencePiece等。BPE从字符开始不断合并高频字符对适合处理多语言和未登录词。WordPiece类似但合并策略不同在BERT系列里用得多。SentencePiece直接把文本当字节流处理对中文、日文这类没有天然空格分隔的语言特别友好。选分词器时主要看三点目标语言覆盖、词表大小、压缩率。词表太小一个词被切成很多token序列变长训练和推理都变慢词表太大嵌入层参数变多低频token学不好。中文场景下词表大小通常在5万到15万之间比较常见。5.2 序列化与打包的实际操作分词之后文本变成了一串token ID。但训练时不是一条一条喂的而是打包成固定长度的序列。这里涉及几个参数最大序列长度、打包策略、注意力掩码。最大序列长度决定了模型一次能看多长的上下文。常见的有2048、4096、8192甚至更长。长度越大显存占用越高但长文本能力越强。打包时短文本会被拼接在一起填满一个序列长文本会被截断或分段。拼接时要注意用特殊token分隔否则模型会把两段无关文本当成连续的。注意力掩码是另一个关键。打包后的序列里不同文档之间不应该互相看见所以需要掩码把跨文档的注意力屏蔽掉。这个细节如果处理错模型会学到错误的依赖关系效果明显下降。5.3 数据加载与训练效率的平衡数据准备到最后还要考虑怎么高效地喂给训练框架。常见做法是把处理好的数据存成二进制格式训练时用内存映射加载避免每次读文本再分词。数据加载器的并行度、预取数量、打乱策略都会影响训练吞吐。我踩过的一个坑是数据打包时没有充分打乱导致同一批里全是相似内容训练loss震荡严重。后来改成全局打乱加局部打乱结合问题才解决。另一个坑是序列长度分布不均大量短序列和少量长序列混在一起导致显存利用率低。解决办法是按长度分桶同桶内打包减少padding浪费。6. 数据准备阶段最容易踩的几个坑6.1 清洗过度导致信息损失清洗规则上得太猛把有价值的短文本、特殊符号、代码片段全删了。我见过一个团队为了干净把所有非中文字符都过滤掉结果模型完全不会处理英文和数字。清洗的目标是去噪声不是去多样性。每加一条规则都要评估它会不会误伤有效数据。6.2 去重不彻底导致模型复读去重没做好模型会反复输出训练数据里的高频内容。典型表现是问它一个问题它把某段网页原文背出来。近似去重一定要做而且阈值要调到位。我通常会在去重后抽样检查看还有没有明显重复。6.3 配比拍脑袋导致能力偏科配比不实验、不迭代直接照搬别人的方案。但别人的方案是针对别人的目标场景的你的场景不同配比就该不同。配比必须通过小规模训练验证不能想当然。6.4 分词器与数据不匹配分词器在一种语言上训练却用来处理另一种语言的数据导致压缩率极低、序列超长。分词器一定要用目标数据训练或者至少验证过在目标语言上的表现。6.5 忽略数据的时间与来源分布数据全来自某几个来源或某个时间段模型知识面窄、时效性差。采集时要刻意保证来源和时间的多样性并在配比时体现出来。7. 我在实际数据准备中的几点体会数据准备是整个大模型训练里最脏、最累、但回报最高的环节。模型结构可以抄训练框架可以用开源的但数据这件事没有捷径必须自己一点点磨。我的体会是把70%的精力放在数据上都不为过因为模型的上限基本由数据决定。另外数据准备不是一次性的。训练过程中发现的问题往往要回到数据阶段解决。所以数据流程要做得可迭代、可追溯每一步处理都要有记录方便定位问题。我习惯给每批数据打上来源、清洗版本、质量分数的标签出问题时能快速回溯。最后说一个容易被忽略的点小规模验证。在正式处理全量数据之前先用一小批数据跑通整个流程看看清洗、去重、分词、打包各环节是否正常再放大到全量。这样能避免处理了几TB数据之后才发现某个环节配置错了那种返工成本极高。数据准备这件事慢就是快前期多花时间验证后期少走弯路。
