BERT 编码器模型并未消亡：分类和抽取仍是主场

在分类、检索和跨度抽取任务上，在这场助手竞赛中落败的 Transformer 仍然是正确答案。这并非仅仅因为它更便宜——尽管确实便宜得多——而是因为对于这些工作，它计算出的答案具有不同的形态。

两个结构差异

一次遍历，而非循环。编码器在单次前向传播中双向读取整个输入，并产生固定大小的输出：类别分布、向量或每个 token 对应的标签。生成式模型必须先预填充输入，然后逐个 token 解码出答案，由此带来的延迟和方差问题随之而来。

偏移量，而非字符串。这一点是正确性层面的差异，理应得到更多关注。要求编码器在一份合同中找出公司名称，它会为 token 打标签，这样你就知道每个匹配项的字符跨度。要求生成式模型来做这件事，它返回的是一个字符串，你必须再将其在源文本中定位——这是一种模糊匹配，在你最在意的精确场景中会失败：模型规范化了大小写、展开了缩写或悄悄修正了拼写错误。对于需要指向原始文档的标注、高亮、注释或任何操作，编码器给你的东西在结构上是生成式模型根本无法提供的。

另外三个特性随之而来：输出是确定性的，类别概率可以直接获取，并且可以根据标注数据进行校准，模型可以在单个 GPU 上用几千个示例进行微调。

算术分析，附带假设

BERT-base 有 1.1 亿参数（Devlin et al., 2018）。将其与一个 70 亿参数的解码器在 200 个 token 输入、输出 5 个 token 的一次分类任务上进行比较，使用本系列其他文章中相同的"每 token 每参数 2 次 FLOPs"近似算法。

assumption: forward cost ~= 2N FLOPs per token; attention's quadratic
term ignored; batching, memory bandwidth and overheads ignored.

encoder  (110M):  200 tokens x 2 x 1.1e8   = 4.4e10 FLOPs, one pass
decoder  (7B):    prefill 200 x 2 x 7e9    = 2.8e12
                + decode    5 x 2 x 7e9    = 7.0e10
                                           = 2.87e12 FLOPs

ratio: about 65x more arithmetic for the generative call.

这个数字有两个注意事项，因为撇开它们不谈会产生误导。实际的服务成本往往受内存带宽和批处理效率约束，而非 FLOPs，因此实际时钟时间和价格比例不会与这个数字完全吻合。而且五个解码步骤带来的延迟代价与其 FLOPs 不成比例，因为每一步都是独立的顺序传递。算术给出的是数量级和方向；你自己的测量给出的是具体数字。

当规模介入时，这就不再是抽象概念了。每天一百次分类，这里什么都没必要考虑，你应该用最快能跑起来的。每天一千万次分类，65 倍的算力差异就是"一行项目"与"一个项目"的差别。

部署上的影响比这个比例暗示的更大。这个规模的模型可以装进普通内存，在 CPU 上运行效果也不错，因此可以嵌入在需要它的服务里——没有 GPU 池、没有外部调用、没有速率限制、没有每次请求的网络跳转，延迟分布的尾部很薄，因为既没有队列也没有冷启动需要消化。对于同步路径上的分类会阻塞用户操作的场景，这改变的是架构上可能性，而不仅仅是成本可负担性。

这类模型决定胜负的场景

高容量固定标签分类。内容审核、意图路由、垃圾信息、语言识别、工单分类。标签集是稳定的，你有或者可以低成本获取训练数据。

Embedding 和检索。几乎所有生产环境的 embedding 模型都是编码器，因为单次双向传递产生一个向量正是所需的形态——参见 embedding 和选择 embedding 模型。

重排序。交叉编码器通过同时读取查询-文档对来打分，这比比较两个独立计算的向量更准确，而且对于候选列表运行足够便宜——晚交互模型介于两者之间。

跨度抽取。命名实体、PII 检测、条款识别——任何需要偏移量的任务，参见上面的论证。

蕴含检查。回答"这段文字支持这个主张吗？"的自然语言推理模型，是可信流水线的一个快速、确定性的护栏。

这个家族也仍在活跃开发中，这出乎以为它已在 2019 年就终结了的人意料：RoBERTa（Liu et al., 2019）和 DeBERTa（He et al., 2020）改进了原始配方，ModernBERT（Warner et al., 2024）带来了现代化的编码器，具有长得多的上下文和当前的架构选择。

生成式模型全面胜出的场景

任何开放性任务。任何还不存在或者每周都会变化的标签集——解码器用提示中的一个句子就能处理新类别，编码器需要标注示例和一次训练。任何需要对输入进行跨文本推理而非模式识别的工作。还有没有任何标注数据且没有预算去制作的情况，这是最常见的场景，也是如此多的流水线端到端使用生成式的诚实原因。

两者结合使用的模式

最优的组合方式：用生成式模型标注几千个示例，人工审查一个样本，用结果训练一个编码器，在高容量路径上服务编码器，将生成式模型保留处理不确定的尾部。这就是蒸馏最实用的形式，它将每次请求的成本转化为一次性的成本。

尾部的路由规则来自编码器自身的类别概率：自信的预测在本地服务，低置信度的十分位交给更大的模型。在关键地方保持准确，只在一小部分流量上支付生成式模型的价格。