最近“某度雷霆AI让用户用BERT”的讨论热度很高。很多人看到这个标题就觉得是在开倒车：都大模型时代了，怎么还让用户用BERT？但这件事真正值得讨论的，不是“某度”有没有水平，而是传统预训练模型在AI应用里到底还有没有位置、该不该被淘汰。
先说明立场：我不了解这个系统的完整设计，也没拿到它的评测数据。所以下面不站队，只把工程选型的思路拆开讲。你会发现，对一个产品负责的工程师来说，“用BERT”和“用大模型”不是先进和落后的对立，而是两种约束条件不同的技术方案。
如果你最近正在做AI应用开发、本地部署AI，或者准备把已有模型做一次替换评估，下面这些内容可以提供一套可参考的检查清单。最值得关注的，不是别人怎么评价某个系统，而是你的任务、数据、延迟和成本到底更适合哪套方案。
1. 这场争议真正想表达的，不是“BERT落后了”
1.1 先理清：BERT和LLM到底差在哪
BERT是Google在2018年提出的预训练语言模型，采用Transformer的Encoder结构。它的核心能力是“理解”：给一段文本，输出一个向量，或者接一个分类层，判断这段文本属于哪个类别、实体在哪里、语义是否相似。它不擅长从头生成一段自然语言。
LLM，也就是大语言模型，是Decoder结构，核心能力是“生成”：给定指令和上下文，输出新的文本。ChatGPT类的产品、AI Agent、AI编程助手，底层都是这种生成式模型。
这两种结构差异决定了它们适合的任务完全不同。很多人把“BERT不如LLM”理解成“BERT落后了”，其实是在拿两个不同物种做比较。BERT是一把手术刀，适合精准分类；LLM是一台多功能机床，能加工复杂工件，但启动成本、耗电、操作门槛都高得多。
1.2 为什么“让用户用BERT”会引发反感
因为普通用户感知到的AI，是“能对话、能写文案、能生成图片”的生成式AI。如果某个产品号称AI，结果用户拿到手发现只能做分类、打标签，自然会觉得名不副实。这是产品预期问题，不是模型能力问题。
还有一种可能性是产品团队并没有认真评估，只是把之前某个LLM方案简单换成BERT，导致功能倒退、交互变差。这种“为了降成本而降成本”的做法，确实值得批评。
但反过来也要看到另一个可能：有些业务本身就是短文本分类、垃圾信息识别、实体抽取，这类任务用BERT反而比大模型更稳。如果产品原来就不需要生成，那么用BERT并不丢人。
1.3 锐评的正确方式：先列约束，再下结论
我在实测和项目评审里有一个习惯：不先争论模型好坏，而是先把需求拆成一张表格。下面这组问题可以拿来作为初始判断：
| 判断维度 | 偏向BERT | 偏向LLM |
|---|---|---|
| 任务类型 | 分类、抽取、匹配、判断 | 开放生成、问答、文案、推理 |
| 输出形式 | 固定标签或离散片段 | 自然语言、代码、结构化文本 |
| 实时性 | 毫秒级在线请求 | 秒级甚至更长响应 |
| 成本敏感 | 高并发、按量付费敏感 | 低频调用、可接受token费用 |
| 数据隐私 | 必须本地化部署 | 可接受外部API或私有化大模型 |
这张表不解决所有问题，但能很快排除错误方向。如果一个需求是“实时拦截违规评论”，用BERT加规则完全够用；如果一个需求是“根据用户描述写一封英文邮件”，BERT不方便做，LLM更合适。
2. 说句公道话：这些场景用BERT确实更合理
2.1 分类与抽取类任务，BERT的优势超过很多人想象
我做过一个关键词过滤系统，最初用大模型API判断一条评论是否违规，每千次请求成本就不低，而且偶尔会出现漏判、误判。后来改成BERT微调模型，只在非常模糊的案例里再让大模型兜底，整体效果更稳定。
原因是这类任务有明确标签边界。BERT的输出被严格限制在预设的类别里，不存在“自由发挥”。大模型虽然也能判断，但它本质是生成式模型，同一个提示词可能产生不同结果，这就叫AI幻觉。对审核、合规、风控场景来说，不可控的输出是不可接受的。
实体抽取也一样。拿一批病历文本做症状、药品、检查项目抽取，BERT类模型可以给出稳定的标注结果，配合规则修正后，准确率在不少数据集上已经够用。用大模型做抽取，效果可能更好，但需要设计prompt、做few-shot校验、处理输出格式错误，时间成本一点不低。
2.2 高并发、低延迟、本地部署，BERT更能扛
BERT-base中文模型的大小一般在400MB左右，不带大词表时实际部署占用可以再压缩。即使没有GPU，用CPU做单条短文本分类，延迟也常常能控制在几十毫秒。如果做量化或蒸馏，可以降到更低。
大模型走外部API调用时，网络延迟和生成token数会直接影响响应时间。即使大模型私有化部署，也需要至少一块中高端GPU，显存占用不是普通服务器能承受的。对高并发的线上场景，一个纯BERT服务的成本要低一个数量级。
这也是“本地部署AI”这个需求里，BERT仍然很有生命力的原因。很多企业内部系统不允许把数据传到外部服务，但自己搭一个7B、13B大模型又缺硬件。这时候在一个普通CPU服务器上跑BERT分类器，是性价比最高的方案。
2.3 对中小团队和数据量不够大的项目，BERT是更现实的起点
微调一个大模型需要多卡GPU、大量数据和比较长的训练周期。而微调一个BERT分类器，准备几千条样本，用一张普通GPU（甚至CPU）也能训练几个小时到一晚上。很多AI应用开发项目其实只需要一个能用的意图分类器，不需要写报告、写代码。
我建议中小团队不要一上来就做“全场景大模型”。可以先评估一下：任务是不是必须生成？如果是，再考虑LLM；如果不是，先用BERT跑通，再逐步替换到更复杂的方案。这不是倒退，而是按需求选型。
3. 如果业务要从LLM换回BERT，具体怎么落地
3.1 第一步：把任务拆成“理解型”和“生成型”
无论你现在被要求从LLM换回BERT，还是想从BERT迁到LLM，第一步都是把线上功能拆开看。一个看起来必须用LLM的功能，里面往往混着很多小任务。
比如一个AI客服助手，用户问“怎么退款”。大模型最终生成一段完整回答，这是生成型。但在生成之前，系统需要先判断用户意图是退款还是物流，这就是理解型。判断意图可以用BERT，生成回答才需要LLM。如果整个链路全部交给LLM，成本会高很多，延迟也明显。
拆任务时拿一张纸把功能点列出来，每个点标注是“理解”还是“生成”。只有生成部分才需要认真考虑LLM；理解部分可以评估是否用BERT。
3.2 第二步：准备数据与评估集
要让BERT替代LLM，前提是有足够的标注数据。不是随便拿几条样例就能微调。我一般建议先准备三类数据：
- 训练集：覆盖各类别和表达方式，至少几千条，类别多时再加。
- 验证集：用于调整超参数和观察收敛情况。
- 测试集：模型训练完后独立评估，不能和训练集重叠。
数据格式很简单：一条文本，一个标签。例如：
{"text": "怎么申请退款", "label": "after_sale"} {"text": "我的快递到哪了", "label": "logistics"}如果原始数据里没有标签，可以先写规则或让大模型辅助标注一批，再人工审核。不能直接拿LLM生成的数据当金标准，因为LLM也会出错。
3.3 第三步：微调一个BERT分类模型
当前常用做法是用transformers库加载预训练模型，然后接一个分类头。以中文短文本意图分类为例，代码骨架大致如下：
from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments model_name = "bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=4)注意这里只是示例代码，实际训练前要把tokenizer和model都加载好，然后把训练数据转成模型需要的格式。训练参数中，最需要关注的是学习率、batch size和epoch数量。
我的经验是：不要一上来就把batch size拉满。先设一个较小值，比如8或16，确认显存不爆，再慢慢往上加。学习率常用2e-5到5e-5，epoch一般取3到5，具体要看验证集指标。
3.4 第四步：用真实指标判断是否达到替换标准
替换不是“模型能跑就行”。至少要对比四个指标：
| 指标 | 替换前（LLM方案） | 替换后（BERT方案） | 是否达标 |
|---|---|---|---|
| P99响应时间 | 看日志统计 | 压测得到 | < 业务要求 |
| 单次调用成本 | API账单 | 服务器均摊 | 明显下降 |
| 准确率/召回率 | 抽样评估 | 测试集F1 | 不低于阈值 |
| 失败率/超时率 | 统计 | 压测和线上观察 | 不超目标 |
如果准确率下降，但成本和延迟大幅下降，可以再评估是否值得。如果分类效果差太多，说明任务不适合纯BERT，需要保留LLM或做混合。
4. 别把BERT和LLM对立，真正高级的是“混合路由”
4.1 为什么需要模型路由
很多团队用的是“所有请求都发给LLM”的最简单方案。好处是开发快，坏处是贵、慢、波动大。尤其当业务里混着大量简单询问时，全部让大模型处理，属于资源浪费。
模型路由的思路是：先请求一个轻量模型判断请求类型，再根据类型分发到不同处理模块。这个轻量模型可以就是BERT。比如先判断这条请求是FAQ查询、情绪表达还是投诉，然后决定走规则、走知识库检索，还是调用LLM生成回答。
4.2 典型混合架构怎么搭
用文字描述一条链路：
- 用户请求进入网关，先做基础校验和清洗。
- BERT分类器识别意图，计算每个意图的置信度。
- 置信度高，且属于“简单意图”，直接走对应服务，不调用LLM。
- 置信度低或属于“复杂生成”，才路由到LLM。
- 所有结果写日志，后续用真实数据做模型迭代。
这样既保留了大模型的生成能力，又把成本控制住。很多AI应用开发里，“AI Agent”也是类似结构：Agent本体用大模型负责规划，但工具选择、文本分类、结果校验这些步骤可以交给小模型做，减少token消耗。
4.3 混合架构需要注意什么
第一个坑是路由阈值调不好。阈值太高，简单请求也跑到LLM；阈值太低，复杂请求被BERT误判。建议先做小流量实验，记录两个模型的预测结果，再选一个平衡点。
第二个坑是日志统计没做好。没有日志，你根本不知道一个请求为什么走错了路。我一般会在路由层加一个字段，记录“模型选择、置信度、耗时、成本估算”，上线后每天看一次分布。
第三个坑是过度设计。如果业务请求量不大，一天只有几百次，用混合路由反而增加维护成本。这种情况下直接用LLM也可能更划算。选型要按数据说话，不要为了“架构高级”而做复杂系统。
5. 判断该用哪个模型的五个关键指标
5.1 单次请求成本
按token付费的LLM，单次成本与输入长度、输出长度正相关。BERT部署在自己的服务器上，成本主要由机器折旧、运维和推理负载构成。日常百万级请求的业务里，BERT方案会便宜很多；日请求量很低时，差异不明显。
5.2 延迟与并发
BERT用CPU也可以做到几十毫秒分类，开多个worker后并发能力不错。LLM生成式推理更依赖GPU，响应时间受输出token数量影响。在线客服、审核、搜索排序这类对延迟敏感的任务，小模型有天然优势。
5.3 输出可控性与幻觉
BERT输出的是标签或固定字段，不会生成不存在的内容。LLM输出是开放式文本，可能出现幻觉、格式不稳定、敏感内容。如果业务对输出边界要求严格，先用BERT做一层约束是更稳妥的工程做法。
5.4 可维护性与迭代成本
BERT需要自己处理数据标注、微调、评估、部署、版本管理。LLM则把模型训练交给厂商或基础模型团队，但你需要设计和维护prompt、few-shot样本、调用API的容错逻辑。两者都有维护成本，只是内容不同。
5.5 数据隐私与合规
有些业务的数据不能出域。如果选外部LLM API，需要确认数据是否会被保存、是否满足合规要求。BERT可以完全内网部署，数据不出服务器。这是很多政企项目仍然坚持用传统预训练模型的主要原因。
6. BERT实际部署中常见的坑和排查清单
6.1 输入长度限制
BERT的输入长度通常限制在512个token，中文大概几百个字。处理长文档时，直接截断会丢失关键信息。可以在截断前先判断重点在哪一段，或用滑窗方式分段预测，再聚合结果。这类问题在从LLM切换回BERT时尤其常见，因为LLM可以接收更长上下文。
6.2 标签不均衡
真实业务里很多标签天然不均衡，比如违规内容只占1%。如果只看准确率，模型可能把所有样本都判成“正常”，准确率也会很高，但实际没有价值。训练时要用F1、召回率，重点是少数类的表现。可以尝试类别加权采样、数据增强或增加少数类样本。
6.3 输出格式与产品交互不匹配
LLM返回的是自然语言，用户可以看懂。BERT返回的是数字标签，还需要映射成前端提示文案。换模型不能只改后端接口，产品文案、用户提示、兜底逻辑都要重新设计。很多“模型替换”项目卡住，不是模型跑不起来，而是交互没有同步改造。
6.4 排查顺序
如果换了BERT后效果差，按这个顺序排查：
- 输入文本编码是否正确，有没有乱码和错别字。
- 分词是否用了与模型匹配的tokenizer。
- 有没有做长度截断，截断位置是否合理。
- 数据标注是否一致，是否有歧义标签。
- 训练和验证集评估指标是否正常。
- 部署推理时有没有开启批量模式，会不会OOM。
大多数问题不是BERT不行，而是输入、数据或部署环境没处理好。遇到问题先看日志，再改参数，不要一上来就怀疑模型能力。
最后，回到“某度雷霆AI让用户用BERT”的讨论。我认为真正值得吸取的经验是：技术选型别只看热度，要看业务约束。BERT不是万能解药，LLM也不是包治百病。如果你正面临“所有请求都塞给大模型”和“全部换回BERT”两个极端，建议各留一条路，用路由机制把简单任务和复杂任务分开处理。先用小样本跑通，再做A/B测试，最后用数据决定去留。这个流程，比单纯锐评某个系统有用得多。
