Google 翻译：难的不是语言，是数据分布和一把量不准的尺子

一句话

你以为机器翻译难在语言学，其实难在资源分配和度量：模型形态（编码器–解码器 + 注意力）在 2017 年后基本收敛、不再是争点，真正决定系统成败的是——怎么用一套参数同时服务一百多种语言而不让小语种饿死，以及怎么在一个没有唯一正确答案的任务上判断自己有没有变好。 这是本书里第一道「输出是完整句子、必须逐句评质量」的题。

Glossary · 术语表

坐标

这是 Part II 十道真题的第二道。上承 Ch2 智能撰写——同样是序列生成，但 Ch2 的预算只有百毫秒、被迫用小模型，翻译允许几百毫秒、能上大模型，两章对照正好量出「延迟预算」能把设计拉开多远。下启 Ch4 ChatGPT：从「有参考答案的生成」走向「连参考答案都没有的生成」。现实对应 Google 翻译、DeepL、字幕与文档本地化，以及任何跨语言检索与客服系统的底座。

这章要解决什么

统计机器翻译的做法是把句子切块、查短语表、再拼回去。它能用，但没有任何一块知道整句在说什么，长距离关系全丢——性数一致、语序重排、代词指代，拼接式系统结构上就够不着。

更硬的问题是规模与倾斜。其一，语言对按平方涨——N 种语言两两互译有 N×(N−1) 个方向，N=100 就是 9900 个，每个方向单独训练、上线、监控一个模型，工程上不可能。其二，语料极度长尾——英法、英西轻松拿到上亿句对，很多语言全网可用的干净句对不足 十万，差四个数量级往上。

不解决会怎样？会得到一个「二十种语言很好用、其余一百种像机翻笑话」的产品。而这一章真正的野心是：让那一百种从二十种身上借力。

核心内容，讲透

一、把翻译定义成条件生成

翻译被建模成：给定源句逐词生成目标句，每步在整个词表上挑下一个 token。两条工程后果。其一，延迟与输出长度成正比——生成 N 个 token 就跑 N 次前向，于是「翻长文」和「翻短消息」是两类 SLO：交互式常把 p95 定在几百毫秒，批量文档按吞吐算账。其二，正确译文不止一个，这直接埋下了后面评估那一节的全部麻烦。

需求澄清该问的是：支持多少语言、文本还是语音、交互式还是批量、要不要保留格式与术语表。「支持多少语言」这一问决定架构，其余只决定参数。

二、子词词表：多语言的入场券

词级词表在多语言下当场崩溃：一百种语言的词并起来是几百万条，而嵌入矩阵的大小正比于词表。子词切分（BPE / SentencePiece）把词切成常见片段，用几万条的共享词表拼出任意语言的任意词——包括训练时没见过的人名和新词。

共享词表还有一个常被忽略的红利：它让语言之间产生了真正的参数共享——拉丁字母系语言大量共用同一批子词片段，从西班牙语学到的表示可被加泰罗尼亚语直接复用。代价是词表配额的争夺：不做平衡，词表会被高资源语言占满，小语种的词被切成一地碎片，同一句话的 token 数可能是英语的三四倍，成本与质量一起变差。

三、一个模型吃下一百种语言

做法朴素得出奇：不改结构，只在源句前加一个目标语言标记，如 <2zh> 表示「翻成中文」，然后把所有语言方向的句对混在一起训练同一套参数。

它买到三样东西。运维上，9900 个模型塌成一个，训练、上线、监控、回滚都只有一份。质量上，发生跨语言迁移：低资源语言借用高资源语言学到的句法与语义结构。能力上，出现零样本——从没见过葡萄牙语→韩语的句对也能翻，因为两端各自与英语的映射把中间表示拉进了同一个空间。

代价叫容量稀释（capacity dilution，又称多语言的诅咒）：参数固定时语言越多、每种语言分到的容量越少，高资源方向往往比它的专用双语模型略差。所以真实系统常是混合的——头部方向另配专用适配器，长尾统一走多语言大模型。

四、低资源语言：把数据凭空造出来

迁移能借到一部分，但缺料终究得补。三条主线：

回译性价比最高。目标语单语文本多得是，先用反方向模型把它译成源语，得到「机翻源句 + 人写目标句」的合成句对。关键在方向：输入端是机翻、输出端是真人写的，所以学到的生成分布仍然干净。

语料挖掘：从网页、字幕、多语官方文档里自动配对句子，靠多语句向量算相似度筛选。量极大，噪声也极大——脏语料的危害常被低估：一对错配句子教给模型的不是错词，而是「可以脱离原文自由发挥」。

数据平衡：训练时按真实语料比例采样，等于把绝大部分算力喂给英法德西。实践做法是按语料量的 1/T 次方重新加权（T 越大越平），人为抬高小语种配额。这是一个直接的零和旋钮：低资源方向的分数涨，高资源方向就掉，没有免费午餐，只有你愿意在哪头让步。

五、评估：BLEU 量的不是质量

BLEU 数的是译文与参考译文重合的 n-gram 比例，再乘一个惩罚过短译文的系数。便宜、快、可回归，于是做了二十年默认尺子。但它的假设是好译文长得像参考译文，而翻译恰恰一对多——同义改写、换语序、换句式，人读着一样好，BLEU 直接扣分。

于是标准做法是三层并用：BLEU / chrF 做每日回归的快尺（chrF 按字符算，对芬兰语这类形态丰富的语言更稳）；COMET / BLEURT 这类学习型指标做上线前把关，它们直接在人工打分上训练，与人的相关性明显更高；MQM 人工评估做最终仲裁，贵且慢，只在关键版本上跑。

还有一类自动指标天然测不出的问题要单列检查表：低资源方向的幻觉（输出一段与原文无关却极其通顺的话——错得流畅，生成式系统的典型失败形态）、性别与职业刻板印象、术语与品牌名被「翻译」掉。

关键权衡与选型

表 1 · 一百种语言怎么装：三种架构

表 2 · 低资源语言：四条补数据的路

表 3 · 评估：三把尺子各量什么

为什么重要 / 落到真实系统

这一章的骨架远不止翻译：任何「一套模型服务极度不均的多个群体」的系统都长这样——多语言语音识别、多国站点的推荐与风控、多方言的意图识别。共享参数吃迁移、加标记做条件、用采样配比调公平、最后被一把不完美的自动指标卡住，四步一模一样。

面试里它最值钱的一句是：把「多语言」讲成容量分配问题，而不是语言学问题。 说出「我愿意让英法掉 1 个 BLEU，换二十个长尾方向各涨 3 个，因为增长在新兴市场」，比背任何模型名字都有说服力。

易错点与争议

• 一上来就聊模型结构。 正确开场是问「支持多少语言、分布多不均」——Transformer 之后结构基本不是争点。
• 拿两个 BLEU 数字直接比大小。 分词口径、大小写处理、参考译文数量一变，分数就变，跨论文跨系统不可比。
• 把零样本当免费能力。 它确实存在，但质量明显低于有监督方向，且容易「跑错语言」——输出语种不对是它的典型失败。
• 以为加语言只涨不跌。 容量固定时必然摊薄，高资源方向退步是常态，这笔账要提前摆到台面上。
• 低估脏语料的破坏力。 错配句对不是教错一个词，而是教会模型「可以不看原文自由发挥」——低资源方向的流畅幻觉大半源于此。
• 只在句子级做设计。 真实输入是段落和文档：代词指代、术语一致、格式标签、语气，都要求把窗口开到句子之外。
• 时代局限。 本章以专用翻译模型为主线；此后通用大模型在高资源语言上已能与专用系统一较高下，还顺带吃下了文档级上下文与风格指令。但数据鸿沟与「评估没有唯一答案」这两条根本约束，一条都没被解决。

要点