前阵子有个准备训练 1.4B 小模型的朋友问我预训练数据集是不是直接把 RedPajama 拉下来开练最省事我第一反应是摇头。他这个问题背后其实藏着整个大模型训练流程里最容易被低估的一环——预训练数据集构建。很多人把精力放在模型结构、并行策略和调参上结果数据准备得糙模型训出来一堆怪毛病回头还得从数据侧返工。这个系列走到第十六篇我觉得是时候把数据这关单独拎出来聊透了。本文不会只给你一堆数据集下载链接而是从数据规模估算、清洗流水线、配比策略、去污染到多模态和代码数据的处理差异按一条真实可落地的路径走一遍。适合准备从零跑预训练、或者已经在训但觉得数据侧不对劲的团队参考。1. 先别急着下载训练目标决定数据规模与结构1.1 三种主流数据源与公开资源预训练数据来源大致分三类第一类是网页抓取数据代表是 Common Crawl 以及基于它清洗出的 C4、RefinedWeb第二类是经过筛选的混合语料比如 The Pile、RedPajama里面混了维基、书籍、学术论文、代码问答等第三类是为特定领域自建的垂类数据比如自己抓的行业文档、教材、专利、客服日志。公开数据集不是不能直接用但你得清楚它已经被处理到什么程度——有些包是“原味”网页有些已经做了语言过滤和去重用之前至少要读一遍它的 data card搞清楚清洗规则和残留风险。我的建议是不要只依赖某一个公开大包。RedPajama 和 RefinedWeb 这类数据能帮你快速起步但一个正经的训练项目手里最好握一条“从原始语料到最终 bin 文件”的完整链路。因为你后面会发现模型表现不对劲时几乎每次都要回数据侧查某个领域的文本是不是被去重去过头了某类噪声文本是不是在质量过滤时漏进来了如果数据全是人家洗好的黑盒你连排查的入口都没有。1.2 用 Chinchilla 法则粗算数据量“到底要准备多少 token”是每次开项目必被问的问题。经典参考是 Chinchilla 法则在固定算力下模型参数量和训练数据量的最优比例大约是 1:20也就是 1B 参数配 20B token。但社区现在的实际做法早就偏向“过度训练”了。比如 LLaMA 系列用 7B 参数训了 1T token差不多是 Chinchilla 建议值的 7 倍。原因是数据质量够好时多喂数据对模型能力的提升往往比单纯加参数更划算。你可以按下面的表粗估一个起点模型规模Chinchilla 参考数据量社区常见的数据量区间1B20B token100B - 500B token7B140B token500B - 1T token13B260B token1T - 2T token70B1.4T token5T token 或更多这个表只是给你一个“别离谱”的范围。真正定多少要看算力预算假设你集群的有效训练吞吐是 2000 token/s/卡1000 张卡计划跑 60 天利用率打八折那实际能消耗的 token 数大约是 2000 × 1000 × 86400 × 60 × 0.8约等于 8.3T。这种情况数据量低于 8T 都是白瞎算力高于这个数则训练不完。所以正确的顺序是先明确算力和训练天数反推 token 预算再定数据规模。而不是先下了一堆数据再纠结训不训得完。1.3 数据形态与质量分层预训练数据不是一个均匀大池子内部质量层级差异很大。我会把语料大致分四层第一层是书籍、维基、教材这类高密度知识文本量少但性价比极高第二层是学术论文、代码、技术文档逻辑性强能显著提升模型的推理和工具使用能力第三层是普通网页量大但噪声多占最终语料的大头第四层是论坛、评论、社交媒体口语化严重一般不直接大量进入预训练。清洗流水线本质上就是做两件事把上层高质量数据尽量保住把下层低质量数据尽量筛掉或降权。还有一个容易被忽视的比例关系最终你想要的 token 组成和原始抓取数据的组成差异巨大。比如最终语料里网页可能占 60%-70%但原始抓取数据里网页通常占 90% 以上。也就是说清洗过滤不是毛毛雨而是会砍掉一大半。做磁盘和带宽预算时得按最终 token 量的 5-10 倍来准备原始数据空间否则跑一半硬盘满了整个流程卡住非常难受。2. 从 HTML 到干净语料清洗流水线的四道工序2.1 URL 过滤与正文抽取第一步永远是 URL 过滤。Common Crawl 这类数据自带 URL 列表你需要准备一份黑名单域名表把色情、赌博、内容农场、垃圾站、追踪器域名全部挡在门外。这里不要只靠现成 blocklist还要定期从自己的抓取日志里挖掘新出现的低质量域名。URL 过滤很便宜越早做越省后续算力。正文抽取是文本清洗里最脏的活之一。网页原始 HTML 里有导航、广告、评论、脚本真正要的正文可能只占一小半。业界常用 trafilatura 或 boilerpy 这类工具做 boilerplate removal。我自己的经验是trafilatura 的默认参数对长文效果不错但对论坛页和列表页经常抽出一堆碎片需要额外加启发式规则——比如“正文长度少于 200 字符的页面丢弃”“文本里连续换行过多的段落丢弃”。抽取完一定要做人工抽检每万篇抽 100 篇逐篇看正文是否完整、有没有混入广告或导航文字。这个抽检工作看着土但比任何算法指标都更能及时发现问题。2.2 语言识别与质量过滤在中文和英文混杂的语料里语言识别是必做项。fastText 的语言识别模型是常用选择跑得飞快准确率也够。实际操作时我会把置信度阈值设在 0.5 到 0.7 之间低于阈值的文本直接丢弃或打回重抽。同时每处理完一批就输出一份语言分布报告比如中文占多少、英文占多少、其他语言占多少方便你对比目标配比。质量过滤是决定语料“文气”的关键。最朴素也最有效的指标是困惑度perplexity。你可以先拿一批你认为质量高的人工精选语料比如书籍、维基训练一个小 n-gram 模型或直接用一个小规模 LM 计算 ppl然后对全体语料算 ppl把过高和过低的都拉出来人工检查。经验上ppl 过低的文本往往是大段重复或乱码ppl 过高的则是机器翻译腔、乱序文本、多语言混杂。实际操作里会组合多种规则比如“平均句长过短丢弃”“感叹号比例过高丢弃”“重复 n-gram 比例过高丢弃”。这类阈值没有通用标准需要按自己的语料分布来标定但下面这套起步值可以参考过滤规则常用阈值说明文档长度少于 200 字符丢弃太短没有训练价值语言置信度低于 0.5-0.7 丢弃防止多语言混杂噪声困惑度按人工语料分位数过滤仅过滤尾部异常值别一刀切重复率文档内重复 5-gram 比例 0.3 丢弃清除乱码和凑字数文本符号比例非字母数字字符比例 0.4 丢弃过滤大量符号堆砌2.3 精确去重与 MinHash 语义去重去重是预训练数据构建里收益最直观的一步。先做精确去重对文档内容做 sha1 或 md5同一份内容只保留一条。这个简单操作能去掉多少数据呢在很多真实抓取语料里5%-15% 是纯重复的。URL 也要做归一化去重把 utm 参数、锚点、http/https 差异抹掉后再比较避免同一篇文章换三个 URL 三番五次进语料。真正考验功力的是近似去重。网页里大量“看起来不一样、内容基本一样”的文本镜像站、转载文章改了个标题、新闻通稿不同媒体换了几句话。这类数据用精确去重完全无能为力得靠 MinHash LSH。原理说人话就是把一篇文档切成很多 5-token 的小片shingle对所有小片做哈希取其中最小的若干哈希值作为这篇文档的“指纹”然后把这些指纹分到若干 band 里。两篇文档只要有一个 band 的指纹完全一致就认为它们可能相似放进同一个桶里比较。实际操作我用过 128 个哈希函数、分成 8 个 band 每组 16 个哈希值的配置对 100 亿文档规模可以接受。相似度阈值可以调到 0.5-0.8 之间低于阈值过于敏感会把正常的相似文本误杀。2.4 隐私脱敏与格式统一这一步经常被只跑学术实验的团队忽略但一旦你的模型要对外提供服务隐私问题迟早找上门。对文本里的邮箱、电话号码、个人账号、支付卡号这类模式化 PII用正则匹配后替换成占位符比如[EMAIL]、[PHONE]。同时保留一份“脱敏位置映射表”用于审计和追溯。这里多说一句脱敏不是删除因为语料仍需要保留正常的语言结构直接把整段删掉会破坏上下文连贯性。格式统一是收尾动作。把全角半角、Unicode 变体、不可见控制字符统一统一换行符为\n确保句子级别的标点不会被错误截断。然后按训练框架的要求拼 sequence多个短文档拼成一个训练样本时中间要插入文档分隔符比如\n\n|doc_end|\n\n否则模型会学到跨文档的“幻觉衔接”表现为生成内容里频繁出现无意义拼接。这个细节我见过很多团队踩坑——数据单独看每篇都干净但拼起来之后训练 loss 一直掉不下去查半天才发现是序列拼接时把两篇不同领域的文章首尾硬接在一起了。3. token 预算是怎么分配的语言、领域与混比策略3.1 语言分布英语主导之外怎么补中文如果你训练的是中文为主、中英双语的模型语言配比得刻意设计。绝大多数开源大包是英文主导直接拿来训中文模型会出现两个问题一是中文 token 太少模型中文能力弱二是 BPE 词表被英文字符占满中文字符编码效率极低。所以需要额外补充高质量中文语料——中文维基、中文书籍、新闻通稿、政府白皮书不含政策评论、高质量社区内容。注意别图省事直接抓一堆论坛帖子口语噪声会拉低整体质量。从我跑过的项目经验看服务中文场景的模型中文语料占比至少要拉到 30%-50%而不是按人口比例随便给个 20%。但也不能全中文训练保留 10%-20% 英文语料能显著提升模型的指令理解、代码能力和跨语言迁移能力。语言配比不是一次定死需要分阶段看训练早期多给通用英文和代码数据打底训练中后期再提高中文和垂类领域数据比例。3.2 领域混比代码、数学、教材的占比经验领域混比直接决定模型的“技能树”。一个很常见的起步配比可以这样给网页通用数据 45%-50%书籍和学术论文 15%代码 12%-15%数学和推理类 5%多语言数据 10%对话和指令类 5%剩余给其他垂类。这个配比不是最优解但它是安全的——不会有哪个领域被完全饿死也不会让某个领域喧宾夺主。代码数据值得单独强调。代码能提升模型对逻辑结构、函数调用、格式规范的理解很多先进模型在代码上花的 token 比例都不低。但代码比例过高也不是好事模型会变得“硬邦邦”自然语言流畅度下降对话时喜欢输出结构化列表。数学数据同理适量能增强推理过量会让通用知识被挤占。每个领域到底多少最终取决于你的下游任务分布不要盲抄别人的配比表。3.3 课程学习与重复次数的上限数据顺序对训练影响很大。“课程学习”的思路是简单直观先给模型喂高质量、结构化的数据书籍、维基、代码再逐步引入噪声更大的网页数据。但我实操下来的体感是严格的课程排序对最终效果提升有限而随机 shuffle 反而更重要。因为一旦同领域文档连续出现模型会在局部数据上过拟合训练 loss 出现周期性波动。所以即便你要做课程式排序也要在领域内部做充分 shuffle让同领域文档间隔足够远。另一个容易被忽略的参数是“重复次数上限”。一份文档在整个训练过程中最多被看见几次我一般控制在 2-4 次。超过这个次数模型会开始记忆而非泛化具体表现是评测集里出现“背题式回答”。实现上可以给每个文档加一个计数器采样时按剩余次数加权已经达到上限的文档不再参与采样。这个机制也能顺带控制高权重领域不要被无限次重复。3.4 对话数据怎么进预训练“多轮对话能力训练”虽然通常放在微调阶段但预训练也可以混入对话数据。做法是把多轮对话按角色标记封装成普通文本比如用|user|、|assistant|作为特殊 token然后作为普通样本参与预训练。这样模型在预训练阶段就接触了对话结构后续做指令微调时起点更高不容易出现“一加入对话数据就灾难性遗忘”的问题。注意控制比例。对话数据在预训练早期占比太高模型容易退化成“只会接话、不会长篇输出”。常见做法是预训练前 90% 阶段几乎不放对话数据最后 10% 逐步混入 2%-5%让模型在临近结束时把对话格式内化。还有一个细节单轮问答不算多轮对话生成式预训练需要的是连续多轮、且上下文有信息增量的对话否则模型学到的只是形式而不是能力。4. 评估集里混进了训练语料去污染与测试集隔离4.1 泄漏的典型表现数据污染是我每次接手新数据集第一反应要查的问题。什么叫污染就是测试题或评测基准里的文本原封不动或者稍微变了下措辞出现在了预训练语料里。它的危害是让你模型在评测集上的分数虚高但真实能力并没有那么好。典型表现是模型在公开基准上 score 很高但换一组同样难度、网上搜不到的题目就现原形。污染从哪里来主要路径是网页抓取。很多评测基准会公开题目、答案、解析比如各种 benchmark 的 GitHub 仓库、论文附录、讲解博客。你爬网页的时候很容易把这些内容整个吞进去尤其一些讲解题目思路的文章几乎就是标准答案的变体。对抗这个问题没有一劳永逸的办法只有持续地做去重和隔离。4.2 n-gram 重叠检测怎么做去污染的核心操作是 n-gram 重叠检测。思路很简单把评测集文本切成 n-gram建倒排索引然后扫训练语料看有多少训练样本和评测集共享超过一定数量的 n-gram。一个可以跑的参考逻辑from collections import defaultdict from itertools import tee def ngrams(tokens, n8): iters tee(tokens, n) for i, it in enumerate(iters): for _ in range(i): next(it, None) return zip(*iters) def build_benchmark_index(benchmark_docs, n8): index defaultdict(list) for doc_id, doc in enumerate(benchmark_docs): for ng in ngrams(doc, n): index[ng].append(doc_id) return index def check_train_doc(train_tokens, index, n8, hit_threshold5): hits defaultdict(int) for ng in ngrams(train_tokens, n): for doc_id in index.get(ng, []): hits[doc_id] 1 return [doc_id for doc_id, cnt in hits.items() if cnt hit_threshold]这里的 n 通常取 8-13 个 tokenhit_threshold 取 5-10。n 太小会把正常的公共表达也误判为重叠n 太大只能抓住整段背诵抓不到“改了几个词”的变体。在大规模场景下先对全量语料做 MinHash 或者 SimHash 粗筛只对最相似的那几千篇做精确 n-gram 比对能省掉大量计算。4.3 公开基准隔离清单隔离的做法是把所有可能被你拿去评测的公开数据集整理成一份“隔离清单”包括它们原始下载包的 md5 列表每天清洗流水线跑完后自动检测训练语料与清单内容的重叠命中的文档直接剔除。下面这种表应该常驻你的数据工程文档里基准类别典型数据集处理建议自然语言理解GLUE、SuperGLUE、MMLU文本全部进隔离清单代码生成HumanEval、MBPP注意题目解法一起隔离视觉检测DOTA、HRSC2016图片不需要但配套的说明文本和论文要隔离点云分割SemanticKITTI类别描述和评测脚本不要进语料故障诊断PHM2012数据说明文档和实验结果表要隔离还需要注意的是隔离不是只做一次。评测集是不断更新的新 benchmark 出来之后旧语料里可能早就混进去了。所以这个检测流程要固定成周期性任务而不是项目启动时跑一次就完事。5. 图文、代码、点云三类特殊数据的处理差异5.1 图文对alt 文本不等于标注CLIP 分数兜底多模态预训练的数据清洗和纯文本完全不是一套逻辑。拿网络图片-文本对来说最常犯的错是把图片的 alt 属性直接当作文本标注。实际上很多网页的 alt 是一句话甚至空白跟图片内容关联性很弱。业界通用的做法是先对图片做 OCR把识别出的文字和文本标注做交集验证图文是否真的对得上再算 CLIP 分数用 CLIP 模型给图片和文本的匹配度打分分数低于阈值的样本丢弃。LAION 这类公开数据集的常见阈值在 0.26-0.32 之间具体按你自己的场景调。另外低俗内容过滤和水印检测在多模态数据里是硬性要求。网页图片里低质量、低俗、带有水印的图片比例远高于纯文本里的噪声需要专门的图像分类器把关。水印检测也很重要否则模型会学到在一些不该出现的地方生成水印文字。最后图文交错文档要定义好图片 token 的占位格式训练时按“文本块-图片块-文本块”切分而不是把图片和文本一股脑全塞进一个序列。5.2 点云、遥感与传感器数据先解决格式对齐很多人一说到预训练就觉得只能是自然语言其实像 SemanticKITTI点云语义分割、DOTA遥感旋转目标检测、PHM2012轴承故障诊断这类数据的“预训练”玩法已经不少了。它们和文本数据的处理差异首先在格式统一点云数据的坐标系、采样密度、类别定义不同数据集的标注标准不一样进预训练前要统一转成同一种格式并建立类别映射表。比如 SemanticKITTI 和 nuScenes 对“汽车”这类物体的标注 id 可能不同你在数据层不统一模型学到的就是混乱的语义。时间序列数据比如 PHM2012 的振动信号做预训练时通常不直接喂原始数值而是做窗口切片、归一化、再离散化成 token。这里有个通用坑数值离散化的桶数量要设置合理桶太少会丢失精度桶太多会导致 token 种类爆炸、模型学不过来。我的建议是根据数据分布做分位数分桶而不是均等分桶这样能保留更多信息密度高的区间。这类传感器数据的预训练目标通常也不是下一个 token而是对比学习类的自监督目标数据处理时要预留出“正样本对”的构造逻辑。5.3 代码数据许可证、PII 与仓库级去重代码数据比自然语言多两道工序许可证过滤和仓库级去重。直接用 GitHub 全量数据风险很大许可证问题必须处理。实操上先按扩展名做白名单过滤.py、.js、.java、.go、.cpp、.rs等再过滤掉明显不允许使用的许可证类型拿不准的仓库直接不进语料。同时代码里经常混着邮箱、token、密钥这类 PII需要专门的正则和规则做脱敏别把真实的密钥送进模型肚子里。代码去重的粒度要提升到仓库级。GitHub 上同一个项目有大量 fork、clone、模板复制文件级别去重根本清不干净。正确做法是先把仓库归一化——把变量名、字符串常量做 token 替换再对整个仓库做 MinHash 指纹相似的仓库只保留一个。shingle 的选择也要注意代码和自然语言不一样按行切 shingle 对缩进、空行特别敏感我习惯按 token 切并把注释先剥离再去判断相似度。还有一个容易被忽略的点跨文件的上下文对代码模型很重要训练样本切片时最好按函数或文件为单位切同时保留文件路径信息让模型知道这段代码属于什么模块。6. 数据质量怎么验证探针训练与版本管理6.1 探针训练小模型跑几天能看出很多问题数据到底行不行最好的验证方式就是真的拿一小批数据跑训练。我每次构建完一个数据版本都会立刻用一个 125M 到 350M 的小模型在 5B-10B token 上做探针训练。不用等大模型小模型几天就能跑完loss 曲线能告诉你非常多的信息如果曲线反复震荡下不来大概率数据里有大量噪声如果验证集 loss 和训练集 loss 差距过大说明数据内部一致性差模型在死记而非泛化。探针训练可以多做几组对比。同一模型结构分别用“旧版数据”和“新版数据”各训一版对比 loss 下降速度和最终验证 ppl。这里有个经验如果新版数据 ppl 降了但下游任务分数没变化说明你增加的只是“更容易拟合”的数据而不是“更有知识”的数据。进一步可以把人工抽样审计做成固定动作——每次数据版本发布前随机抽 3000 条样本人工打分badcase 率超过 1%这个版本就别放行。这招虽然土但比任何自动指标都可靠。6.2 统计指标重复率、tokenizer 效率与困惑度分布除了训练验证日常还要盯一组静态指标。最基础的是文档级重复率精确重复率、近似重复率都要统计近似重复率用 MinHash 批量算。很多团队只统计了精确重复结果镜像站点、转载文章带来的近似重复占了 20% 都不自知。第二组指标是 tokenizer 效率平均每个 token 对应多少字节、中英文混合时中文的编码效率。如果中文部分的字节/token 比值很高说明词表里中文字符分配严重不足模型要花很多步才能消化一段中文。困惑度分布图是我个人最爱的诊断工具。把所有语料的 ppl 画成直方图正常情况下应该是单峰分布。如果出现明显的双峰说明语料里混进了风格差异巨大的两个群体。这时候不要急着合并先把两个峰对应的文本各抽几百条人工看判断是低质文本混入还是高价值的长尾知识。如果是后者可以保留但单独确定采样权重而不是让它和主流文本混在一起被平均掉。6.3 数据版本管理与清洗规则记录数据构建本质上是一个持续迭代的工程版本管理做不好会非常痛苦。我见过最典型的场景是训练跑了一周发现数据有 bug但没人记得当前这份数据是用哪个清洗脚本、哪个阈值、从哪个原始快照洗出来的最后只能全部重跑。规范的团队应该给每一个数据版本生成 manifest 文件记录原始数据快照的哈希、清洗脚本的 git commit、每个过滤规则的参数、最终 token 数、语言分布、重复率统计。这些信息在跑实验复现时比“数据放在哪个目录”重要得多。实践中可以用 DVC 或简单的目录结构来管data/raw/20250101/、data/clean/20250115_v3/、data/tokenized/20250120_v3/每个版本目录里放 manifest.json。清洗阈值一旦改动旧版本不要覆盖新版本另起一个目录。这个习惯在跨团队协作时尤其重要——算法团队和数据处理团队经常不在一个节奏上没有版本号两边对不上是家常便饭。6.4 合成数据的加入策略合成数据不是新话题但最近社区讨论确实越来越多从指令微调蔓延到了预训练阶段。所谓合成数据通俗说就是用模型生成的高质量文本、代码、推理轨迹再回灌进训练集。最近讨论比较多的智能体轨迹数据和反思式生成数据本质都是这个思路。它的价值是能定向补足某个领域比如数学推理链条、多步规划过程这些在自然语料里很难大量获取。但合成数据进预训练要非常克制。我的做法是先让团队里的强模型生成一批样本人工抽 500 条判断质量再跑小规模探针训练对比“加合成数据”和“不加合成数据”的差异。常用的混入比例是 5%-10%超过这个比例容易产生“近亲繁殖”问题——模型反复学习模型生成文本的分布偏差越训越窄。还有一条铁律合成数据的生成 prompt 要多样化同一个模板造出来的东西再多也只是一堆同质样本对模型多样性是负贡献。7. 实操踩坑记录硬盘、带宽与预期管理7.1 先算算要占多少盘大部分人对数据体积的预估第一版总是偏小。假设你最终要 500B token 的清洗后语料按每个 token 平均 4 字节算纯 token 化的 bin 文件就要 2TB。但这是清洗后的结果。原始网页数据通常是这个量的 5-10 倍中间还要留出解析、去重、临时文件的 buffer。经验公式是存储预算 最终 token 数 × 4 字节 × 10。按这个公式500B token 的项目你至少要准备 20TB 可用空间。别迷信“数据下完再删”清洗流程是一个 iterating 过程旧版本、中间产物都要留一阵子等验证无误再清理。带宽同样要提前算。假设你原始数据要拉 5TB10Gbps 的带宽理论上一天能拉完。实际传输会有损耗、有重试按 70% 利用率算大概 1.5 天。但真正的瓶颈往往不在下载而在于解析、去重、质量过滤这些 CPU 密集型环节。单机跑 trafilatura 之类的正文抽取速度远赶不上下载速度所以正规流程一定是分布式处理。先给自己算一笔 CPU 账再决定是先扩容机器还是减少原始数据量。7.2 试跑管线再扩量的节奏数据管线最大的坑是“一上来就跑全量”。全量数据量巨大任何一个小 bug 的代价都是按天计的。正确节奏是先拿 1GB 级别的样本把抽取、语言过滤、质量过滤、精确去重、MinHash 去重、隐私脱敏、tokenize 这条链路完整跑一遍中间每一步的输出都用人工抽样确认质量。这一步跑通之后再放大到 100GB 级别测一次吞吐和资源占用确认瓶颈在哪里最后才上全量。这个节奏看起来多花了一周实际上能救你一个月。有个项目当时跳过了小规模验证直接全量跑清洗跑了三天才发现正文抽取环节对某些编码格式的网页会输出乱码结果三分之一的数据白洗了只能回炉。中间产物建议按 staging 和 release 分目录staging 放每次清洗的临时输出release 放经过验证、打过版本号的正式产物。staging 目录随时能删release 目录必须保留。7.3 预期管理与几条保命建议最后聊点“软”的。数据管线在预训练项目里的耗时占比通常比你想的高得多。很多人以为训练是最耗时的实际数据准备、清洗、验证、返工经常占掉整个项目 50% 以上的时间。所以尽早冻结一个“数据 v1”特别重要——哪怕你知道它有瑕疵先让它跑起来同时并行迭代数据 v2。训练和数据构建并行推进比按顺序“等数据完美再开训”要高效得多。还有一条保命建议每个清洗规则改动都要留下效果记录。比如“MinHash 阈值从 0.6 调到 0.7 之后整体删除比例从 8% 降到 5%但这 3% 的差异主要是短文档”。这些记录在后续排查模型问题时都是关键线索。数据团队最怕的不是规则复杂而是规则改动了却没人说得清改动的影响。让数据集的“可读性”和数据量同样重要这是我跑过这么多轮数据迭代后最深的一点体会。