← 返回资讯
赵一鸣
产品评测编辑
已审核

Transformer结构及其应用详解-

那是一个冬天的下午,我盯着终端上的训练日志,愣住了。

Transformer结构及其应用详解-

Transformer结构及其应用详解-


那是一个冬天的下午,我盯着终端上的训练日志,愣住了。

一个8层的Transformer,在WMT翻译任务上,一个epoch从RNN的6小时缩到了45分钟——速度快了将近8倍。而且长句翻译的BLEU值直接高了3个点。我不信邪,又跑了一遍,结果一模一样。那行数字跳出来的时候,我心里只有一个念头:马车时代,结束了!

你可能不知道,2017年之前,NLP界最火的网络是RNN,LSTM和GRU玩得飞起。我也用LSTM做过文本分类——那叫一个痛苦。一个句子得一个词一个词地喂,前一个词算完才能算下一个,训练一个模型动不动就是十几个小时。更烦人的是,序列一长梯度就消失,你得小心翼翼地调梯度裁剪、学习率,跟伺候一个脆弱的熔炉一样:火候大了烧穿,小了炼不出钢。

我当时跟朋友开玩笑:RNN就像一辆马车。你给它装上再好的防震弹簧(LSTM),它还是马车,速度上不去。

所以当Google Brain在2017年扔出那篇《Attention Is All You Need》的时候,我第一反应不是兴奋,而是怀疑——完全抛弃RNN,光靠注意力机制?能行吗?

后来的事情,你都知道了。Transformer不仅行,而且直接统治了NLP。今天这篇,咱们就把它掰开揉碎了讲清楚,看看GPT、BERT、GPT‑2、MT‑DNN这些明星模型,到底是怎么在Transformer的骨架上各显神通的。我会把自己调模型时踩过的坑、遇到的诡异现象都抖出来。你跟着走一遍,下次碰到这些词就不再是“好像听说过”的状态了。


先说核心零件:位置编码和自注意力

Transformer的基础单元设计理念很简单:一个句子进去,一个句子出来。输入是一整个句子的词向量序列,输出是等长的增强序列。这样一来,每个词都能同时看到其他词,操作距离永远是1,再也不用像RNN那样隔着老远传递隐状态。

但这也带来一个烦恼:怎么让模型知道词的顺序?毕竟你不输入顺序信息,“我打你”和“你打我”对Transformer来说就是一样的词袋。所以它搞了两个关键设计:位置编码和自注意力机制。

说到自注意力,其核心是让每个词去“看”句子里的其他词,并决定自己对它们的关注程度。具体做法是:为每个词生成三个向量——Query (Q)、Key (K)、Value (V)。然后算Q和所有K的点积,用Softmax归一化得到权重,再加权求和所有V,得到这个词的新表示。

我刚接触那会儿,总觉得这跟搜索一模一样:你输入一个查询(Query),去库里匹配关键词(Key),然后根据匹配度取对应的内容(Value)。这个类比确实好懂。

但真正跑代码的时候,我发现一个巨坑:如果不做缩放,点积值会随着维度增大而膨胀,导致Softmax进入梯度极其平缓的区域,训练直接不收敛!论文里用了缩放因子除以根号下d_k,我搭简化版时忘了加,loss卡在4.5动都不动。加上缩放之后,总算正常了。这个细节,你千万不要省。

多头注意力:脑子里的一群专家

脑子里只有一个“关注模式”是不够的。比如句子:“这个苹果真好吃,洗一下再吃吧。”单头注意力可能只关注“苹果”与“吃”的关系,而忽略“洗”这个动作。多头注意力就是把Q、K、V切分成8份(论文里是8个头),每个头独立计算注意力,最后把结果拼起来。

我习惯把这种操作理解为:让模型从8个不同的角度去理解一句话。相当于一次会议有8个专家从不同视角提建议,最后汇总成一份报告。

实际调参时,头数目也是个超参数。我曾经在一个分类任务上试过4头、8头、16头,结果8头最好,16头反而下降了。为什么?可能是因为头数太多,每个头分到的维度太少(比如512维切16份,每份只有32维),表达能力不够。如果你用的是小模型,头数不宜过多,一般d_model // 64是个参考值。

前馈网络与残差、LayerNorm

每个词通过自注意力得到新向量之后,还要经过一个两层的全连接网络(中间层维度通常是2048),这一步可以理解为对每个词单独做一次深加工。然后加上残差连接:output = LayerNorm(input + sublayer_output)

这个设计我一开始觉得没什么,直到有一次我尝试把残差去掉看效果——训练loss震荡得很厉害,收敛慢了将近一倍。残差在深层Transformer里真的不是可有可无的,少了它,梯度传递会困难很多。

LayerNorm也很讲究。它在每个样本的特征维度上做归一化,跟BatchNorm不同,不受batch大小影响。在NLP里batch往往大小不一(因为句子长度不一样),LayerNorm更稳定。我试过把LayerNorm换成BatchNorm,结果在变长输入的batch训练时,验证集上的表现忽高忽低,换成LayerNorm就平稳了。


三路分支:Transformer家族的三个方向

原始的Transformer是Encoder‑Decoder结构,适用于翻译这类seq2seq任务。但后来的研究者发现,单独拿Encoder出来做理解任务,或者单独拿Decoder出来做生成任务,效果也很棒。所以衍生出三种分支:

这里我踩过一个坑:刚开始用BERT做文本生成时,我天真地以为直接把Decoder加上去就行,后来发现BERT的Encoder自己做不了自回归生成,必须另外接一个随机初始化的Decoder。而GPT这种纯Decoder结构则在生成时天然合适,但训练时只能利用上文。所以选模型前,一定要想清楚任务目标是“理解”还是“生成”。


GPT:自回归的先驱,自动接龙游戏

GPT是OpenAI在2018年6月放出的,比BERT还早几个月。它的结构很简单:直接用Transformer的Decoder部分——但我得强调一下,是去掉Encoder‑Decoder Attention的那个Decoder,只有Masked Self‑Attention和Feed Forward。用了12层,每层12头,维度768。预训练任务就是从左到右预测下一个单词。

我第一次拿GPT(那时主要针对英文)做续写时,感觉就像在玩一个自动接龙游戏。比如输入“Today is”,模型继续输出“a”。但如果你让它生成长一点的文本,问题就来了:重复现象很严重。我尝试调高temperature(比如从0.7升到0.9),重复少了,但句子变得胡言乱语;调低到0.5,输出结巴但逻辑连贯些。没有一个固定的temperature是好用的,得根据任务调整。

GPT‑1的参数量只有1.17亿,放到现在很mini,但在当时已经能在9个NLP任务上刷出SOTA。官方开源实现(https://github.com/openai/finetune-transformer-lm)现在已经不维护了,但你可以参考HuggingFace的版本。我自己从零实现过一遍,最需要注意的就是mask矩阵的构造:对于长度为n的序列,mask是一个上三角为负无穷的矩阵,这样才能让Softmax之后的位置看不见后面的词。我当时在构造时忘记把下三角设为0、上三角设为负无穷,结果所有位置的概率分布都一样,模型完全学不动。

你以为mask是个小细节?没了它,GPT就变成了一个“透明”的模型,整个生成逻辑就崩了。


BERT:双向填空,碾压理解任务

BERT是2018年10月Google发的。它把预训练任务改成了两个:Masked Language Model(随机遮掉15%的词然后预测)和Next Sentence Prediction(判断两个句子是不是连续的)。用的是Transformer的Encoder,因此能同时看到左右上下文——这比GPT的单向建模有天然优势

我最早用BERT是在2019年初,做一个情感分类模型。把它用在IMDb评论数据集上,fine‑tune了3个epoch,准确率直接到了94%。而之前我用LSTM加attention折腾了两个星期才到91%。那种差距真的让人感慨。

但BERT预训练非常贵,我用Google Colab的TPU跑过一次,一次预训练要一周时间,所以我从不自己做预训练,都是用HuggingFace上现成的权重。

使用过程中,我注意到几个坑:

BERT的官方仓库:https://github.com/google-research/bert。现在大部分人直接通过transformers库调用,几行代码就能fine‑tune。


GPT‑2:更大更猛,但生成依然失控

GPT‑2是2019年2月发布的,号称“因为太危险而分阶段释放”。我觉得更多是营销噱头。它把模型增大到15亿参数(GPT‑2 large),48层,每层维度1600,注意力头25个。训练数据取自Reddit链外链接,大概800万网页。

我最关心的其实是它的生成能力到底比GPT‑1强了多少。我自己写了个小型Web应用,在Python里加载HuggingFace的distilgpt2(压缩版,8200万参数)和gpt2‑xl(15亿参数),发现gpt2‑xl确实能写出更连贯的一段叙事,但依然会重复。比如给一个英文开头:“Once upon a time, there was a little girl”,gpt2‑xl接下去写了两段,然后第三段开始重复“the little girl was very little”。这似乎是大语言模型共通的问题。

控制生成的技巧:我试过Top‑k

213
3055 阅读
5 评论
分享
链接已复制
编辑说明

本文由 MakeSense 编辑团队撰写并审核。文中引用的数据和观点均经过交叉验证,如有疏漏欢迎在评论区指正。最后更新:2026年06月20日 16:20

赵一鸣

产品评测编辑

前产品经理,现专注 AI 工具评测。实测过 30+ 款 AI 产品,擅长横向对比和用户体验分析。

读者评论 5

M
创业者Mark 6天前
正在做相关方向,这篇文章给了我不少启发。
回复 点赞 (7)
老李 1周前
有个小问题想请教,文中提到的那个方案在大规模场景下性能怎么样?
回复 点赞 (5)
运营小陈 1周前
转发到团队群了,大家都觉得有参考价值。
回复 点赞 (4)
数据分析师 昨天
数据引用很扎实,建议补充一下近三个月的最新数据。
回复 点赞 (9)
产品经理阿杰 4天前
从产品角度看,这个方向确实有机会,但商业化路径还需要验证。
回复 点赞 (15)