編者按：本文來自微信公眾號「大數據文摘」（ID：BigDataDigest），作者蔣寶尚、Andy，36氪經授權發布。
這兩天，微信翻譯團隊難得的上了次熱搜。
事情的發展是這樣的。有網友發現，當翻譯中帶有caixukun的人名拼音時，微信翻譯會出現一些奇怪的中文詞語，比如👇
之後，不僅人名測試開始一發不可收拾，網友們紛紛出動，想要尋找微信翻譯的其他彩蛋👇
網友們因此大為驚奇，玩得不亦樂乎，以至於這個話題被推上了熱搜。
針對相關問題，騰訊微信團隊昨天也做出了回應，強調這不是暖心的彩蛋，是翻譯引擎在翻譯一些沒有進行過訓練的非正式英文詞彙時出現誤翻。
文摘菌今天早上進行測試，發現微信團隊已經修復了bug，已無誤翻的情況，但是，帶有人名的句子在翻譯中會直接全句copy下來。
那麼，真的像微信翻譯團隊所說，這一翻譯車禍現場都是算法的鍋嗎？
文摘菌諮詢了自然語言處理領域的兩位專家，他們表示，算法上當然也有問題，但是，更大的問題可能在於訓練語料。
目前，機器翻譯領域主要使用的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是利用組成兔子手部的つ，這實際上是一個日語字符。有了它，整句話就會被當成日語來翻譯，由於日語語法，疑問句就會因此翻譯成肯定句。例如：
/つ 想不想...（我、出去浪）
/つ 要不要...（吃雞、去死)
/つ 你是不是...（一隻豬）
好啦，最後，祝大家表白順利。