[[253242]]

大數(shù)據(jù)文摘出品

編譯：張秋玥、蔣寶尚

文字語音轉換圈內流傳這么一則真假未知的故事：一個研究者花了數(shù)月(甚至數(shù)年)調整他/她的語音生成模型，使其語音樣本聽起來效果非常好。最后他們發(fā)現(xiàn)，他們從頭到尾都誤用同一語音文件進行訓練，最終模型只是完全符合該語音文件特征所以才擁有如此流暢的語音樣本輸出。這個故事到現(xiàn)在都讓人不寒而栗。

想象一下另一則恐怖故事：你是個小實習生，老板讓你搭建一個判斷識別“Yes”與“No”的語音識別分類器。你有這些音頻文件：yes1.wav，no1.wav，yes2.wav，no2.wav，yes3.wav等等。你建好了分類器，效果也很好。就在你要展示工作成果之前，你發(fā)現(xiàn)這個模型唯一在做的事情就是通過讀取文件名里的yes或者no來預測結果，壓根不會聽文件里面的音頻。你嚇傻了，大哭一場，準備跑路。

這就是本文作者Vincent Vanhoucke所經歷的恐怖故事，完全真實，這些小事故也決定了這位Google首席科學家的職業(yè)生涯。

以下是他以第一人稱講述的更多小故事，讓我們看看能夠從中得到哪些經驗：

那是我作為研究者的第一份工作。任務很明確，提供了大量數(shù)據(jù)以及優(yōu)秀的預測準確度標準來評估模型效果。模型的基準結果很強，我最后甚至和一位客戶一起在生產實踐中部署了這個模型。

我有試圖根據(jù)我覺得很聰明很厲害的方法來改進模型表現(xiàn)指標——它沒有很完美但每一天都在進步。我都能看到我腦子里慢慢形成的一篇優(yōu)秀學術論文啦。生活真美好。

這算是一項產業(yè)研究，所以在開始撰寫論文之前我還需要通過最后一項測試：使用真實顧客數(shù)據(jù)來評估模型，以便于快速在生產實踐中部署改進方案。在真實數(shù)據(jù)集上我的模型達成了零精確度成就。我可是一直在提高我覺得超級厲害的表現(xiàn)指標來著。

八成是出了bug，要不就是真實顧客數(shù)據(jù)質量很糟糕——我腦子這么想著，覺得沒多大關系就急著開始上手寫論文了。但實際上我又并沒有辦法完全放下這個糟糕結果，所以我就開始研究到底是怎么回事。我最后發(fā)現(xiàn)的是全世界數(shù)據(jù)科學家共同的噩夢：準確度就是零，這一點毫無疑問。我其他所有的準確度數(shù)據(jù)都是所謂的“幽靈”數(shù)字。我簡直不敢信：這些數(shù)字看起來超可信啊，它們比基準高但并沒有高到不可能的地步。

人們常說，災難一般不會“成單”出現(xiàn)，而是在有兩件事一起出錯時，因為我們總體來說很擅長預判并改正單個失誤。為了完全了解到底是什么樣幾乎不可能發(fā)生的系列事件導致了這些看似可信的精確度數(shù)字的出現(xiàn)，我必須得從細節(jié)開始分析。

模型目標是改善用來識別人名的語法數(shù)據(jù)結構。比如說，假如你叫“Robert Moore”，語音識別系統(tǒng)可能將會把你的名字編譯成為一個語音圖，大致看起來像是某種正則表達式：“/(ˈɹɑb.əɹt|ˈbob|ˈɹɑb) mʊɹ/”——它還兼容類似于“Rob”或“Bob”的昵稱呢。我的任務是生成更好的語音圖。我的數(shù)據(jù)被存儲為鍵值對數(shù)據(jù)庫的形式：

record { 
key (string): “robert_moore” 
value (Grammar): /(ˈɹɑb.əɹt|ˈbob|ˈɹɑb)mʊɹ/ 
} 

這里有一個bug：有些我的語法數(shù)據(jù)結構里用到的語音符號并不會被發(fā)音引擎識別。系統(tǒng)嘗試把語法數(shù)據(jù)結構編譯為一個應當代表正則表達式的圖像對象，但它失敗了。在層層代碼的深處，有人曾嘗試將系統(tǒng)變得對于這些失敗更加穩(wěn)?。寒吘梗灰赡?，你永遠不希望系統(tǒng)在生產實踐中突然垮掉嘛。那段代碼看起來類似于這樣：

Graph* graph = compile(record->value); 
if (!graph) { // Failed to compile. 
graph = compile(record->key); // （什么鬼？？？） 
} 

這可真的讓我大吃一驚措手不及：怎么會有人覺得只要一條數(shù)據(jù)庫記錄損壞了就代表這條記錄的鍵包含真正的負載?而且這怎么可能可行嘛?“值”就是一條序列化的型語法，“鍵”就只是一串字符而已。再深挖一點——看，更“穩(wěn)健”的在這里：

Grammar* grammar = parse(record); 
if (!grammar) { // Failed to parse. 
grammar = parse(pronounce(record)); // （啥？？？） 
} 

如果數(shù)據(jù)不是我們預想的類型，我們就會盡量提取那條記錄的內容為單詞進行發(fā)音。為什么不呢，反正已經毫無希望了嘛。而且，發(fā)音生成是一項非常耗時耗計算力的操作。想象一下，不管出于什么原因，一大串沒有任何意義的垃圾字符(包括對于拒絕服務的報復性操作)突然被輸入到系統(tǒng)里，這對于系統(tǒng)意味著什么。系統(tǒng)將會立刻過載，而非“逐漸失敗”。

你可能已經意識到接下來要發(fā)生什么了。我的數(shù)據(jù)的鍵都是用戶的真名，比如“robert_moore”。發(fā)音引擎很容易就將其近似于“/ˈɹɑb.əɹt mʊɹ/.”。所以，我的數(shù)據(jù)的問題直接來自于決定模型評估標準的事實。

理論上來說這就與我在前文提到的根據(jù)文件名預測音頻是yes還是no一個道理。我沒預料到的是，發(fā)音模型的隨機試驗看起來確實改善了結果。然而，那其實只是取決于每次實驗中未編譯成功的數(shù)據(jù)比例而已。我的模型失敗次數(shù)越多，生成的錯誤就更多，真實鍵值使用的更多，我的模型精確度就越好。至于解鎖零精確度成就的真實數(shù)據(jù)?那個數(shù)據(jù)庫里的鍵都是亂七八糟的字符串，看起來類似于“h4a7n6ks2l”這種發(fā)音模型?

我還算是幸運的。我對符號檢索問題進行的修復確實提高了效果，新系統(tǒng)確實得到了改進。數(shù)周的實驗最后都是竹籃打水一場空，我還得跟同事解釋我這個模型差點就上線運行害了所有客戶，以及為啥我越傷害這個模型線下精確度就越高。必須得說一句，他們最后只是大笑了一場這事兒就過去了，還是很客氣的。

下面是我學到的經驗教訓：

第一，不要相信任何人、任何事情。

誰都想抓住你的把柄，尤其是數(shù)據(jù)科學界。大多數(shù)問題會將預測結果變得看起來糟糕很多，但有時結果看起來還是足夠好且真實讓人無法起疑心。實際上在語言建模領域，這是一個超級常見的問題。計算以及比較困惑度階段超多陷阱，極小的錯誤都時常能夠提高實驗數(shù)字(而非降低!)。因此，這個領域的人對于證明的要求都很高;基于這個原因，我建議在將模型推廣之前你最好多在開源評估工具上試驗試驗。

第二，更不要相信你自己。

在我整個學術生涯中，我很快就學到了我需要過分質疑任何我得到的結果，盡管我本性并非如此。我現(xiàn)在會為了模型結果持續(xù)尋求外部意見，最好是使用一個完全不同的代碼庫。

第三，寫簡單的防衛(wèi)代碼

不要自作聰明。你的代碼應該跟你本人一樣偏執(zhí)，就算是合同里最小的細節(jié)有一點不符，你的模型都該立刻引人注目地垮掉。每個程序員都肯定經歷過這樣的事：閱讀堆棧跟蹤到一段標注為“這就永遠不該發(fā)生”的代碼。大量數(shù)據(jù)被寫入磁盤，甚至位翻轉這種事情都時有發(fā)生。我以前有過一個生產系統(tǒng)，因為XML分析錯誤就直接崩潰了。磁盤上配置文件(程序自動生成的)看起來就像這樣：

<item/> 
<item/> 
…類似的一百萬行… 
<item/> 
<itel/> 
<item/> 
<item/> 
…再省略一百萬行… 
<item/> 

看到哪里不同了嘛?我都等不及下一次日冕物質拋射活動來讓我們都變成更厲害的程序員啦(譯者注：這個作者只是在這里發(fā)泄怨氣…)。

第四，不要相信你的代碼，更不要相信你自己的數(shù)據(jù)處理能力。

想讓你的數(shù)據(jù)出錯，方法超多的。即使你只有1%的數(shù)據(jù)出錯，你的A/B測試結果可能也完全不對。比如，有些著名網絡數(shù)據(jù)集里的某些圖片就是無法被某些圖像解析器讀取。如果你使用另一個解析器，或者你將這些圖片計入分母，最后的結果都會與別人不同。很長一段時間內，我都在評估結果內重復計入了某些測試圖像，因此得到了壓根不正確卻看似很可信的數(shù)字結果。

第五，盡量故意擾亂你的實驗。

把標簽打亂，計算概率層面精確度。在1%的數(shù)據(jù)上進行訓練，確保你過度擬合。更好的方法是：把你的模型交給別人，讓他們自己上手使用。每個實驗室都有這么一個永遠能第一時間掛掉你完美代碼的人。盯住他們就對啦!

這種對結果的有益的懷疑論可能是我在博士與非博士之間發(fā)現(xiàn)的品質上的最大區(qū)別。我們博士都經受過這樣的打擊?；叵肫饋恚液苄疫\能夠以這么一種尷尬又沒有很不合適的方式在職業(yè)生涯早期收到驚訝，以確保我永遠都小心翼翼地進行研究。必須說不幸的是，數(shù)據(jù)科學界從來沒有“幸福小事故”這種事情(西方公眾名人Bob Ross名言：世上沒有“錯誤”一說，它們只是“幸福小事故”)。

相關報道：https://medium.com/s/story/no-happy-little-accidents-8663540763f8

【本文是51CTO專欄機構大數(shù)據(jù)文摘的原創(chuàng)譯文，微信公眾號“大數(shù)據(jù)文摘（ id: BigDataDigest）”】

戳這里，看該作者更多好文