本文为学习目的的个人翻译，译文及后文「译者总结」仅供参考。
原文链接：How Roblox Uses AI to Translate 16 Languages in 100 Milliseconds。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。
在 16 种语言之间做翻译，意味着要支持 256 种可能的语言对，比如韩语到英语、法语到泰语、葡萄牙语到日语，等等。一种做法是为每一种语言对分别构建一个模型。但 Roblox 决定只做一个。
Roblox 是一个全球化平台，每天有超过 7000 万人在上面玩游戏、创作和社交，这些行为分布在 1500 多万个活跃体验中。用户遍布 180 个国家，并且会在体验内文本聊天中持续交流。如今，一个统一的模型就能为所有这些用户处理实时聊天翻译，单次翻译延迟大约 100 毫秒，每秒处理超过 5000 条聊天消息。
不过，Roblox 真正的工程挑战，并不是造出一个“能翻译”的模型，而是构建一个能够以对话速度完成翻译、又不破坏用户体验的系统。本文会看看 Roblox 构建了什么，以及他们做了哪些权衡。
免责声明：本文基于 Roblox 工程团队公开分享的细节整理。如果你发现其中有不准确之处，欢迎指出。
为每一种语言对单独构建模型，是最显而易见的起点。英语到韩语一个模型，韩语到法语一个模型，法语到泰语再一个模型，依此类推。
在 16 种语言下，这就是 16 × 16，也就是 256 个独立模型。每个模型都需要自己的训练数据、自己的基础设施、自己的维护成本。而当 Roblox 想增加第 17 种语言时，他们需要的不是一个新模型，而是 32 个。这个方法会以平方级增长，在真正上线之前就会因为复杂度失控而崩塌。
Roblox 走了另一条路。
他们构建了一个基于 Transformer 的统一翻译模型，用来处理全部 256 个翻译方向。让这件事可行的关键架构叫作 Mixture of Experts，也就是 MoE。不是每一个翻译请求都会经过模型中的所有参数，而是通过一个路由机制，根据输入只激活其中一部分专门化的“专家”子网络。
不同的专家会专注于一组相近语言。给定源句子和目标语言后，系统会激活对应的专家，或者是专家组合，来生成翻译。你可以把它想象成一组坐在同一个前台后面的专业译员。请求来了，路由层把它送到合适的专家那里，真正干活的只有那个专家。整个团队具备广泛能力，但任何一次翻译实际上只会激活其中一小部分。
这种统一方案带来了一些明显好处。所有语言一起训练时，相近语言实际上会彼此增益。比如西班牙语和葡萄牙语在结构上足够接近，把它们放进同一个模型里训练，会同时提高两者的翻译质量。模型还会学到足够多的语言模式，因此即使语言设置错误或缺失，它也能自动识别源语言。它甚至可以处理混合语言输入，也就是用户在同一条消息里夹杂两种语言，仍然能把内容合理地翻译成目标语言。
但整合也是有代价的。如今，一个模型要承载全部 256 个方向的负担。为了在如此多样的任务上维持可接受的质量，Roblox 的模型最终做到了大约 10 亿参数。对这样一个大模型做推理，在大规模实时聊天场景下既太慢，也太昂贵。架构问题解决了，但服务问题才刚开始。
一个 10 亿参数的模型可以给出不错的翻译，但它的速度还不足以支撑两个人的实时对话。
在每秒 5000 多条聊天请求、延迟上限约 100 毫秒的前提下，Roblox 必须填平一个很大的差距，才能把系统真正做到可生产使用。他们靠两步做到了。第一步，把模型变小；第二步，用一套基础设施把剩下的每一毫秒都榨出来。
Roblox 使用了一种叫作 knowledge distillation 的技术，也常被描述成 teacher-student 方法。思路很直接：先训练一个大而高质量的模型，也就是 teacher；然后再训练一个更小的模型，也就是 student，去模仿 teacher 的输出。关键点在于，student 学的并不只是 teacher 的最终答案，而是 teacher 对所有可能翻译结果的概率分布，换句话说，也就是 teacher 在不同翻译候选上的置信度。
通过这个过程，Roblox 把模型从大约 10 亿参数压缩到了不足 6.5 亿。除了蒸馏之外，他们还使用了 quantization，也就是降低模型权重的数值精度，以及 model compilation，也就是针对特定硬件优化计算图。这些都属于叠加在蒸馏之上的额外压缩手段。
不过，服务基础设施才是另一半故事。即便是蒸馏后的模型，在这个规模下也无法单靠自己跑进 100 毫秒。模型只是更长链路中的一个组件，而大部分延迟优化实际上发生在模型之外。
当一条聊天消息需要翻译时，它会先经过 RCC，也就是 Roblox 的后端服务。在模型真正介入之前，系统会先查翻译缓存。如果完全相同的“源文本 → 目标语言”翻译以前已经做过，就会立刻返回缓存结果，无需再做模型推理。
如果缓存未命中，请求就会进入后端，在那里一个动态批处理器会把多条翻译请求打成一批。批处理非常关键，因为 GPU 在一次处理多条输入时，效率远高于逐条处理。之后，这批请求会流经模型的 encoder 栈，把源文本转成数值表示。
这时候，第二种不同的缓存就发挥作用了。Roblox 在 encoder 和 decoder 之间加入了 embedding cache。这个优化对应一个在平台上频繁发生的场景：假设一个韩语用户在一个同时有英语、德语和法语用户的服务器里发出一条消息，那么这同一条韩语消息就需要分别生成三种翻译。如果没有 embedding cache，encoder 必须把同一条韩语消息重复处理三次。有了这个缓存后，编码过程只做一次，中间表示会被缓存下来，decoder 再基于这一份编码结果生成三种翻译。在 Roblox 这种聊天流量规模下，这个优化非常可观。
最后，解码后的译文会经过 Roblox 的信任与安全系统，也就是平台对所有文本都会执行的同一套审查流程，以便拦截任何违反平台政策的内容。随后，系统会把译文和原文一起发送到接收方设备上，让用户可以在翻译结果和发送者原话之间自由切换。
一个翻译模型的效果，最终取决于两件事：它训练所用的数据，以及你是否有能力衡量它到底表现得怎样。对于 Roblox 这种规模下的 256 个语言方向来说，这两件事都很难。而 Roblox 为这两件事都构建了定制方案。
标准的翻译质量评估指标，通常会把模型输出和一份“正确的人类翻译”进行对比，这份正确答案通常被称为 reference。但如果要为 256 个语言方向、覆盖 Roblox 聊天消息的体量与多样性，持续产出 reference translation，这几乎是不可能的。你需要人类译员为每一种组合不断生成 ground truth。Roblox 的解决办法是构建自己的质量估计模型，它只基于源文本和机器翻译输出打分，不需要 reference translation。
这个质量模型会从多个维度评估翻译结果。 它会检查准确性，也就是是否有增译、漏译或误译；检查流畅性，包括语法、拼写和标点；以及检查 reference consistency，也就是这条翻译放回整段对话上下文中是否合理。
错误会按严重程度分为 critical、major 和 minor 三类。这个模型的粒度是词级别，而不只是句子级别。它不只是把一条翻译粗略标成“好”或“坏”，而是会指出究竟哪些词错了，以及错误有多严重。
为了实现这点，Roblox 先基于人工标注的错误类型和评分训练了一个机器学习模型，然后再对一个多语言语言模型做微调，让它能够预测词级错误，并按照他们的多维标准进行评分。
像英语到西班牙语这样的常见语言对，在网上有大量平行语料，甚至能找到数十亿组对齐句子。但也有一些稀有组合，比如法语到泰语。如果你手里没有这两个语言之间的翻译样本，就很难把这个方向的翻译器训练好。
Roblox 用 iterative back-translation 来应对这个问题。做法是先拿一段法语文本，用当前模型把它翻译成泰语，再把这段泰语翻译回法语。然后把回译结果和原始法语进行比较。如果两者足够接近，那么中间那组法语-泰语翻译结果大概率就是一条不错的合成训练样本。
这里最关键的词是“iterative”。Roblox 不是只做一轮，而是进行了多轮迭代，把这种合成出来的回译数据和人工标注的监督数据混合起来，逐步扩充训练集。合成数据和真实数据之间的比例很重要。合成数据太多会让质量下降，因为模型会开始反复学习自己制造出来的错误。
通用翻译语料里，并不会包含像 “obby”（Roblox 中的障碍闯关玩法）这样的词，也不会包含平台特有的俚语和缩写。Roblox 引入了人工评估人员，把热门词汇和趋势词汇翻译成 16 种语言，再把这些翻译结果喂回训练数据中。这是一项持续工作，因为俚语的变化速度总是比任何一次模型重训都更快。
Roblox 的统一翻译模型确实带来了真实成本，而理解这些成本，和理解它的架构本身一样重要。
- 质量与延迟之间始终存在张力。蒸馏后的 student 模型在先天上就比 teacher 更不准确。每当 Roblox 改进 teacher 时，他们都必须面对一个问题：这些提升在压缩后还能保留下来吗？而 100 毫秒这个硬上限，也限制了线上服务模型到底能做得多大、多准。
- 低资源语言对依然是薄弱环节。回译能提供帮助，但法语到泰语永远不会像英语到西班牙语那样好。模型可以处理混合语言输入，但准确率会下降。统一模型不意味着所有方向的质量都完全一致。
- 维护负担是真实存在的。自己构建定制翻译模型，就意味着要拥有整套栈：训练、评估、服务、俚语更新、安全集成，全部都得自己负责。使用商业翻译 API，则是把这些复杂性转交给别人。Roblox 这样做是合理的，因为他们需要非常强的领域特定准确性（按他们自己的指标，在 Roblox 内容上，他们的模型优于商业 API），同时还要在超大规模下做到极低延迟。对大多数公司而言，更合理的选择依然是使用现成翻译服务，把工程精力投入到别处。
- 这种无需 reference 的质量估计模型虽然很聪明，但也有天然局限。它可能会带有一些系统性偏差，而这些偏差又恰好与翻译模型自身的弱点重叠。所以它是一个务实方案，但不是完美方案。
参考资料：
译者总结
这篇文章真正想说明的，不只是“Roblox 用 AI 做翻译”，而是他们如何把一个原本会随语言数量平方级膨胀的问题，压缩成一个可以统一维护、还能在实时场景中跑起来的工程系统。
可以重点记住四点：
- 统一模型解决的是规模复杂度问题：16 种语言不是只多 16 个方向，而是 256 个翻译方向。Roblox 选择单模型 + MoE，本质上是在避免多模型体系失控。
- 蒸馏、量化、编译和缓存解决的是延迟问题：大模型能提升质量，但要把延迟压进 100ms，真正关键的是模型压缩和服务链路优化，而不只是模型本身。
- 质量评估是独立难题：当语言方向很多、人工参考答案又不可能持续覆盖时，怎么评估翻译质量本身就成了一个单独的机器学习问题。
- 低资源语言和领域词汇始终需要额外投入：统一架构并不能自动消除长尾语言对、平台黑话和俚语带来的问题，这些部分仍然要靠数据构造和人工维护兜底。
如果把这套方案抽象开来看，它其实很像很多 AI 系统的通用工程结论：模型设计只解决一部分问题，真正决定线上体验的，往往是压缩、缓存、批处理、评测和安全这些外围系统。