考察点
这道题表面问架构史，实际考察你是否理解「训练目标决定模型能力形态」。面试官想听的是：三种架构各自适合什么、Decoder-only 凭什么统一江湖、它带来的副作用是什么。追问常落在「那 BERT 类模型还活着吗」「为什么生成任务不保留 Encoder」。
参考答案
三种架构的分工史
先厘清三兄弟。Encoder-only 的代表是 BERT，双向注意力，能同时看到左右上下文，预训练目标是掩码预测（遮住一个词猜出来），天然适合分类、抽取、语义匹配这类「理解」任务，但它不会生成——没有定义从左到右的生成过程。Encoder-Decoder 的代表是 T5 和原始 Transformer，Encoder 编码输入、Decoder 生成输出，适合翻译、摘要这类输入输出界限分明的任务。Decoder-only 的代表是 GPT 系列，用因果掩码（每个位置只能看左边），训练目标就一条：预测下一个 token。
Decoder-only 赢在哪
第一，训练目标足够通用且数据无限。预测下一个 token 不需要任何人工标注，整个互联网文本都是训练语料。而 BERT 的掩码任务和 T5 的 span 损坏任务都需要构造，规模化时反而束手束脚。当模型参数量和数据量同时放大，「简单目标 + 海量数据」的路线 scaling 效果最好，这是被反复验证过的。
第二，一切任务都能统一成生成。分类、翻译、问答、写代码，统统可以表达成「给定前缀，续写下文」。一个模型、一个目标、一套推理引擎，覆盖所有任务。更关键的是 in-context learning 能力：Decoder-only 模型在上下文里看到几个示例就能模仿，prompt 工程、few-shot 这套玩法完全建立在自回归生成的形态上。Encoder-Decoder 结构里输入输出被硬性切开，这种灵活性反而弱。
第三，工程链条简单。单向注意力意味着生成时可以直接缓存历史 Key/Value（KV Cache），逐 token 增量推理非常自然；一套架构打天下，推理框架、量化工具、部署方案都可以围绕一个形态极致优化。学术界早年有争论说 Encoder-Decoder 的输入理解更深，但实践结果是：规模上去之后，Decoder-only 的理解能力并不吃亏，而统一架构带来的工程红利是实打实的。
代价是什么
天下没有免费午餐，Decoder-only 的短板要心里有数。一是自回归生成是逐 token 串行的，输出越长延迟越高，这是应用层必须做流式输出和长度控制的根源。二是因果掩码导致模型对文本的「理解」天然是单向的，做纯语义匹配、向量检索时，Decoder-only 模型产出的 embedding 未必比专门的双向模型好——所以 RAG 里的 embedding 模型至今常用 BERT 系或专门对比训练的双塔模型，这就是 Encoder-only 还活着的地方。三是生成式模型的输出不可枚举，不能像分类模型那样给出确定标签，应用层要靠约束解码、输出校验来兜底。
对应用工程师的实际影响
架构统一意味着「prompt 就是编程接口」：你不需要为每个任务换模型，而是为每个任务写上下文。同时也意味着面试常问的「理解类任务用大模型还是专用小模型」有标准答案：高并发、低延迟、输出空间固定的场景（如意图分类），微调一个小模型往往比调大模型便宜且稳定；输出开放、需要推理和生成的场景，才是 Decoder-only 大模型的主场。
可能的追问
- GLM 这类混合架构怎么看？GLM 用自回归填空统一理解和生成，本质上还是想兼得两边优点，工程上也收敛到了接近 Decoder-only 的形态，说明统一性比架构精巧更重要。
- 为什么生成任务舍弃 Encoder？有了足够长的上下文窗口，输入直接塞进 Decoder 的前缀即可，单独的 Encoder 成了冗余结构，省掉它参数利用率和训练效率都更高。
- 双向注意力用在 Decoder 上行不行？不行，那样预测下一个 token 时模型能偷看答案，训练目标直接失效。