Seq2Seq 与 Encoder-Decoder:从翻译任务到最小可运行 PyTorch 实现
副标题 / 摘要 这篇文章不把 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 拼起来”,而是: ...