日均 5 亿字符翻译量，百毫秒内响应，携程机器翻译平台实践

随着国际化进程的开展，携程正加速第三次创业，各部门及业务场景对多语种的需求日益增长，依靠译员或精通多语种的客服难以支撑持续扩大的自然文本翻译流量。机器翻译技术作为近年来人工智能领域在自然语言处理任务上探索的先驱，逐渐走出学术的象牙塔，开始为普通用户提供实时便捷的翻译服务，并已取得了显著的成效。在这样的形势下，针对旅游服务场景提供更高质量低成本的机器翻译服务成为了一个重要课题。

一、需求分析

就翻译工作本身而言，有专业译员和机器翻译两种方案。目前机器翻译技术的普遍水平在短期内是无法完全替代专业译员的，首先需要找到机器翻译的合理价值点。

考虑 AI 的优势在于高效、低成本的处理能力以及随时随地按需弹性扩展，我们能快速推导出机器翻译的两类适用场景：

1）冷启动，也就是需要短时间内翻译大量文本的情况；

2）实时场景，需要翻译的内容是不断动态变化无简单规律可循的，并且一般要求即时的翻译结果；

从交流层面，员工、客户、供应商之间或内部的跨地区沟通就是典型场景，包括但不限于企业 IM、运营工单系统、攻略点评社区等等。特别的，在客户的行程中可能还有涉及到与当地人沟通交流的线下场景。

其次，从办公角度来看，对于大型企业内部的工具如 IM、邮箱，系统如人事系统、帮助中心，文档中心如 wiki 或大型 confluence 系统的国际化都满足上述情况。

最后是运营角度，产品相关条目如名称、描述、政策条款，项目的文案报告、行业信息资料等等也面临着短期大量需求接踵而至的挑战。

这些场景中，机器翻译都能很好的起到人工替代或者润滑助推的作用。

图表 1 携程机器翻译场景分析

二、推广使用

携程的机器翻译技术研发工作于 18 年中展开，在 19 年中成立平台正式服务于全公司各类业务场景。目前已经能够支持 34 种语言（超过 1000 种语言方向）的自动翻译，能够对 180 种以上语言进行自动检测识别。未来计划会扩充到 54 种语言，其中包括对中文、英语、西班牙语这三个常见语种进行区域化细分。

携程各业务场景中，机器翻译平台已向超过 150 个入口提供支持，以百毫秒内的平均响应性能达成 5 亿字符的日均翻译量，可承受超过 25 万字符数的瞬时并发请求。

根据业务部门的反馈数据统计，我们的机器翻译效果评估结果在旅游垂直领域内高于行业内平均水平 10 个点以上，内部的用户满意度调研中，超过一半的用户有推荐使用的倾向。

图表 2 携程机器翻译平台简况

三、平台架构

得益于携程私有云和技术中台化，机器翻译服务通过中台可以轻松的对接上百个使用场景，包括客户端、APP、H5 等多种入口，用户可以在中台很方便的了解产品、试用产品、一键接入翻译能力。在容器化的资源调度、数据存储、系统监控等各方面，携程私有云也提供给了机器翻译服务最基本的基础设施保障，使技术团队能专注于算法本身的研发优化工作。

机器翻译技术的整体架构分为三部分，前端接口层负责服务接口、翻译内容识别、语种检测等。翻译内容识别需要我们从各种各样的数据格式中找出需要翻译的内容并剥离出来，比如网页、富文本、甚至图片等，在交给下游处理逻辑翻译完成后重新拼接回原始数据格式。语种识别也采取了规则初筛加语义模型细分的基本策略实现。

在中端预处理层，我们会进行一些语种相关的文本的预处理工作，并通过负载均衡交给后端模型进行正式翻译。

在后端模型服务正式翻译前，我们会做一个批次化操作。之所以引入批次化操作是由于深度学习模型的特点是具有大量的向量化操作，此类操作可通过专门的异构计算设备进行加速。这个加速过程的效率除了受加速器本身算力的影响外，数据在各个级别缓存之间吞吐的速度与数量、核心计算 kernel 发起次数等非计算本身因素也有很大的制约效应，比如 GPU 这种多核心设备，容易存在木桶效应无法充分利用所有核心，小数据量多次运算的效果往往不如合并运算。

通过这个批次化操作，对模型接收到的推断请求进行拆分打包重组，可以使得整个系统的瓶颈从计算以外的因素回归到设备算力本身上，充分释放加速器的性能潜力，牺牲一部分小请求的延迟来降低平均与最差响应延迟，提升整体用户体验。

图表 3 批次化模块处理

最后由基于深度学习的模型完成最终的翻译工作。我们的模型主要参考了 Transformer 的结构，这是一种由谷歌 17 年提出的翻译模型，包含编码器、解码器两部分，其中的 self-attention 子结构在自然语言处理的各种任务中被广泛采用，在很多领域的 SOTA 实现中都能见到它的身影。

图表 4 携程机器翻译平台基本架构

四、数据建设

AI 除了算法研究以外，数据建设也是很重要的一个环节，在机器翻译服务平台的研发过程中，我们建立起了一个良好的数据闭环。

通过开源数据的采集，私有高质量数据的采购，携程自身业务开展过程中的收集等渠道完成了一定程度的原始积累。有了这样的积累后，我们便开始孵化各种算法，并应用算法进行数据生成、数据治理，进一步提高我们数据的质与量。

具体来说，翻译数据非常依赖于平行语料，而我们的数据采集过程中获取的单语种语料占了大多数，并且有着更加丰富从计算机到新闻到旅游的话题种类。通过翻译模型、句子级别的编码器等我们可以进行反译、句子对齐，甚至通过文本自编码器或者来自业务使用方的 badcase 反馈来产生创造更多的平行语料。

同时，平行语料打分器、字词对齐工具、语言模型由可以对我们所有的数据进行质量评估，筛选出高质量的语料进行保留，清理矫正脏数据，并对数据进行更加细致的分门别类。这样高质量的数据又进一步提升了算法水平，最终形成一个良性的数据建设闭环，对于我们机器翻译技术应付低资源语种、多场景问题带来了极大的帮助。

目前，这个数据闭环已经能够为我们提供多达 60 种语言 26 亿句的平行语料库，建立了一个数量达 500 万的专业术语对照词库，并且为大多数数据打上了各类细分场景、质量评分等标签。

图表 5 携程机器翻译数据建设闭环

五、算法设计

5.1 文本预处理

文本预处理首先是序列标注，用于定位文本中的领域或歧义信息，然后是词法分析，将文本分为连续的 token 块，并标注每一个 token 块属于哪种基本成分（如普通文本、标点、关键信息）。这两步操作的目的是为了后续的一系列人工干预措施。

领域和歧义信息主要是文本中的一些实体、术语构成，这类数据在各个语言下往往会有专业的表达，可以通过词库、用户术语表、规则翻译来很好的解决绕开模型处理。

在翻译前对原文以及翻译后对译文我们都会对文本进行规范化处理，以保证文本习惯，如标点、金额、单位的使用符合本地化规范，有助于模型翻译质量以及最终译文的友好呈现。简单的举例有：标点前后的空格、不同国家使用的金额单位、数字的千分位、万分位转换等。

词法分析的结果除了文本规范化以外，也被用于句子切分，过长的句子对于翻译模型的质量与性能都不太友好。

总结下来，预处理模块的工作目的就是用人工干预的手段在模型以外帮助机器翻译得到更标准、更地道、更专业的译文结果。

图表 6 预处理模块相关工作

5.2 任务空间信息融合

由于我们业务场景繁多、语种涉猎广泛，如何节省训练、部署资源应付多样化的需求是必须考虑的问题，为此我们借鉴并引入了任务空间（task space）的思想，令一个模型完成多语言翻译任务并且面对不同的场景将可能有歧义的字词被正确翻译的概率提高。

我们把一次翻译任务的语向、涉及的场景标签作为空间信息融合进模型输入以获得期望的输出，考虑到我们场景的多样性以及共存，20 种场景可能会有 100 万种组合，这样的复杂度无论是 one-hot 还是 multi-hot 这类静态表达方式都难以很好的处理。所以参考了 self-attention 结构，通过一个可训练的 query 向量来动态的生成固定大小场景向量，并与语向向量合并最终加入模型，这样的表达方式类似自然语言处理的过程，更加灵活且能够通过数据驱动来自适应泛化到数据中没有的任务组合上。很好的解决了低资源、多场景的单模型训练与部署问题。

图表 7 任务空间信息融合模型

编码和解码分别采用了不同的 task space encoding，因为我们在一些实验中发现分开编码能够提升模型的最终指标，通过对语向编码的部分可视化分析可以看到，各语言之间的相对位置关系发生了明显的变化，说明模型确实在编码和解码的过程中，对语向信息有着不同的高维理解。

图表 8 编码器、解码器任务空间的不一致性

场景标签信息的融入也在中英模型、中英日韩模型两组对照实验中的评价指标 bleu 上有相应的体现。

图表 9 任务编码空间对于模型性能的影响

5.3 术语翻译干预机制

被定位的关键信息会通过既有的翻译规则、词表、用户术语表来进行更为准确的翻译。为了让模型处理好这种已有翻译解决方案的关键信息连同上下文一起翻译的情况，就需要我们在机器翻译模型中用到一种统一干预机制——词对齐。

图表 10 词对齐机制模型拓扑图

将关键信息定位后，我们会用占位符进行替换，不同类型的关键信息可能会被替换为不同种类的占位符，比如下图里，红框的信息会被替换为人名占位符、黄框会被替换为时间占位符，蓝框会被替换为数字占位符。之所以对不同的关键信息用不同的占位符替换是为了尽可能保留占位符的词性、内容信息，以帮助模型更好的理解翻译内容及句子结构同时不必过于注意信息细节。

图表 11 占位符示例

经过占位符替换后的文本进入翻译模型，就像 UNK（表外词）一样，被正常翻译并出现在译文中合理的位置。这里存在一个问题，即不同语言由于语法的差异可能有不同的语序，译文中的占位符并不能根据顺序一一与原文对齐，并且由于语言习惯，可能对存在一个占位符被多次提及或者多个相同指代的占位符被省略为较少占位符出现在译文的情况。这样便需要通过一个词对齐步骤来将原文与译文中的占位符进行一一关联，以追溯原始信息，并交给上层逻辑进一步处理。

翻译模型中的交叉注意力机制（cross attention mechanism ）得到的注意力矩阵就是很好的信息来源，但是直接使用这个矩阵存在一些问题。首先是多头注意力机制存在不一致的结果时应该参考哪一头？注意力矩阵的结果代表概率分布，如何选取一个阈值进行二值化处理？注意力矩阵通常存在一个注意力漂移问题，即生成当前词的时候注意力可能在上下文其他词上，影响对齐结果。

我们用了数据驱动的方案解决这个问题，首先我们注意到多头注意力矩阵有点类似多通道的图像，通过一系列卷积层和最后一个逐像素逻辑回归，可一次性解决多头选取、阈值选取和注意力漂移问题。

有一些传统的基于统计的词对齐工具，通过 IBM Model 也就是 EM 算法进行词对齐工作，相关工具有 Berkerly Aligner、Fast Align 等，我们选取 Fast Align 作为基础标注生成器，用于监督对齐卷积神经网络的训练。

图表 12 词对齐工作及标签获取

之所以不直接采用统计学习的工具，主要有以下几点考虑：

a）我们需要定义各种不同类型的占位符，且占位符数量不受限制；

b）交叉注意力矩阵可能带有句子级别的信息，能泛化出更好的对齐结果；

c）统计学习的结果通过翻译模型加对齐模型的联合训练，进一步提升翻译模型的质量以及帮助提升收敛速度；

d）单个深度学习模型解决问题可以通过加速器获得更好的性能，整体架构风险可控，部署方便；

为了获得更好的泛化能力，我们对于统计学习模型的结果会进行随机采样，最终在占位符对齐任务上仅仅依靠模型可得到 96%的准确率。

损失函数设计：

其中δ是{0,1}随机掩码

图表 13 词对齐模块工作性能

5.4 低资源语种翻译质量评估

低资源语种除了模型翻译质量的问题以外，在翻译质量评估本身上也有一定的困难。主要表现在缺乏标准数据、缺乏专业译员指导上，WMT 世界机器翻译大会也有专门的翻译质量评估（QE）赛道，可见其重要性。

为此，我们提出了一种无监督的质量评估方式，这个方案由三部分组成

第一部分是无监督覆盖率分，Muse 是 Facebook 提出的可不借助任何平行语料的无监督翻译建模方法，他的基本思想是将来自不同语言的句子映射到同一个空间进行翻译。使用生成对抗网络--也就是生成器学习映射关系，使得判别器不能区分词向量映射后来源；判别器相反尽力区分词向量来自源语言还是目标语言。

通过词空间的映射，我们得到了由无监督学习产生的双语对照词表，在一组语种两个语向上我们分别生成一个辞典，每个词可以存在多个候选译文单词。通过这个辞典我们可以很方便的计算待评测译文的词级别召回率。

图表 14 Muse 的跨语言无监督词空间映射

第二部分是词向量距离分，使用 Muse 训练结果中的词向量进行空间距离计算，对每个源端词选取的一个最近的距离进行求和得到。

第三部分是语言模型分，我们选用了 transformer-XL，因为它能将大量的篇章级单语文本用于模型训练，更充分的利用单语语料数据。

图表 15 Transformer-XL 的篇章级语言模型训练

最后通过系数调整合并成为最终的双语质量分，通过在标准数据、随机数据上与 BLEU 比较都能得到一个接近 1 的相关性系数，表明我们的无监督评分结果有不错的泛化能力，可以在不少语向上接近并替代 BLEU。

图表 16 无监督翻译质量打分工具性能评测

综合翻译质量打分公式：

然而，这个打分机制里缺乏了句子级别的语义理解信息，同 bleu 一样存在缺陷，还有很大的提升空间和工作要做。

六、性能优化

我们首先分析网络结构中是否存在冗余计算，transformer 的 decoder 部分就是个很好的例子。由于我们前面提到的模型自回归性质，解码器是一个词一个词进行推理的，每个词的迭代过程需要与历史词进行 self-attention 计算，因为这里 kv 的值是历史值，所以我们通过缓存就在之后任意时刻的迭代轮次中可以获取到，不需要重复计算。

然后分析算法的改进空间，再一个典型的例子就是生成模型的 beamsearch 算法。一般每轮迭代会延续之前几个 topk 结果进行计算，保留至多 k 个终结搜索路径作为候选池，比分方法是累计每条路径上的困惑度，对于不通长度的后选句进行长度惩罚以公平比较，也就是困惑度相同的情况下越长的候选句子分数一般越高。

这样就可以引入 earlystop 机制，因为推理有最大长度限制，困惑度又是累加的，我们很容易发现困惑度累积到一定程度后，即使假设句子长度达到最大获得更有优势的惩罚系数，仍然无法得到比候选池里句子更高的分数，此时搜索就可以提前终止了。另外在编码器中使用 rnn 结构，避免每次迭代都对过去时刻进行运算也是一种结构上的优化手段。

从框架层面分析，通过算子的自定义、算子融合、减少访存开销来提升计算效率。

从系统角度分析，则是尽可能使用高性能数学库，无论是 cpu 还是 gpu，若非针对特定场景，很难手工复现出比官方的高性能数学库更好综合性能的基本算子。

对于 CPU 来说，编译及运行时优化层面，使用 intel 提供的编译器和硬件 SIMD 指令集，并且在硬件资源调度层面上，绑定 CPU 核心到进程上避免线程迁移，是可以快速吃到的性能 Free Lunch。

对于 GPU，我们主要参考了 NVIDIA 的 FasterTransformer2.0 方案，并针对自己网络情况作出了必要的定制化修改。包括：

a）更改内存布局，将所有 GEMM 运算之间的计算融合成一个调用核心，调用 cuBLAS 的 GemmBatch 进行运算，有效避免了无意义的显存申请以及矩阵转置操作。同时也减少了内存访问、多线程启动开销，并在硬件允许条件下，在 GPU 上使用 tensor core 的方式进行 GEMM 运算。

b）采用低精度 FP16 进行推理计算，FP16 可以充分利用 Volta 和 Turing 架构 GPU 上的 Tensor Core 计算单元，同时显存降低为原来一半。

c）对于比较复杂的 算子，它们很多不适合 GPU 上并行的规约操作，针对这种情况我们根据 GPU 的硬件特性重新设计新算法，极大降低了这些算子的延迟。

d）由于 NLP 的采用变长输入特性，为了避免运算中不断地分配释放内存，我们通过 Caching 方式管理显存，一次请求中直接按预先确认的峰值内存申请一个大内存，请求间托管给 Tensorflow 进行内存整理。

通过以上几道措施，相比原始的 Tensorflow 实现，我们达成了至多接近 7 倍的加速比，同时在模型精准度上几乎没有任何损失。

具体情况可见下图，我们测试了不同压力下（根据 batchsize 调整）的模型推理速度，并根据线上压力分布计算了最大（MAX）、期望(EXP)、平均(AVG)加速比以及模型推理准确率（BLEU）。其中 BLEU 回归测试中 FP16 方案可以拿到 99.9 的高分，证明了低精度模型能够很好的应付生成模型的推理场景。

图表 17 在 Tesla T4 上参考 NVIDIA FT 2.0 方案后的各推理压力下的加速比表格

七、结语

通过技术的不断更迭、平台的持续运营，我们的机器翻译服务质量逐渐能够满足实际场景的需求了。客服、订单、事件、IM、产品等各类内外部系统中都能够看见机器翻译服务为国际化做贡献的身影。

随着场景的铺开，针对各场景在质量、性能、服务方式上的个性化与多样性有着更大的挑战。在这样一个有巨大提升空间的背景下，我们将继续完善技术建设，给互联网旅游行业带来最佳的用户体验。

参考文献

【1】Vaswani A,Shazeer N, Parmar N, et al. Attention is all you need[C]//Advances in neuralinformation processing systems. 2017: 5998-6008.

【2】Vaswani A,Bengio S, Brevdo E, et al. Tensor2tensor for neural machine translation[J].arXiv preprint arXiv:1803.07416, 2018.

【3】A. Conneau*, G. Lample*, L. Denoyer, MA.Ranzato, H. Jégou, WordTranslation Without Parallel Data

【4】Dai Z, Yang Z,Yang Y, et al. Transformer-xl: Attentive language models beyond a fixed-lengthcontext[J]. arXiv preprint arXiv:1901.02860, 2019.

【5】Graves A.Sequence transduction with recurrent neural networks[J]. arXiv preprintarXiv:1211.3711, 2012.

【6】https://github.com/NVIDIA/DeepLearningExamples/tree/master/FasterTransformer

作者介绍：

Chan Yu，携程资深算法工程师，主要从事机器翻译的算法研究与工程应用，目前专注于多语种自然语言处理在垂域下的成熟解决方案。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

日均5亿字符翻译量，百毫秒内响应，携程机器翻译平台实践