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