UltraBERT研究：8.8万亿token训练后，分类与检索不再二选一

2019年前后，做自然语言处理的工程师要是被问起，有没有一个编码器模型能同时把文本分类和语义检索都做好，多半只能摇头。

没人试过吗？其实试的人不少。这几年ModernBERT、Ettin、NeoBERT、GTE接连冒出来，各自在某个方向上都刷过纪录。可有个怪事一直没解决：分类强的模型，检索分数总差那么一截；检索强的模型，分类又掉队。好比训练营里练短跑的怎么也练不出马拉松耐力，练马拉松的百米冲刺又快不起来。久而久之，大家把这当成了编码器的宿命。

Korea University的研究团队偏不信这个邪。他们怀疑毛病不在模型架构，出在训练方法这套配方上，而且这套配方已经过时。论文讲的就是他们怎么找出病根、再把它治好。

编码器为什么卡在这个瓶颈里

双向编码器*：这类语言模型能同时看到句子前后文，跟只能从左往右生成的GPT类解码器不一样，它把整段文字的信息压成向量，用来做分类、打分、检索，不负责生成新文字。

先把编码器为什么还重要说清楚。眼下人人都在聊GPT这类生成式大模型，可编码器在很多场景反而更顶用：RAG系统里做检索召回、给训练数据做质量过滤、给强化学习打奖励分，这些活对响应速度和成本都极其敏感。用十亿参数的小编码器，往往比调百亿参数的大模型更划算，效果还未必差。

问题在于，这些年编码器往前走的路线，更多是借解码器的架构创新，比如旋转位置编码、FlashAttention这类加速和扩上下文的技术。可训练编码器最核心的那一环，也就是掩码语言建模，一直照着BERT时代的老经验来。

掩码语言建模（MLM）*：训练编码器时，先把句子里一部分词换成特殊的[MASK]标记，再让模型靠上下文猜被遮住的词，这个过程逼着模型学会理解语言结构。

这里有个关键参数叫掩码比例，指的是一句话里有多大比例的词被遮住。BERT用的是15%，这个数字从2018年一直用到今天，几乎成了约定俗成的常识。但研究团队发现，此前所有关于最优掩码比例的研究，实验预算都在100亿到1000亿token这个量级。真正的问题在于：那个预算下得出的结论，很可能不是最优，只是收敛最快。

打个比方。让两个学生用不同方法备考，只给一周时间，你测出来的更好的方法，多半只是更快见效的方法，不是长期掌握知识更扎实的方法。要是给一个学期呢？排名说不定就反过来了。研究团队怀疑，过去关于掩码比例的结论，正是被训练时间不够长这种假象误导了。

于是他们做了一件几乎没人做过的事：把编码器训练拉到8.8万亿token的规模，看看充分训练之后真相到底是什么。

训练到头了，但模型没有学傻

第一个实验结果出人意料。研究团队训练了150M和1.3B两种规模的编码器，一路喂到8.8万亿token，同时记录训练损失、验证损失，以及GLUE、SQuAD 2.0、BEIR这些下游任务的表现。

GLUE*：一套综合性的英语语言理解评测基准，包含多种句子分类和推理任务，常被用来衡量编码器的综合语文水平。

BEIR*：一个专门评测零样本检索能力的基准，测试模型在没见过的新领域里找到相关文档的能力。

结果是：训练损失和验证损失一路稳步下降，说明模型确实还在学东西，没有过拟合。可下游任务的分数，大约在1到2万亿token之后就原地不动了，尤其是BEIR检索分数，甚至在2750亿token的第一个检查点之后就没再怎么涨。

这意味着什么？意味着你哪怕再多喂几万亿token，模型的内在语言能力还在精进，但这种精进已经转化不成任何实际可用的下游表现。解码器类大模型的行为完全不同，后者往往训练token越多，各种benchmark表现越好，甚至会出现涌现能力这种随规模突然跃升的现象。

研究团队又做了个对照实验。他们把1.3B编码器和SmolLM2这个1.7B解码器放在一起，用6个常见的多选问答基准测试。在基座模型阶段，也就是没经过指令微调的时候，两者都随着训练token增多而进步，解码器甚至表现出那种典型的涌现式跳跃。可一旦经过指令微调，情况就分化了：解码器继续随token数增长而进步，编码器却又一次撞上那堵看不见的墙，分数稳在某个水平不再上升。

这个发现挺让人深思。它说明编码器和解码器在知识积累这件事上，可能走的是两条完全不同的路。解码器像一个不断往仓库里囤货的商人，仓库越大，能卖的东西越多；编码器更像一个打磨某项具体技能的工匠，熟练度到一定程度之后，继续练带来的边际收益就趋近于零。还按老办法硬喂数据，只是在浪费算力。这也是论文标题里超越BERT预训练极限的第一层含义：先搞清楚极限在哪，才知道该在哪里突破。

掩码比例：分类和检索的拉锯战

既然多喂数据已经没用，那在饱和点之后，还有什么杠杆能撬动性能？答案指向掩码比例本身。

研究团队在150M、380M、1.3B三种规模下，分别用3%、15%、30%、50%四档掩码比例训练编码器。按照先前确定的饱和规律，低比例的训练配置拿到了更多token，因为低掩码比例收敛更慢，要走更久才能到饱和点。

分类任务（GLUE和SQuAD 2.0）的分数，在所有模型规模下都随掩码比例上升而一路走低，结论相当明确。此前有研究主张模型越大、掩码比例就该越高，这次的结果恰好与之相左。研究团队把分歧归因于旧实验的预算不足：收敛快这一长处，把语料被破坏得更厉害这一短处盖住了。训练一旦足够充分，破坏带来的代价才真正暴露出来。

还有个插曲挺有意思。业内流传一种看法：ELECTRA那套训练方式用的是"替换检测"，不靠"遮盖猜词"，天生就在分类任务上占便宜。

替换检测（RTD）*：和MLM不一样，它不遮词，而是先让一个小型生成器把某些词换成看着合理、其实错误的词，再由主模型判断哪些词被动过手脚。

研究团队设了一组精巧的对照实验，把掩码比例和替换比例严格对齐。结果显示，RTD对MLM的优势在掩码比例15%附近最高，往两头走都会收窄。到50%附近，生成器能拿到的上下文太少，换出来的词太容易识破，这种"题目过于简单"对训练没多少帮助；到3%附近，遮盖也好替换也好，句子本身被破坏的程度就很轻，两种方式自然拉不开差距。

更关键的发现在这里：分类任务本来就偏好低掩码比例，而RTD的优势恰好在这个区间不明显。那么编码器守着MLM就够了，没必要为了分类去冒检索能力大幅下滑的风险——已有研究反复证明，RTD训练出来的模型在检索上表现很差。

不过故事没完。分类喜欢低掩码比例，检索呢？

研究团队把目光转向BEIR，趋势完全掉了个头：50%的掩码比例在所有模型规模下都拿到最高的检索分数。为了弄清原因，他们测了模型输出向量的有效秩。

有效秩*：用来衡量一个向量空间实际用上了多少维度，数值越高，说明信息铺得越开，而不是挤在少数几个方向上。

数据表明，掩码比例越高，有效秩越高，两者相关系数达到0.91，属于强相关。道理不难懂：检索靠的是向量空间的可分辨性，如果所有文本的向量都挤在一个狭窄子空间里，语义差得再远，向量距离也拉不开，检索就不准。掩码比例一高，模型被迫在更残缺的信息里做更复杂的推断，这个推断过程客观上让表示空间被用得更充分。

研究团队还想验证因果：能不能跳过"提高掩码比例"，直接用正则化手段把有效秩人为拉高？他们引入了KoLeo正则化器——一种鼓励向量在空间中均匀分布的技术，在6%掩码比例下测试。

结果是：BEIR分数确实涨了，但幅度远不如直接用50%掩码比例；它还反过来拖累了GLUE表现。可见有效秩提升并不是检索性能提升的充分条件，掩码比例带来的改变，比单纯"让向量分布更均匀"要复杂得多，它可能同时改掉了模型学习语义表示的整套方式。

这个发现把研究团队逼到了两难：分类要低掩码比例，检索要高掩码比例，正则化这种"走捷径"的路又走不通，难道只能二选一？

两个LM头，一场内部的"井水不犯河水"

研究团队下一步的推理很关键。两种任务需要两种截然不同的训练信号，那能不能把两种信号同时喂给模型，让模型自己去协调？这其实就是多任务学习的经典思路——把每个掩码比例当成一个独立"任务"去联合优化。

他们先试了两种常见做法：一是让掩码比例随训练从50%逐渐衰减到6%或15%；二是每个批次里从5%到50%之间随机采样掩码比例。结果都不理想，衰减策略在GLUE上甚至比单一低比例训练还差，随机采样的效果基本等同于用一个折中的平均比例（比如27.5%左右）去训练，哪头都没讨到好。

研究团队由此得到一条关键提醒：掩码比例的“混合”一旦没处理好，结果就会掉到“平均值”上；而平均值这个位置，恰恰两头都不占优，十分尴尬。

那问题出在哪？他们把输入词嵌入矩阵和语言模型头（LM头）的几何结构画出来做了对比。

LM头*：编码器的最后一层，负责把模型的内部表示转换成对每个词的预测概率，训练时真正产生"猜词对错"信号的地方就是它。

结果发现，6%和50%掩码比例训练出来的模型，输入嵌入几乎一模一样，LM头的形状却天差地别——6%训练出来的LM头奇异值更集中，占据的是一个更低维的子空间；50%训练出来的LM头则铺得更开。

这说明冲突的根源不在模型的"输入理解"，而在"输出预测"：两种掩码比例要求模型用完全不同的方式组织预测逻辑，一旦共用同一个LM头，两套逻辑就互相拉扯，谁也做不彻底。

好比让同一个人同时兼两份性质完全相反的工作：一份是精修细节的校对员，一份是快速扫描全局的巡检员。公司非要他用同一套流程、同一张办公桌处理两份活儿，他大概率两头都做不精，因为两份工作需要的注意力分配方式根本不同。不做区分、硬把两份活儿混着干，结果就是校对出错率上升、巡检也漏东西，正是前面"随机采样"实验里那种"平均值陷阱"。反过来，给他配两张不同的办公桌，分别处理两类任务、互不干扰，效果反而会好很多。

研究团队由此提出LM头解耦方案：每个训练批次里同时混入5%掩码和50%掩码的句子（比例4:1，因为低掩码比例收敛更慢，需要更多样本量来补偿），但两种掩码比例各配一个独立的LM头，互不干涉。

实验结果验证了这个判断：解耦后的模型在GLUE上拿到89.4分，在BEIR上拿到45.1分，几乎同时逼近单独用6%训练（89.5分）和单独用50%训练（45.0分）的最佳水平。不做解耦的话，GLUE只能停在88.9分，相当于单一15%掩码训练的水平。这个对比很说明问题：共享一个LM头，哪怕喂进去再多高掩码比例的数据，分类任务也占不到什么便宜。

研究团队再次画出解耦后两个LM头的几何结构，果然，5%那个头和50%那个头呈现出截然不同的分布形态。这印证了他们最初的判断：冲突确实发生在LM头这一层，而解耦确实把这个结解开了。

蒸馏不是万能药，但用对地方就是神器

掩码比例的矛盾解决之后，研究团队又往前推了一步。他们想弄清楚：知识蒸馏能不能让小模型学到更大模型的本事，把小模型自己的上限再抬高一些？

所谓知识蒸馏，就是拿一个已经训练好的大模型当教师，去带一个小模型当学生。学生通常不只看标准答案，还要去拟合教师输出的概率分布，这样一来，能拿到的信息比标准答案本身要丰富得多。

模型剪枝则是另一条路：把训练好的大模型里的部分参数直接裁掉，换来个头更小的模型，再接着训练，让性能恢复甚至往上走。这种做法往往比从零训练一个小模型效果更好。

解码器那边，这条路已经走得很熟了。Llama、Gemma这些知名模型系列都试过"剪枝+蒸馏"的组合拳。可研究团队发现，同样的方法挪到编码器上，照搬并不一定能成。

他们先把训练好的1.3B编码器剪到380M，再让1.3B模型当教师来做蒸馏，在15%和50%两种掩码比例下分别测试。结果分化得很明显：15%掩码比例下，蒸馏确实有用，GLUE从90.2分升到90.8分，这也印证了"低掩码比例利好分类"的规律；可到了50%掩码比例，蒸馏后的模型在BEIR上反倒从47.2分滑到46.5分，比从零训练还差。

这个结果让研究团队有些意外，他们本来以为蒸馏至少是"稳赚不赔"的。仔细分析之后，他们推测问题出在教师模型身上：高掩码比例下，教师给出的信号本身就比较"水"。句子被遮掉一半时，教师自己都很难做出有区分度的预测，这种模糊的监督传给学生，很可能变成一种噪声。这和前面RTD在高掩码比例下失灵的原因有点像——信息破坏得太厉害，老师也教不出什么有营养的东西。

想明白这一点，研究团队做了一个克制又精准的选择：蒸馏的KL散度损失只在低掩码比例（也就是5%那部分数据）上用，高掩码比例（50%那部分）继续走标准MLM损失，不引入教师信号。

LM头解耦，加上有选择性的蒸馏，这两招合在一起，构成了UltraBERT最终训练方案的核心骨架。

UltraBERT：一场系统性整合的最终答卷

把前面这些发现拼起来，UltraBERT的训练流程就清楚了：先训一个1.3B的教师模型，再通过剪枝压到380M，继续剪枝压到150M；每个训练批次里，5%和50%掩码的句子按4:1混合，分别喂给各自独立的LM头；5%掩码那部分接受1.3B教师的KL散度蒸馏，50%掩码那部分用标准MLM损失训练；整个过程吃了2万亿token，并且原生支持32K长上下文。

最终成绩体现在Table 3里，UltraBERT在几乎所有基准上都拿到最佳或接近最佳。150M这个"基础版"量级上，它GLUE拿到89.5分，SQuAD 2.0的F1分数为89.2，BEIR拿到45.2分，只有在MultiCoNER v2这个命名实体识别任务上略输给最强基线，但仍超过了ModernBERT和Ettin Encoder。

380M这个"中等版"量级里，UltraBERT拿下GLUE 91.0分、BEIR 47.7分，几乎横扫所有子项，唯一的例外是在MLDR长文档检索上略微落后于LFM2.5-Encoder-350M。

和代码、数学检索相关的RAR-b基准更能说明问题。基础版上，UltraBERT的代码检索得分39.1，数学检索55.4，相比第二名分别领先7.3分和8.3分；中等版上领先得更多，代码检索高出8.4分，数学检索高出7.7分。这说明UltraBERT学到的语义表示跨领域泛化能力更强，并不是只在训练过的领域里打转。

长上下文方面的差距同样明显。研究团队专门用LongEmbed基准来测模型在超长文档里"大海捞针"的能力，结果发现：那些原生上下文只有512或8192 token的模型，一旦文档长度超过自己的训练上下文，表现就断崖式下跌。UltraBERT靠原生32K上下文的设计，在所有长度（从256到32768 token）上都保持99%以上的准确率，是唯一做到这一点的模型。直观图表里这个结果特别震撼：其他模型的曲线在超过自己上下文长度那一刻集体跳水，只有UltraBERT的曲线像一条平直的绿线一路横到底。

表格里最耐人寻味的一点是，纵览所有基线模型，没有一个能在所有任务类别上都占第一。Ettin Encoder在GLUE、SQuAD 2.0和RewardBench上最强，NomicBERT、RoBERTa、GTE-en-MLM轮流在NER任务上领先，ModernBERT和LFM2.5-Encoder则分别是检索基准上的佼佼者。每个模型都像某个单项的冠军，但没有一个全能选手。UltraBERT是这篇论文里唯一在两大类任务上都站上顶点的模型，而且两种参数规模下都做到了。

"全面领先"的背后，其实是研究团队不肯接受"编码器天生就得在分类和检索之间做取舍"这个行业默认设定。他们没有去堆更多参数或更多数据——事实上论文开篇就证明了堆数据在饱和点之后毫无意义——而是精确诊断出矛盾发生的具体位置（LM头的几何冲突），再用一个足够精巧的工程方案（头解耦+选择性蒸馏）把它化解掉。

论文出来后，顺着往下想，有一条路挺自然：既然掩码比例这层冲突能靠解耦的LM头拆开，那别的训练目标之间打架，比如多语言和单语言、长文本和短文本，是不是也能照“分开走、共用主干”的办法来处理？眼下的多语言编码器研究，像mmBERT，也已经在试“把不同训练信号隔开”这类做法。切入的角度未必一样，思路却对得上：与其逼着一个模型拿同一套参数去扛所有互相矛盾的目标，不如在要紧的瓶颈处拆得细一点，让模型里面长出一批各管一摊、又能配合的子系统。

写在后面

读完这篇论文，最让我意外的其实不是UltraBERT最终的分数，而是那个"8.8万亿token"的饱和实验。

长期以来，大家已经习惯“模型能力靠数据堆出来”这套说法，甚至默认只要给语言模型多喂数据，它就会越来越强。可这篇论文用扎实的实验说明，至少在编码器上，这个直觉并不成立：损失仍在下降，下游表现却早已停住。这提醒人们，损失曲线往下走，并不等于模型在学你真正在意的那件事，它可能只是在某个与下游任务无关的维度上继续精进。这个教训放到别处同样成立——凡是用代理指标（比如损失）去衡量真实目标（比如实际任务表现）的场合，都可能踩进这种“假性进步”的陷阱。

还有一个细节让人反复琢磨，就是CoLA这个语法可接受性判断任务，在附录里被单独拿出来讨论。研究团队发现，只要让模型做100亿token的RTD训练，CoLA分数就能跳涨将近10个百分点，其他任务却几乎纹丝不动。这说明CoLA这个“经典”评测任务，测的可能压根不是“模型有多聪明”，而是“模型的预训练目标和这个任务的评判逻辑有多像”。这个提醒值得警惕：我们拿来评判AI模型能力的基准测试，本身也可能暗藏某种“题型偏好”，并不是纯粹的能力刻度尺。

论文没有回答的问题是：LM头解耦这个思路，能不能扩展到两个以上的训练目标？如果以后要同时兼顾分类、检索、长文本、多语言四个维度，是不是得配四个甚至更多独立的头？这种解耦会不会在维度数量越过某个点之后失控，变成参数冗余的黑洞？这大概是留给后续研究者的下一道题。

Q&A

Q1：UltraBERT是什么？

UltraBERT由韩国高丽大学团队打造，是一种双向编码器模型，参数规模分为150M和380M两档；该模型重做了掩码语言建模的训练策略，结果在文本分类和语义检索两类任务上同时拿到业界最佳，属首次。

Q2：UltraBERT为什么能同时做好分类和检索？

问题出在共享LM头：研究团队发现，低掩码比例对分类有利，高掩码比例对检索有利，两者共用同一个LM头就会内部打架。UltraBERT的解法是给两种掩码比例分别配一个独立LM头，并且只对低掩码比例那部分做知识蒸馏，矛盾就此化解。

Q3：编码器预训练是不是训练数据越多越好？

答案是否定的。论文实验表明，编码器训练到1到2万亿token上下，下游任务表现就饱和了；训练损失和验证损失还在往下走，继续加数据也换不来实际任务效果的提升。这一点和解码器大模型越喂数据越受益的规律不一样。