選自towardsdatascience
作者：David Herron
機器之心編譯
參與：高璇、王淑婷
為解決機器學習可復現性的問題，很多人會用 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 管理的數據可以很容易地與其他使用此存儲系統的用戶共享。
選自towardsdatascience
作者：David Herron
機器之心編譯
參與：高璇、王淑婷
為解決機器學習可復現性的問題，很多人會用 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 管理的數據可以很容易地與其他使用此存儲系統的用戶共享。
圖源：http://dvc.org/
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」，文件將會匹配新版本。
選自towardsdatascience
作者：David Herron
機器之心編譯
參與：高璇、王淑婷
為解決機器學習可復現性的問題，很多人會用 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 管理的數據可以很容易地與其他使用此存儲系統的用戶共享。
圖源：http://dvc.org/
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」，文件將會匹配新版本。
圖源：http://dvc.org/
在 DVC 端，這在 DVC 緩存中處理。存儲在緩存中的文件通過內容校驗和（MD5 哈希值）進行索引。隨著 DVC 管理的各個文件發生變化時，其校驗和會發生變化，並會創建相應的緩存條目。緩存將保存每個文件的所有實例。
為了提高效率，DVC 使用多種鏈接方法（取決於文件系統支持）將文件插入工作區而無需複製。這樣，DVC 可以在請求時快速更新工作目錄。
DVC 使用所謂的「DVC 文件」來描述數據文件和工作流步驟。每個工作區將有多個 DVC 文件，每個文件都用相應的校驗和描述一個或多個數據文件，每個文件都要描述在工作流中執行的命令。
cmd: python src/prepare.py data/data.xmldeps:- md5: b4801c88a83f3bf5024c19a942993a48 path: src/prepare.py- md5: a304afb96060aad90176268345e10355 path: data/data.xmlmd5: c3a73109be6c186b9d72e714bcedaddbouts:- cache: true md5: 6836f797f3924fb46fcfd6b9f6aa6416.dir metric: false path: 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: true md5: ce68b98d82545628782c66192c96f2d2 metric: false path: data/Posts.xml.zip persist: 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 會跟蹤所有內容。
選自towardsdatascience
作者：David Herron
機器之心編譯
參與：高璇、王淑婷
為解決機器學習可復現性的問題，很多人會用 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 管理的數據可以很容易地與其他使用此存儲系統的用戶共享。
圖源：http://dvc.org/
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」，文件將會匹配新版本。
圖源：http://dvc.org/
在 DVC 端，這在 DVC 緩存中處理。存儲在緩存中的文件通過內容校驗和（MD5 哈希值）進行索引。隨著 DVC 管理的各個文件發生變化時，其校驗和會發生變化，並會創建相應的緩存條目。緩存將保存每個文件的所有實例。
為了提高效率，DVC 使用多種鏈接方法（取決於文件系統支持）將文件插入工作區而無需複製。這樣，DVC 可以在請求時快速更新工作目錄。
DVC 使用所謂的「DVC 文件」來描述數據文件和工作流步驟。每個工作區將有多個 DVC 文件，每個文件都用相應的校驗和描述一個或多個數據文件，每個文件都要描述在工作流中執行的命令。
cmd: python src/prepare.py data/data.xmldeps:- md5: b4801c88a83f3bf5024c19a942993a48 path: src/prepare.py- md5: a304afb96060aad90176268345e10355 path: data/data.xmlmd5: c3a73109be6c186b9d72e714bcedaddbouts:- cache: true md5: 6836f797f3924fb46fcfd6b9f6aa6416.dir metric: false path: 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: true md5: ce68b98d82545628782c66192c96f2d2 metric: false path: data/Posts.xml.zip persist: 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 會跟蹤所有內容。
圖源：http://dvc.org/
DVC 使團隊成員之間輕鬆實現數據和代碼共享
機器學習研究人員可能需要與同事合作，需要共享數據、代碼和配置。或者需要將數據部署到遠程系統，例如在雲計算系統（AWS、GCP 等）上運行軟件，這意味著將數據需要上傳到相應的雲存儲服務（S3、GCP 等）上。
DVC 工作空間的代碼和配置端存儲在 SCM 中（如 Git）。使用普通的 SCM 命令（如 git5 clone），你可以輕鬆地與同事共享代碼和配置。但是如何與同事共享數據呢？
DVC 具有遠程存儲的概念。DVC 工作空間可以將數據傳輸到遠程存儲中或從遠程存儲中提取數據。遠程存儲池可以存在於任何雲存儲平臺（S3、GCP 等）以及 SSH 服務器上。
因此，要與同事共享代碼、配置和數據，首先要定義遠程存儲池。保存遠程存儲定義的配置文件由 SCM 跟蹤。接下來，將 SCM 存儲庫傳送到共享服務器，該服務器附帶 DVC 配置文件。當你的同事克隆存儲庫時，他們就可以立即從遠程緩存中提取數據。
這意味著你的同事不用再費心思量如何運行你的代碼。他們可以輕鬆復現你的確切步驟，充分利用精確數據來生成結果。
選自towardsdatascience
作者：David Herron
機器之心編譯
參與：高璇、王淑婷
為解決機器學習可復現性的問題，很多人會用 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 管理的數據可以很容易地與其他使用此存儲系統的用戶共享。
圖源：http://dvc.org/
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」，文件將會匹配新版本。
圖源：http://dvc.org/
在 DVC 端，這在 DVC 緩存中處理。存儲在緩存中的文件通過內容校驗和（MD5 哈希值）進行索引。隨著 DVC 管理的各個文件發生變化時，其校驗和會發生變化，並會創建相應的緩存條目。緩存將保存每個文件的所有實例。
為了提高效率，DVC 使用多種鏈接方法（取決於文件系統支持）將文件插入工作區而無需複製。這樣，DVC 可以在請求時快速更新工作目錄。
DVC 使用所謂的「DVC 文件」來描述數據文件和工作流步驟。每個工作區將有多個 DVC 文件，每個文件都用相應的校驗和描述一個或多個數據文件，每個文件都要描述在工作流中執行的命令。
cmd: python src/prepare.py data/data.xmldeps:- md5: b4801c88a83f3bf5024c19a942993a48 path: src/prepare.py- md5: a304afb96060aad90176268345e10355 path: data/data.xmlmd5: c3a73109be6c186b9d72e714bcedaddbouts:- cache: true md5: 6836f797f3924fb46fcfd6b9f6aa6416.dir metric: false path: 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: true md5: ce68b98d82545628782c66192c96f2d2 metric: false path: data/Posts.xml.zip persist: 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 會跟蹤所有內容。
圖源：http://dvc.org/
DVC 使團隊成員之間輕鬆實現數據和代碼共享
機器學習研究人員可能需要與同事合作，需要共享數據、代碼和配置。或者需要將數據部署到遠程系統，例如在雲計算系統（AWS、GCP 等）上運行軟件，這意味著將數據需要上傳到相應的雲存儲服務（S3、GCP 等）上。
DVC 工作空間的代碼和配置端存儲在 SCM 中（如 Git）。使用普通的 SCM 命令（如 git5 clone），你可以輕鬆地與同事共享代碼和配置。但是如何與同事共享數據呢？
DVC 具有遠程存儲的概念。DVC 工作空間可以將數據傳輸到遠程存儲中或從遠程存儲中提取數據。遠程存儲池可以存在於任何雲存儲平臺（S3、GCP 等）以及 SSH 服務器上。
因此，要與同事共享代碼、配置和數據，首先要定義遠程存儲池。保存遠程存儲定義的配置文件由 SCM 跟蹤。接下來，將 SCM 存儲庫傳送到共享服務器，該服務器附帶 DVC 配置文件。當你的同事克隆存儲庫時，他們就可以立即從遠程緩存中提取數據。
這意味著你的同事不用再費心思量如何運行你的代碼。他們可以輕鬆復現你的確切步驟，充分利用精確數據來生成結果。
圖源：http://dvc.org/
結論
復現結果的關鍵是，不僅要確保數據的正確版本，還要保證代碼和配置文件的正確版本，並自動執行各個步驟。成功的項目有時需要與同事協作，而這可以通過雲存儲系統更輕鬆地實現。有些工作要求在雲計算平臺上運行 AI 軟件，因此需要將數據文件存儲在雲存儲平臺上。
藉助 DVC，機器學習研究團隊可以確保他們的數據、配置和代碼全部同步。它是一個易於使用的系統，可以有效地管理共享數據存儲庫和 SCM 系統（如 Git），以存儲配置和代碼。
原文鏈接：https://towardsdatascience.com/why-git-and-git-lfs-is-not-enough-to-solve-the-machine-learning-reproducibility-crisis-f733b49e96e8
相關推薦
