1. 从数据视角切入大模型训练为什么值得深挖做模型训练的人都有一个共识架构决定上限数据决定下限。很多人拿到一个开源大模型第一反应是去看它的网络结构——注意力怎么设计的、位置编码用的什么方案、归一化放在哪里。但真正跑过预训练或者微调的人会告诉你模型结构翻来覆去就那么些花样真正拉开差距的往往是数据管线的设计。我最近在系统性地拆解一个开源大模型项目的代码重点放在它的数据处理层。这个项目在数据准备上做了相当多工程化的设计从原始语料的采集、清洗、去重到tokenize、分片、打包再到最终喂给训练框架的格式整条链路非常完整。很多做模型的朋友平时只关注训练脚本和模型定义对数据管线这一层往往是“能跑就行”的态度结果就是训练出来的模型效果不稳定排查半天也找不到原因。这篇文章主要面向几类人一是正在做预训练或继续预训练需要搭建自己数据管线的工程师二是想理解大模型数据从原始文本到训练样本完整流程的算法同学三是对数据处理工程化实践感兴趣、想看看成熟项目怎么做的开发者。我会把数据层的核心设计思路、关键代码逻辑、实操中容易踩的坑都讲清楚尽量做到看完就能对照着自己项目改。2. 数据管线的整体架构与设计哲学2.1 为什么数据层要独立成一个模块很多小团队做训练的时候数据处理代码是散落在训练脚本里的——读文件、清洗、tokenize、拼batch全揉在一起。这种写法在数据量小、迭代快的时候没问题但一旦数据规模上到TB级别问题就全暴露出来了清洗逻辑改一行要重跑整个训练、不同实验之间数据版本对不上、tokenize后的数据没法复用每次都要重新处理。这个项目把数据层完全独立出来核心思路是离线处理、在线读取。也就是说原始语料的清洗、去重、tokenize、分片全部在训练之前离线完成训练时只需要按索引读取已经处理好的二进制分片。这样做的好处非常明显训练脚本变得极简只负责读数据和跑梯度数据处理可以单独调试、单独验证处理好的数据可以跨实验复用换模型结构不用重新处理数据。从工程角度看这种设计还有一个隐性收益数据处理的每一步都可以做质量检查。比如去重前后各有多少条数据、tokenize后序列长度分布是什么样的、有多少样本被截断这些统计信息在离线阶段收集起来非常方便而如果揉在训练流程里就很难做。2.2 分层设计从原始语料到训练样本整个数据管线我把它拆成四个层次来理解每一层解决不同的问题。第一层是原始语料层。这一层的数据来源可能是网页抓取、书籍电子化、代码仓库、论文PDF等格式五花八门质量参差不齐。这一层要做的核心工作是格式统一和初步过滤把各种来源的数据转成统一的JSONL或者类似的结构化格式每条数据至少包含文本内容和一些元信息来源、时间、语言等。第二层是清洗与去重层。这是数据质量的关键环节。清洗包括去除HTML标签残留、修复编码问题、过滤低质量内容比如重复字符过多的、长度过短的、乱码比例高的。去重则分为精确去重和模糊去重精确去重通常用哈希模糊去重则用MinHash或者SimHash这类局部敏感哈希算法。第三层是Tokenize与分片层。把清洗后的文本用tokenizer转成token id序列然后按照固定长度比如2048或4096切分成样本。这里有个关键决策是每条文档独立tokenize后padding还是把多条文档拼接到一起凑满固定长度前者浪费大量padding计算后者则是主流做法。拼接的时候要注意在文档之间插入EOS token作为分隔。第四层是训练读取层。把分片好的数据存成二进制格式比如numpy的memmap或者自定义的bin文件训练时通过索引随机读取。这一层要考虑的是读取效率、shuffle策略、多worker并发读取等问题。2.3 设计取舍离线处理的代价与收益离线处理不是没有代价的。最大的问题是存储放大。原始文本假设是100GBtokenize成int32之后如果平均每个token占4字节而压缩比大概是1个token对应0.75个英文单词或者1.5个中文字符那么tokenize后的数据量可能膨胀到原始文本的2到3倍。再加上如果做了多份不同切分长度的数据存储开销会更大。另一个代价是灵活性降低。离线处理完之后如果想改tokenizer或者改序列长度就得重新跑一遍整个管线。所以这个项目在设计时做了一个折中tokenize和分片是分开的两步tokenize后的token id序列单独存一份分片时再根据需要的序列长度从token序列里切。这样改序列长度只需要重跑分片不用重新tokenize。实操心得如果你的数据量在百GB级别以下其实可以不做离线tokenize训练时在线tokenize也能接受。但一旦上到TB级别离线处理带来的训练加速是非常可观的通常能让训练吞吐提升30%以上因为tokenize本身是CPU密集型的放在训练循环里会拖慢GPU利用率。3. 数据清洗的核心细节与实操要点3.1 文本规范化看似简单实则坑最多文本规范化是清洗的第一步目标是把各种来源的文本转成统一的表示。听起来简单但实际操作中坑非常多。最常见的问题是编码不一致。有的数据是UTF-8有的是GBK有的甚至是Latin-1混进来的。处理的时候要先做编码检测检测不准的要么丢弃要么用启发式方法修复。我见过一个案例某批数据里混了大概2%的GBK编码文本训练出来的模型在特定中文场景下会输出乱码排查了很久才发现是数据源头的问题。第二个问题是Unicode规范化。同一个字符可能有多种Unicode表示方式比如带音标的字符既可以用单个码点表示也可以用基础字符加组合音标表示。如果不做规范化tokenizer会把它们当成不同的token导致词表浪费。通常的做法是用NFKC规范化它会把兼容字符转成标准形式。第三个问题是空白字符处理。全角空格、不间断空格、零宽空格这些在网页抓取的数据里非常常见。处理策略通常是把各种空白字符统一转成普通空格连续多个空格合并成一个行首行尾空格去掉。但要注意代码数据里的缩进是有意义的不能无脑合并空格所以不同来源的数据要用不同的清洗策略。import unicodedata import re def normalize_text(text, source_typeweb): # Unicode规范化 text unicodedata.normalize(NFKC, text) # 统一空白字符 text re.sub(r[\u00a0\u2000-\u200a\u202f\u205f\u3000], , text) if source_type web: # 网页文本可以激进地合并空格 text re.sub(r , , text) text re.sub(r\n{3,}, \n\n, text) elif source_type code: # 代码只处理行尾空格和连续空行 text re.sub(r[ \t]\n, \n, text) text re.sub(r\n{4,}, \n\n\n, text) return text.strip()3.2 质量过滤如何判断一段文本“值不值得学”质量过滤的目标是去掉那些对训练没有帮助甚至有害的样本。这个项目用的是一套组合规则我把它整理成几个维度。长度维度太短的样本比如少于50个字符通常信息量不足太长的样本比如超过10万字符可能是拼接了整本书需要单独处理。通常的做法是设一个长度区间区间外的要么丢弃要么截断。重复度维度统计文本中重复n-gram的比例。如果一段文本里“哈哈哈哈哈哈”占了80%或者某个短语重复了几十遍这种样本对训练是有害的。计算方法是取所有3-gram看重复的3-gram占比。符号比例维度统计非字母数字字符的比例。正常的自然语言文本标点和符号比例一般在10%到30%之间。如果超过50%很可能是代码、表格或者乱码需要根据数据来源决定是否保留。语言置信度维度用语言检测工具判断文本的主要语言置信度低的样本丢弃。这个在混合多语言数据时特别重要避免某种语言的数据里混入大量其他语言的噪声。过滤维度典型阈值处理策略注意事项字符长度50-100000区间外丢弃或截断代码数据下限可放宽到203-gram重复率0.3丢弃计算重复3-gram占比诗歌等特殊文体需单独处理符号比例0.5丢弃非字母数字字符占比数学公式数据需放宽语言置信度0.7丢弃语言检测工具打分短文本检测不准需特殊处理平均词长15或2丢弃总字符数除以词数中文需先分词再统计3.3 去重策略精确去重与模糊去重的组合拳去重是数据清洗里最影响模型效果的一环。重复数据会导致模型对某些内容过拟合生成时反复输出相似内容严重时甚至会导致训练不稳定。精确去重相对简单对每条文本算一个哈希比如SHA256哈希相同的只保留一条。但精确去重只能去掉完全一样的文本对于稍微改了几个字的近似重复无能为力。模糊去重才是重头戏。这个项目用的是MinHash加LSH的方案。具体做法是对每条文本抽取一组n-gram通常是5-gram或者词级别的shingle然后用多个哈希函数对每个n-gram算哈希值取每个哈希函数的最小值组成MinHash签名。两条文本的MinHash签名中相同位置的元素比例就是它们Jaccard相似度的无偏估计。LSH的作用是加速查找。把MinHash签名分成多个band每个band单独哈希只有至少一个band哈希相同的候选对才进入精确相似度计算。这样可以把O(n²)的比对降到接近O(n)。from datasketch import MinHash, MinHashLSH def dedup_documents(docs, threshold0.8, num_perm128): lsh MinHashLSH(thresholdthreshold, num_permnum_perm) minhashes {} for idx, doc in enumerate(docs): m MinHash(num_permnum_perm) # 用5-gram作为shingle for i in range(len(doc) - 4): m.update(doc[i:i5].encode(utf-8)) minhashes[idx] m lsh.insert(idx, m) # 找出重复的文档 duplicates set() for idx in range(len(docs)): if idx in duplicates: continue candidates lsh.query(minhashes[idx]) for cand in candidates: if cand ! idx and cand not in duplicates: duplicates.add(cand) return [doc for idx, doc in enumerate(docs) if idx not in duplicates]注意事项MinHash的threshold设置很关键。设太高比如0.9会漏掉很多近似重复设太低比如0.5会误删很多正常样本。根据我的经验自然语言文本用0.8左右比较合适代码数据可以用0.85到0.9因为代码的结构化程度高稍微改一点就算不同样本了。4. Tokenize与分片的工程实现4.1 Tokenizer选型与特殊token处理Tokenizer的选择直接影响模型的词表大小和序列长度分布。这个项目用的是BPEByte Pair Encoding的变体词表大小在5万到10万之间。选BPE而不是WordPiece或者Unigram主要考虑是BPE对未登录词的处理更稳健而且训练速度相对快。特殊token的处理有几个细节值得说。首先是BOS和EOS每条文档开头加BOS、结尾加EOS这样模型能学到文档的边界。其次是PAD token虽然训练时通过拼接避免了padding但某些场景比如推理时的batch还是需要PAD。最后是mask token如果后续要做MLM任务需要预留。还有一个容易被忽略的点是tokenizer的确定性。同一个文本多次tokenize的结果必须完全一致。这听起来是废话但如果tokenizer实现里有随机性比如BPE合并时的随机选择就会导致数据不可复现。所以训练tokenizer时要固定随机种子推理时也要确保没有随机操作。4.2 序列拼接如何优雅地把短文档凑成长序列前面提到主流做法是把多条文档拼接到一起凑满固定长度。这个操作看起来简单但有几个细节需要处理。第一个细节是文档边界标记。拼接的时候要在文档之间插入EOS token这样模型能区分不同文档。有些实现还会在文档开头插入BOS但这样会浪费token通常只在第一条文档前加BOS。第二个细节是截断策略。如果一条文档特别长超过了目标序列长度是直接截断还是分成多条直接截断会丢失信息分成多条则会产生很多短样本。这个项目的做法是超过目标长度的文档按目标长度切分切分后的片段各自作为独立样本但只在最后一段加EOS。第三个细节是拼接的填充策略。如果所有文档都拼完了最后一个样本还差一些长度才满是用PAD填充还是丢弃通常的做法是丢弃因为PAD会浪费计算。但如果数据量本身就不大也可以保留并用attention mask标记出来。def pack_sequences(tokenized_docs, max_length4096, eos_token_id2): packed [] current [] for doc_tokens in tokenized_docs: # 文档太长切分处理 if len(doc_tokens) max_length: # 先处理当前缓冲区 if current: packed.append(current) current [] # 切分长文档 for i in range(0, len(doc_tokens), max_length): chunk doc_tokens[i:imax_length] if len(chunk) max_length: packed.append(chunk) else: current chunk continue # 尝试拼接到当前缓冲区 if len(current) len(doc_tokens) 1 max_length: current.extend(doc_tokens) current.append(eos_token_id) else: # 当前缓冲区满了保存并开始新的 if current: packed.append(current) current doc_tokens [eos_token_id] if current: packed.append(current) return packed4.3 二进制分片存储格式选择与读写优化Tokenize和拼接完成后需要把数据存成训练时能高效读取的格式。这个项目用的是自定义的二进制格式每条样本存成固定长度的int32数组所有样本拼成一个大文件另外用一个索引文件记录每条样本的偏移量。为什么不用现成的格式比如HDF5或者Parquet主要是读取速度的考虑。训练时数据读取是瓶颈之一自定义二进制格式可以用memmap直接映射到内存读取时几乎没有解析开销。HDF5虽然也支持随机读取但每次读取都有一定的解析开销在需要每秒读取上千条样本的场景下会成为瓶颈。分片的大小也有讲究。分片太小比如每个文件几MB文件数量太多文件系统元数据操作会成为瓶颈分片太大比如每个文件几十GBshuffle时不够灵活而且一旦某个分片损坏影响范围大。通常的做法是每个分片控制在几百MB到2GB之间整个数据集分成几百到几千个分片。存储格式读取速度随机访问压缩支持适用场景自定义bin极快支持需自己实现大规模预训练HDF5中等支持内置中小规模实验Parquet中等支持内置结构化数据TFRecord快支持内置TensorFlow生态JSONL慢不支持无小规模调试实操心得分片文件命名建议用固定位数比如shard_00001.bin、shard_00002.bin这样排序时不会出现shard_10排在shard_2前面的问题。另外索引文件建议单独存一份不要和分片混在一起方便单独校验数据完整性。5. 数据加载与训练集成中的常见问题5.1 数据加载的并发与预取训练时数据加载通常用多进程或者多线程来做主进程负责计算子进程负责读数据。这里有几个参数需要调优。worker数量太少会导致数据供给跟不上GPU计算太多会浪费CPU资源甚至导致内存溢出。经验值是每个GPU配4到8个worker具体要看数据读取的复杂度和CPU核心数。预取数量每个worker预取多少个batch的数据。预取太少会导致worker等待预取太多会占用大量内存。通常设2到4比较合适。shuffle策略有两种做法一种是全局shuffle把所有样本的索引打乱后按顺序读另一种是分片shuffle先打乱分片顺序再在分片内打乱。全局shuffle更彻底但需要维护一个大的索引数组分片shuffle内存开销小但随机性稍差。这个项目用的是分片shuffle加缓冲区shuffle的混合策略。5.2 数据版本管理与实验复现做过多次训练实验的人都知道数据版本管理是个大问题。同一个模型结构用不同版本的数据训练效果可能差很多。如果没有记录清楚每次实验用的哪个版本的数据复现就成了玄学。这个项目的做法是给每次数据处理生成一个数据指纹包含原始数据的哈希、清洗规则的版本号、tokenizer的哈希、分片参数的配置。训练时把这个指纹记录到日志里这样任何一次实验都能追溯到确切的数据版本。具体实现上可以在数据处理完成后生成一个manifest文件记录所有分片的哈希值和样本数量。训练前校验manifest确保数据没有损坏或被意外修改。5.3 常见问题速查表问题现象可能原因排查方法解决方案训练loss突然飙升数据中混入异常样本检查最近读取的分片增加质量过滤规则模型输出重复内容去重不彻底统计训练数据重复率加强模糊去重数据加载成为瓶颈worker数不足或IO慢监控GPU利用率和IO等待增加worker、用SSD不同实验无法复现数据版本不一致对比manifest文件固定数据版本某些语言效果差该语言数据被过度过滤分语言统计过滤率调整该语言的过滤阈值内存溢出预取太多或分片太大监控内存使用减少预取、减小分片避坑技巧数据处理管线一定要做单元测试。比如去重函数拿几条已知重复和不重复的样本测一下确保逻辑正确。清洗规则也是拿几条边界样本超长、超短、特殊字符测一下。这些测试看起来麻烦但能避免后面训练出问题后大海捞针式地排查。6. 数据质量评估与迭代优化6.1 如何量化评估数据质量数据质量不能只靠感觉需要有一些量化指标。这个项目在数据处理完成后会生成一份质量报告包含以下指标。基础统计总样本数、总token数、平均序列长度、长度分布直方图。这些指标能快速看出数据的基本形态。质量指标去重前后的样本数对比、各过滤规则的触发比例、语言分布、来源分布。这些指标能反映清洗的效果。多样性指标不同n-gram的覆盖率、词表使用率tokenizer词表中有多少token在数据中出现过。多样性太低说明数据同质化严重模型学到的知识面会窄。污染检测如果后续要用这个数据做评测需要检测训练数据里是否混入了评测集的内容。通常用n-gram重叠度来检测重叠度高的样本要剔除。6.2 数据配比不同来源数据的混合策略预训练数据通常来自多个来源网页、书籍、代码、论文等。不同来源的数据配比直接影响模型的能力偏向。代码数据多了模型的逻辑推理能力会强一些但自然语言生成可能变差网页数据多了模型的知识面广但质量参差不齐。配比没有标准答案要根据模型的目标用途来定。但有几个原则可以参考高质量来源书籍、论文的比例可以适当提高低质量来源网页要做更严格的过滤代码数据通常占10%到20%比较合适如果要做多语言模型英文和中文的比例要根据目标场景调整。这个项目在配比上的做法是分阶段训练前期用配比均衡的数据做基础训练后期用高质量数据做退火训练。这样模型既能学到广泛的知识又能在最后阶段被高质量数据“拉”到更好的分布上。6.3 数据迭代的闭环数据管线不是一次做完就完了需要根据模型训练的效果持续迭代。闭环大概是这样的训练模型、评测效果、分析bad case、定位数据问题、调整数据处理规则、重新处理数据、再训练。这个闭环里最关键的是从bad case反推数据问题。比如模型在某个领域的知识总是出错可能是该领域的数据太少或者质量太差模型生成的内容风格不对可能是训练数据里该风格的比例不对。有了这些线索再去调整数据配比和清洗规则就能有针对性地改进。我在实际操作中的体会是数据迭代的收益往往比模型结构调优更大。同样的模型结构数据管线优化一轮效果提升可能相当于模型参数翻倍。所以如果你的训练效果不理想先别急着改模型花时间看看数据往往能找到更大的提升空间。最后分享一个小技巧数据处理管线里加一个采样检查的功能每次处理完随机抽几百条样本出来人工看看。机器指标再好看也不如人眼扫一遍来得直接。我就在采样检查时发现过好几次过滤规则误杀正常样本的情况这些是看统计指标发现不了的。