為解決機器學習可復現性的問題，很多人會用 Git 和 Git-LFS，但這二者並不足以解決這個難題。為此，作者在文中提出了 DVC 並列出了它的三大優勢：精準記錄時間點和使用的檔案、特定時間點使用命令的確切順序、輕鬆實現資料和程式碼共享。
有人認為，由於軟體工具的不充分，無法保證完全復現機器學習模型的結果，機器學習領域正「陷入危機」。這個危機可以透過為機器學習從業者提供更好的軟體工具來解決。
可復現性問題非常重要，每年一度的 NeurIPS 會議也將其列為 NeurIPS 2019 討論的主要議題。
所謂的危機是因為研究者難以復現同行或科學家們的工作，這制約了他們在彼此工作基礎上進一步取得進展。由於機器學習和其他形式的人工智慧軟體在學術和企業研究中得到廣泛應用，因此可複製性或可復現性是一個亟待解決的關鍵問題。
我們可能認為這可以透過典型的軟體工程工具來解決，因為機器學習開發與普通軟體工程類似。在這兩種情況下，我們會生成某種編譯軟體工具，以便在計算機硬體上執行，並獲得準確的結果。為什麼我們不能利用豐富的軟體工具和質量極佳的軟體來為機器學習團隊構建可復現流程呢？
遺憾的是，傳統的軟體工程工具並不能很好地滿足機器學習研究者的需求。
關鍵問題是訓練資料。通常，訓練機器學習模型需要大量的資料，例如影像、影片或文字。而訓練資料不在任何一種原始碼控制機制下，因為像 Git 這樣的系統不能很好地處理大型資料檔案，並且用於生成 delta 文字檔案的原始碼控制管理系統不能很好地處理對大型二進位制檔案的更改。
任何經驗豐富的軟體工程師都會告訴你，沒有原始碼控制的團隊只是「無頭蒼蠅」。更改檔案不會一直被記錄，團隊成員時常會忘記執行過的操作。
而當訓練結束時，你可能無法復現用該訓練資料訓練的模型，因為訓練資料集將以未知方式發生改變。如果沒有軟體系統記錄某次的資料集狀態，那麼有什麼機制可以記錄這一切呢？
Git-LFS 是解決方案嗎？
我們首先想到的解決方案可能是簡單地使用 Git-LFS (Git Large File Storage)，顧名思義，它在構建 Git 時處理大檔案。Git-LFS「用 Git 內部的文字指標替換大型檔案，如音訊、影片、資料集和圖形，同時將檔案內容儲存在 GitHub.com 或 GitHub Enterprise 等遠端伺服器上。」
我彷彿還能聽到機器學習團隊說「聽起來很棒，開始吧」。它能夠處理數千兆位元組的檔案，加快遠端儲存庫的出庫速度，並使用同樣舒適的工作流。這肯定符合標準了，對吧？
並沒這麼簡單，專案經理沒有告訴你要三思而後行嗎？就像另一個寶貴的人生意見一樣：過馬路之前要左右看看。
你應該首先考慮的是 Git-LFS 需要一個 LFS 伺服器，並且該伺服器不是透過每個 Git 託管服務都可用。三巨頭（Github、Gitlab 和 Atlassian）都支援 Git-LFS，但也許你天生愛 DIY。相比使用第三方 Git 託管服務，你可能更願意自己託管 Git 服務。例如，Gogs 是一個功能強大的 Git 伺服器，你可以輕鬆地在自己的硬體上執行，但它沒有內建的 Git-LFS 支援。
根據你的資料需求，下一步可能會有點「致命」：Git-LFS 允許的儲存檔案最大為 2 GB。這是 Github 帶來的限制，而非 Git-LFS，但是似乎所有的 Git-LFS 實現都受到各種限制。Gitlab 和 Atlassian 都有各種 Git-LFS 限制。想想 Github 的這個 2GB 限制：Git-LFS 有個應用案例是儲存影片檔案，但是影片的大小經常超過 2GB。因此，Github 上的 GIt-LFS 可能不適用於機器學習資料集。
不僅僅是 2GB 的限制，Github 對 Git-LFS 使用的免費層也設定了嚴格的限制，使用者必須購買涵蓋資料和頻寬使用的資料計劃。
與頻寬相關的一個問題是，當你使用託管的 Git-LFS 解決方案時，訓練資料會儲存在遠端伺服器中，必須透過 Internet 下載資料。而下載過程嚴重影響使用者體驗。
另一個問題是，在執行基於雲的 AI 軟體時，通常需要將資料檔案放置在雲端儲存系統（AWS、GCP 等）上。而來自 Git 伺服器三巨頭的主要 Git-LFS 產品將 LFS 檔案儲存在它們的伺服器上，一般不支援雲端儲存。
有一個 DIY 的 Git-LFS 伺服器可以在 AWS S3 上儲存檔案，網址是 https://github.com/meltingice/git-lfs-s3，但是設定自定義的 Git-LFS 伺服器需要額外的工作。
而且，如果需要將檔案放在 GCP 而不是 AWS 基礎架構上時，該怎麼辦？是否有 Git-LFS 伺服器能夠將資料儲存在自主選擇的雲端儲存平臺上？是否有使用簡易 SSH 伺服器的 Git-LFS 伺服器？換句話說，GIt-LFS 限制了使用者對資料儲存位置的選擇。
使用 Git-LFS 解決了所謂的機器學習復現危機嗎？
使用 Git-LFS 後，你的機器學習團隊可以更好地控制資料，因為它現在是版本控制的。這是否意味著問題已解決？
先前我們說過「關鍵問題是訓練資料」，但這是一個小謊言。是的，資料能在版本控制下就是一個很大的改進。但是缺乏對資料檔案的版本控制是整個問題所在 嗎？並不。
什麼決定了訓練模型或其他活動的結果？決定因素包括但不限以下內容：
訓練資料——訓練模型時使用的影像資料庫或任何資料來源
訓練模型使用的指令碼
訓練指令碼使用的庫
處理資料使用的指令碼
處理資料使用的庫或其它工具
作業系統和 CPU/GPU 硬體
生產系統程式碼
生產系統程式碼使用的庫
顯然，訓練模型的結果取決於各種條件。由於存在多方變數，所以很難準確描述，但一般的問題是缺少所謂的配置管理。軟體工程師已經認識到能夠指定部署系統時使用的精確系統配置十分重要。
機器學習可復現性的解決方案
人類是一個富有創造力的群體，為這個「危機」提出了很多可能的解決方案。
R Studio 或 Jupyter Notebook 等環境提供了一種互動式 Markdown 文件，可以配置用來執行資料科學或機器學習工作流。這對於記錄機器學習工作以及指定使用哪些指令碼和庫來說非常有用。但是這些系統不提供管理資料集的解決方案。
同樣，Makefile 和類似的工作流指令碼工具提供了一種重複執行一系列命令的方法。執行命令是透過檔案系統時間戳確定的。這些工具也不提供資料管理解決方案。
另一方面，像 Domino Data Labs 或 C3 IoT 這樣的公司提供了資料科學和機器學習的託管平臺。兩者都將基於大量資料科學工具的產品打包在一起。在某些情況下，如 C3 IoT，使用者使用專用語言編碼，並將資料儲存在專用資料儲存中。「一站式備齊」可能真的很便捷，但它能提供足夠的靈活性嗎？
本文接下來的部分將介紹 DVC。它的設計充分利用了大多數人對 Git 的熟悉程度，旨在與 Git 功能緊密匹配，但它具有適用於機器學習環境中的工作流和資料管理的功能。
與 Git-LFS 或其他幾種可能的解決方案相比，DVC 承擔並解決了機器學習復現性的大部分問題。它的方式是在 DVC 和像 Git 這樣的原始碼管理系統（SCM）中混合管理程式碼（指令碼和程式）以及大資料檔案。此外，DVC 管理處理機器學習實驗中使用的檔案所需的工作流。
DVC 檔案中描述了資料檔案和要執行的命令，我們將在接下來的小節介紹這些檔案。最後，使用 DVC 可以輕鬆地將資料儲存在許多儲存系統上，像本地磁碟、SSH 伺服器或雲系統（S3、GCP 等）。DVC 管理的資料可以很容易地與其他使用此儲存系統的使用者共享。
DVC 使用與 Git 類似的命令結構。正如我們看到的，就像 git push 和 git pull 用於共享程式碼和配置一樣，dvc push 和 dvc pull 用於共享資料。所有這些都將在後面的章節詳細介紹，或者如果你想學習 DVC，請參閱教程：https://dvc.org/doc/tutorial。
DVC 可以精準記錄時間點和使用的檔案
DVC 的核心是為儲存和版本控制大檔案而最佳化的資料儲存（DVC 快取）。團隊可以選擇將哪些檔案儲存在 SCM（如 Git）中，哪些儲存在 DVC 中。儲存由 DVC 管理的檔案，這樣 DVC 可以維護每個檔案的多個版本，並使用檔案系統連結快速更換正在使用的檔案版本。
從概念上講，SCM（如 Git）和 DVC 都有儲存庫，其中包含每個檔案的多個版本。如果檢視「版本 N」，相應的檔案將出現在工作目錄中，然後檢視「版本 N + 1」，檔案將會匹配新版本。
在 DVC 端，這在 DVC 快取中處理。儲存在快取中的檔案透過內容校驗和（MD5 雜湊值）進行索引。隨著 DVC 管理的各個檔案發生變化時，其校驗和會發生變化，並會建立相應的快取條目。快取將儲存每個檔案的所有例項。
為了提高效率，DVC 使用多種連結方法（取決於檔案系統支援）將檔案插入工作區而無需複製。這樣，DVC 可以在請求時快速更新工作目錄。
DVC 使用所謂的「DVC 檔案」來描述資料檔案和工作流步驟。每個工作區將有多個 DVC 檔案，每個檔案都用相應的校驗和描述一個或多個資料檔案，每個檔案都要描述在工作流中執行的命令。
cmd: python src/prepare.py data/data.xmldeps:- md5: b4801c88a83f3bf5024c19a942993a48path: src/prepare.py- md5: a304afb96060aad90176268345e10355path: data/data.xmlmd5: c3a73109be6c186b9d72e714bcedaddbouts:- cache: truemd5: 6836f797f3924fb46fcfd6b9f6aa6416.dirmetric: falsepath: data/preparedwdir: .
示例的 DVC 檔案來自 DVC 入門示例（https://github.com/iterative/example-get-started），並顯示了工作流的初始步驟。在下一節，我們會詳細介紹工作流。現在，請注意此命令有兩個依賴項 src/prepare.py 和 data/data.xml，以及一個名為 data/prepared 的輸出資料目錄。這些都會產生 MD5 雜湊值，並且隨著檔案更改，MD5 雜湊值將發生變化，更改後的資料檔案的新例項將儲存在 DVC 快取中。
DVC 檔案被檢入 SCM 管理（Git）儲存庫。當存入 SCM 儲存庫時，每個 DVC 檔案都會使用每個檔案的新校驗和來更新（如果適用）。因此，使用 DVC 可以精確地重新建立每個提交的資料集，團隊也可以精確地重新建立專案的每個開發步驟。
DVC 檔案類似於 Git-LFS 中使用的「指標」檔案。
DVC 團隊建議在每個實驗中使用不同的 SCM 標籤或分支。因此，訪問適合該實驗的資料檔案、程式碼和配置就像切換分支一樣簡單。SCM 將自動更新程式碼和配置檔案，DVC 將自動更新資料檔案。
這意味著你不用再絞盡腦汁去記住哪些資料檔案用於什麼實驗了。DVC 會為追蹤這一切。
DVC 會記住特定時間點使用命令的確切順序
DVC 檔案不僅能記住特定執行階段使用的檔案，還能記住在該階段執行的命令。
復現機器學習結果不僅需要使用相同的資料檔案，而且需要相同的處理步驟和相同的程式碼/配置。一般建立模型的步驟，首先要準備在後續步驟中使用的樣本資料。你可能會利用 Python 指令碼 prepare.py 來拆分資料，並且在 data/data.xml 檔案中輸入資料。
$ dvc run -d data/data.xml -d code/prepare.py \-o data/prepared \python code/prepare.py
我們用該語句使 DVC 記錄該處理步驟。DVC「run」命令根據命令列選項建立 DVC 檔案。
-d 選項定義依賴項，在本例中，我們看到 XML 格式的輸入檔案以及 Python 指令碼。-o 選項記錄輸出檔案，這裡列出了輸出資料目錄。最後，執行的命令是一個 Python 指令碼。
因此，我們輸入的資料、程式碼和配置以及輸出資料，都被事無鉅細地記錄在生成的 DVC 檔案中，該檔案對應上一節中顯示的 DVC 檔案。
如果 prepare.py 從本次提交更改為下一次提交，則 SCM 將自動跟蹤更改。同樣，對 data.xml 的任何更改都會在 DVC 快取中產生新例項，DVC 將自動跟蹤該例項。如果結果資料目錄發生更改，DVC 也會跟蹤它們。
DVC 檔案也可以簡單地引用檔案，如下所示：
md5: 99775a801a1553aae41358eafc2759a9outs:- cache: truemd5: ce68b98d82545628782c66192c96f2d2metric: falsepath: data/Posts.xml.zippersist: falsewdir: ..
這是 dvc add file 命令得到的結果，該命令僅在只有一個資料檔案時使用，並且其他命令不會產生這個結果。例如，在 https://dvc.org/doc/tutorial/define-ml-pipeline 中會顯示，結果會立刻出現在前面的 DVC 檔案：
$ wget -P data https://dvc.org/s3/so/100K/Posts.xml.zip$ dvc add data/Posts.xml.zip
然後，Posts.xml.zip 檔案是本教程中一系列步驟的資料來源，每一步都要從這些資料中獲取資訊。
退一步講，我們要明確這些是更大型工作流中的單個步驟，或者在 DVC 中稱之為管道的步驟。透過 dvc add 和 dvc run，可以將多個階段串聯起來，每個階段都使用 dvc run 命令建立，且由 DVC 檔案描述。
這意味著每個工作目錄將包含多個 DVC 檔案，其中一個用於該專案流程的每個階段。DVC 掃描 DVC 檔案，構建復現流程所需命令的有向非迴圈圖（Directed Acyclic Graph DAG）。
每個階段都像一個 mini-Makefile，只有當依賴關係發生變化時，DVC 才會執行命令。它也有所不同，因為 DVC 不會像 Make 那樣只考慮檔案系統時間戳，而是考慮檔案內容是否已更改，這由 DVC 檔案中的校驗和與檔案的當前狀態確定。
最重要的是，這意味著不需再費盡周章記住每個實驗使用哪個版本的指令碼。DVC 會跟蹤所有內容。
DVC 使團隊成員之間輕鬆實現資料和程式碼共享
機器學習研究人員可能需要與同事合作，需要共享資料、程式碼和配置。或者需要將資料部署到遠端系統，例如在雲端計算系統（AWS、GCP 等）上執行軟體，這意味著將資料需要上傳到相應的雲端儲存服務（S3、GCP 等）上。
DVC 工作空間的程式碼和配置端儲存在 SCM 中（如 Git）。使用普通的 SCM 命令（如 git5 clone），你可以輕鬆地與同事共享程式碼和配置。但是如何與同事共享資料呢？
DVC 具有遠端儲存的概念。DVC 工作空間可以將資料傳輸到遠端儲存中或從遠端儲存中提取資料。遠端儲存池可以存在於任何雲端儲存平臺（S3、GCP 等）以及 SSH 伺服器上。
因此，要與同事共享程式碼、配置和資料，首先要定義遠端儲存池。儲存遠端儲存定義的配置檔案由 SCM 跟蹤。接下來，將 SCM 儲存庫傳送到共享伺服器，該伺服器附帶 DVC 配置檔案。當你的同事克隆儲存庫時，他們就可以立即從遠端快取中提取資料。
這意味著你的同事不用再費心思量如何執行你的程式碼。他們可以輕鬆復現你的確切步驟，充分利用精確資料來生成結果。
結論
復現結果的關鍵是，不僅要確保資料的正確版本，還要保證程式碼和配置檔案的正確版本，並自動執行各個步驟。成功的專案有時需要與同事協作，而這可以透過雲端儲存系統更輕鬆地實現。有些工作要求在雲端計算平臺上執行 AI 軟體，因此需要將資料檔案儲存在雲端儲存平臺上。
藉助 DVC，機器學習研究團隊可以確保他們的資料、配置和程式碼全部同步。它是一個易於使用的系統，可以有效地管理共享資料儲存庫和 SCM 系統（如 Git），以儲存配置和程式碼。