作者 | 蔣寶尚
編輯 | 叢末
自然語言處理果真是人工智慧皇冠上的明珠，在走向摘取顆果實的路上，人類恐怕還只是走了一半。
具體表現是，在機器翻譯的世界裡，一直無法賦予機器足夠的「靈性」。例如，林則徐虎門銷煙被某度軟體翻譯成了「Lin Zexu sells cigarettes in Humen」 。
圖註：筆者後續對百度進行測試時，發現已經是正確翻譯：「Lin Zexu destructed opium at Humen」
顯然，機器把「銷」等同於「銷售」。其實，這種等同，對於其他人，在沒有上下文語境的情況下是完全可行的，例如，小李虎門銷煙=小李虎門賣（銷售）煙、小明虎門銷煙=小明虎門賣（銷售）煙。但是，對於林則徐，是無論如何不能做這種混淆，因為，這句話本身就包含了上下文語境。虎門銷煙是中國近代史上的重要事件，對於人工譯員來說，這是非常重要的背景知識，銷毀（銷）的是鴉片（煙），目前機器翻譯系統明顯缺乏對這種知識的理解能力，這也可能是導致翻譯錯誤的一個重要原因。
對此，AI科技評論還專門測試了其他幾個著名的翻譯軟體。其表現如下：
顯然，谷歌翻譯也沒能經受的得住考驗。
金山翻譯，仍然是sells，這動詞還用的是第三人稱單數！
有道翻譯：「銷煙=煙」。有道的整體翻譯，總感覺怪怪的，如果把smoke看成動詞「吸菸」也不怎麼通順！難道它把「林則徐虎門」看成了一個人？
騰訊翻譯爭氣了很多，「Lin Zexu destroys opium in Humen」點燃了希望之光~
我們試了試在日本大火的DeepL：譯文的內容相對完整一些，但也沒有正確翻譯「煙=鴉片」，譯文中包含一些多餘的單詞。
1
數據和算法雙重問題下的翻譯BUG
那麼，只是簡單的一句缺乏上下文語境就能解釋這麼多家翻譯軟體為什麼都出現BUG麼？為此，AI科技評論專門諮詢了東北大學自然語言處理實驗室主任肖桐老師，他解釋道：「主要還是訓練數據的覆蓋度問題，數據中「銷」很多的時候被當作sell，對生僻一些的用法機器翻譯現在還無法處理。說到底，機器翻譯現在還是在「背」，沒見過的情況，不會像人一樣推理，缺乏對句子的真正理解能力。」
小牛翻譯創始人、東北大學朱靖波老師將這種譯文與原文本意不同的現象，稱之為「跑飛」現象，他解釋到：「出現這種現象的原因是神經機器翻譯技術本質上沒有對句子進行真正的理解，所以有些時候無法保證譯文的忠實度。早期神經機器翻譯中這個問題比較嚴重，現在這個問題得到了緩解，偶爾會出現，但不常見。」
論文連結：https://arxiv.org/pdf/1803.00047.pdf
對於機器翻譯的這些BUG，2018年也有一篇論文詳細闡述了這些現象。這篇論文的第一作者是來自FAIR的Myle Ott，他在論文的引言部分就提到：當前大多數機器翻譯的模型都是基於神經網絡（NMT），而神經網絡機器翻譯明顯沒有給予生詞（rare words）足夠的重視，最明顯的表現是曝光誤差(exposure bias)，簡單來講是因為文本生成在訓練和推斷時的不一致造成的。
在論文中，作者對於包括但不限於「生詞」的機器翻譯現象給予了一個總結：所有的機器翻譯問題的基本主題都是不確定性，即學習任務的一對多性質，換句話說給定一個句子，有多種翻譯結果。
然後，針對這種不確定性，作者分了兩類解釋原因，一類是數據的不確定性，另一類是模型解讀（搜索）信息的不確定性。
數據的不確定性來源與兩個方面：內在和外在。
內在不確定性的表現是：一句話會有幾種等價的翻譯。因為在翻譯的過程中或多或少是可以直譯的，即使字面上有很多表達相同意思的方法。句子的表達可以是主動的，也可以是被動的，對於某些語言來說，類似於「the」，「of」，或「their」也是可選擇的。除了一句話可以多種翻譯這種情況外，規範性不足同樣是翻譯不確定的來源。
另外，如果沒有背景輸入，模型通常無法預測翻譯語言的時態或數字，因此，簡化或增加相關背景也是翻譯不確定性的來源。
外在的不確定性表現在：使用低質量的網絡數據進行高質量的人工翻譯。這一過程容易出錯，並導致數據分配中出現其他的不確定性。目標句可能只是源句的部分翻譯，或者目標句裡面有源句中沒有的信息。
對模型輸出中的不確定性量化，作者在論文中先比較了集束搜索(Beam Search）和採樣兩種搜索策略，然後研究了數據中特定種類的外部不確定性對集束搜索的影響。得出的結論是集束搜索非常高效，而更大的波束寬度在尋找更高的似然輸出方面也更加高效，而外部不確定性通過影響波束寬度從而影響搜索的效果。
在論文的最後，作者採用更全面的觀點，將估計分布與真實數據分布進行比較。結論是與數據分布相比，模型在假設空間中傳播的概率過大，往往低估了個別假設的實際概率。換句話說，模型根據概率輸出翻譯結果，有時候會出現不靠譜的情況。
2
機器翻譯：如何讓機器不再死記硬背？
回顧機器翻譯技術的發展歷程，第一代是基於規則的機器翻譯技術RBMT，主要通過專家手工書寫翻譯規則來實現；第二代是統計機器翻譯技術SMT，第三代是目前主流的神經機器翻譯技術NMT。
第二代SMT和第三代NMT採用機器學習方法，數據驅動，基於大規模雙語句對來訓練構建機器翻譯系統。由於人工書寫規則的代價很高，構建大規模雙語句對的代價也非常高，很多語言對難以收集大規模的雙語句對，在上述例子中機器將「虎門銷煙」中的「銷」作為「銷售」處理，也正是因為語料稀缺所致。
朱靖波老師在去年9月AI Time的一場活動中曾經提到過當前的機器翻譯與我們在外語學習機制上的差異：我們學習外語的方法並不是通過閱讀大量雙語文章，而是背背單詞，學學語法，以及大量閱讀外文單語文章，在不知不覺中掌握了外語。但機器學習外語的方式就大不一樣，不管是上一代的統計機器翻譯，還是目前主流的神經機器翻譯，都是基於大量的雙語句對訓練構建機器翻譯系統。從這個角度上說，要緩解神經機器翻譯技術在稀缺用語上「翻車」的現狀，則需要引入新的學習機制，例如往人類學習外語的新範式方向發展，擺脫對大規模雙語句對的依賴。這就好像AlphaGo最初根據人類棋譜來學習，之後的AlphaGo Zero引入新的學習方式，不依賴於人類棋譜來學習，下棋水平反而更高一樣。
不過，要讓機器像人類一樣學習外語，當中有一個急需解決的問題：翻譯人員對於自己的母語具有非常強的語法，能夠準確判斷母語譯文是否符合母語說法，甚至人類的大腦對於不符合母語說法的錯誤會進行自動糾正，例如下面這句：
「研表究明，漢字序順並不定一影閱響讀。比如當你看完這句話後，才發這現裡的字全是都亂的。」
同樣，在翻譯的過程中，例如在英翻中的任務中，為了構建表達一個具體含義的中文句子，只要從英文原文句子中得到幾個中文譯文單詞。例如用「我 北京 去 明天」，我們也可以容易構建一個合法中文句子「明天我去北京」或者「我明天去北京」，不會說「我北京明天去」和「我去明天北京」等不合法的中文句子，在構建過程不需要過多依賴英文原文。這一能力被研究者稱為「生成能力」，如何讓機器具有可以與人媲美的「生成能力」，則是實現類似人類學習方式的「單語學習」第四代機器翻譯的關鍵。
據AI科技評論了解，這一工作的瓶頸在於有些源語言的句法語義分析技術還處於起步階段，相關研究成果如張嶽、朱靖波、劉群等人合作研究並在2014年EMNLP發表的論文《Syntactic SMT Using a Discriminative Text Generation Model》，論文先分析源語言的句法成分和語義成分，再根據部分翻譯的基本單元生成目標語言，近期類似工作也得到了一定的關注。
論文地址https://www.aclweb.org/anthology/D14-1021.pdf
毋庸置疑，目前的機器翻譯在對那些任務重複性較大、翻譯難度較低的低端翻譯上已經取得了一定的成績，但在實現翻譯「信、達、雅」的終極目標上還需時日。一個可喜的變化是，近年來機器翻譯和人工翻譯兩個領域的合作與交流日趨頻繁，機器翻譯技術目前正處在一個量變到質變的積累時期，下一代的機器翻譯技術也將更多的從模仿人類的學習機制、開展人機協作上開展研究，而且這個質變或許已經為時不遠。
3
OMT：微信、谷歌翻車小集錦
這種「生詞」處理不當，其實機器翻譯出現問題的一個方面，前段時間火邊B站的「谷歌翻譯20遍」，恰恰反映了把句子機翻成英文再翻回來之後譯文不一致的情況。以少年閏土為例，原文與翻譯二十遍之後的譯文為：
原文：深藍的天空中掛著一輪金黃的圓月，下面是海邊的沙地，都種著一望無際的碧綠的西瓜。其間有一個十一二歲的少年，項帶銀圈，手捏一柄鋼叉，向一匹猹用力地刺去。那猹卻將身一扭，反從他的胯下逃走了。
譯文：在綠色天空中幾乎到處都是無盡的金色月亮，沙灘上滿是沙子。那時，這個11歲的男孩儘可能地用金屬皮帶系住他的手，並將其放在金屬把手上。叔叔關上身體，逃離叔叔。
......看到這裡，怕是魯迅大叔的棺材板都壓不住了吧！
除了谷歌，【微信翻譯】之前也出現過誤翻情況，原因是無法有效應對沒經過訓練的非正式英文詞彙，不過，現在微信翻譯團隊已經通過添加特殊詞的copy機制初步解決了這個問題。當時的截圖如下：
當出現人名時候，【微信翻譯】會出現胡言亂語~~
招 聘
AI 科技評論希望能夠招聘 科技編輯/記者 一名
辦公地點：北京/深圳
職務：以參與學術頂會報導、人物專訪為主
工作內容：
1、參加各種人工智慧學術會議，並做會議內容報導；
2、採訪人工智慧領域學者或研發人員；
3、關注學術領域熱點事件，並及時跟蹤報導。
要求：
1、熱愛人工智慧學術研究內容，擅長與學者或企業工程人員打交道；
2、有一定的理工科背景，對人工智慧技術有所了解者更佳；
3、英語能力強（工作內容涉及大量英文資料）；
4、學習能力強，對人工智慧前沿技術有一定的了解，並能夠逐漸形成自己的觀點。
感興趣者，可將簡歷發送到郵箱：cenfeng@leiphone.com