企业官网建设流程全解析

1. 从标题说起：为什么BERT和GPT值得放在一起反复讲

“Transformer BERT 与 GPT（五）”这个标题，一看就是系列内容的第五篇。能写到第五篇，说明前面四篇已经把Transformer的基础架构、自注意力机制、BERT的预训练范式、GPT的自回归生成路线讲得差不多了。到了第五篇，通常要处理的是更“硬”的东西——要么是两者的深度对比与选型逻辑，要么是微调策略的差异，要么是实际落地时的工程化问题。

我自己在带团队做NLP项目的时候，最常被问到的问题就是：“到底该用BERT还是GPT？”这个问题看似简单，但背后牵扯的东西特别多：任务类型、数据量、算力预算、推理延迟要求、部署环境、甚至团队的技术栈熟悉程度。很多人上来就说“GPT生成强，BERT理解强”，这话没错，但太粗了。真正做项目的时候，你需要知道的是：什么任务下BERT的微调成本更低？什么场景下GPT的few-shot能力可以省掉大量标注？两者的tokenizer差异会对中文任务产生什么影响？这些问题不搞清楚，选型就是拍脑袋。

这篇内容适合谁看？如果你已经了解Transformer的基本结构，知道self-attention是怎么回事，也跑过至少一个BERT或GPT的demo，那这篇就是给你准备的。我会把两者在架构设计、训练目标、微调方式、推理特性、工程落地这几个维度上的差异掰开揉碎讲清楚，并且给出可以直接参考的选型决策表和实操建议。如果你是完全的新手，建议先补一下前四篇的基础内容，否则有些地方可能会觉得跳。

2. 架构层面的核心分歧：编码器与解码器的路线之争

2.1 编码器堆叠与解码器堆叠的本质差异

BERT用的是Transformer的编码器部分，GPT用的是解码器部分。这个大家都知道，但“编码器”和“解码器”到底差在哪，很多人其实说不清楚。

编码器的核心是双向注意力。也就是说，在处理一个token的时候，它可以同时看到左边和右边的所有token。这让BERT特别擅长理解上下文——比如“苹果”这个词，在“我吃了一个苹果”和“苹果发布了新手机”这两句话里，编码器能根据两侧的信息给出不同的表示。这种双向性是通过attention mask实现的：编码器的mask只屏蔽padding位置，不屏蔽未来位置。

解码器就不一样了。GPT用的是因果注意力，也就是每个token只能看到它左边的token，右边的全部被mask掉。这个设计是为了做自回归生成——你预测下一个词的时候，不能偷看后面的答案。所以GPT的训练目标是“给定前n个token，预测第n+1个token”，这天然就是一个生成式的框架。

我经常用一个类比来解释：BERT像是一个阅读理解高手，它可以把一篇文章的每个角落都看一遍，然后回答关于这篇文章的问题；GPT像是一个接话高手，你给它上半句，它给你补下半句，而且补得越来越像人话。

2.2 注意力mask的实操细节

在实际写代码的时候，这个差异体现在attention mask的构造上。BERT的mask很简单，就是padding mask，形状是[batch_size, seq_len]，1表示真实token，0表示padding。GPT的mask是因果mask，通常是一个下三角矩阵，形状是[seq_len, seq_len]，对角线及以下为1，以上为0。

如果你用HuggingFace的transformers库，这些细节都被封装好了。但如果你想自己从零实现一遍，或者想改一些底层逻辑，就必须要搞清楚。我见过有同学在微调BERT的时候不小心把attention mask搞成了因果mask，结果模型性能直接掉了一大截，排查了半天才发现是mask的问题。

注意：BERT的attention mask是padding mask，GPT的是causal mask。两者不能混用。如果你在做序列到序列的任务，比如翻译或摘要，那用的是encoder-decoder架构，mask的构造又不一样，编码器用padding mask，解码器用causal mask加cross-attention。

2.3 位置编码的处理方式

BERT用的是可学习的位置嵌入，也就是说位置信息是通过训练学出来的。GPT早期版本用的是可学习的位置嵌入，但到了GPT-2之后，很多实现改用了正弦位置编码或者相对位置编码。这个差异在长文本任务上会有影响：可学习的位置嵌入在超出训练长度时表现会急剧下降，而正弦编码理论上可以外推到更长的序列，虽然实际效果也会衰减。

我在做一个长文档分类任务的时候，就遇到过这个问题。当时用的BERT模型最大长度是512，但有些文档超过2000个token。直接截断会丢信息，分段处理又会丢失跨段落的依赖。后来换了一个支持长序列的编码器模型，同时调整了位置编码的方式，才把效果拉回来。所以如果你要处理长文本，位置编码的方案一定要提前考虑。

3. 预训练目标的根本不同：MLM与CLM

3.1 掩码语言模型的训练逻辑

BERT的预训练目标是Masked Language Model，简称MLM。具体做法是：随机把输入序列中15%的token替换成[MASK]，然后让模型去预测这些被mask掉的token。这个任务迫使模型学会利用双向上下文来推断缺失的信息。

这里有个细节：15%被选中的token里，并不是全部替换成[MASK]。实际做法是80%替换成[MASK]，10%替换成随机token，10%保持不变。为什么要这么做？因为如果全部替换成[MASK]，模型只在看到[MASK]的时候才去预测，而微调阶段根本没有[MASK]这个token，会导致预训练和微调之间的不一致。加入随机token和保持不变的情况，是为了让模型在任何输入下都保持一定的预测能力。

MLM的缺点也很明显：训练效率低。因为每次只预测15%的token，模型收敛需要更多的训练步数。而且[MASK]这个token在微调阶段不会出现，造成了一定的浪费。

3.2 因果语言模型的训练逻辑

GPT用的是Causal Language Model，简称CLM。训练目标很简单：给定前面的token，预测下一个token。整个序列的每个位置都参与预测，没有mask掉任何位置。这意味着GPT的训练信号比BERT密集得多，每个token都是一个训练样本。

CLM的优势在于训练效率高，而且天然适合生成任务。但它的缺点是只能利用单向上下文，对于需要双向理解的任务，比如情感分类、命名实体识别，效果可能不如BERT。

我自己的经验是：如果你手头有大量无标注文本，想做一个通用底座，然后微调到各种理解任务上，BERT的MLM是更合适的选择；如果你想做一个对话系统或者文本生成工具，GPT的CLM是更自然的路线。

3.3 两种目标的实际训练成本对比

从训练成本来看，MLM因为只预测15%的token，达到同样的效果通常需要更多的训练数据或更长的训练时间。CLM每个位置都预测，收敛更快，但对数据质量的要求更高——如果训练数据里有大量噪声，CLM会把这些噪声也学进去，生成的时候就会暴露出来。

我在一个项目中同时训练了BERT和GPT的小模型，用的是同样的数据和差不多的参数量。结果CLM的loss下降明显更快，但生成出来的文本在早期阶段有很多重复和不通顺的地方；MLM的loss下降慢，但微调到分类任务上之后，准确率提升得更稳定。这个观察不一定适用于所有场景，但可以作为一个参考。

4. 微调策略的差异：全量微调、冻结层与适配器

4.1 BERT的微调范式

BERT的微调通常是在预训练模型上面加一个任务特定的头。比如做分类就在[CLS] token的表示上加一个全连接层，做序列标注就在每个token的表示上加一个分类层。微调的时候，可以选择全量微调，也可以冻结底部的若干层只训练顶部。

全量微调的效果通常最好，但需要更多的显存和计算资源。如果数据量不大，冻结底部层可以防止过拟合。我一般会先尝试全量微调，如果过拟合严重再逐步冻结底层。冻结的层数没有固定标准，通常从冻结底部4层开始试，然后根据验证集表现调整。

BERT微调的学习率一般设置在2e-5到5e-5之间，比从头训练的学习率小一到两个数量级。这是因为预训练模型已经学到了很好的表示，微调只是在这个基础上做微小的调整，学习率太大会破坏预训练的知识。

4.2 GPT的微调与提示工程

GPT的微调方式和BERT类似，也是加一个任务头然后微调。但GPT更常用的方式其实是提示工程和few-shot learning。因为GPT的生成特性，你可以通过设计prompt来引导模型完成各种任务，而不需要更新任何参数。

比如做情感分类，你可以把输入构造成“这句话的情感是正面还是负面？句子：今天天气真好。答案：”，然后让GPT补全“正面”。这种方式在GPT-3及之后的模型上效果很好，尤其是当标注数据很少的时候。

但提示工程也有缺点：不稳定。同样的prompt，换个措辞或者换个顺序，结果可能就变了。而且prompt的设计需要大量的实验和直觉，很难系统化。所以在实际项目中，如果标注数据足够，我还是倾向于微调；如果数据很少，才会考虑few-shot。

4.3 参数高效微调方法的选型

不管是BERT还是GPT，全量微调的成本都不低。尤其是当模型参数量到了十亿级别以上，全量微调需要大量的GPU显存。这时候就需要参数高效微调方法，比如Adapter、LoRA、Prefix Tuning等。

LoRA是我目前最常用的方法。它的思路是在原始权重旁边加一个低秩矩阵，只训练这个低秩矩阵，原始权重冻结。这样可训练的参数量可以减少到原来的百分之一甚至千分之一，显存占用大幅降低，效果却接近全量微调。

我在一个文本分类任务上对比过全量微调和LoRA微调：全量微调需要4张显卡，LoRA只需要1张；全量微调的F1是0.92，LoRA是0.91。差距很小，但资源消耗差了好几倍。所以如果你的算力有限，LoRA是非常值得尝试的方案。

提示：LoRA的秩（rank）是一个关键超参数。秩越大，可训练参数越多，效果可能更好但显存占用也更大。通常从8或16开始试，根据效果和资源情况调整。

5. 推理阶段的工程化考量：延迟、吞吐与部署

5.1 推理延迟的构成与优化

BERT和GPT在推理阶段的延迟特性完全不同。BERT是一次前向传播，输入整个序列，输出每个位置的表示。延迟主要取决于序列长度和模型层数。GPT是自回归生成，每生成一个token都需要一次前向传播，而且每次都要把之前生成的token重新输入。这意味着GPT的推理延迟和生成长度成正比，生成长文本时延迟会非常高。

优化BERT的推理延迟相对简单：可以用ONNX Runtime或者TensorRT做图优化，可以用量化把FP32转成INT8，可以用蒸馏把大模型变小模型。这些方法都很成熟，效果也比较稳定。

优化GPT的推理延迟就复杂得多。常见的方法包括KV Cache、批处理、投机采样等。KV Cache是最基本的优化：把之前计算的key和value缓存起来，避免重复计算。这个优化可以把生成速度提升好几倍，但会增加显存占用。

5.2 吞吐量与批处理策略

吞吐量是指单位时间内能处理的请求数。BERT的吞吐量优化主要靠批处理：把多个请求拼成一个batch，一次前向传播处理完。batch越大，吞吐量越高，但延迟也会增加。需要根据实际场景做权衡。

GPT的吞吐量优化更棘手，因为每个请求的生成长度可能不同，而且自回归的特性使得批处理变得复杂。常见的做法是连续批处理：动态地把新请求加入正在运行的batch，把完成的请求移出。这样可以提高GPU利用率，但实现起来比较复杂。

我在部署一个文本分类服务的时候，用的是BERT加ONNX Runtime加动态批处理。在同样的硬件上，吞吐量比直接用PyTorch推理提升了大约3倍。延迟从原来的50毫秒降到了20毫秒左右。这个提升在线上服务里是非常可观的。

5.3 模型压缩与量化实战

模型压缩是另一个重要的工程手段。BERT-base有1.1亿参数，FP32下模型大小约440MB。如果量化到INT8，模型大小可以降到110MB左右，推理速度也能提升2到4倍。对于资源受限的部署环境，量化几乎是必选项。

量化的方式有动态量化和静态量化两种。动态量化在推理时动态计算量化参数，实现简单但速度提升有限；静态量化需要校准数据，提前计算好量化参数，速度提升更明显但需要额外的校准步骤。

我一般会先用动态量化快速验证效果，如果精度损失在可接受范围内，再尝试静态量化进一步优化。精度损失通常控制在1%以内是可以接受的，如果超过这个范围，就需要考虑混合精度或者只量化部分层。

6. 常见问题与排查技巧实录

6.1 微调不收敛或效果差

这是最常见的问题。可能的原因有很多：学习率太大或太小、batch size不合适、数据预处理有问题、标签噪声太大等。

我的排查顺序是这样的：先检查数据，看看输入和标签是不是对得上，有没有明显的错误；然后检查学习率，用一个小学习率跑几百步看看loss有没有下降；然后检查batch size，太小会导致梯度噪声大，太大会导致泛化差；最后检查模型本身，看看预训练权重有没有正确加载。

有一个容易被忽略的点是tokenizer的配置。BERT和GPT用的tokenizer不一样，如果加载错了tokenizer，输入就会被编码成完全不同的token序列，模型自然学不好。我遇到过有同学用GPT的tokenizer去编码BERT的输入，结果[CLS]和[SEP]都被拆成了奇怪的子词，效果当然差。

6.2 生成结果重复或不通顺

GPT生成重复内容是一个经典问题。原因通常是解码策略的问题。贪心解码容易陷入重复循环，beam search可以缓解但也会产生重复。常用的解决方案包括：温度采样、top-k采样、top-p采样、重复惩罚等。

温度采样是调整softmax的温度参数，温度越高分布越平坦，生成越多样；温度越低分布越尖锐，生成越确定。top-k采样只从概率最高的k个token里采样，top-p采样从累积概率达到p的最小token集合里采样。重复惩罚是对已经生成过的token降低其概率。

我一般会先用温度0.7加top-p 0.9的组合，如果还有重复再加大重复惩罚。但要注意，重复惩罚太大会导致生成不连贯，需要反复调试。

6.3 显存不足的应对方案

显存不足是训练和推理时的常见问题。训练时可以通过减小batch size、使用梯度累积、使用混合精度、使用LoRA等方式缓解。推理时可以通过量化、剪枝、蒸馏、减小最大序列长度等方式缓解。

梯度累积是一个很实用的技巧：用小的batch size跑多次前向传播，累积梯度，然后再更新一次参数。这样可以在显存有限的情况下模拟大batch的效果。我经常用梯度累积来在单卡上训练那些原本需要多卡的模型。

混合精度训练是另一个利器：用FP16做前向和反向传播，用FP32保存模型权重。这样可以把显存占用减少大约一半，速度也能提升。但要注意，有些操作在FP16下会溢出，需要用loss scaling来防止。

6.4 常见问题速查表

7. 选型决策：什么场景用什么模型

7.1 任务类型驱动的选型逻辑

如果你的任务是文本分类、情感分析、命名实体识别、问答抽取这类理解型任务，BERT及其变体通常是更好的选择。因为双向注意力能更好地捕捉上下文信息，而且微调成本相对较低。

如果你的任务是文本生成、对话、摘要、翻译这类生成型任务，GPT及其变体是更自然的选择。自回归的特性使得它天然适合生成，而且few-shot能力可以在标注数据少的时候快速上手。

但这不是绝对的。现在很多模型融合了两者的优点，比如T5用编码器-解码器架构，既能理解又能生成；还有一些模型用前缀语言模型的方式，在编码器上加一个生成头。所以选型的时候不要被“BERT只能理解、GPT只能生成”的刻板印象限制住。

7.2 数据量与算力预算的影响

数据量少的时候，GPT的few-shot能力可以省掉大量标注成本。你只需要设计好的prompt，就能在几十个甚至几个样本上得到不错的效果。但数据量大的时候，微调BERT或GPT都能得到很好的效果，这时候就要看算力预算了。

算力充足的情况下，全量微调大模型通常效果最好。算力有限的情况下，LoRA等参数高效微调方法是首选。如果连微调都做不了，那就只能走提示工程路线，但效果上限会低一些。

我在一个项目中遇到过这样的情况：标注数据只有500条，算力只有一张消费级显卡。最后选择了GPT的few-shot方案，虽然没有微调，但在业务指标上达到了可用的水平。如果当时硬要微调BERT，可能连模型都加载不进去。

7.3 部署环境的约束

部署环境对选型的影响也很大。如果是云端部署，算力相对充裕，可以选择大一点的模型。如果是边缘设备部署，算力、内存、功耗都有限制，就必须选择小模型或者量化模型。

延迟要求也是一个关键因素。如果要求毫秒级响应，GPT的自回归生成可能就不合适，因为生成长文本的延迟太高。这时候要么用BERT做理解然后模板生成，要么用非自回归的生成模型。

注意：选型没有银弹。同一个任务，不同的数据、算力、延迟要求，可能适合不同的模型。最好的做法是先用小规模实验对比几个候选方案，然后再做最终决定。

8. 我个人的实操体会

写了这么多，最后分享几个我在实际项目中踩过的坑和总结的经验。

第一个体会是：不要迷信模型大小。我见过很多团队一上来就要用最大的模型，结果发现推理成本扛不住，最后又灰溜溜地换回小模型。其实在很多任务上，一个精心微调的BERT-base就能达到很好的效果，没必要上大模型。先用小模型快速迭代，等效果遇到瓶颈了再考虑换大模型，这个顺序比较稳妥。

第二个体会是：数据质量比模型选择更重要。我做过一个对比实验，同样的BERT模型，一份标注质量高的数据比一份标注质量低的数据，F1能差10个点以上。所以与其花时间调模型，不如先花时间清洗数据、检查标注一致性。

第三个体会是：推理优化要提前考虑。很多团队在训练阶段不考虑推理，等模型上线了才发现延迟太高、吞吐量太低。我的建议是在训练阶段就考虑好推理框架和优化方案，比如用ONNX导出、用TensorRT优化、提前做好量化校准。这样上线的时候就不会手忙脚乱。

第四个体会是：prompt engineering不是万能的。虽然few-shot很诱人，但它的稳定性确实不如微调。如果业务对稳定性要求高，还是老老实实标注数据做微调。prompt engineering更适合快速验证想法或者冷启动阶段。

这个系列写到第五篇，基本上把BERT和GPT的核心差异和实操要点都覆盖了。后续如果还要继续，可能会聊一些更前沿的话题，比如多模态模型、检索增强生成、模型对齐等。但那些都是后话了，先把眼前这些基础打牢，比什么都重要。