245
讓科學的“可重複性流程”重回數據科學
科學（比如物理、化學等）的主要原則（或者至少是科學的理想原則）之一是：可重複性。隻有結果能被清楚地再現並經過嚴格的同行評議後，真正“科學的”結論才能被學術界所接受。當然，不管是學術界裏科學家還是數據科學家，在實際操作過程中，事情都會變的有些混亂。很多數據科學家所使用的流程都還遠未達到可重複性。這些流程可能是如下的幾種形式：
-
一係列的Jupyter notebook，裏麵包括不斷增加的描述性的文件名，比如second_attempt_at_feature_selection_for_part2.ipynb。
-
Python或R的腳本，被手工拷貝到一台機器上，並用crontab來設置定時運行。
-
相當魯棒但很難看懂的應用程序。一般是由數據科學家完成需求文檔，並交由軟件工程師來開發的。
-
一些應用程序，它們生成的結果幾乎不可能與一個或多個持續變化的數據集的特殊狀態相關聯起來的。
最好的情況是，這些工作流的產出結果一般可以被這些項目的參與人員所重新生成。但是，如果讓新加入項目的人員或者是進行項目評估的人再重新生成同樣的結果，就不可能了。
與可重複性相關的苦惱已經在整個數據科學社區中被廣為探討：
“數據分析是非常容易出錯的，很難知道你什麼時候得到了正確的結果。這使得形成可重複的研究變的非常重要”——《可重複性不僅僅隻是研究人員需要關注的》，數據學院。
“曾經試圖去重複你幾個月前做的一個分析嗎？或者是幾年之前？盡管可能是你自己寫的代碼，但是現在你幾乎不可能去理解並決定是用哪一個程序來完成任務。是make_figures.py.old？還是make_figures_working.py？或者是new_make_figures01.py？”
——Cookiecutter數據科學
“6個月之後，別人問了一個你分析裏沒有涉及的問題，這要求你必須重複你的分析。但是你就是記不得你把文件存在電腦的什麼地方了。如果你是一個數據科學家，特別是關注決策科學和決策分析的那種，你一定碰到過這種情況。”
——《最無聊/有價值的數據科學的建議》，Justin Bozonier
可重複的問題是一個機構裏的數據科學團隊在某個時間點不得不麵對的問題。然而，這是一個好消息！隻要運用一點點原則和正確的工具，數據科學團隊就可以獲得可重複的能力。這篇博文將會討論一下可重複性的價值，並提供實現可重複性的一些實戰方法。
為什麼數據科學團隊需要關心可重複性？
一些人可能會認為隻要模型和分析能輸出“好的”結果，這個結果是否能夠被重複並不重要。然而如果忽略可重複性，即使是一個很小的數據科學團隊也可能會出問題。在數據科學中，可重複性不應該被放棄，無論你的機構有多大或者有多成熟，因為可重複性是以下活動的前提條件：
合作：數據科學，或是通常意義上的科學，都是一個合作的行為。沒有一個數據科學家知道所有的建模技術和分析方法。即使有人全都知道，但是現代公司裏的數據問題的複雜度和規模已經超出了單個人所能控製的範疇。因此作為一個數據科學家，你應該總是要關心如何把你的結果分享給你的同事，以及你們如何在分析和建模時進行合作。特別是，你應該使用一個專門的方式來分享和部署產品，能讓別人使用相同的數據，重複你的方法，產出相同的結果。不然，你的團隊將無法把團隊合作出的知識變現，同時團隊內部的進步將也僅僅隻能被個別人了解，而成為個人的進步。
創新：怎麼能知道一個新模型比舊的模型要有更好的表現？怎麼能恰當地證明對分析所加入的創新的精細度或複雜度更好？不幸的是，這些問題的答案通常都是通過個別人的試錯（例如用一個notebook）得到的，而一般在做出決定後就被忘掉了。但是如果分析是可重複的，數據科學團隊就可以(1)明確地判定新的分析結果是否比舊的好，因為舊的分析可以被再現，且新的分析是用已知的數據來進行的；(2) 清晰地了解到過去哪一個分析的表現比較差，從而能避免犯同樣的錯誤。
合規：隨著越來越多的統計、機器學習和人工智能的應用做出對用戶產生直接影響的決定，將會越來越多的來自大眾的壓力，要求解釋這些決定，並能重現結果。事實上，歐盟已經對很多由算法生成並對用戶產生影響的決定提出了“獲取解釋的權利”。如果沒有一個清晰可理解的和可再現結果的工作流，這樣的解釋將無法給出，而相應的審計也無法進行。
數據科學團隊怎樣才能實現可重複性？
在不同的組織裏來成功地實現可重複性的方法會有不同，因為數據科學團隊所解決的任務是非常不同的。不過通過對於下述最佳實踐、技術和工具的組合使用，將有可能幫助你的工作流程更接近可重複性。
努力實現簡單、可解釋的解決方案，並為之喝彩
深度學習就是一個典型的很強大但通常非常難重複的分析工具的例子。並不是所有的業務問題都需要使用深度學習，盡管它和其他類型的神經網絡算法都明顯更好。經常是一個簡單的統計聚合（例如計算最大和最小值）就能為數據驅動的決策提供非常好的支持。在某些場合下，簡單的線性回歸或是決策樹也有可能產生足夠好的（甚至是非常好的）預測結果。
在這些場景裏，使用更複雜的建模技術所帶來的精確度和準確度的提升可能並不能抵消在可解釋性上付出的代價。這裏的基線就是，如果使用更複雜的數據處理管道和建模技術後不能保證可重複性，那麼可重複性應該比使用最新和最好的模型的價值更高。
無重複性，不部署
無論你麵臨著什麼樣的時間節點壓力，都不應該把一個不完善的分析應用上線。作為數據科學家，我們努力地創造一個依靠數據驅動來製定決策的文化。如果你的應用故障了，還沒有一個解釋（很可能是因為你無法再現故障的結果），大家就會對你的應用喪失信心，並不會依據它的產出來做決定。即使你最終修複了故障，用戶喪失的信心卻是非常難以挽回。
數據科學團隊應該按照要求有單元測試、靜態代碼分析、代碼版本控製和代碼回顧一樣的方式來要求有可重複性。如果不能用已知的數據持續重複地生成同樣或者更好的結果，分析就絕對不能進入開發階段。可重複性的具體的表現可以使用與集成測試相同的技術來衡量。更進一步，如果可能，新的模型應該和已有的係統上運行的模型並行運行，對相同的數據做分析，從而實現相互的比較。
你可以自己完成上述測試和測量的排程，但你也可以考慮使用諸如LeVar這樣的工具。LeVar提供了“一個數據庫來存儲分析用的數據集和使用它們的實驗，從而可以用它來記錄和跟蹤新的方法對於靜態和已有的數據的運行和表現”。
版本化你的數據
即使你已經版本化了代碼或者Jupyter的notebook，但如果你不能使用同樣的數據，你還是無法重複之前的分析。這意味著你需要製定計劃，並用工具來獲取曆史上某個點的分析和數據的狀態。現在越來越多的數據版本化的工具出現了，下麵會對它們做簡單的分析。不過你的團隊應該製定一個數據版本化的計劃，並嚴格執行。實現數據版本化之前的數據科學猶如Git之前的軟件工程。
Pachyderm是我非常了解的一個工具（曝光一下，我就在Pachyderm工作）。它可讓你如在Git上提交代碼一樣的提交數據。Pachyderm的文件係統是由“數據資料庫”構成的，你可以提交任何格式的數據文件。
對數據的任何操作，你都可以把它們包裝成一個版本後提交到Pachyderm裏。這意味著操作是可回溯的，而對你和你的同事而言新狀態是可重複的。就如在Git裏一樣，提交是可回退的，所以你的數據可以回退到之前的任何狀態。
知道你數據的淵源
實際上，版本化數據還不夠。數據來的時候可能是用它自己的封包形式，可能是來自一係列的轉換後形成的。因此你有可能會需要理解數據的淵源。沒有上下文的結果是沒有意義的。你分析的每一步中，你需要能理解數據是從哪裏來的，以及它們是如何變成當前的形式的。
類似Pachyderm這樣的工具（作為一個工具或是你自己過程的一個模型）在這裏也能幫忙。例如，通過Pachyderm運行的一個分析在執行過程中會自動的記錄起源。在輸入數據沒有成為輸出的起源時，分析是不會采用此輸入的。
記錄下來
如果你想，這一步也可以叫“文檔化”。在任何時間，你的文檔都應該包含一個“實驗筆記”，用來記錄你是如何做出會影響分析結果的決定的。每個決定都應該有一個被記錄下來的動機和與之相關的代價。
例如，你非常可能需要去正則化一個變量。然而在你正則化的時候，與這個變量相關的單位信息就會丟失，並可能造成別人無法理解這個變量。其他情況可能是其他人在利用你的分析時也可能會基於列名來假定測量單位。
Elias Ponvert在他的博文《我們是怎麼用人的模式來進行數據科學的》裏對這一點做了非常好的討論：
“實驗筆記太重要的了。沒有它，數據科學家非常難以重新開始他或她在一個實驗項目裏遺留下來的工作，即使他或她僅僅隻是做了一兩天這個實驗。”
原文發布時間為：2017-03-16
本文來自雲棲社區合作夥伴“大數據文摘”，了解相關信息可以關注“BigDataDigest”微信公眾號
最後更新：2017-05-22 16:01:34