不要只看論文，缺乏工程實踐才是深度學習研究的瓶頸

學術界面臨的研究瓶頸不僅來自各種技術，還包括社區文化和研究流程等問題。本文提到當下發表的大部分論文中 90% 的內容都是他人的研究成果，剩下的 10% 不過是研究者測試自己的假設，而且這種形式的論文很少會帶來驚喜。就連 Andrej Karpathy 都十分贊同的文中一個觀點：讀論文不會太在意它的結果，只是為了獲得靈感。

讀研時，我研究的是 NLP 和信息提取，我幾乎將所有時間都花在編碼研究思路上。這就是有一個不喜歡接觸代碼導師（這樣的導師估計占所有導師的 95%）的研究生所做的事。當我對問題（problems）表示擔心時，總會聽到這樣的話「這只是一個工程問題；繼續。」後來我才意識到這句話的真實含義：「我認為，一篇論文提到了這點就通不過同行評議」。這種心態似乎在學術界普遍存在。但作為一個工程師，我不禁注意到缺乏工程實踐如何會讓我們停滯不前。

我會拿我熟悉的深度學習社區作為一個例子，但這也可能適用於其他社區。作為研究人員的社區，我們都有一個共同的目標：推動該領域發展。推進當前最先進的技術。有很多方法做到這一點，但是，最常見的是發表論文。絕大多數發表的論文都是漸進式的，我沒有貶低的意思。我相信，研究當然是漸進的，也就是說，新成果是建立在別人過去所做的基礎之上的。而且這就是它應該的樣子。說得具體一點，我讀過的大多數論文的內容中有 90% 都是現有的東西，包括數據集、預處理技術、評估標準、基線模型架構等等。作者們通常會再添加一些新的東西，展示一下做了哪些超越現有基線的改進。

目前來看，這麼做也沒什麼錯。問題不在於這個過程本身，而是如何實施。在我看來，這裡面有兩個突出的問題，都可以用「工程實踐（just engineering）」來解決。1、浪費研究時間；2、缺乏精確性和可重複性。逐一展開。

浪費研究時間（站在他人肩膀上的不易）

研究者都是經過高度訓練的專業人士。很多人都花了幾年到幾十年的時間才拿到博士學位，成為各自領域的專家。只有那些人花大部分時間做他們擅長的事——通過提出新的技術來進行創新，才有意義。就像你不想讓一個訓練有素的外科醫生每天花幾個小時從紙質表格上輸入病人的數據一樣。但他們每天做的幾乎就是這些事情。

在一個理想狀態里，一個有想法的研究者能夠輕鬆以已有成果為基礎（亦即上文提到的論文 90% 的內容），剩下 10% 的內容用於測試研究者的假設。（我發現，也有例外，如果你正在做的研究真的很新，但是大部分發表的研究都不屬於這個例外）。在實踐中，幾乎沒有什麼真正新東西。研究者花上幾周的時間重複做數據的預處理和後處理，一遍又一遍地部署，調試基線模型。這些工作通常包括追蹤相關論文的作者，弄清楚他們用的到底是什麼技巧。論文往往不會提到細節（fine print），因為這會讓結果看起來沒那麼令人印象深刻。在這個過程中，研究者會引入數十個混雜變數（confounding variables），這基本上會讓比較變得沒什麼意義。然而後面還有更多沒意義的事情。

我意識到，在他人成果基礎上做研究的難易性是決定你正在做的是什麼研究的主要因素。大多數研究者都是在自己的研究基礎上一遍一遍做研究。當然有人可能會說，這是因為他是某個特定子領域的專家，所以，只有繼續關注類似的問題才有意義。雖然不是完全沒道理，但我認為，這麼做沒什麼意義（尤其是深度學習領域，裡面很多子領域之間聯繫非常緊密，以至於其間的知識遷移可以做的很好）。我相信，主要的原因是從實驗的角度看，在自己工作的基礎上做研究是最容易的。它能帶來更多的論文發表，並讓周轉時間變得更快。基線已經用熟悉的代碼部署好了，評估已經設置好了，相關工作也寫好了，等等。而且這麼做，競爭更少——其他人沒法能接觸到你的實驗裝置也就沒法輕易和你競爭。如果這與在他人成果上做研究一樣容易，我們可能會在發表的研究中看到更多的多樣性。

並非都是壞消息。當然，有幾個趨勢正朝著正確的方向發展。發表代碼越來越普遍。像 OpenAI 的 gym（以及 Universe）那樣的軟體包確保了至少評估和數據集能夠做到效率化（streamlined)。Tensorflow 等深度學習框通過部署低水平基元（primitives）移除了大量潛在混雜變數。有人說，我們還有很多能做的事情沒做到。試想一下，如果我們有標準化的框架、標準的資料庫、標準的代碼庫和編碼風格、嚴格的自動評估框架和在完全相同的數據集上運行的實體，研究效率又會如何。從工程角度來看，所有這些都是簡單的事情，但是可能會產生巨大的影響。

我認為，我們低估了這一事實：我們是在和純軟體打交道。聽起來似乎顯而易見，但是，茲事體大。在諸如醫學或心理學領域，設計牢牢加以控制的實驗幾乎不可能，工作量也相當龐大。而軟體領域基本上是自由的。這一領域比我們絕大多數所認為的那樣還要獨特。但是，我們並沒有這麼做。我相信，這些變化（以及許多其他變化）還未發生的原因之一在於動機不對稱。說實話，幾乎所有研究人員更關心論文發表、引證率以及可授予終身教職的聘任制度，而不是真地推進這個領域。他們對有利於自己的現狀很滿意。

缺乏精確性（rigor）

第二問題與第一個問題密切相關。上文也暗示過了。就是缺乏精確性和可重複性。理想狀態是，研究人員可以控制住所有無關變數，採用新的技術，然後展示各種基線的改善情況（在顯著邊際內）。貌似顯而易見？好吧，如果你碰巧讀了很多深度學習方面的論文，那麼，你會覺得這個理想狀態就像直接源自科幻電影。

實踐中，當每個人採用不同框架和流程再度實現技術時，比較會變得沒有意義。幾乎每個深度學習模型在使用過程中都會存在很多會影響結果的「隱藏變數」，包括加進代碼中的不明顯的模型超參數，data shuffle seeds，變數初始化器以及其他論文通常不會提及的東西，但是，很明顯它們會影響最終測量結果。當你用一個不同的框架重新使用你的 LSTM，預處理數據並寫下幾千行代碼，你創造了多少混雜變數？我猜幾百甚至幾千個吧。如果你可以證明較之基準模型，有 0.5% 的邊際改進，你怎麼證明它們之間的因果關係？你咋知道這個結果就是結合某些混雜變數的結果？

我本人根本不相信論文結果。我讀論文更多是為了獲取靈感——關注論文的想法，而不是結果。這不是個應然問題。如果所有的研究人員都發布代碼，會怎麼樣？會解決問題？實際上，並非如此。將 1 萬條代碼未入文獻的代碼放到 Github 上，說「在這裡，運行這個指令，複製我的結果。」，這和生產人們願意閱讀、理解、證實和以此為基礎進行研究的代碼不是一回事。這就像望月新一證明 ABC 猜想，除了他，沒人看得懂。

再一次，「不過是個工程問題（just engineering）」有望解決這個難題。解決方案和問題 1（標準代碼、數據組、評估實體等）解決方案差不多，但問題也差不多。實際上，發表具有可讀性的代碼，可能並不最有利於研究人員。如果人們找到 bug 怎麼辦？需要收回論文嗎？除了為你效勞的單位做公關，沒有其他清楚的好處，發表代碼是在冒險。

機器之心編譯

原文：http://blog.dennybritz.com/2017/01/17/engineering-is-the-bottleneck-in-deep-learning-research/