Transformer机器翻译源码实战：数据流、训练避坑与BLEU评测

简介：Transformer凭借自注意力机制取代循环网络，成为神经机器翻译的主流架构，其长距离依赖建模能力与并行训练优势，让开发者能高效构建翻译系统。理解词表构建、padding与mask的配合，是跑通源码链路的关键，也是控制显存开销与训练稳定性的基础。在工程落地中，合理配置学习率、teacher forcing与beam search参数，直接影响模型收敛效果与推理质量。本文从一段毕业作品级源码出发，拆解Transformer翻译系统的数据流实现，结合sacrebleu评测，梳理loss不降、显存溢出等高频避坑方案，适合作为翻译任务深度学习的实践入门指南。

1. 拿到毕业作品级的 Transformer 翻译源码，第一件事不是跑通，而是看懂数据流

把一份《深度学习基于 Transformer 的机器翻译系统 python 源码（毕业作品）.zip》解压后，多数人的第一反应是pip install -r requirements.txt，然后直接python train.py。我的建议是反过来：先不急着训练，先在编辑器里把一条样本从文本变成 loss 的路径走一遍。这类毕设源码通常只有几千行，模型定义往往不是瓶颈，真正的复杂度全在词表构建、padding 与 mask 的配合上。这篇笔记要拆的正是这条链路：毕设为什么清一色选 Transformer 做机器翻译、数据预处理怎么写、训练参数怎么定、loss 不降和显存溢出分别怎么排，最后拿 BLEU 证明系统真的能翻。它适合正在做翻译类毕业设计的学生，也适合想低成本复现一个翻译 baseline 的深度学习入门者。

2. Transformer 翻译系统：为什么这套架构成了毕设标配

2.1 从 Seq2Seq 到 Self-Attention：选 Transformer 的四个现实理由

在 Transformer 出现之前，神经机器翻译的典型基线是 LSTM/GRU 组成的 Seq2Seq。编码器把源语言句子读成一个固定维度的向量，解码器再从这个向量中逐词生成译文。这个设计的瓶颈有两个：一是最后一个隐藏状态要“打包”整句话的信息，句子超过三四十个词，后面的词基本记不住；二是循环结构必须按时间步展开，batch 内句子越长，训练一个 step 的开销线性上涨，显存占用也不好控制。到现在，不少课程习题还在用 Seq2Seq + Attention 做课后题，但真实项目里已经很少用它来落地翻译了。

Transformer 用自注意力替代循环，让任意两个位置的 token 可以直接计算相关度，长距离依赖被压缩成一次矩阵运算；多头注意力又把同一句话拆进多个子空间，模型可以同时关注语法关系、指代关系和语义相近的词。加上位置编码，token 的顺序信息也没有丢。对毕设而言，选它有三个很现实的理由：第一，代码量小，没有循环和隐状态传递，几百行 PyTorch 就能写一个能跑的最小实现；第二，PyTorch 内置nn.Transformer，很多源码包其实是在这个接口外面套了一层自己的封装，读起来省力；第三，同一套 encoder-decoder 骨架，改改输入输出就能做分类、序列预测甚至 vision transformer 图像任务，答辩时“架构通用性”是一个送分点。网上关于 Transformer 模型详解的帖子很多，但如果手边有《动手学深度学习》，直接看它对应章节比啃原论文快得多。

不过要泼一盆冷水：选型成熟不代表训练容易。Transformer 对学习率、mask 和数据的敏感度远高于 LSTM，原论文里那个 6 层、d_model=512 的配置是给千万句级 WMT 语料调的，毕设语料经常只有几万到几十万句，直接照抄必过拟合。这是后面几章要反复强调的取舍，也是这个方向最容易翻车的地方。

2.2 源码包里最常见的骨架：Encoder、Decoder 与最小 PyTorch 实现

这类毕业作品源码的目录结构通常很规矩：transformer.py放模型定义，dataset.py放数据读取和词表，train.py放训练循环，translate.py放推理脚本。模型部分无论外面包了多少层，核心都是位置编码、多头注意力、前馈网络、残差连接和层归一化。下面是我在本地复刻的最小版本，去掉了 dropout 和参数初始化，逻辑和 PyTorch 官方示例保持一致：

import torch import torch.nn as nn import math class PositionalEncoding(nn.Module): def __init__(self, d_model, max_len=5000): super().__init__() pe = torch.zeros(max_len, d_model) position = torch.arange(0, max_len, dtype=torch.float).unsqueeze(1) div_term = torch.exp(torch.arange(0, d_model, 2).float() * (-math.log(10000.0) / d_model)) pe[:, 0::2] = torch.sin(position * div_term) pe[:, 1::2] = torch.cos(position * div_term) self.register_buffer('pe', pe) # 不参与梯度更新 def forward(self, x): return x + self.pe[:, :x.size(1)] class Translator(nn.Module): def __init__(self, src_vocab, tgt_vocab, d_model=512, nhead=8, num_layers=6, dim_ff=2048): super().__init__() self.src_embed = nn.Embedding(src_vocab, d_model) self.tgt_embed = nn.Embedding(tgt_vocab, d_model) self.pos = PositionalEncoding(d_model) self.core = nn.Transformer(d_model=d_model, nhead=nhead, num_encoder_layers=num_layers, num_decoder_layers=num_layers, dim_feedforward=dim_ff, batch_first=True) self.fc_out = nn.Linear(d_model, tgt_vocab) def forward(self, src, tgt, src_key_padding_mask, tgt_mask, tgt_key_padding_mask, memory_key_padding_mask): src = self.pos(self.src_embed(src)) tgt = self.pos(self.tgt_embed(tgt)) memory = self.core.encoder(src, src_key_padding_mask=src_key_padding_mask) out = self.core.decoder(tgt, memory, tgt_mask=tgt_mask, tgt_key_padding_mask=tgt_key_padding_mask, memory_key_padding_mask=memory_key_padding_mask) return self.fc_out(out)

这段代码有三处要对齐你自己的 PyTorch 版本。一是 register_buffer 把位置编码注册成非参数张量，存模型时它跟着 state_dict 走，但不会出现在优化器里；二是nn.Transformer的 encoder 和 decoder 默认都是 6 层，这个数字在毕设数据量下通常要减半，后面 4.1 的配置表会再展开；三是batch_first=True让输入输出都是 (batch, seq_len, d_model)，调试时打印 shape 更直观。fc_out输出的形状是 (batch, tgt_len, tgt_vocab)，送进交叉熵前要把后两维 reshape 成 (batch * tgt_len, tgt_vocab)。

把张量形状变化写出来，比反复读论文更管用。假设 batch=4，源语言句子最长 30 个 token，目标语言最长 40 个 token，那么 src 的初始形状是 (4, 30)，tgt 是 (4, 40)；经过 embedding 和位置编码后变成 (4, 30, 512) 和 (4, 40, 512)；encoder 输出仍是 (4, 30, 512)，这也就是 memory；decoder 拿 tgt 的 (4, 40, 512) 做 query，拿 memory 做 key 和 value，输出 (4, 40, 512)；最后的线性层把最后一维映射到目标词表大小，得到 (4, 40, 32000)。中间任何一维对不上，基本都是 embedding 维度、max_len 或 mask 形状的问题。

2.3 一张样本从文本到 loss 的完整路径

把数据流走一遍，三类 mask 的设计动机就清楚了。原始句子先按空格或分词工具切成 token，再查词表映射成 id 序列；编码器侧把 id 查 embedding 得到向量矩阵，加上位置编码后进自注意力；解码器侧每一步只能看到目标语言已经生成的词，为了训练时能并行，用 teacher forcing 一次性喂入整个目标句子（右移一位），同时用一个上三角 mask 把未来位置遮住。

三个 mask 的分工要记牢。tgt_mask 是 (tgt_len, tgt_len) 的上三角矩阵，PyTorch 约定对角线及以上为 True 表示“遮住”，作用是不让解码器偷看未来；src_key_padding_mask 和 memory_key_padding_mask 都是 (batch, src_len) 的布尔矩阵，padding 位置为 True，作用是把无效的<pad>排除出注意力计算；decode 时目标侧也有 tgt_key_padding_mask，形状是 (batch, tgt_len)。新手最容易踩的隐性坑是布尔语义：很多老教程里 0/1 的含义和 PyTorch 正好相反，直接抄过来会得到 mask 全部失效，注意力把 padding 也算了进去。

loss 的计算也有一个容易错的点。训练样本 tgt 会被拆成两份：tgt_input等于tgt[:, :-1]，前面人为补了一个<bos>；tgt_output等于tgt[:, 1:]，最后跟着<eos>。模型输出每个位置的预测分布，和 tgt_output 逐位算交叉熵，并且要把 pad_idx 设进 ignore_index，否则大量 padding 位置会稀释真实词的梯度。这一步看着不起眼，但 5.1 节要讲的 loss 不降，十有八九死在这里。再有就是数据本身的干净程度：文件读取时句子没去重、没清洗，词表里混进残缺 token 和孤立标点，模型要花大量容量去拟合噪声。下一步的数据预处理，就是专门处理这些问题。

3. 把数据喂进模型：词表构建、padding 与 mask 的三件套

3.1 词表构建：word-level 起步，BPE 留给答辩加分

词表是整个链路里第一个分水岭。毕设语料通常不大，我建议直接用 word-level 分词，也就是按空格把句子切成词。它的优势是直观、可解释，词表可以直接打印出来检查，复现成本低；缺点是遇到中英混合、粘连标点和罕见词时表现差。如果导师要求提效果，再往 BPE/子词方向走，用 sentencepiece 或 tokenizers 库训练一个子词模型，词表可以压到 8k~32k，同时把未登录词问题基本解决。但对第一次跑通链路来说，word-level 完全够用，关键是词表本身要干净。

from collections import Counter def build_vocab(sentences, vocab_size=32000, min_freq=2): counter = Counter() for s in sentences: counter.update(s.strip().split()) vocab = {'<pad>': 0, '<bos>': 1, '<eos>': 2, '<unk>': 3} for w, c in counter.most_common(vocab_size - 4): if c >= min_freq: vocab[w] = len(vocab) else: break return vocab

这里最核心的约定是<pad>必须是 0。这不是强迫症，而是因为后面collate_fn里torch.full默认用 0 填充，所有 padding mask 都依赖这个编号。<bos>、<eos>、<unk>紧跟其后，顺序固定，推理脚本里才不会搞混。min_freq=2会把只出现一次的词丢掉，这些词通常是拼写错误或语料噪声，留着只会让模型去背噪声；most_common按频次降序，遇到低于 min_freq 的单词就 break，所以实际词表可能到不了 vocab_size，这是正常的。词表建好后，建议统计一下验证集里<unk>的比例，超过 10% 就说明词表太小或分词粒度不对，需要调 vocab_size 或改用子词。

3.2 collate_fn 与三种 mask：变长 batch 的标准写法

PyTorch 的 DataLoader 只负责按 batch_size 取样本，它不知道句子是变长的，所以需要 collate_fn 把列表里的句子 pad 成同一个长度。常见的错误是一律 pad 到全局 max_len=128，明明一个 batch 最长只有 20 个词，却要按 128 算注意力，显存和算力都被浪费掉。正确做法是 pad 到当前 batch 的最大长度，同时在 batch 内按长度排序，让相近长度的句子凑在一起，padding 比例能显著下降。

import torch def collate_fn(batch, pad_idx=0): src, tgt = zip(*batch) max_src = max(len(s) for s in src) max_tgt = max(len(t) for t in tgt) src_padded = torch.full((len(batch), max_src), pad_idx, dtype=torch.long) tgt_padded = torch.full((len(batch), max_tgt), pad_idx, dtype=torch.long) for i, (s, t) in enumerate(zip(src, tgt)): src_padded[i, :len(s)] = torch.tensor(s, dtype=torch.long) tgt_padded[i, :len(t)] = torch.tensor(t, dtype=torch.long) return src_padded, tgt_padded def make_masks(src, tgt, pad_idx): src_pad_mask = (src == pad_idx) # (batch, src_len) tgt_pad_mask = (tgt == pad_idx) # (batch, tgt_len) tgt_mask = torch.triu( torch.ones(tgt.size(1), tgt.size(1), device=src.device), diagonal=1 ).bool() return src_pad_mask, tgt_mask, tgt_pad_mask

collate_fn 返回的两个张量形状分别是 (batch, max_src) 和 (batch, max_tgt)，max_src、max_tgt来自当前 batch 而不是全局配置，这是省显存的关键。make_masks 接收 pad 后的张量，一次性生成三种 mask：src_pad_mask直接比较 src 是否等于 pad_idx，得到布尔矩阵；tgt_mask用torch.triu生成上三角，diagonal=1表示从右上角第一条对角线开始置 True，含义是“遮住当前位置之后的未来词”；tgt_pad_mask同理。这三样东西每次 forward 都要传入，漏掉任何一个，注意力计算都会把 padding 位置或未来位置算进去，训练时看不出明显问题，推理时译文会莫名变差。

3.3 数据清洗与长度过滤：小语料省显存的第一步

除了词表，原始语料的清洗往往决定训练能不能稳定。我的固定流程是：先按行读入平行语料，丢掉空行和明显乱码的行；再统一语言侧的分词方式，英文按空格分词并处理标点粘连，中文可以先用 jieba 分词，或者干脆按字切分——按字切分在词表很小的时候反而稳；最后去掉重复句对。重复句对会让模型把同样的输入输出背下来，验证集里如果混了训练集的重复句，BLEU 会被虚高，答辩时被追问会很难看。

import random def filter_pairs(pairs, max_len=128, min_len=1): out = [] for src, tgt in pairs: if min_len <= len(src) <= max_len and min_len <= len(tgt) <= max_len: out.append((src, tgt)) return out def bucket_batches(pairs, batch_size): buckets = {} for p in pairs: key = len(p[0]) // 10 * 10 # 按源语言长度每 10 词一桶 buckets.setdefault(key, []).append(p) for k in buckets: random.shuffle(buckets[k]) for k in sorted(buckets): for i in range(0, len(buckets[k]), batch_size): yield buckets[k][i:i + batch_size]

长度过滤是省显存和稳定训练的关键。Transformer 的注意力复杂度是 O(n²)，句子越长，内存和耗时涨得越快。毕设语料我一般设 max_len=64 到 128，超过的直接丢弃；同时设 min_len=1，避免空句和单标点句进入训练。bucket_batches是另一个实用技巧：把语料按长度分成若干桶，每次从桶里取 batch，而不是全局随机 shuffle。这样做可以让一个 batch 内的句子长度差距变小，padding 比例下降，训练速度在同样的 batch_size 下能快 30% 以上。注意这个简化版按源语言长度分桶，如果你的目标语言长度差异更大，可以改成按 max(len(src), len(tgt)) 分桶。

4. 训练与推理：学习率、teacher forcing 与 beam search 的落地写法

4.1 必调参数：batch size、max_len、学习率与 warmup 的配置表

先给一张我常用的配置表，它适用于单卡 8G 显存、几万到几十万句的翻译语料。这个配置不是我拍脑袋定的，而是从原论文配置往下缩出来的，缩的幅度由数据量决定。

参数	常见值	作用	踩过的坑
d_model	256	向量维度	512 在小语料上必过拟合
num_layers	3~4	encoder/decoder 层数	6 层是 WMT 配置，别照抄
batch_size	32~64	每步样本数	8G 显存下 64 可能 OOM
max_len	64~128	句子长度上限	过短丢信息，过长吃显存
lr	1e-3	Adam 初始学习率	不开 warmup 就 1e-3 会炸
warmup_steps	4000	学习率预热	不设则 loss 早期剧烈震荡
label_smoothing	0.1	标签平滑	不设容易过拟合
clip_grad_norm	1.0	梯度裁剪	不设长句梯度容易爆炸

配置的核心逻辑是“跟着数据量走”。原论文 d_model=512、6 层、warmup=4000，那是几十万到上百万句的 WMT 语料调出来的。毕设语料如果只有几万句，512 维的 embedding 会把训练集整个背下来，验证集 BLEU 反而个位数。我一般先用 256 维、3 层、batch=32 跑通，再逐步加大。学习率方面，Adam 的默认 lr 是 1e-3，但 Transformer 的梯度尺度对 lr 非常敏感，必须配 warmup 或直接降到 3e-4 固定值。注意 batch_size 和 max_len 决定了一个 step 的实际 token 数，如果显存溢出，优先减 max_len 而不是 batch_size，因为超长句对注意力的内存消耗是二次方级的。

4.2 训练循环：teacher forcing、ignore_index 与梯度裁剪

训练循环的骨架在各类翻译源码里高度一致，差别主要在 mask 的传递和 loss 的忽略位上。下面这段是完整可跑的一个 epoch 写法，基于前面 2.2 的模型和 3.2 的 mask 函数：

def train_one_epoch(model, loader, optimizer, criterion, scheduler, device, pad_idx, clip_norm=1.0): model.train() total_loss = 0.0 for src, tgt in loader: src, tgt = src.to(device), tgt.to(device) tgt_input = tgt[:, :-1] # 去掉最后一个 <eos> tgt_output = tgt[:, 1:] # 去掉开头的 <bos> src_pad_mask, tgt_mask, tgt_pad_mask = make_masks(src, tgt_input, pad_idx) logits = model(src, tgt_input, src_key_padding_mask=src_pad_mask, tgt_mask=tgt_mask, tgt_key_padding_mask=tgt_pad_mask, memory_key_padding_mask=src_pad_mask) loss = criterion(logits.reshape(-1, logits.size(-1)), tgt_output.reshape(-1)) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), clip_norm) optimizer.step() scheduler.step() total_loss += loss.item() return total_loss / len(loader)

这里有两个关键约定。一是tgt_input = tgt[:, :-1]、tgt_output = tgt[:, 1:]，前者负责喂进 decoder，后者是每个位置要预测的真实词，两者形状完全一致；二是criterion必须是nn.CrossEntropyLoss(ignore_index=pad_idx)，把 padding 位置的 loss 全部忽略，否则大量<pad>会稀释真实词的梯度，loss 看起来居高不下。梯度裁剪clip_grad_norm_是 Transformer 训练的保险丝，长句样本的梯度范数可能异常大，不裁剪的话一个 batch 就能把 embedding 打飞。

如果要用原论文的 Noam 学习率调度，可以自己实现一个十行的小类，逻辑是 d_model 的 -0.5 次方乘以 step 和 warmup 两个约束的最小值。它的效果是前 warmup 步学习率线性上涨，之后按 step 的 -0.5 次方衰减。注意scheduler.step()要在optimizer.step()之后调用，PyTorch 2.x 的 LambdaLR 也是这个顺序，写反了学习率会慢一拍。

class NoamScheduler: def __init__(self, optimizer, d_model, warmup_steps=4000): self.optimizer = optimizer self.d_model = d_model self.warmup = warmup_steps self._step = 0 def step(self): self._step += 1 lr = self.d_model ** -0.5 * min(self._step ** -0.5, self._step * self.warmup ** -1.5) for g in self.optimizer.param_groups: g['lr'] = lr

用这个类时，Adam 的 lr 参数会被覆盖，所以torch.optim.Adam(model.parameters())里可以不用传 lr。如果你的训练循环里已经有optimizer.step()，那scheduler.step()只负责更新 lr，不要在里面再调optimizer.step()，否则一个 batch 会更新两次参数。

4.3 推理端：greedy 起步，beam search 提分

训练完成后，推理是另一个故事。最简单的是 greedy：每一步选概率最大的词，拼成译文。速度快，但容易陷入局部最优，典型表现是译文平淡、容易提前结束。要提分就用 beam search，它每一步保留概率最高的 k 条候选路径，最后再选一条整体分数最高的。对毕设语料，beam_width=4 或 5 性价比最高，再往上推理时间成倍增加，BLEU 提升往往不到 1 个点。

def translate_beam(model, src_ids, beam_width=4, max_len=50, bos_idx=1, eos_idx=2, pad_idx=0, device='cpu'): model.eval() src = src_ids.unsqueeze(0).to(device) src_pad_mask = (src == pad_idx).to(device) memory = model.core.encoder( model.pos(model.src_embed(src)), src_key_padding_mask=src_pad_mask ) beams = [([bos_idx], 0.0)] for _ in range(max_len): candidates = [] for seq, score in beams: if seq[-1] == eos_idx: candidates.append((seq, score)) continue tgt = torch.tensor([seq], device=device) tgt_mask = torch.triu( torch.ones(tgt.size(1), tgt.size(1), device=device), diagonal=1 ).bool() logits = model.core.decoder( model.pos(model.tgt_embed(tgt)), memory, tgt_mask=tgt_mask ) logits = model.fc_out(logits[:, -1, :]) # 只看最后一个位置 logp = torch.log_softmax(logits, dim=-1) topk = logp.topk(beam_width, dim=-1) for i in range(beam_width): new_seq = seq + [topk.indices[0, i].item()] new_score = score + topk.values[0, i].item() candidates.append((new_seq, new_score)) beams = sorted(candidates, key=lambda x: x[1], reverse=True)[:beam_width] if all(b[0][-1] == eos_idx for b in beams): break best = max(beams, key=lambda x: x[1] / (len(x[0]) ** 0.7)) return best[0][1:-1] if len(best[0]) > 2 else []

这段是教学用的简化版，把 encode 和 decode 拆开写是为了让你看明白每一段在干什么。beam search 的停止条件是所有候选都以<eos>结尾或达到 max_len。选择最终句时不能只看累计 log 概率，否则模型天然偏好短句，所以加长度惩罚：score / len(seq) ** 0.7。这个 0.7 是经验值，想更稳可以试 0.6~1.0。另外，这个简化版省略了 memory padding mask，单句推理没影响，批量评测时要补上，否则 batch 内不同长度的句子会互相干扰。

5. 避坑指南：Transformer 翻译最容易翻车的五个地方

这些坑是我自己跑翻译类项目时踩过的，也是毕设答辩前后问得最多的问题。每一条按“现象 → 原因 → 解决”的顺序写，对照你自己的日志排查，比从头翻代码快。

5.1 loss 不降或抖动剧烈？先检查 target shift 与 ignore_index

现象：训练几十步后 loss 基本不动，或者在一个值附近剧烈抖动，打印出的 loss 一直是 9~10 这种“天文数字”。

原因：最常见的是 tgt_input 和 tgt_output 没有错位，decoder 输入和目标完全一样，模型学到的是恒等映射，loss 自然降不下去；其次是 CrossEntropyLoss 没设 ignore_index，padding 位置全部参与 loss 计算，噪声把梯度方向带偏了；第三是词表<unk>比例过高，大量输入被替换成同一个 token，模型无从学起。

解决：打印一个 batch，确认tgt_input[0]的前三个 id 是不是[<bos>, 第一个词, ...]，tgt_output[0]是不是[第一个词, ..., <eos>]；把 criterion 改成nn.CrossEntropyLoss(ignore_index=0)；再统计验证集 unk 比例，超过 10% 就回 3.1 重做词表或改子词。

5.2 训练集没问题、验证集 BLEU 个位数？评估脚本和分词粒度在背锅

现象：训练 loss 正常下降，人工看训练集译文也像模像样，但验证集 BLEU 只有 5~10，甚至不如随机。

原因：第一，验证集里混入了训练集的重复句，模型“背”出来的分数虚高，而换到真正的新句子上就现原形；第二，评估时没去掉<bos>和<eos>，特殊 token 参与了 n-gram 统计；第三，模型侧英文按空格分词，而 BLEU 计算时用 sacrebleu 默认的 13a 切分，两者粒度不一致，分数会被系统性拉低。中英混合时这个差异尤其明显。

解决：切分验证集时按句子哈希去重，保证和训练集零 overlap；评估前把特殊 token 剥掉；中英翻译用corpus_bleu(hyps, refs, tokenize='zh')，英文用tokenize='13a'，并把这个配置固定下来写进答辩文档，避免别人质疑你的评估口径。

5.3 显存溢出？batch_size、max_len 和梯度累积三板斧

现象：训练跑不到一个 epoch，PyTorch 报CUDA out of memory，而且往往不是一开始就报，是跑到某条特定句子附近才崩。

原因：Transformer 的注意力内存随序列长度平方增长。很多时候不是 batch 太大，而是 batch 里混进了一条超长句，它一个就占掉了整块显存。

解决：先加长度过滤把 max_len 压到 64，把 batch 里的最长句隔离出来人工检查；再把 batch_size 减半；如果还想保住等效 batch，用梯度累积：每 k 个 step 累加梯度、更新一次参数，代码上就是把optimizer.zero_grad()和optimizer.step()移到一个 if 条件里。注意配合 NoamScheduler 时，学习率要在真实更新那一步才调一次，scheduler 的 step 次数按真实更新算，而不是按每个小 batch 算。

5.4 译文反复重复同一个词？beam search 缺长度惩罚

现象：推理结果形如 “the the the the the ...”，或者中文里某个高频词连续出现，而打分看起来还挺高。

原因：训练语料里某些词出现频率过高，模型在不确定的位置倾向于输出高频词；beam search 累计 log 概率时没有惩罚重复 n-gram，导致重复路径一路保持高分。

解决：在 beam 的累计分数里对已经生成的 n-gram 做惩罚，例如每出现一个新的 bigram 加一个小奖励、重复出现的 bigram 扣分，这是简单的重复惩罚；再配合长度惩罚score / len ** 0.7，两者一起上，重复现象基本消失。如果还不行，回查训练语料，看看是不是有大量整句重复，把重复句对去掉再训。

5.5 复现对不上？随机种子、设备差异和浮点累积

现象：同一条命令在不同机器上跑，loss 曲线和 BLEU 分数对不上，甚至同一台机器两次结果不同。

原因：PyTorch 的 CUDA 卷积和注意力在浮点累加上有非确定性，另外没设随机种子时数据 shuffle 和 Dropout 每一次都不一样。

解决：在 train.py 开头固定三样：torch.manual_seed(42)、random.seed(42)、numpy.random.seed(42)，再用torch.backends.cudnn.deterministic = True和torch.backends.cudnn.benchmark = False换确定性算法。这样至少同配置可复现，答辩时别人问“你这个结果怎么来的”，你能现场跑出同一份数字。注意数据加载器的 worker 也要设种子，常见做法是在 DataLoader 里传一个worker_init_fn，给每个 worker 单独设一次 seed。

6. 验证与进阶：BLEU 打分、译文检查与三个值得做的方向

6.1 用 BLEU 分数说话：sacrebleu 的评估姿势

很多毕设还在用 NLTK 的 BLEU 脚本，我建议换成 sacrebleu，接口更简单，分词口径也更规范。至少要 200~500 句才能算 corpus_bleu，单句 BLEU 没有统计意义；对中英翻译，几万句语料训出的模型 BLEU 在 15~30 之间都算正常，关键是拿它和 baseline（比如 LSTM Seq2Seq）对比，以及看训练/验证集上的差距，而不是纠结绝对数值。

from sacrebleu import corpus_bleu hyps, refs = [], [] for src, tgt in eval_pairs: pred = translate_beam(model, torch.tensor(src, dtype=torch.long), beam_width=4) hyps.append(" ".join(ids_to_tokens(pred))) refs.append([" ".join(ids_to_tokens(tgt))]) score = corpus_bleu(hyps, refs, tokenize='zh' if is_chinese else '13a') print(f"BLEU: {score.score:.2f}")

6.2 人工检查译文的四个维度

自动指标之外，自己读一遍译文才能发现 BLEU 看不出的事。我习惯从四方面看：一是忠实度，源句子里的专有名词、数字、否定词有没有丢掉；二是流畅度，译文读起来像不像人话；三是长度，是不是每句都比参考译文短一截，如果是，多半是长度惩罚没调好；四是标点与大小写是否一致。把翻译失败的案例单独存成一个文件，答辩前专门看这类案例，比盯着总分有用得多。

6.3 拿到这份源码之后，三个值得继续做的方向

如果基础链路已经跑通，下一步我建议按性价比排这三件事。第一，把 word-level 换成 BPE 子词，几行配置就能降低<unk>比例，通常能提升 2~4 个 BLEU；第二，给训练加上 label smoothing 和 Noam 调度，这俩是原论文标配，能明显压过拟合；第三，如果你对同一套架构更感兴趣，可以把 encoder 单独拆出来做文本分类，或者换成 vision transformer 处理图像，把“Transformer 迁移到其他任务”写进论文的展望部分。毕竟机器翻译只是 Transformer 的一个落地点，理解了数据流和 mask，做其他序列任务就只剩换数据的事了。我自己的习惯是每完成一个阶段就把“验证集 BLEU、复现命令、随机种子”写进一个 README 文件，因为答辩前一天你一定会忘掉 beam_width 到底设的 4 还是 5。这个习惯救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取