作者：蒋宝尚、Andy
这两天，微信翻译团队难得的上了次热搜。
事情的发展是这样的。有网友发现，当翻译中带有caixukun的人名拼音时，微信翻译会出现一些奇怪的中文词语，比如👇
之后，不仅人名测试开始一发不可收拾，网友们纷纷出动，想要寻找微信翻译的其他彩蛋👇
网友们因此大为惊奇，玩得不亦乐乎，以至于这个话题被推上了热搜。
针对相关问题，腾讯微信团队昨天也做出了回应，强调这不是暖心的彩蛋，是翻译引擎在翻译一些没有进行过训练的非正式英文词汇时出现误翻。
文摘菌今天早上进行测试，发现微信团队已经修复了bug，已无误翻的情况，但是，带有人名的句子在翻译中会直接全句copy下来。
微信翻译BUG都是算法的锅？
那么，真的像微信翻译团队所说，这一翻译车祸现场都是算法的锅吗？
文摘菌咨询了自然语言处理领域的两位专家，他们表示，算法上当然也有问题，但是，更大的问题可能在于训练语料。
目前，机器翻译领域主要使用的NMT架构都差不多，一方面问题出在解码器语言模型，使用的语料让它学习到了这些最大概率出现的词。
微信团队在处理的过程中似乎没有对“特殊情况”进行处理，更准确来说，模型没有添加copy机制，无论输出的英文“单词”多么奇形怪状，模型都会遵守最大概率原则对单词进行翻译。
如果添加了特殊词的copy机制，完全可以把无法翻译的单词不进行翻译，直接copy过去。
也就是说，一个聪明的模型应该知道哪些应该翻译，哪些不应该翻译，微信团队做的这只AI显然不够聪明。
从目前微信的修复结果全局copy来看，微信团队似乎已经重新设置了这一机制，对于敏感词“caixukun”或者句式“you are so……”进行原句返回。
另一方面，问题可能更多出现在语料库上，现在业界所做的机器翻译很大程度上靠语料“怼”，只要平行语料数量足够多，质量足够好， 其实一般的系统也可以训练出很好的结果。
之前在知乎上就有一个问题询问微信翻译团队如何设置，根据自称团队成员”LynnCui“的爆料，微信翻译是由微信后台一小撮不到10人的工程师团队从零折腾出来的引擎完成翻译的。
嗯~语料库、算法、不到10人......根据这些线索，文摘菌猜测微信翻译出现这种问题的原因是：训练语料。如果训练语料多来自相对便宜的电影字幕、多语言会议等材料，那么模型最终呈现的翻译内容也会相对应比较“活泼”和“口语化”。
而在面对库中不存在的词，比如caixunkun，算法会自动匹配最经常出现，或者在同语境下最容易匹配的内容，比如形容词“帅哥”、“傻蛋”。
那么，经过这一乌龙事件，微信团队是否会真的重视起翻译产品，然后重金重制语料库呢？我们拭目以待。
谷歌相关事件
其实相关翻译乌龙并不只有微信出现过，翻译领域的先驱谷歌也有过类似的事件。
之前外媒Motherboard有整理来自Reddit论坛的帖子发现，谷歌翻译在学习的过程中可能受到了输入来源的影响，竟将一些意味不明的语句翻译成了如圣经一般的语言。
比如，若用户将翻译设置为从毛利语翻译成英语，之后输入一长串的“dog”（英文意为“狗”），最后会得出这样的结果。
翻译出来的英文大意为：
世界末日时钟在12点3分钟，我们正在经历世界上的人物和戏剧性的发展，这表明我们越来越接近末日和耶稣的回归。
哈佛大学助理教授，研究自然语言处理和计算机翻译的Andrew Rush认为，这些神秘的翻译结果可能和谷歌几年前采用的“神经机器翻译”技术有关。他表示，在神经机器翻译中，系统训练用了一种语言的大量文本来和另一种语言进行相应翻译，以在两者之间创建模型。但当输入的是无意义内容时，系统就会出现“幻觉性”的输出结果。
由于谷歌这一学习系统的原因，类似的翻译结果层出不穷。据悉，在设置从索马里语言翻译成英语的时候，谷歌有时翻译也会念起“圣经”，比如下面这个例子。
其大意为：
因为上帝的名字是用希伯来语写的，所以用希伯来民族的语言写成。
机器翻译有哪些不确定性？
八卦归八卦，热搜归热搜。吃完瓜，文摘菌还是要跟各位强调，到底如何避免机器翻译的车祸现场。
让我们先从NMT的诞生讲起。
2013 年，Nal Kalchbrenner 和 Phil Blunsom 提出了一种用于机器翻译的新型端到端编码器-解码器结构 。该模型可以使用卷积神经网络（CNN）将给定的一段源文本编码成一个连续的向量，然后再使用循环神经网络（RNN）作为解码器将该状态向量转换成目标语言。这一研究成果的发布可以说是神经机器翻译（NMT）的诞生。虽然在那之后有无数的研究者进行改进模型，但是仍然缺乏对模型的理解。
具体遇到的问题包括：训练和解码过程相当慢；对同一个词的翻译风格可能不一致；在翻译结果上还存在超出词汇表（out-of-vocabulary）的问题；黑箱的神经网络机制的可解释性很差；训练所用的参数大多数是根据经验选择的。
NMT和SMT对比
总的来说：不确定性是翻译中的一个核心挑战。我们需要知道不确定性的典型来源是什么？为什么会出现这种问题？
文摘菌在一篇论文《Analyzing Uncertainty in Neural Machine Translation》中找到了这个问题的答案。
论文下载地址：
https://arxiv.org/pdf/1803.00047.pdf
根据论文，在构建翻译的模型的时候，基本上有两种不确定性，一种是任务本身固有的不确定性，另一种是数据收集过程中存在的不确定性。
内在的不确定性
不确定性的一个来源是一句话会有几种等价的翻译。因为在翻译的过程中或多或少是可以直译的，即使字面上有很多表达相同意思的方法。句子的表达可以是主动的，也可以是被动的，对于某些语言来说，类似于“the”，“of”，或“their”也是可选择的。
除了一句话可以多种翻译这种情况外，规范性不足同样是翻译不确定的来源。
另外，如果没有背景输入，模型通常无法预测翻译语言的时态或数字，因此，简化或增加相关背景也是翻译不确定性的来源。
外在的不确定性
机器翻译系统，特别是模型，需要大量的训练数据才能表现良好。为了节省时间和精力，使用低质量的网络数据进行高质量的人工翻译是常见的。这一过程容易出错，并导致数据分配中出现其他的不确定性。目标句可能只是源句的部分翻译，或者目标句里面有源句中没有的信息。
在一些加了copy机制的翻译模型中，对目标语言进行翻译的时候可能会完全或部分复制源句子。论文作者经过研究发现，即使copy机制很小，也能对模型预测产生较大的影响。
除此之外，这篇论文主要探究了NMT模型的适用性以及搜索。虽然模型在token和句子方面有很好的校准，但是预测的概率分布太广泛。这个问题的原因作者认为取决于函数是否是光滑的。
另外，论文研究了错配的影响，过度的概率分布会把样本在模型中的表现变差，而且。copy机制会更加突出。
福利：微信翻译的隐藏表白神器
其实微信翻译里面不仅仅有过翻车现场，也有一些隐形撩妹彩蛋！文章的最后，文摘菌也为大家送上这波福利。
有细心的网友会发现你在微信聊天里面发送信息【ohh】,翻译内容是：【留在我身边】。
如今这个梗在知乎上广为流传，而且至今微信翻译这个bug还在，微信翻译也至今没有进行补丁，可见微信团队的程序员们不仅技术牛，也是很有爱的一波人呢！
既然没被修补，我们就好好利用这个bug吧！抱着学习的态度，文摘菌从知乎上拔下来了另外一些表白术语，分享给大家。
eed:誓言
sme：我们
ichliebe dich：我爱你
这里应该是触发了德语翻译。
还有一些看起来不像正经文字的缅甸语可以拿去用。
ငါသည်သင်တို့၏ရည်းစားဖြစ်ချင်
我想成为你的男朋友
မင်းကိုသတိရနေတယ်
思念
注：可能在输入框内会出现一连串的问号，只要复制点击发送就好。这是因为手机上一般都不会安装这些小语种的字体，于是微信无法正常显示，出来就是连串的问号，但是微信翻译系统却能支持多种语言，所以当你在微信消息或者朋友圈中长按“翻译”按钮时，微信的翻译系统会自动解码，并翻译为中文。
另一个微信翻译的Bug是利用组成兔子手部的つ，这实际上是一个日语字符。有了它，整句话就会被当成日语来翻译，由于日语语法，疑问句就会因此翻译成肯定句。例如：
/つ 想不想...（我、出去浪）
/つ 要不要...（吃鸡、去死)
/つ 你是不是...（一只猪）
好啦，最后，祝大家表白顺利。
声明：本文来自大数据文摘，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
