Encoder-Decoder on Jeanphilo Blog

Attention-Based Seq2Seq：为什么会自然过渡到 Transformer

Thu, 23 Apr 2026 15:51:40 +0800

副标题 / 摘要 这篇文章专门解释一个关键过渡：为什么 fixed-length 的 seq2seq 很快会不够用，attention-based seq2seq 是怎么补上“按需读取源序列”这个能力的，以及这个思路为什么几乎会自然长成 Transformer。最后会收束到一份最小可运行的 PyTorch GRU + additive attention 实现。

从“苹果”为什么老翻不准开始

还是用这个最小翻译任务：

src: <bos> I really love green apples <eos>
tgt: <bos> 我 真的 喜欢 青 苹果 <eos>

当 decoder 走到要生成“苹果”这一步时，最理想的行为其实很明确：

它应该重点回头看源序列里的 apples
它可能顺手也看一眼 green
它不能只依赖一个已经被反复压缩过很多轮的最终隐藏状态

如果你用上一篇里那个最小 seq2seq：

encoder 把整句读完
只把最后一个 hidden_enc 交给 decoder
decoder 后面每一步都只靠这个固定长度状态和自己的历史

那么句子一长，这里就会出现一个很具体的问题：

decoder 明明需要“现在按需去看源序列的某几个位置”，但 fixed-length seq2seq 只给了它“一次性打包好的整句摘要”。

这就是 attention-based seq2seq 出现的真实压力。它不是为了“概念更高级”，而是因为 decoder 在每个时间步都需要重新决定自己该看源序列的哪里。

快速掌握地图

fixed-length seq2seq：encoder outputs -> 丢弃大部分，只保留 final hidden
attention-based seq2seq：decoder step t -> 对所有 encoder outputs 打分 -> 加权求和得到 context_t
核心收益：不同目标位置可以读取不同源位置
仍然存在的限制：encoder 和 decoder 还是循环结构，时间上依然串行
通向 Transformer 的关键桥：decoder state 作为 query，encoder outputs 作为 memory

这篇文章重点深挖的两个概念

对齐分数与上下文向量：decoder 怎样在每一步决定“该看源序列哪里”
从 attention-based seq2seq 到 Transformer 的结构映射：哪些东西被保留了，哪些东西被替换了

大师级心智模型

fixed-length seq2seq 的核心假设是：

Seq2Seq 与 Encoder-Decoder：从翻译任务到最小可运行 PyTorch 实现

Thu, 23 Apr 2026 15:27:55 +0800

副标题 / 摘要 这篇文章不把 seq2seq 和 encoder-decoder 当成术语表来讲，而是从一个最小翻译任务出发，解释为什么“输入一段序列、输出另一段序列”会自然逼出编码器和解码器的分工，最后收束成一份最小可运行的 PyTorch GRU 实现。

从一个最小翻译任务开始

假设源序列是：

<bos> I love apples <eos>

目标序列是：

<bos> 我 喜欢 苹果 <eos>

当模型要生成“苹果”时，它至少要解决三件事：

它必须知道整句英文大意，而不只是当前一个词
它必须记住自己前面已经生成了“我喜欢”
它必须按顺序一个词一个词地产生输出，而不是一次吐出整个目标序列

如果你只用一个普通分类器把源句子映射成一个类别，这个任务做不成。因为这里的输出不是一个固定标签，而是长度可变的目标序列。

所以这里天然会逼出一个更具体的数据流：

先把源序列读完，压成可传递的状态
再从 <bos> 开始，逐步生成目标序列
每生成一步，都要同时依赖“源侧信息”和“目标侧历史”

这就是 sequence-to-sequence 的最小问题形态。 seq2seq 说的是任务：输入一段序列，输出另一段序列。 encoder-decoder 说的是实现：先编码输入，再逐步解码输出。

下面不先堆名词，直接按这个压力把代码一步一步长出来。

快速掌握地图

问题形态：src -> encoder -> hidden/context -> decoder -> logits
核心目标：学习条件概率 p(y_t | y_{<t}, x)
最小实现：Embedding + GRU Encoder + GRU Decoder + output projection
何时适用：翻译、摘要、改写、问答这类“输入序列 -> 输出序列”任务
明显局限：如果所有源信息都被压进一个固定长度向量，长句子会吃力

这篇文章重点深挖的两个概念

隐藏状态交接：encoder 到底把什么交给 decoder
右移目标序列与 teacher forcing：训练时 decoder 为什么不能直接喂完整真实答案

大师级心智模型

这类模型的核心抽象不是“两个 RNN 拼起来”，而是：

Transformer 结构推导：一步一步搭出最小可运行 PyTorch 实现

Thu, 23 Apr 2026 10:13:23 +0800

副标题 / 摘要 这篇文章不把 Transformer 当成一个现成黑盒来介绍，而是直接从一个最小翻译任务开始，让需要的结构一层一层长出来，最后收束成一份最小可运行的 PyTorch encoder-decoder Transformer。

从一个最小翻译任务开始

假设源序列是：

<bos> I love apples <eos>

目标序列是：

<bos> 我 喜欢 苹果

当模型要生成“苹果”时：

它不能看目标序列里未来还没生成的位置
它需要重点读取源序列中的 apples
它可能还需要参考前面的“我喜欢”来决定当前词

所以这里天然会逼出三件事：

目标侧必须有因果约束
源侧和目标侧都需要全局读取
解码器不仅要读自己，还要读编码器输出

RNN 和 CNN 也能处理序列，但它们在长距离依赖和全并行训练上都有明显限制。所以这里真正要解决的，不只是“做一个更深的网络”，而是让任意位置能直接交互，并且显式控制信息流方向。

下面开始按这个压力一步一步长代码。

Step 1：先有输入表示，但先不谈注意力

先看一个已经分词并编号后的最小输入：

<bos> I love apples <eos>
-> [1, 15, 982, 204, 2]

这里的 1, 15, 982, 204, 2 还不是模型已经理解后的表示。它们只是词表里的编号，作用更接近“标签”或“学号”：

15 比 204 小，不代表它们语义上更接近
直接拿这种离散编号去做线性变换或点积，含义也不对

所以第一步只解决一个更具体的问题：

怎样把“词表编号”变成“模型后面可以继续计算的一组连续数值”？

这里再引入两个词：

token id：分词后查词表得到的离散编号
embedding：把每个离散编号映射成长度为 d_model 的可学习向量

先写最小版，不额外引入别的机制：