最近“某度雷霆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_labels4)注意这里只是示例代码实际训练前要把tokenizer和model都加载好然后把训练数据转成模型需要的格式。训练参数中最需要关注的是学习率、batch size和epoch数量。我的经验是不要一上来就把batch size拉满。先设一个较小值比如8或16确认显存不爆再慢慢往上加。学习率常用2e-5到5e-5epoch一般取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测试最后用数据决定去留。这个流程比单纯锐评某个系统有用得多。
