跳到主要内容

4.2 配比、打包与数据的边界

上一节欠了一个交代​

4.1 讲完了语料从哪来、怎么洗、不够了怎么造。但有一句话它是绕过去的:

各来源按什么比例混合(数据配比),直接影响模型的「性格」和强项——这是每家公司最核心的机密之一。

「是机密」这个说法只对了一半。各家最终用的那组数字确实不公开,但决定这组数字的方法完全是公开的。 这一节先把这套方法讲清楚,再补上另一件 4.1 没说的事:洗干净的文档,是怎么变成模型真正吃下去的那一条条序列的。

配比:机密的是数字,不是方法​

先说为什么配比值得当机密。同样是十几万亿 token,代码多喂两个百分点、书籍少喂两个百分点,训出来的模型在推理题和长文写作上的表现会明显不同。配比是少数几个「不用加算力就能改变模型强项」的旋钮,而每调一次都要烧掉一批实验算力去验证——所以它既值钱又难得。

但公开信息比你想的多。

先看一个把配比完全摊开的例子。 The Pile(2020)是第一个把「配比」当成核心设计的公开数据集:22 个来源,每个来源的权重、原始体积、重复几遍,全部写在论文表格里。网页抓取占了最大一块,学术论文、代码、书籍、问答各占一定比例。今天没人再直接用 The Pile 训旗舰模型,但它示范了配比这件事该怎么被记录和讨论。

再看一个反复被验证的结论:代码的特殊地位。 在语料里多放代码,模型在非代码的推理任务上也会变强——这在多个公开的消融实验里被反复观察到。直觉上说得通:代码是人类写出来的最长、最严密的一类逻辑链条,变量要定义了才能用、分支要闭合、类型要对齐。模型为了把下一个 token 猜准,被迫学会跟踪状态和约束,而这套本事会溢出到别的任务上(回扣 4.3 节:想把预测做准,你不得不变聪明)。

那配比到底怎么定? 三条路,从笨到巧:

  1. 小模型消融。这是最扎实也最贵的一条:固定算力,训一批几亿参数的小模型,每个用不同配比,然后比下游指标。缺点是小模型上的结论未必能外推到大模型——配比的效果本身就随规模变化。
  2. 代理模型自动调权。既然人工试太慢,能不能让算法来找?DoReMi(2023)是代表:先用一个小的代理模型跑一轮,看哪些来源「学得最吃力」,据此自动调高它们的权重,得到一组配比再拿去训大模型。它把配比从手工调参变成了一个可优化的问题。
  3. 直接拿退火当探针。这是 4.1 的退火带来的副产品:拿一个训到一半的检查点,用候选配比退个火,比一比分数。比从头训小模型便宜得多,2024 年后已成常规手段。

最后一件容易被忽略的事:配比不是一个数,是一条曲线。 主段吃广度、退火段吃质量——同一份语料,在训练的不同阶段权重是不同的。所以「这个模型的数据配比是多少」这个问题本身就问得不够准,正确的问法是「在哪个阶段的配比是多少」。

从文档到 batch:中间还差一步​

现在换个问题。假设语料洗好了、配比定了,你手上是几亿篇长短不一的干净文档:有的 50 个 token,有的 3 万。

而模型每一步吃的是固定长度的序列(比如 2048、8192)。

这中间怎么对上?答案叫打包(packing)——自己拖一遍就明白了:

🎮 动手实验
打包:12 篇长短不一的文档,怎么塞进定长格子
模型每一步只吃固定长度的序列(这里设为 2048 token)。可真实文档从几十字到几千字都有——中间这一步怎么填,直接决定你有多少算力花在了废话上。
序列条数
12 条
算力利用率
40.7%
浪费在补白上
14,585 token
会串味的序列
0 条
文档 #1(1180 token)补白 868 token —— 这部分算力完全浪费文档 #2(240 token)补白 1808 token —— 这部分算力完全浪费文档 #3(2600 token)文档 #4(90 token)补白 1958 token —— 这部分算力完全浪费文档 #5(760 token)补白 1288 token —— 这部分算力完全浪费文档 #6(1520 token)补白 528 token —— 这部分算力完全浪费文档 #7(310 token)补白 1738 token —— 这部分算力完全浪费文档 #8(55 token)补白 1993 token —— 这部分算力完全浪费文档 #9(940 token)补白 1108 token —— 这部分算力完全浪费文档 #10(3400 token)文档 #11(180 token)补白 1868 token —— 这部分算力完全浪费文档 #12(620 token)补白 1428 token —— 这部分算力完全浪费
各色 = 不同文档灰 = 补白(纯浪费)
一篇一条 + 补白。每篇文档单独占一条序列,不够 2048 就用无意义的 padding 填满。看那一大片灰色——利用率只有 40.7%,也就是说你买的 GPU 有大半时间在计算「什么都不是」的填充符。 真实语料里短文占绝大多数,这个比例只会更难看。
💡 要点:训练时模型吃的不是「一篇文档」,而是一条定长序列。一篇一条地补白最直观,也最浪费——真实语料里短文占绝大多数,补白能吃掉大半算力。所以生产上一律打包:文档首尾相接塞满,用 EOS 分隔,超长的切段续到下一条。
代价是同一条序列里会挤进好几篇不相干的文档,注意力能看到前面那篇——这叫跨文档污染。现代做法是打包的同时加一层文档级注意力隔断,两头的好处都要。
文档长度为教学构造,但「大量短文 + 少量长文」的分布形态照着真实语料做;真实实现还会做长度分桶、best-fit 装箱等优化,这里只演示核心权衡。

三个策略逐个点:

① 一篇一条 + 补白。 最直观:每篇文档单独占一条,不够就用无意义的填充符补满。看那一大片灰色——利用率只有 40.7%。你买的 GPU 有大半时间在计算「什么都不是」的东西。而且真实语料里短文占的比例远比这 12 篇更极端,实际浪费只会更难看。

② 打包塞满。 文档首尾相接,中间用一个 EOS 分隔符隔开,装不下的切段续到下一条(注意 #3 和 #10 那两篇长文被拆成了两段)。利用率冲到 96.8%,序列条数从 12 降到 6——算力直接省了一半。

但它引入了一个新问题:5 条序列里挤着不止一篇文档。而注意力默认能看到同一条序列里的全部内容——模型在预测一篇菜谱的下一个词时,会去看前面那篇毫不相干的财报。这叫跨文档污染。

③ 打包 + 文档隔断。 装填方式和 ② 一模一样,但在每个文档边界加一道注意力隔断:每个 token 只能看到自己这篇文档内的前文,看不到隔壁。算力不浪费,语义也不串味——这是 2023 年后的主流做法。

「装箱」这个比喻在哪里不准确

把打包想成「往箱子里塞行李」很好懂,但有两处会误导。

一、切开的文档不是「坏掉的行李」。 一篇 3 万 token 的长文被切成 4 段放进 4 条序列,这在训练上是完全正常的——每一段各自都是合法的「预测下一个词」训练样本。它损失的只是跨段的长程依赖,而那本来也超出了模型的训练长度。

二、隔断不是把序列切开。 加了文档隔断之后,这一条序列在计算上仍然是一条(同一次前向、同一份位置编码起点通常也会重置),只是注意力掩码从「下三角」变成了「块对角」。它省的不是算力,是语义干扰——所以 ② 和 ③ 的利用率完全相同。

另外提醒:本节的利用率数字来自这 12 篇构造文档,只说明量级和方向。真实系统还会做长度分桶、best-fit 装箱等优化,补白比例通常比这里的 ① 更好看一些,但结论不变——不打包就是在烧钱。

顺手算一笔:十几万亿 token 是多少步​

有了打包,就能把「语料规模」换算成「训练要跑多少步」了——这是 4.4 Scaling Laws 那笔账在时间轴上的样子:

训练步数=总 token 数每步的 token 数\text{训练步数} = \frac{\text{总 token 数}}{\text{每步的 token 数}}

代入一组旗舰级的量级(2024-2025 年公开报告的常见配置):总量 15 万亿 token,每步全局批量 1600 万 token(比如约 2000 条 8192 长度的序列)——

15×10121.6×107≈94 万步\frac{15 \times 10^{12}}{1.6 \times 10^{7}} \approx 94\ \text{万步}

几个月的训练,大约就是一百万次「前向 + 反向 + 更新参数」。 每一步都要几千张卡协同完成(4.5 节讲怎么协同),中间任何一步崩了都要从检查点恢复(4.6 节讲怎么不翻车)。

知识截止日期是怎么来的​

你一定问过模型「你的知识截止到什么时候」。这个日期不是谁拍脑袋定的,它就是语料快照的时间——抓取工作停在哪个月,模型对世界的了解就停在哪个月。

但它比大多数人以为的模糊得多,有三个原因:

  • 各来源的新鲜度不一致。 网页抓取可能停在 3 月,而某个代码库快照是去年的,某本书是十年前的。所谓「截止日期」是一堆不同时间点的混合,通常按最晚的那批来报。
  • 后面还有好几道工序会补进新内容。 4.1 的退火段、以及第 5 章的后训练数据,都可能包含比预训练快照更新的材料。所以模型对某些近期事件有零星印象,并不奇怪。
  • 模型自己也说不准。 它关于「我的截止日期」的回答,同样来自训练数据里的文本,而不是来自某种内省——报错日期是常见现象。

对使用者的实际含义只有一条:截止日期是个模糊的下界,不是保证。 时效性强的事实,无论模型说自己知道到什么时候,都该外挂检索(本站中篇讲的就是这件事)。

中文语料的现实​

前面所有讨论都有一个隐含前提:语料池足够大,你有得挑。这个前提对英文成立,对中文要打不小的折扣。

第一,池子小一个量级。 按公开统计的量级,Common Crawl 这类全网抓取里英文内容占四成以上,中文只有个位数百分比。也就是说同样一遍抓取,中文可用的原始素材从一开始就少得多——而 4.1 的清洗流水线还要在此基础上再淘掉九成以上。

第二,来源结构完全不同。 英文语料里学术论文(arXiv)、开源电子书、技术文档这些「高密度、长篇、严谨」的来源开放度很高;中文对应的部分要么不公开、要么受版权限制,于是中文语料的实际构成里,论坛、自媒体、内容平台的占比明显更高。这直接影响模型的文风和知识密度——不是中文模型的算法差,是它能吃到的东西结构不一样。

第三,还有几个英文没有的麻烦。 简繁转换(同一内容的两个版本容易被去重误判为重复,或者该判重的没判出来)、大陆与港台的用词差异、以及大量内容平台的正文和推荐流、评论区混在一起难以提取。

实际后果是:中文能力更依赖后天补救。 合成数据(4.1 讲的改写和出题)、从英文语料翻译回译、以及在后训练阶段集中补中文示范——这些手段在中文模型的训练里,权重比英文模型高得多。你在 1.3 节已经见过一个相关的现象(同样内容中文更费 token),那是表示层的劣势,这里是语料层的劣势,两者叠加。

这不是「中文注定更差」

两点澄清。其一,这些是工程约束不是能力天花板:2024 年以来中文模型在中文任务上的表现已经普遍超过同规模的英文主导模型,靠的正是上面那些补救手段加上针对性的数据建设。其二,「语料少」和「语料差」是两回事——中文有大量高质量内容,问题在于它们的开放度和可获取性,而不是本身的质量。

另外,本节的比例都是公开统计的量级,各家实际用的中文数据规模和来源都不公开,别把这些数字当精确值引用。

一个绕不开的问题:这些数据能用吗

本章到此为止都在讲技术上怎么用,但还有一层:法律上能不能用。

抓取全网训练模型,触及三类问题:受版权保护的作品(书籍、新闻、代码)被用于训练是否构成合理使用,2023 年起在多个法域引发了大量诉讼且尚无定论;网站的抓取协议(robots.txt、服务条款)在法律上的约束力各地认定不一;以及语料里夹带的个人信息,在 GDPR 一类法规下有明确的处理义务(4.1 的清洗流水线里那道「隐私打码」工序就是为它而设,但打码远不等于合规)。

对使用开源数据集的人,还有一条很实际的:数据集的许可证和它内容的许可证是两回事。一个以宽松许可发布的数据集,里面可能混着不允许商用的内容——真要做商业模型,这一层必须自己查。

本书不提供法律意见。这里要传达的只有一点:数据的合规性是数据工程的一部分,不是「技术做完再说」的附加项——因为一旦语料进了模型参数,你没法把它单独删掉(这也是 K8.2 讲的「RAG 能删、微调不能删」的另一面)。

本节要点
  • 配比:机密的是数字,不是方法。 三条公开路径:小模型消融(扎实但贵)、代理模型自动调权(DoReMi 一类)、拿退火当探针(最便宜,2024 年后的常规手段)。
  • 代码多喂一点,模型在非代码推理上也会变强——它是人类写出的最严密的长逻辑链。
  • 配比不是一个数,是一条曲线:主段吃广度、退火段吃质量,问「哪个阶段的配比」才问得准。
  • 打包:文档首尾相接塞满定长序列(利用率 40% → 97%),代价是跨文档污染;现代做法是打包 + 文档级注意力隔断,两头好处都要。
  • 十几万亿 token ÷ 每步一千六百万 ≈ 一百万个训练步。
  • 知识截止日期是语料快照的时间,且是个模糊的下界——各来源新鲜度不一,退火与后训练还会补进新内容,模型自己也常报错。
  • 中文语料池比英文小一个量级、来源结构也不同(高密度长文来源开放度低),这是工程约束不是能力天花板,但它解释了为什么中文模型更依赖合成数据与针对性数据建设。
📝 动手自测0/4
1. 关于数据配比,下面哪个说法最准确?
2. 为什么训练时要把多篇文档「打包」进同一条定长序列?
3. 打包之后加「文档级注意力隔断」,主要解决什么问题?
4. 模型说自己的知识截止到某年某月,正确的理解是?

延伸阅读​