简介《2024大模型训练数据白皮书》是由阿里巴巴集团数字中国研究院福建与阿里云智能集团专家委员会编写的一份专业报告面向大模型研发者、数据工程师及人工智能技术决策者系统剖析训练数据对大模型发展的关键作用。白皮书不仅梳理了大语言模型与多模态模型所需的数据类型还澄清了“训练依赖用户个人信息”“中文语料短缺”等常见误解并科学阐释高质量数据的标准进而提出合成数据作为解决训练数据供给不足的新方案。值得注意的是包内仅含1个PDF文件大小15.19MB内容完整且结构清晰覆盖数据重要性、类型、质量、合成数据与治理生态等核心章节。目前已有252人学习适合希望从理论到实践理解大模型训练数据资源建设与合规治理的读者可作为行业研究、课程教学或技术决策的参考资料。1. 2024大模型训练数据白皮书模型能力为什么卡在数据管线上“2024大模型训练数据白皮书.pdf”表面上是一份行业报告实际上是一张数据管线的施工图。它要回答的不是“模型为什么变聪明”而是“聪明的模型到底吃了什么样的数据”。看完之后我的第一感觉是模型能力的天花板已经明显转移到了数据管线这一端。同一套网络结构换成不同配比、不同清洗深度的数据下游任务分差能拉到两位数比调参带来的收益大得多。这份白皮书特别适合正在搭数据流水线的工程师、管算力预算的技术负责人以及一直在纠结“合成数据和真实语料到底该混多少”的人。你不需要照搬它的大规模方案真正值得抄的是它衡量数据质量的指标和参数取舍。2. 把原始语料变成训练样本数据收集、过滤与清洗的完整工序数据管线的基础工序可以用一句话概括把非结构化文本变成高质量训练样本。各家公开的数据报告里流程都是串行的从 URL 清单到最终混样中间至少经过采集、正文抽取、过滤、去重、隐私清理、配比混合六道工序。每一道工序的意义不在于“做没做”而在于“做到什么程度”。很多团队翻车不是缺了某道工序而是某道工序的参数设得太松或太紧导致前后环节互相干扰。2.1 数据从哪里来公开语料与行业语料的取舍策略公开语料主要来自网络爬取吃进去的是网页、百科条目、书籍扫描、预印本平台和代码托管仓库。优点是规模大、覆盖面广缺点是噪声多、域名质量参差不齐。做完正文抽取后一份网页转纯文本往往能压缩掉 70% 的体积剩下那 30% 才是真正能被模型学习的文本。我一般会先做一次“域名分层”把已知的高质量来源和普通网页分开后续再做采样加权。2024 年白皮书里的主流做法也是这样先按来源分层再按内容质量细分。# 按域名粗略分层为后续采样加权做准备 mkdir -p buckets/{high_quality,medium_quality,general_web} cat url_list.txt | while read -r url; do domain$(echo $url | sed -E s#https?://([^/])/.*#\1#) case $domain in *wikipedia*|*github*|*arxiv*) buckethigh_quality ;; *blog*|*news*) bucketmedium_quality ;; *) bucketgeneral_web ;; esac echo $url buckets/${bucket}/urls.txt done这段脚本做的事情很简单按域名把 URL 归入三个桶。high_quality 里的域名通常是白皮书里反复出现的“高价值来源”medium_quality 里是质量和噪声都比较普通的博客、新闻站点general_web 则是长尾域名。这样分桶之后后续采样权重才能拉开差距。常见做法是 high_quality 的采样权重设为 general_web 的 8~10 倍medium_quality 居中具体倍数以实测的验证集效果为准。那行业语料呢企业内部文档、产品手册、客服对话这类数据规模小但质量高授权路径清晰。2024 年的白皮书普遍认同一种做法公开语料给规模行业语料给精度。理想比例是七成公开、三成自建但自建部分需要商务授权成本不低。如果预算有限我建议优先把公开语料的清洗做好再考虑引入行业数据。因为行业数据量少清洗再差也能很快人工排查公开语料量大清洗标准稍微松一点垃圾样本就会淹没那部分高价值内容。2.2 质量过滤怎么做规则过滤与模型打分两层衔接质量过滤通常分两层。第一层是启发式规则几行代码就能跑完却能过滤掉大半的乱码、空白页和导航栏文本。第二层是用一个小型文本分类器打分保留语义完整的样本。为什么不要只靠模型打分模型打分会把那些“格式特殊但内容专业”的文本误杀比如数学公式密集的论文、代码片段、表格数据。反过来只靠规则又解决不了语义垃圾——比如一篇语法正确但完全在胡说的营销稿。两层各管一段规则层管格式模型层管语义。# 两层过滤第一层规则第二层分类器打分 def quality_filter(row, classifierNone, score_threshold0.7): text row[text] # 规则一文本长度过低通常是导航栏、空白页或验证码页 if len(text) 200: return False # 规则二单个字符占比过高常见于乱码和网址堆叠 max_char_ratio max(text.count(c) for c in set(text)) / len(text) if max_char_ratio 0.3: return False # 规则三平均句子长度过低多半是标题或关键词堆砌 sentences [s for s in text.split(。) if s.strip()] if len(sentences) 0 and sum(len(s) for s in sentences) / len(sentences) 8: return False # 第二层分类器打分分数低于阈值则丢弃 if classifier is not None: score classifier.predict_proba([text])[0][1] return score score_threshold return True这段代码的价值在于把“过滤标准”显性化了。长度阈值 200 字符、单字符占比 0.3、平均句长 8 字符这些参数不是拍脑袋定的而是在小样本上做了保留率统计之后定出来的。常见的错误是直接套别人公开的阈值不去看自己语料的分布。比如代码语料天然短句子多把平均句长调到 8会把大量单行代码误杀法律文书则天然长句多阈值调到 8 又几乎没有过滤作用。所以参数必须按子集统计后再设。规则建议阈值过滤目标最小文本长度≥200字符导航栏、空白页、验证码最大单字符占比≤0.3乱码、网址堆叠平均句长≥8字符标题堆砌、关键词营销稿分类器得分≥0.7低质量重复文本、语义垃圾分类器得分阈值为什么选 0.7 而不是 0.50.5 会把很多边界样本放进来模型训练时这些噪声会不断累积0.85 以上又容易把专业性强但格式特殊的语料全部误杀。我一般会先拿 0.7 跑一遍统计留下样本的分布再按子集上下微调。白皮书里的做法也是如此先定基线再看保留率和评测集分数的变化而不是一上来就追求完美阈值。3. 去重不是删文件这么简单MinHash 与去重粒度的工程细节去重是整个管线里最容易被低估的环节。重复数据不会直接报错但它会让模型在训练时反复看到同样的文本轻则过拟合评测集重则让模型把训练语料里的错误表述当成事实记住。公开网络语料的文档级重复率通常在 20%~40% 之间如果你发现自己的数据重复率只有 5%说明采集源过于集中多样性不足这反而是另一种风险。2024 年白皮书里反复强调一个观点去重是“控制记忆污染”的第一道闸门。3.1 去重粒度怎么选文档级与段落级的边界文档级去重处理的是“完全重复”和“几乎完全重复”的文档实现简单计算量小。但网络语料里真正的重复往往不是整篇复制而是“拼接式重复”有人把两篇文章各截一段拼成新页面或者把同一段话换几个词重新组织。文档级去重对这种情况无能为力必须再做段落级去重。段落级去重是把文档切成长度为 5~10 句的片段逐片段计算相似度再决定是否丢弃。代价是计算量急剧上升副作用是可能误删同一作者的系列文章。去重粒度覆盖的重复形态成本主要副作用文档级整篇复制、URL 镜像低无法处理拼接式重复段落级局部复制、改写式重复高可能误删同主题连篇内容语义级语义高度相似的不同表述很高误删率难以控制我的经验是先跑文档级去重把全篇重复的样本清掉再对剩余数据做段落级去重。如果拿 10 万条语料做抽样观察你会发现段落级去重能额外清理掉 3%~8% 的重复片段这些片段单独看都不算垃圾但放进训练集就会让模型对某些句式产生偏好。白皮书里特别提醒段落粒度不能切得太短。切到 2~3 句时大量正常表达会被判为重复造成误杀切到 10 句以上时又回到了文档级去重的覆盖范围形同虚设。3.2 MinHash 参数校准num_perm、阈值和分片实践的取舍MinHash 是目前做大规模模糊去重最常用的方案原理不复杂把文本拆成 token 集合用多个哈希函数取最小值生成一个固定长度的签名然后通过 Jaccard 相似度估计两个文本的重复程度。工程上的关键在于三个参数num_perm哈希函数数量、阈值相似度判定线、分片大小。# 使用 MinHashLSH 做近似去重核心参数集中在 num_perm 与 threshold from datasketch import MinHash, MinHashLSH def build_signature(text, num_perm128): m MinHash(num_permnum_perm) # 用集合去重后再计算避免同一文本内的高频词拉高签名噪声 for token in set(text.split()): m.update(token.encode(utf-8)) return m def dedup_shard(shard_texts, threshold0.85, num_perm128): lsh MinHashLSH(thresholdthreshold, num_permnum_perm) signatures [] for idx, text in enumerate(shard_texts): sig build_signature(text, num_perm) signatures.append(sig) # index 用 id 而非文本本身保留映射关系用于后续校验 lsh.insert(fdoc_{idx}, sig) duplicates set() for idx, text in enumerate(shard_texts): sig signatures[idx] candidates lsh.query(sig) for cand in candidates: cand_idx int(cand.split(_)[1]) if cand_idx idx: continue # LSH 返回的是候选集必须用精确 Jaccard 复核 real_sim signatures[idx].jaccard(signatures[cand_idx]) if real_sim threshold: duplicates.add(max(idx, cand_idx)) return list(duplicates)这段代码里最重要的不是我调用了哪些函数而是那个“精确复核”的步骤。LSH 的本质是“先粗筛、再精排”它返回的结果里会混入一些不相似的样本如果直接拿来删数据误杀率会让你在训练后才发现数据量不对。所以必须对候选对做一次精确 Jaccard 计算确认真的超过阈值再删。这个步骤多花一点算力但能避免后续整个数据集的二次清洗。参数取值效果num_perm128签名精度适中内存开销可控num_perm256相似度精度更高内存翻倍threshold0.8去重力度大误杀率略高threshold0.9只删高相似重复保留改写文本num_perm 选 128 还是 256取决于你的数据规模和机器内存。1B 级别以下的语料用 128 完全够用再大就上 256。threshold 我一般先设 0.8观察重复率统计结果再决定要不要调到 0.85 或 0.9。如果只是想清理“完全复制的页面”0.9 足够如果你想连“改写拼接”一起处理0.8 更合适但要做好误杀部分同主题文章的心理准备。提示MinHash 的判定结果受 token 切分方式影响很大。直接按空格切分会漏掉“词序调整后的重复内容”按 n-gram 切分比如每 3 个连续 token 作为一个单元能捕获更多改写痕迹相应也会增加计算量。4. 数据配比与合成数据2024 年白皮书里最有价值的两组实验配比和合成数据是 2024 年各种数据白皮书里最有实操价值的两块内容。配比解决“吃什么”合成数据解决“不够吃怎么办”。前者靠对比实验定比例后者靠生成策略补长尾分布。这两件事做对了即便清洗质量一般模型能力也能有明显提升反过来清洗做得再细配比失衡或合成数据过浓照样会把模型喂坏。4.1 配比表这样读典型比例、消融实验和参数调整大多数公开报告都会附一张配比表里面列出网页文本、代码、书籍、数学科学、多语言等子集的占比。典型数据大致是网页文本 60%~70%代码 10%~15%书籍与长文本 5%~10%数学与科学 3%~5%多语言 3%~5%合成数据 5%~10%。看这张表关键不在于记住具体百分比而在于读懂三条规律。第一条代码比例在 2024 年普遍上调因为它不仅提升代码生成能力对其他推理类任务也有正向迁移第二条书籍和长文本占比始终不低因为长文本是模型学会“跨段落推理”的基础第三条合成数据的占比很少超过 15%它的作用定位是“补缺”而非“主餐”。数据子集常见占比区间主要作用网页文本60%~70%提供广泛的世界知识和语言多样性代码10%~15%增强结构化推理与逻辑能力书籍/长文5%~10%强化长距离依赖与深度理解数学/科学3%~5%提升量化推理与严谨表述多语言3%~5%维持各语言覆盖面合成数据5%~15%补长尾分布与指令多样性读配比表时我一般会先看两个东西一是有没有消融实验也就是把某一类数据设为 0 之后模型能力的下降幅度二是采样方式是固定的还是动态的。2024 年公开报告里有一个反复出现的观点代码数据对模型整体能力的影响比同比例的网页文本大得多。所以如果你预算有限想快速提升模型表现优先补代码语料比盲目扩大网页抓取更划算。当然前提是你把代码里的低质量部分先过滤掉否则垃圾代码只会教会模型生成语法错误的大段废话。4.2 合成数据三条路线从种子指令到分布迁移合成数据在 2024 年不再是“锦上添花”而是成为数据管线里的固定一环。但“怎么合成”决定了它到底有用还是有害。我比较常用的三条路线种子指令扩展、改写增强、检索辅助增强。种子指令扩展的思路是拿一小撮高质量人工指令让模型生成同分布的新指令改写增强是拿真实文本让模型换个说法重写增加表达的多样性检索辅助增强则是先从真实语料里检索相关片段再让模型基于这些片段生成新指令。# 种子指令扩展用少量人工指令生成同分布的新指令 def expand_seed_instruction(seed_instruction, generator, temperature0.8, top_p0.95): prompt ( 下面是一条人工编写的指令请仿照它的难度、长度和风格 生成一条全新的指令不要重复原指令的内容\n f{seed_instruction} ) response generator.generate( prompt, temperaturetemperature, top_ptop_p, max_new_tokens128 ) return response.strip()生成合成数据时temperature 的取值是关键。0.8 到 1.0 之间生成的指令多样性最好低于 0.6 就退化成“换汤不换药”把有限的种子指令翻来覆去说高于 1.0 则容易生成跑题内容反而增加清理成本。top_p 固定 0.95 基本不会出问题。参数归参数比这更重要的是比例控制。我见过把合成数据调到 40% 以上的团队评测分数涨得很快上线一测就发现对话特别模板化。合成数据只能补长尾不能当主食。合成数据的三条路线成本差异也很大种子指令扩展最便宜改写增强需要高质量源文本检索辅助增强还要搭一套检索系统。如果团队人力有限我建议从种子指令扩展入手先跑通流程再用评测集验证合成样本是否真的改善了模型表现。很多团队踩坑的共性是合成数据生成完直接混进训练集不做质量抽检。合成数据的质量问题比真实语料更难发现因为它看起来太“正常”了实际上可能在逻辑上有系统性错误。5. 训练数据避坑五条来自一线数据管线的踩坑记录白皮书里的方案再完善落到自己的管线上还是会遇到各种实际问题。以下五条是我在数据管线建设里最常见的踩坑记录每条都按“现象→原因→解决”的顺序写供你排查时对照。5.1 局部 loss 震荡现象训练中期 loss 曲线出现周期性抖动先下降后回升整体趋势不收敛调学习率也无济于事。原因去重阈值设得太高比如 0.95大量相似度在 0.8~0.9 的“改写版重复”被放进了训练集。这些重复样本在低学习率阶段被模型反复学习导致 loss 震荡。解决把去重阈值从 0.95 降到 0.8同时开启段落级去重。改完后再看 loss 曲线抖动明显消失。教训是去重阈值不是越高越好而是要在“保留多样性”和“清理重复”之间找平衡。5.2 时间线错乱现象模型在回答“当前年份之后的事件”时引用了未来时间点的内容或者对已过时的信息仍然坚定输出。原因语料的日期元数据不可靠。URL 里的时间戳、网页底部的发布时间、正文里提到的时间词互相矛盾训练时没有按时间排序导致未来信息混入早期训练样本。解决清洗时同时解析 URL 时间戳和正文时间词两者不一致就丢。训练前按文档时间排序并在推理时明确设置知识截止日期。这个问题的隐蔽性在于错乱的信息不会让 loss 变差但会让模型在关键业务上无法信任。5.3 tokenizer 词表外溢现象训练时发现 OOV未登录词比例异常高某些低频专业词被切成碎片生成时专有名词频繁拼错。原因质量过滤阶段为了控制噪声把含公式、生僻词的文本大量删除了导致词表统计失真。词表是统计出来的你把那些词频低的样本删了词表自然覆盖不到。解决先对原始文本做一次分词频次统计再按词表覆盖率反推过滤标准。公式类和专业术语较集中的文本单独建桶处理不要一刀切丢进垃圾桶。这个坑最隐蔽因为它在训练初期不会暴露要到生成阶段才体现。5.4 合成数据过拟合现象合成数据占比提到 40% 后评测集分数上升但真实对话越来越模板化用户稍一追问就回到固定句式幻觉率同步上升。原因合成数据由同一个模型反复生成等于在不断强化模型自身的偏好。模型生成的内容又被拿去训练模型造成自循环放大。解决把合成数据占比压回 20%~30% 以内并且每个合成样本过一道质量打分得分低于真实数据中位线的直接丢弃。另外要定期用真实用户反馈做校验不能只看评测集分数。5.5 内容源合规隐患现象线上模型被内容方提出权利要求要求下架或删除但团队无法快速定位这些内容的训练数据来源。原因清洗只做了质量和去重没做溯源和退出机制。一旦接到诉求就只能全量重训成本极高。解决建立内容源主动退出列表和溯源链路记录每一条训练数据的来源域名和原始 URL。接到诉求后定位数据位点标记后从新训练批次中剔除。2024 年白皮书里普遍认可的方案是“让内容方可以选择退出”这个机制不是一次性交付而是需要持续维护的。合规这件事做在前面永远是成本最低的。6. 用白皮书的方法检验自己的数据一个可以照做的季度排期白皮书读一百遍不如跑一遍。如果你现在手上有一批数据但不确定该从哪开始改我给你一个按季度推进的排期表直接照着做就行。这套排期的核心逻辑是先盘点再清洗再审计最后小规模训练验证。6.1 季度排期表从盘点到底层验证前两周做数据盘点统计现有数据的规模、来源域名分布、重复率基线产出数据报告第三到第六周跑完整管线把采集、过滤、去重、配比全部跑通记录每道工序的保留率第七到第八周做数据审计用一批真实用户问题去测试清洗后的数据第九到第十二周用小规模训练跑一轮验证实验对比清洗前后的评测集分数。整个排期的关键是一次只改一个变量不要同时调阈值和配比否则出了问题排查不了。时间交付物关键验收指标第1~2周数据盘点报告数据规模、重复率、域名分布第3~6周第一版清洗管线各工序保留率、过滤日志第7~8周数据审计与红队测试重复残留、时间线错乱、隐私泄漏第9~12周小规模训练验证评测分对比、loss 曲线稳定性6.2 快速审计清单十分钟检查数据健康度手工审计时我会先看四个东西重复率是否在 15% 以下时间戳是否按序排列有没有未来内容混入PII 隐私信息扫描结果以及合成数据占比是否在 20% 以内。这四个指标能快速暴露管线里的主要问题。如果没有大算力做全量清洗就抽 10 万条先跑一遍子集子集跑通再全量上这样能省掉大量重复劳动。我第一次组织数据管线时觉得把清洗做好就万事大吉结果把代码语料和百科语料混合得太早配比失衡导致后来重跑了一轮训练多烧了一个多月的算力。这之后我给自己定了条规矩任何配比调整都要先跑 2% 的子集实验再全量上。数据管线的优化没有捷径每次都按“小实验验证大调整”的节奏走才是最省时间的方式。希望帮到你。本文还有配套的精品资源点击获取