讓科學重回資料科學

編者注：想了解更多關於資料科學專案裡的合作與可重複性問題，可以檢視這個“Jupyter Notebook for Data Science Teams video”連結。Johathan Whitemore會教你如何用Jupyter Notebook來進行專案擴充套件、部件化和團隊內共享。

科學（比如物理、化學等）的主要原則（或者至少是科學的理想原則）之一是：可重複性。只有結果能被清楚地再現並經過嚴格的同行評議後，真正“科學的”結論才能被學術界所接受。當然，不管是學術界里科學家還是資料科學家，在實際操作過程中，事情都會變的有些混亂。很多資料科學家所使用的流程都還遠未達到可重複性。這些流程可能是如下的幾種形式：

• 一系列的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在他的博文《我們是怎麼用人的模式來進行資料科學的》裡對這一點做了非常好的討論。：

 “實驗筆記太重要的了。沒有它，資料科學家非常難以重新開始他或她在一個實驗專案裡遺留下來的工作，即使他或她僅僅只是做了一兩天這個實驗。”

結論

在你的資料科學工作流裡確保可重複性看起來像是一個很恐怖的任務。然而，遵循一些最佳實踐並運用合適的工具就能幫你完成。最終你所做的這個努力都是值得的，並會在一個合作、創新和合規的環境裡得到回報。

Daniel Whitenack

Daniel是一個擁有博士學位的資料科學家/工程師，並有為大小公司開發資料科學應用的行業經驗，包括預測模型、看板、推薦引擎等。Daniel在全球多個會議（Gopherfest、GopherCon等）上發表過演講。他還維護者Jupyter的Go核心，並主動地幫助多個開源的資料科學專案組織它們的程式碼提交。