不推公式讲Transformer：面试必问，关键是它跟你写代码什么关系

上篇写 KV Cache 的时候，我说 ChatGPT 回你第一个字慢得反常，根子在那。发出去之后好几个人留言说：KV Cache 我算是看明白了，但 Transformer 本身还是云里雾里。行，那今天干脆一次讲透。

我最近帮几个朋友改简历、模拟面试，发现一个挺普遍的现象：不管面后端、前端、产品还是算法，面试官十有八九会随口来一句——说说你对 Transformer 的理解。很多人当时的表情我见过，就是那种"我就调个 API，又不炼模型，你问我这个干嘛"的茫然。

我理解这种心态，但用处真的比你想的大。你回想一下：怎么聊几句就烧掉几万 Token？上下文为什么有上限？为什么聊着聊着它就忘了前文？为什么稍微排好版的 Prompt 总比一大段文字好使？我当初也是被这些问题卡住，往下挖了三层，最后全撞到同一堵墙上，就是 Transformer。

为什么主流大模型全长在 Transformer 上

面试官要是这么问你：为什么叫得上号的大模型，底层架构几乎全是 Transformer？你怎么接？

我习惯把时间拨回它诞生之前，这样对比才清楚。

2017 年 Google 发表 Attention Is All You Need 之前，NLP 挑大梁的是 RNN（循环神经网络）和 CNN（卷积神经网络）。RNN 上世纪 80 年代就有了，思路是一个词接一个词往后读，跟人看书一样从左到右，把前面读到的东西不断往后递。CNN 要追溯到 LeCun 1998 年的 LeNet，2012 年 AlexNet 靠它横扫 ImageNet，从此统治了计算机视觉，后来 NLP 的人把它借来处理文本，办法是用滑动窗口扫局部特征。

这两条路线各有一处绕不过去的硬伤，我当年读论文的时候卡了很久才想通。

RNN 的问题在于信息得一站一站往后递，递到第 1000 站时，第 1 站的消息早就衰减得所剩无几，这就是梯度消失。而且它天然串行，第 N 个 Token 必须等前面 N-1 个全部算完才能动手，GPU 的并行算力完全派不上用场。我做过一个粗略估算，一个 512 长度的句子在 RNN 里就是 512 次串行依赖，这在 GPU 上等于浪费 99% 的算力。

CNN 则是天生短视，像拿手电筒读书，一次照到几个词就没电了。想关联两个离得很远的词，只能一层层往上堆，代价也跟着水涨船高。

Transformer 换了条路：信息不再逐个往后传，每个词直接向其余所有词广播一句「我跟你们谁有关」，所有词同时回应，一轮下来结果就有了。不用排队，而这正是 GPU 最擅长的全员并行动作。

我个人的总结是：RNN 传着传着忘了开头，CNN 只看得见眼前几个字，Transformer 让所有词直接互相对话，一步到位还顺带并行加速。Mamba、RWKV 这些新架构确实在挑战它的地位，但论通用性和工程生态，目前还没有谁真正接得住。我跟踪了大半年，结论没变。

Self-Attention：每个词怎么打量自己和所有词的关系

Q、K、V 是面试高频考点。公式不用背，把逻辑讲明白就够了，我面试的时候也是这么答的，对方基本就点头了。

先来个直观的例子：「我买了一斤苹果」里的苹果是水果，「苹果发布了新 iPhone」里的苹果是公司。同一个词放进不同上下文，含义天差地别。Self-Attention 干的就是这活儿：扫一遍整个上下文，实时判定每个词当下该被理解成什么。

它具体怎么运作？每个 Token 会拆出三个角色：

• Q（Query，提问者）：我想知道自己在这句话里该是什么含义
• K（Key，应答者）：我这儿有些线索可以给到你
• V（Value，内容本体）：这是我携带的具体内容

落到例子上：苹果的 Q 发出询问「谁跟我有关系」，发布的 K 应声说「跟我强相关」，接着模型把发布的 V 拉过来刷新苹果的表示，于是它就明白这里的苹果指公司。我给自己记了个口诀：Q 找对象，K 判匹配，V 给内容。每次跟新人讲都管用。

这对我们开发意味着什么？你喂给模型的上下文，就是 Self-Attention 的原料。原料里噪音多，注意力就被稀释到无关的地方；原料干净，注意力才集中得起来。我实测下来，同样的任务，把无关段落删掉之后准确率能上去不少。所以写 Prompt，措辞花不花哨无所谓，信息给对给足才是重点。Attention 的计算细节我在 KV Cache 那篇拆过，底层的逻辑在那儿。

Multi-Head Attention：结构化 Prompt 为什么更吃香

只有一组 QKV 的话，模型只能从一个角度观察词与词的关系。可自然语言天然是多层的：主谓怎么搭配、代词指回谁、哪些词语义相近，一组 QKV 根本顾不过来。

Multi-Head Attention 的办法很直白：克隆出多组 QKV，各自独立地算注意力。拿 8 个头举例，相当于 8 个分析师同时读同一段文字，每人盯一个维度上的关系，最后把各自的发现拼在一起，得到更立体的理解。

我写 Prompt 的时候开始有意识地在配合这个机制。把目标、参数、约束、上下文用清晰的结构分开，等于替每个注意力头划好了重点。反过来，一大段不分段的文字，好比把 8 个分析师塞进一间乱屋子，东西都在，翻起来费劲。说白了，结构化 Prompt 就是顺着多头注意力的工作方式在配合它，不是玄学。

位置编码和 Decoder-Only：两个直接影响你写 Prompt 的概念

先说位置编码。很多人没意识到，Self-Attention 其实是个不关心顺序的机制。「我欠你一万块」和「你欠我一万块」，不加位置编码的话在它眼里一模一样，这显然不行。于是 Transformer 额外加了 Positional Encoding，相当于给每个词编个座位号。

座位号也有副作用：模型训练时只见过有限范围内的编号，出了这个范围就不灵了。这直接拖累了超长上下文的质量。而且模型对中间位置的信息天然容易走神，学术上叫 Lost in the Middle。我踩过一次，把一段 8000 字的文档中间塞了个关键约束，模型直接无视了，挪到开头之后立刻生效。所以实战里，关键信息尽量往 Prompt 的头部和尾部放。

再说 Decoder-Only 架构。现在叫得上名的大模型，GPT、Claude、LLaMA、Gemini，清一色走这条路。它的逻辑极简，只看已经出现的内容，再往下猜一个词。你发一段 Prompt，模型干的就是文字接龙。

为什么全行业都押注它？我梳理下来好处有几个：规模越大收益越稳，在 Scaling Law 上表现最好；一套架构既能生成又能理解，而 Encoder-Only 做不到生成；训练目标也高度统一，永远只是预测下一个 Token，工程上自然省心省力。

这对开发的启示是：大模型骨子里在做续写。Prompt 末尾的指令离生成点最近，拿到的注意力权重天然更高。所以 System Prompt 放开头定基调，关键指令放结尾定方向，上下文铺在中间。这是架构本身决定的，跟拍脑袋的经验无关。

Transformer 的四个局限

Transformer 很强，但代价不小。认清这些局限，你的技术判断会更靠谱，我面试的时候也会主动提这些，面试官一般会觉得你有思考深度。

O(n²) 的平方代价：注意力的计算量跟输入长度的平方成正比，输入翻倍，算力翻四倍。1K Token 大约需要 100 万次计算，到 128K 就飙到 163 亿次。上下文窗口为什么没法无限扩大、长文本 API 为什么贵得吓人，根子都在这儿。

位置编码的有效射程：模型训练时只见过一定范围的位置标记，再往外就像地图上的空白地带。RoPE、YaRN 这些技术在拼命拉长射程，但只能缓解，治不了本。

中间信息的注意力盲区：不管模型多强、上下文多长，开头和结尾总能分到更多关注，夹在中间的内容容易被直接跳过去。

逐词生成的速度天花板：Decoder-Only 模型吐字只能一个 Token 接一个 Token，前一个没出来，后一个就开不了口。所以凡是长输出场景，流式返回基本是标配。

压上下文长度，图省钱是一方面，更关键的是在压 O(n²) 的计算复杂度；把关键信息往前放，同样是架构层面的对策，专治中间迷失。这些操作看着像技巧，其实每一项都对应一条架构约束。

这也解释了为什么主流模型的定价都跟上下文长度直接挂钩：Gemini 超过 128K Token 之后单价翻倍，Claude 的长上下文请求比短请求贵出一大截。O(n²) 的计算复杂度，最后都会写进你的账单。我算过一笔账，一个 200K 上下文的请求，光注意力那一块的算力开销就是 20K 请求的 100 倍，账单上的差距就是这么来的。

面试高频问题，我直接给答案

Q：用大白话讲讲 Q、K、V？

把 Q 理解成提问，K 理解成举手应答，V 就是应答者手里那份实际内容。谁举的手高，也就是谁的 Q 和 K 匹配度高，谁的 V 在最终结果里权重就更大。

Q：为什么要多个注意力头？

一个头只学得会一种看文字的方式。语言本身是多维的，谁修饰谁、谁指代谁、谁和谁意思接近，需要不同视角同时运转。所以多头并行分析，最后汇总到一起。

Q：Decoder-Only 怎么成了行业标配？

架构最简洁，规模效应最明显，一套模型既能写代码又能做阅读理解。训练目标还只有一个，预测下一个词，工程复杂度自然最低。

Q：面对 O(n²) 复杂度，开发里怎么应对？

我一般给四招：精简上下文，别把整个代码库都怼进去；按需选模型，短任务用小模型控成本，长任务上大窗口模型保质量；重要信息往前放，绕开中间盲区；输出走流式，缓解逐词生成的迟滞感。说到底就是顺着架构的脾气做优化，别跟复杂度硬碰。

Q：懂 Transformer 对写代码、调 API 到底有啥实际帮助？

举个例子：知道 O(n²)，你就不再把无关信息往上下文里塞；知道中间迷失，你会把核心需求放到 Prompt 开头；知道多头注意力，你会用结构化格式写 Prompt；知道 Decoder-Only 做的是续写，你会把最要紧的指令放到末尾。每一条优化背后都有架构层面的解释，不靠玄学。

最后说两句

绕了一大圈，回到开头那个问题：做应用开发的人，为什么还得花时间理解 Transformer？

因为你用的每一个大模型，能力边界、性能瓶颈、行为特征，全被这个架构框死了。不懂架构，只能凭手感调参数、碰运气写 Prompt；懂了架构，才能从机制层面推出该怎么做。

像上下文怎么组织、关键指令放在哪、Token 预算怎么分这类日常决策，背后站着的都是 Transformer 这个幕后推手。我现在的习惯是，每遇到一个"为什么模型表现成这样"的困惑，先回到架构层面找原因，找不到的再去查论文。省了不少试错时间。