UltraBERT：当BERT训练到极限，分类和检索终于不用二选一

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在高掩码比例下失效的原因有些相似,信息被破坏得太厉害，就算是老师也教不出什么有营养的东西。

于是研究团队做出了一个克制而精准的决定：只在低掩码比例（也就是5%那部分数据）上应用蒸馏的KL散度损失，高掩码比例（50%那部分）继续用标准的MLM损失训练，不引入教师信号。

这套组合拳,LM头解耦加上有选择性的蒸馏,就是UltraBERT最终训练方案的核心骨架。

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

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

最终结果体现在Table 3里，UltraBERT在几乎所有基准上都拿到了最佳或接近最佳的成绩。在150M这个"基础版"量级里，它在GLUE拿到89.5分，SQuAD 2.0拿到89.2的F1分数，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是什么？

A：UltraBERT是韩国高丽大学团队提出的一种双向编码器模型，提供150M和380M两种参数规模，通过重新设计掩码语言建模的训练策略，首次在文本分类和语义检索两类任务上同时达到业界最佳水平。

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

A：因为研究团队发现低掩码比例利好分类、高掩码比例利好检索，这两者在共享LM头时会产生内部冲突。UltraBERT给两种掩码比例各配一个独立的LM头，并只对低掩码比例部分做知识蒸馏，从而化解了这个矛盾。

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

A：不是。论文实验显示，编码器在训练到1到2万亿token左右时，下游任务表现就会饱和，即使训练损失和验证损失继续下降，再多喂数据也无法进一步提升实际任务效果，这和解码器大模型持续受益于更多数据的规律不同。