从技术到体验：vivo机器翻译落地实践
编辑整理：甘雨鑫 上海财经大学
出品平台：DataFunTalk
导读：无论是在工作还是生活中，人们每天都离不开手机。研究表明，截止2020年底，人均使用手机的时长已经高达6-7小时。其实，手机上的很多应用都蕴含着大量的翻译需求。例如：看美剧、和外国友人打电话、发消息，或者浏览一些国外新闻、看论文等。现阶段，很多人都不愿意在手机上使用翻译功能，原因是交互起来非常麻烦，假如我们把实现一次翻译的操作步骤缩短在两步以内，那么可以极大地提升用户的翻译体验。
本文题目为从技术到体验：vivo机器翻译落地实践。我们将结合翻译能力落地的实战经验，围绕翻译能力落地时需要考虑的方方面面展开介绍，同时分享一些快速提升翻译质量的小技巧，主要内容包括：① 做算法前先了解你的业务（业务）；② 算法不仅是NMT模型（算法）；③ 数据决定了翻译效果的上限（数据）；④ 科学评测指引优化方向（评测）；⑤ 工程工作同样很重要（工程）。
在做翻译落地之前，要先了解翻译能力服务的人群和使用场景。这一点很重要，就像我们优化模型的目标函数一样，如果目标函数都错了，模型再怎么优化也无济于事了。不同的人群，他们使用的翻译场景也不一样，翻译的内容自然也有差异。
1. 核心人群分析
可以看到每一类人群都有他们特别的翻译需求，因此我们需要定制化翻译的能力。
2. 高频场景分析
确定好核心服务的人群之后，还要洞察各类人群使用翻译的高频场景，然后根据这些场景去逐个优化、逐个攻破。
3. 需要的翻译技术类型
分析完核心人群和场景后，我们已经基本知道需要什么样的翻译技术来实现我们的需求了。
目前大部分翻译还是聚焦在文本翻译上。但其实我们生活在一个有声有色的世界里，人们还可以通过声音、图像、视频等多模态感知一个事物，而非仅依靠纯文本。我们的翻译也不仅是从文本到文本，而是图像、语音等一系列技术形成的多模态翻译技术。需要什么样的翻译技术，需要依据具体的业务场景确定。
介绍完业务，我们来看算法。这里所说的算法，不仅是NMT（Neural Machine Translation，神经机器翻译）的一个模型。非常庆幸的是现在已经有很成熟的开源翻译框架可以直接使用，这极大程度地降低了我们做机器翻译落地的门槛。
这里列举几个主流框架，大家可以根据实际情况选择使用。模型的训练流程是相对明确的，从数据的搜集、清洗到数据的预处理，再到训练和测试。那完成一次翻译的完整流程包括哪些步骤呢？将输入文本做完分词和BPE（Byte Pair Encoding，双字节编码）直接输入NMT模型就能得到译文了吗？其实不然，一个句子输入到翻译引擎里后，在NMT模型翻译前后有很多前后处理工作要做。下面展开介绍几个核心的模块。
1. 语种检测
平时做实验时测试，都是预先知道输入文本的语种，直接调用对应的翻译模型。但在实际线上使用时，模型并不知道用户输入的是哪国语言、应该调用哪个翻译模型。这个时候就需要做语种检测。语种检测本质上是一个多分类任务，有以下4个难点：
① 难点1：100+分类任务，需要解决数据稀疏和不平衡问题。
市面上主流使用的语种有一百到二百多种，但除了头部大语种外，其他小语种使用的人群很少，网上能搜集到的语料也相对少，因此对于很多小语种上很难获得高质量的带语种标签的数据，并且在实际业务使用中，大语种频率也远高于小语种。
② 难点2单词或缩写的语种难以识别。
输入文本较短时，如单词、短语、缩写缺少上下文，难以判定语种。例如die，在英语中是“死亡”的意思，在德语中又是一个非常高频的冠词，相当于是英文里的“a”、“the”，对于模型来说，没有上下文的信息，很难确定其语种。
③ 难点3：混合语种判断
一句话包含多种语言字符是很常见的情况，例如中文里面夹杂英文术语，或者是在一些特定场景也会出现这种情形，如群聊场景，英文句子“please take a look”中夹杂了“@所有人”的中文，对于语种模型来说干扰很大，需要结合应用场景去做处理后再判断。
④ 难点4：相似语种的识别很困难。
很多语言之间共享语言符号或文字，例如印欧语系中的各个语言，都使用26个拉丁字母，且互相之间共享大量词汇、外来语等，使得如“英语”、“德语”、“意大利语”等同一语系下的语言较难区别。又比如日语中的“走死走爱”，完全是由4个中文字符组成，但并非一个中文词汇，而是日语词汇，表达“相亲相爱”的意思。仅基于各语种的字符占比来识别句子的语种，在相似语种情况下就很难获得准确的结果。
2. 中英文分词
中文等语言在翻译之前通常需要先做分词，将输入文本分割为更细粒度的语义单元，虽然分词和BPE都可以实现这个功能，但BPE完全基于语料的统计信息，可能会忽略句子的语义特征，造成一些错误切割的情况，进而导致翻译错误。例如句子：“你好牛啊”，很容易错分成“你好 牛 啊”，接而翻译成“hello, cow”那就大错特错了。对于英文，连续粘连的单词大多是没有意义的字符串，可能是由前序任务错误传递造成的，对它进行合理的分词，能够确保翻译的准确性。
3. 文本处理
文本处理主要针对英文场景，做翻译前后的大小写和标点处理。Tokenize是将句子中单词与标点或缩写形式分割的操作，句子中标点通常和单词连在一起使用，对于模型来说“ethics.“和“ethics”是两个不同的单词，Tokenize则是将“ethics.“分成两个token “ethics”和“.”的过程，Detokenize是它的一个反操作，这两个是熟知的。
Truecase、Detruecase和Recase都是处理英文单词大小写的模块。英文语法中首字母单词要大写，一个单词在句首和句中会由于它的首字母大小写不同而变成两个不同的单词。
Truecase模块能将句首单词的首字母转换成真实大小写的样子，比如图中例子“Young”这个单词，平时使用时是小写开头，由于在句首所以被大写了，Truecase操作就将它转成小写“young”，如果是“China”呢，是一个专有名词，平时在哪里使用都是大写，则Truecase完会保留它大写的样子。Detruecase是它的一个反操作。
Recase模块通常应用在语料资源不足，全小写训练时。小写训练模型预测生成的译文也是纯小写的，我们不可能把一串小写的文字直接返回给用户，Recase模块就是将句中该大写的单词改成大写的过程。
这么多标点和大小写的操作，应该谁先做谁后做呢？经验来说，最好在所有操作之前做Tokenize，在所有操作都做完后再做Detokenize。
4. 长句拆分
长句拆分这个模块相对简单，但在实际应用中是不可或缺的，它的主要目的是将长的段落拆分成短的句子，提升模型翻译的稳定性和性能。目前主流的翻译模型还是以自回归模型为主，它推理的耗时与输入的文本长度基本上是呈线性关系的。对于较长的文本，可以将其拆成多个子句，通过batch生成或并发调用翻译模型，减少翻译耗时。
具体操作时，可以简单地通过标点等分隔符作为一个拆分。当遇到一些极端的情况，比如句子很长且没有标点时，可以训练一个断句模型来预测句子中自然停顿的地方进行合理的拆分。
5. 混合语种文本拆分
混合语种文本拆分是和长句拆分配合使用的，混合文本翻译时，源端句子包含目标端译文的一部分词汇，经过翻译模型后，源端句中的一些词会被修改的问题。比如图中这段话，我们要将其从英文翻译到中文。句中已经存在很多中文，有经验的同学肯定会想到，若直接将其输入英译中模型，翻译后句中的中文很可能会发生改变，这是我们不想见到的，原因是源端英文词表里可能不会出现这么多中文字符，很难得到充分的学习。这时，我们做混合语种切分，仅将英文为主的句子输入翻译模型，其余不过模型，则能够有效解决这个问题。这里的第一个和第三个句子，主体成分是中文，只有个别专有名词和缩写是英文，这两句就可以不过翻译模型，只需要将第二个和第四个句子调用翻译模型。如此，不仅从总体上缩减了翻译耗时，还最大程度地杜绝了大段中文输入英中模型后中文被改变的问题。
6. 模型领域适应
在训练模型时有两个非常重要的点，一个是模型的领域适应，另一个是模型的鲁棒性增强，下面将分别做介绍。
模型领域适应是为了做更好的业务场景定制，让模型生成的译文更加贴合业务场景的文本特点，显得更加地道。我们介绍两个操作起来比较简单的方法：
① 方法一：微调模型领域
用领域相关的数据去微调模型领域。领域数据获取方法有两种，第一，训练一个领域分类器，它可以对我们的全量训练数据做一个领域的分类，挑出跟业务相关领域的数据以微调模型；第二，运用相似度的检索引擎，从全量数据里检索出业务相关领域的数据。在具体训练时，加大领域相关的文本的权重，或者说在模型快要收敛之前，用领域的数据对模型做一个微调，使它的选词更加符合领域的特点。
② 方法二：改造预测模型
对模型预测做一个改造，主要是在每一个encoder和decoder层都添加一个adapter层，它的主要目的是学习各个领域文本的参数，模型在预测的时候，可以根据文本的领域标签采用不同的参数生成译文，它训练和预测的时候都需要配合领域分类器使用，为每一条数据打上这个领域的标签。
7. 模型鲁棒性增强
模型的鲁棒性在落地的时候是非常重要的，因为神经网络非常容易受小数据的波动，从而产生一些意想不到的低级翻译错误。如果在线上发生低级错误，是很容易遭到用户投诉的。比如此处PPT中，虽然observable这个单词是不完整的，但我们还是期望模型能够根据上下文的语境去猜出来这个单词“可观测的”的含义，而不是翻译成“愚拙的”这样大相径庭的意思。这里，我们列举几个增强鲁棒性比较有效的工作：
① 工作一：随机替换ground truth单词
论文：《Bridging the Gap between Training and Inference for Neural Machine Translation》
该方法改变了模型训练的方式，即在训练时以一定概率随机用预测的词汇替代标准答案的词汇，一定程度上可以缓解暴露偏差和模型矫枉过正的问题。这种方法可以略微提升模型在真实预测时的鲁棒性。
② 工作二：平滑标签算法
该方法主要通过平滑标签的算法调节模型预测时的置信度，将置信度处于一个中间水平。对预测的置信度进行一个区间惩罚，比如重点打压模型预测置信度大于0.7的部分，这在一定程度上可以缓解暴露偏差的问题。
③ 工作三：生成对抗样本
该方法来自谷歌，利用语言模型生成最容易出错的对抗样本作为输入，提升模型在实际使用中的抗干扰能力。
④ 工作四：随机修改数据
在训练时，可以随机去修改一些数据以产生噪声，比如随机增添一些句末标点、做一些单词的随机粘连，以及构造一些不完整的单词。实验表明，该方法能够提升模型的抗干扰能力。
介绍完模型侧，接下来看看数据。众所周知，数据的质量基本决定了模型翻译效果的上限。
1. 拆解分析训练数据
在训练模型之前，一定要详细拆解分析训练数据。我们拿开源数据集mRASP（一个多语言翻译数据集）为例，抽取其中中英数据4000多万语料做样例拆解分析。
mRASP地址：
https://github.com/linzehui/mRASP
首先，做一个长度分布的分析，以此了解该数据的长度分布是否跟真实业务场景数据的长度分布接近。比如当训练数据总体都偏长时，实际使用中，一些短文本如口语的翻译表现可能欠佳。
其次，需要了解数据的领域分布，这一点很重要。因为在训练模型时，数据量达到一定规模以后，往往不是越多越好，而是越对口越好。如图中领域分布所示，mRASP数据集中政治领域占了一半以上，其次是口语和新闻，而其它专业领域的文本是相对较少的。那么以此训练出来的模型，对一些正式、偏书面的文本的翻译质量可能较好，而对一些口语性较强的文本，可能表现欠佳。
最后，需要了解数据的质量，看数据里是否存在一些严重的错误或问题。比如，一些开源数据集中有大段纯大写、纯小写的语料，或者语料没有标点。这样的数据训练出来的模型，在线上表现的时候，很有可能引发大小写或标点错误。甚至有些开源数据集中包含了很多别人做的数据增强，也就是抗噪声样本生成的数据。这时，如果把噪声内侧作为模型学习的目标端，可能就会带来很大的问题。检测以上问题的方法也很简单，大小写、标点类问题通过简单的规则就可以发现。而对于抗噪声增强语料，怎么识别呢？通常我们在构造抗噪声样本的时候，都是保持一侧不变，在另外一侧随机添加噪声。因此一个好的方法是：检测一个句子是否对应了很多个不同的译文，就能发现了。
2. 数据搜集与清洗
在对数据有了初步的了解后，我们需要做数据的搜集与清洗。分为单语和双语两类介绍。
大量的单语数据可以提升译文的流畅度及地道程度。图中列举了一些我们从网上可以搜集到的单语，并对数据的数量和质量做了大致评估。单语数据的质量可以通过语言模型或者质量把关的分类器进行筛选。
双语数据资源是非常稀缺的。上图左边列举了一些双语数据的数据源，右侧列举了对双语数据进行筛选的六大类有效方法供参考。
3. 翻译模型如何“本土化”
让翻译模型更加“本土化”其实就是做模型领域适应，反应了译文的地道程度和与业务领域的贴合程度。上一个章节算法篇有介绍如何从模型方面提升模型领域上的表现效果，这节从数据的角度出发介绍依赖的数据工作如何做。首先，可以搜集大量单语数据来构造回翻数据，增强模型效果。另外，通过领域分类做数据的微调。这里我们有几条经验：
① 经验一
回翻的数据不是越多越好，通常建议不要超过真实语料的50%，小语种上可以酌情增大比例。
② 经验二
回翻数据的领域一定要与业务领域相近。领域不相关的话，即使回翻语料质量再高，模型在评测集上的表现可能也看不出效果。
③ 经验三
加入回翻数据，BLEU（Bilingual Evaluation Understudy，双语评估替换）值不一定提升，这个时候禁用BLEU值评测可能就不够客观了。通常，还要结合人工评测。
4. 从细节处优化翻译体验
如何从数据层面优化我们的线上翻译体验呢？这里我们介绍一些真实落地时的小技巧。
① 俚语翻译增强
高频的俚语其实是有限的，做梳理加入检索库和训练语料，用户触发时地道的俚语翻译能极大提升用户惊喜感。
② 数字、时间、日期表达式翻译增强
数字，时间，日期表达式类数字在模型翻译时经常很不稳定。同样都是数字，有的数字在语料中出现频次高能得到很好的学习，而有些数字出现较少，则可能翻译出错。因此可以在语料里对各类数字、日期等做特定的增强。
③ 缩写翻译增强
缩写的增强也是非常必要的，因为句子中的缩写通常是专有名词，我们倾向于保留不翻译。比如图中例子，在法律文书中，SOW是一个领域专业词，若按其本意“母猪”翻译则大错特错了。
④ 序号、人名、地名翻译增强
序号，人名，地名也可以针对性增强，通过在语料里替换人名地名等槽位，加强那些冷门人名和地名的翻译效果，可以提升模型的表现。
⑤ 结合业务场景定制翻译优化
比如聊天交互场景中，表情符、emoji字符等要确保它不翻译。另外，群聊场景中有很多@某人的情况，若将@后面的昵称混入文本中翻译就错误了，需要强化模型对@人名保持不翻译。
介绍完算法、数据侧的工作后，接下来介绍同样很重要的评测。“信达雅”是我们机器翻译一直在追求的三个境界。主观评测和客观评测都很重要，评测一定是主观评测和客观评测相结合。
对于客观评测，一个评测集是不够的，最好是要去构建多个评测集。多个评测集的功能是不一样的，比如要构造领域评测集，像书面的、口语的、语法现象的、短文本和长文本、简单句和复杂句等，尽量都要覆盖。另外，还要构建一些专项评测集，专门去评测模型的抗噪声、鲁棒性。每次模型训练完成后，就通过多个评测集从多维度去看模型是不是真的有提升，是否产生了新的问题等。
对于人工评测，建议聘请全职的语言专员指导模型的优化和评测模型。客观BLEU值评测存在局限性，它只考虑句子当中的单词和短语命中次数，而无法区分词和短语的重要性。另外，BLEU值也不考虑句法的信息，无法处理像多样化的语言表达。而且像我们具体评测时，语法时态单复数的小错误，和词语漏译增译这样的大错误BLEU值也是没有办法衡量的。所以当模型优化到一定程度时，BLEU值的高低已经无法客观衡量模型的好坏了，这个时候一定要结合人工评测。
1. 性能优化
模型线上运行对性能的要求非常高，图中列举了五种可以快速提升性能的方法。比如上线要求平均请求耗时在200毫秒以内，但你的句子长达200个字符甚至是1000个字符怎么办？这时可以适当做长句拆分，另外，加缓存、做模型压缩、做batch生成等，都可以提升翻译服务整体的性能。
2. 线上快速修复
另外，在上线的时候我们也要考虑线上紧急badcase修复。主要有两个方法，一个是检索库，另一个是翻译干预。
① 方法一：检索库
检索库很简单，就是快速地把错误的数据改成正确译文加到检索库里，这样可以实时修复问题。
② 方法二：翻译干预
检索库只能一对一修复问题，这不够方便。对于一个术语的翻译错误，换一个上下文可能又错了，这时可以用翻译干预技术来做修复。通过自定义快速修复的术语映射表，可以修复不同句中术语的翻译错误。值得一提的是，翻译干预技术使用也有局限性，相对适合一些专有名词、领域术语或者名词性短语，不太适合动词、形容词、副词或虚词这些语义较多的术语。
3. 模型迭代优化闭环
最后想介绍的是，建议构建一个模型迭代优化的闭环流程。整个流程包括线上产生的log、自动化定位语料中潜在的错误、结合人工去做一个预判断，之后分类到各个模块的中具体的错误类型，对错误类型进行修复，修复完之后，不管是沉淀数据还是修复模型，最后都要更新到线上。这样的闭环流程要构建并运转，才能保证模型快速迭代更新。
本文介绍了如何从零构建机器翻译能力，涉及到翻译能力落地的业务、算法、数据、评测、工程等方方面面工作。最后想说，技术永远都是为产品服务的，产品才能解决用户实际问题。技术落地时，我们需要多站在产品、用户的视角寻求技术优化的方向。
Q：如何做单句中混合语种的识别？
A：这个本质是一个动态规划算法。我们需要根据具体的业务场景预先确定哪些混合语种要翻译，哪些不要翻译，然后确定什么样的情况要拆分、什么样的情况不拆分，然后遍历整个文本将待拆分的混合语种边界识别出来进行切分。
举个例子，这里整段的第一个句子里仅包含个别英文单词和缩写，这种的话，我们可能倾向于它是不拆分的。而像最后一个句子，冒号后是英文，而冒号前是中文为主体的，这样我们就会识别出这个边界，做一个切分。其实混合语种文本拆分和长句拆分是配套使用的，它们是共同开发的。