為解決機(jī)器學(xué)習(xí)可復(fù)現(xiàn)性的問題，很多人會用 Git 和 Git-LFS，但這二者并不足以解決這個(gè)難題。為此，作者在文中提出了 DVC 并列出了它的三大優(yōu)勢：精準(zhǔn)記錄時(shí)間點(diǎn)和使用的文件、特定時(shí)間點(diǎn)使用命令的確切順序、輕松實(shí)現(xiàn)數(shù)據(jù)和代碼共享。

有人認(rèn)為，由于軟件工具的不充分，無法保證完全復(fù)現(xiàn)機(jī)器學(xué)習(xí)模型的結(jié)果，機(jī)器學(xué)習(xí)領(lǐng)域正「陷入危機(jī)」。這個(gè)危機(jī)可以通過為機(jī)器學(xué)習(xí)從業(yè)者提供更好的軟件工具來解決。

可復(fù)現(xiàn)性問題非常重要，每年一度的 NeurIPS 會議也將其列為 NeurIPS 2019 討論的主要議題。

所謂的危機(jī)是因?yàn)檠芯空唠y以復(fù)現(xiàn)同行或科學(xué)家們的工作，這制約了他們在彼此工作基礎(chǔ)上進(jìn)一步取得進(jìn)展。由于機(jī)器學(xué)習(xí)和其他形式的人工智能軟件在學(xué)術(shù)和企業(yè)研究中得到廣泛應(yīng)用，因此可復(fù)制性或可復(fù)現(xiàn)性是一個(gè)亟待解決的關(guān)鍵問題。

我們可能認(rèn)為這可以通過典型的軟件工程工具來解決，因?yàn)闄C(jī)器學(xué)習(xí)開發(fā)與普通軟件工程類似。在這兩種情況下，我們會生成某種編譯軟件工具，以便在計(jì)算機(jī)硬件上執(zhí)行，并獲得準(zhǔn)確的結(jié)果。為什么我們不能利用豐富的軟件工具和質(zhì)量極佳的軟件來為機(jī)器學(xué)習(xí)團(tuán)隊(duì)構(gòu)建可復(fù)現(xiàn)流程呢?

遺憾的是，傳統(tǒng)的軟件工程工具并不能很好地滿足機(jī)器學(xué)習(xí)研究者的需求。

關(guān)鍵問題是訓(xùn)練數(shù)據(jù)。通常，訓(xùn)練機(jī)器學(xué)習(xí)模型需要大量的數(shù)據(jù)，例如圖像、視頻或文本。而訓(xùn)練數(shù)據(jù)不在任何一種源代碼控制機(jī)制下，因?yàn)橄?Git 這樣的系統(tǒng)不能很好地處理大型數(shù)據(jù)文件，并且用于生成 delta 文本文件的源代碼控制管理系統(tǒng)不能很好地處理對大型二進(jìn)制文件的更改。

任何經(jīng)驗(yàn)豐富的軟件工程師都會告訴你，沒有源代碼控制的團(tuán)隊(duì)只是「無頭蒼蠅」。更改文件不會一直被記錄，團(tuán)隊(duì)成員時(shí)常會忘記執(zhí)行過的操作。

而當(dāng)訓(xùn)練結(jié)束時(shí)，你可能無法復(fù)現(xiàn)用該訓(xùn)練數(shù)據(jù)訓(xùn)練的模型，因?yàn)橛?xùn)練數(shù)據(jù)集將以未知方式發(fā)生改變。如果沒有軟件系統(tǒng)記錄某次的數(shù)據(jù)集狀態(tài)，那么有什么機(jī)制可以記錄這一切呢?

Git-LFS 是解決方案嗎?

我們首先想到的解決方案可能是簡單地使用 Git-LFS (Git Large File Storage)，顧名思義，它在構(gòu)建 Git 時(shí)處理大文件。Git-LFS「用 Git 內(nèi)部的文本指針替換大型文件，如音頻、視頻、數(shù)據(jù)集和圖形，同時(shí)將文件內(nèi)容存儲在 GitHub.com 或 GitHub Enterprise 等遠(yuǎn)程服務(wù)器上�！�

我仿佛還能聽到機(jī)器學(xué)習(xí)團(tuán)隊(duì)說「聽起來很棒，開始吧」。它能夠處理數(shù)千兆字節(jié)的文件，加快遠(yuǎn)程存儲庫的出庫速度，并使用同樣舒適的工作流。這肯定符合標(biāo)準(zhǔn)了，對吧?

并沒這么簡單，項(xiàng)目經(jīng)理沒有告訴你要三思而后行嗎?就像另一個(gè)寶貴的人生意見一樣：過馬路之前要左右看看。

你應(yīng)該首先考慮的是 Git-LFS 需要一個(gè) LFS 服務(wù)器，并且該服務(wù)器不是通過每個(gè) Git 托管服務(wù)都可用。三巨頭(Github、Gitlab 和 Atlassian)都支持 Git-LFS，但也許你天生愛 DIY。相比使用第三方 Git 托管服務(wù)，你可能更愿意自己托管 Git 服務(wù)。例如，Gogs 是一個(gè)功能強(qiáng)大的 Git 服務(wù)器，你可以輕松地在自己的硬件上運(yùn)行，但它沒有內(nèi)置的 Git-LFS 支持。

根據(jù)你的數(shù)據(jù)需求，下一步可能會有點(diǎn)「致命」：Git-LFS 允許的存儲文件最大為 2 GB。這是 Github 帶來的限制，而非 Git-LFS，但是似乎所有的 Git-LFS 實(shí)現(xiàn)都受到各種限制。Gitlab 和 Atlassian 都有各種 Git-LFS 限制。想想 Github 的這個(gè) 2GB 限制：Git-LFS 有個(gè)應(yīng)用案例是存儲視頻文件，但是視頻的大小經(jīng)常超過 2GB。因此，Github 上的 GIt-LFS 可能不適用于機(jī)器學(xué)習(xí)數(shù)據(jù)集。

不僅僅是 2GB 的限制，Github 對 Git-LFS 使用的免費(fèi)層也設(shè)置了嚴(yán)格的限制，使用者必須購買涵蓋數(shù)據(jù)和帶寬使用的數(shù)據(jù)計(jì)劃。

與帶寬相關(guān)的一個(gè)問題是，當(dāng)你使用托管的 Git-LFS 解決方案時(shí)，訓(xùn)練數(shù)據(jù)會存儲在遠(yuǎn)程服務(wù)器中，必須通過 Internet 下載數(shù)據(jù)。而下載過程嚴(yán)重影響用戶體驗(yàn)。

另一個(gè)問題是，在運(yùn)行基于云的 AI 軟件時(shí)，通常需要將數(shù)據(jù)文件放置在云存儲系統(tǒng)(AWS、GCP 等)上。而來自 Git 服務(wù)器三巨頭的主要 Git-LFS 產(chǎn)品將 LFS 文件存儲在它們的服務(wù)器上，一般不支持云存儲。

有一個(gè) DIY 的 Git-LFS 服務(wù)器可以在 AWS S3 上存儲文件，網(wǎng)址是 https://github.com/meltingice/git-lfs-s3，但是設(shè)置自定義的 Git-LFS 服務(wù)器需要額外的工作。

而且，如果需要將文件放在 GCP 而不是 AWS 基礎(chǔ)架構(gòu)上時(shí)，該怎么辦?是否有 Git-LFS 服務(wù)器能夠?qū)��?shù)據(jù)存儲在自主選擇的云存儲平臺上?是否有使用簡易 SSH 服務(wù)器的 Git-LFS 服務(wù)器?換句話說，GIt-LFS 限制了用戶對數(shù)據(jù)存儲位置的選擇。

使用 Git-LFS 解決了所謂的機(jī)器學(xué)習(xí)復(fù)現(xiàn)危機(jī)嗎?

使用 Git-LFS 后，你的機(jī)器學(xué)習(xí)團(tuán)隊(duì)可以更好地控制數(shù)據(jù)，因?yàn)樗�現(xiàn)在是版本控制的。這是否意味著問題已解決?

先前我們說過「關(guān)鍵問題是訓(xùn)練數(shù)據(jù)」，但這是一個(gè)小謊言。是的，數(shù)據(jù)能在版本控制下就是一個(gè)很大的改進(jìn)。但是缺乏對數(shù)據(jù)文件的版本控制是整個(gè)問題所在 嗎?并不。

什么決定了訓(xùn)練模型或其他活動的結(jié)果?決定因素包括但不限以下內(nèi)容：

訓(xùn)練數(shù)據(jù)——訓(xùn)練模型時(shí)使用的圖像數(shù)據(jù)庫或任何數(shù)據(jù)源
訓(xùn)練模型使用的腳本
訓(xùn)練腳本使用的庫
處理數(shù)據(jù)使用的腳本
處理數(shù)據(jù)使用的庫或其它工具
操作系統(tǒng)和 CPU/GPU 硬件
生產(chǎn)系統(tǒng)代碼
生產(chǎn)系統(tǒng)代碼使用的庫

顯然，訓(xùn)練模型的結(jié)果取決于各種條件。由于存在多方變量，所以很難準(zhǔn)確描述，但一般的問題是缺少所謂的配置管理。軟件工程師已經(jīng)認(rèn)識到能夠指定部署系統(tǒng)時(shí)使用的精確系統(tǒng)配置十分重要。

機(jī)器學(xué)習(xí)可復(fù)現(xiàn)性的解決方案

人類是一個(gè)富有創(chuàng)造力的群體，為這個(gè)「危機(jī)」提出了很多可能的解決方案。

R Studio 或 Jupyter Notebook 等環(huán)境提供了一種交互式 Markdown 文檔，可以配置用來執(zhí)行數(shù)據(jù)科學(xué)或機(jī)器學(xué)習(xí)工作流。這對于記錄機(jī)器學(xué)習(xí)工作以及指定使用哪些腳本和庫來說非常有用。但是這些系統(tǒng)不提供管理數(shù)據(jù)集的解決方案。

同樣，Makefile 和類似的工作流腳本工具提供了一種重復(fù)執(zhí)行一系列命令的方法。執(zhí)行命令是通過文件系統(tǒng)時(shí)間戳確定的。這些工具也不提供數(shù)據(jù)管理解決方案。

另一方面，像 Domino Data Labs 或 C3 IoT 這樣的公司提供了數(shù)據(jù)科學(xué)和機(jī)器學(xué)習(xí)的托管平臺。兩者都將基于大量數(shù)據(jù)科學(xué)工具的產(chǎn)品打包在一起。在某些情況下，如 C3 IoT，用戶使用專用語言編碼，并將數(shù)據(jù)存儲在專用數(shù)據(jù)存儲中�！敢徽臼絺潺R」可能真的很便捷，但它能提供足夠的靈活性嗎?

本文接下來的部分將介紹 DVC。它的設(shè)計(jì)充分利用了大多數(shù)人對 Git 的熟悉程度，旨在與 Git 功能緊密匹配，但它具有適用于機(jī)器學(xué)習(xí)環(huán)境中的工作流和數(shù)據(jù)管理的功能。

與 Git-LFS 或其他幾種可能的解決方案相比，DVC 承擔(dān)并解決了機(jī)器學(xué)習(xí)復(fù)現(xiàn)性的大部分問題。它的方式是在 DVC 和像 Git 這樣的源代碼管理系統(tǒng)(SCM)中混合管理代碼(腳本和程序)以及大數(shù)據(jù)文件。此外，DVC 管理處理機(jī)器學(xué)習(xí)實(shí)驗(yàn)中使用的文件所需的工作流。

DVC 文件中描述了數(shù)據(jù)文件和要執(zhí)行的命令，我們將在接下來的小節(jié)介紹這些文件。最后，使用 DVC 可以輕松地將數(shù)據(jù)存儲在許多存儲系統(tǒng)上，像本地磁盤、SSH 服務(wù)器或云系統(tǒng)(S3、GCP 等)。DVC 管理的數(shù)據(jù)可以很容易地與其他使用此存儲系統(tǒng)的用戶共享。

 

 

圖源：http://dvc.org/

DVC 使用與 Git 類似的命令結(jié)構(gòu)。正如我們看到的，就像 git push 和 git pull 用于共享代碼和配置一樣，dvc push 和 dvc pull 用于共享數(shù)據(jù)。所有這些都將在后面的章節(jié)詳細(xì)介紹，或者如果你想學(xué)習(xí) DVC，請參閱教程：https://dvc.org/doc/tutorial。

DVC 可以精準(zhǔn)記錄時(shí)間點(diǎn)和使用的文件

DVC 的核心是為存儲和版本控制大文件而優(yōu)化的數(shù)據(jù)存儲(DVC 緩存)。團(tuán)隊(duì)可以選擇將哪些文件存儲在 SCM(如 Git)中，哪些存儲在 DVC 中。存儲由 DVC 管理的文件，這樣 DVC 可以維護(hù)每個(gè)文件的多個(gè)版本，并使用文件系統(tǒng)鏈接快速更換正在使用的文件版本。

從概念上講，SCM(如 Git)和 DVC 都有存儲庫，其中包含每個(gè)文件的多個(gè)版本。如果查看「版本 N」，相應(yīng)的文件將出現(xiàn)在工作目錄中，然后查看「版本 N + 1」，文件將會匹配新版本。

 

 

圖源：http://dvc.org/

在 DVC 端，這在 DVC 緩存中處理。存儲在緩存中的文件通過內(nèi)容校驗(yàn)和(MD5 哈希值)進(jìn)行索引。隨著 DVC 管理的各個(gè)文件發(fā)生變化時(shí)，其校驗(yàn)和會發(fā)生變化，并會創(chuàng)建相應(yīng)的緩存條目。緩存將保存每個(gè)文件的所有實(shí)例。

為了提高效率，DVC 使用多種鏈接方法(取決于文件系統(tǒng)支持)將文件插入工作區(qū)而無需復(fù)制。這樣，DVC 可以在請求時(shí)快速更新工作目錄。

DVC 使用所謂的「DVC 文件」來描述數(shù)據(jù)文件和工作流步驟。每個(gè)工作區(qū)將有多個(gè) DVC 文件，每個(gè)文件都用相應(yīng)的校驗(yàn)和描述一個(gè)或多個(gè)數(shù)據(jù)文件，每個(gè)文件都要描述在工作流中執(zhí)行的命令。

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)，并顯示了工作流的初始步驟。在下一節(jié)，我們會詳細(xì)介紹工作流。現(xiàn)在，請注意此命令有兩個(gè)依賴項(xiàng) src/prepare.py 和 data/data.xml，以及一個(gè)名為 data/prepared 的輸出數(shù)據(jù)目錄。這些都會產(chǎn)生 MD5 哈希值，并且隨著文件更改，MD5 哈希值將發(fā)生變化，更改后的數(shù)據(jù)文件的新實(shí)例將存儲在 DVC 緩存中。

DVC 文件被檢入 SCM 管理(Git)存儲庫。當(dāng)存入 SCM 存儲庫時(shí)，每個(gè) DVC 文件都會使用每個(gè)文件的新校驗(yàn)和來更新(如果適用)。因此，使用 DVC 可以精確地重新創(chuàng)建每個(gè)提交的數(shù)據(jù)集，團(tuán)隊(duì)也可以精確地重新創(chuàng)建項(xiàng)目的每個(gè)開發(fā)步驟。

DVC 文件類似于 Git-LFS 中使用的「指針」文件。

DVC 團(tuán)隊(duì)建議在每個(gè)實(shí)驗(yàn)中使用不同的 SCM 標(biāo)簽或分支。因此，訪問適合該實(shí)驗(yàn)的數(shù)據(jù)文件、代碼和配置就像切換分支一樣簡單。SCM 將自動更新代碼和配置文件，DVC 將自動更新數(shù)據(jù)文件。

這意味著你不用再絞盡腦汁去記住哪些數(shù)據(jù)文件用于什么實(shí)驗(yàn)了。DVC 會為追蹤這一切。

DVC 會記住特定時(shí)間點(diǎn)使用命令的確切順序

DVC 文件不僅能記住特定執(zhí)行階段使用的文件，還能記住在該階段執(zhí)行的命令。

復(fù)現(xiàn)機(jī)器學(xué)習(xí)結(jié)果不僅需要使用相同的數(shù)據(jù)文件，而且需要相同的處理步驟和相同的代碼/配置。一般創(chuàng)建模型的步驟，首先要準(zhǔn)備在后續(xù)步驟中使用的樣本數(shù)據(jù)。你可能會利用 Python 腳本 prepare.py 來拆分?jǐn)?shù)據(jù)，并且在 data/data.xml 文件中輸入數(shù)據(jù)。

$ dvc run -d data/data.xml -d code/prepare.py \ -o data/prepared \ python code/prepare.py

我們用該語句使 DVC 記錄該處理步驟。DVC「run」命令根據(jù)命令行選項(xiàng)創(chuàng)建 DVC 文件。

-d 選項(xiàng)定義依賴項(xiàng)，在本例中，我們看到 XML 格式的輸入文件以及 Python 腳本。-o 選項(xiàng)記錄輸出文件，這里列出了輸出數(shù)據(jù)目錄。最后，執(zhí)行的命令是一個(gè) Python 腳本。

因此，我們輸入的數(shù)據(jù)、代碼和配置以及輸出數(shù)據(jù)，都被事無巨細(xì)地記錄在生成的 DVC 文件中，該文件對應(yīng)上一節(jié)中顯示的 DVC 文件。

如果 prepare.py 從本次提交更改為下一次提交，則 SCM 將自動跟蹤更改。同樣，對 data.xml 的任何更改都會在 DVC 緩存中產(chǎn)生新實(shí)例，DVC 將自動跟蹤該實(shí)例。如果結(jié)果數(shù)據(jù)目錄發(fā)生更改，DVC 也會跟蹤它們。

DVC 文件也可以簡單地引用文件，如下所示：

md5: 99775a801a1553aae41358eafc2759a9outs:- cache: true md5: ce68b98d82545628782c66192c96f2d2 metric: false path: data/Posts.xml.zip persist: falsewdir: ..

這是 dvc add file 命令得到的結(jié)果，該命令僅在只有一個(gè)數(shù)據(jù)文件時(shí)使用，并且其他命令不會產(chǎn)生這個(gè)結(jié)果。例如，在 https://dvc.org/doc/tutorial/define-ml-pipeline 中會顯示，結(jié)果會立刻出現(xiàn)在前面的 DVC 文件：

$ wget -P data https://dvc.org/s3/so/100K/Posts.xml.zip$ dvc add data/Posts.xml.zip

然后，Posts.xml.zip 文件是本教程中一系列步驟的數(shù)據(jù)源，每一步都要從這些數(shù)據(jù)中獲取信息。

退一步講，我們要明確這些是更大型工作流中的單個(gè)步驟，或者在 DVC 中稱之為管道的步驟。通過 dvc add 和 dvc run，可以將多個(gè)階段串聯(lián)起來，每個(gè)階段都使用 dvc run 命令創(chuàng)建，且由 DVC 文件描述。

這意味著每個(gè)工作目錄將包含多個(gè) DVC 文件，其中一個(gè)用于該項(xiàng)目流程的每個(gè)階段。DVC 掃描 DVC 文件，構(gòu)建復(fù)現(xiàn)流程所需命令的有向非循環(huán)圖(Directed Acyclic Graph DAG)。

每個(gè)階段都像一個(gè) mini-Makefile，只有當(dāng)依賴關(guān)系發(fā)生變化時(shí)，DVC 才會執(zhí)行命令。它也有所不同，因?yàn)?DVC 不會像 Make 那樣只考慮文件系統(tǒng)時(shí)間戳，而是考慮文件內(nèi)容是否已更改，這由 DVC 文件中的校驗(yàn)和與文件的當(dāng)前狀態(tài)確定。

最重要的是，這意味著不需再費(fèi)盡周章記住每個(gè)實(shí)驗(yàn)使用哪個(gè)版本的腳本。DVC 會跟蹤所有內(nèi)容。

 

 

圖源：http://dvc.org/

DVC 使團(tuán)隊(duì)成員之間輕松實(shí)現(xiàn)數(shù)據(jù)和代碼共享

機(jī)器學(xué)習(xí)研究人員可能需要與同事合作，需要共享數(shù)據(jù)、代碼和配置�；蛘咝枰獙�數(shù)據(jù)部署到遠(yuǎn)程系統(tǒng)，例如在云計(jì)算系統(tǒng)(AWS、GCP 等)上運(yùn)行軟件，這意味著將數(shù)據(jù)需要上傳到相應(yīng)的云存儲服務(wù)(S3、GCP 等)上。

DVC 工作空間的代碼和配置端存儲在 SCM 中(如 Git)。使用普通的 SCM 命令(如 git5 clone)，你可以輕松地與同事共享代碼和配置。但是如何與同事共享數(shù)據(jù)呢?

DVC 具有遠(yuǎn)程存儲的概念。DVC 工作空間可以將數(shù)據(jù)傳輸?shù)竭h(yuǎn)程存儲中或從遠(yuǎn)程存儲中提取數(shù)據(jù)。遠(yuǎn)程存儲池可以存在于任何云存儲平臺(S3、GCP 等)以及 SSH 服務(wù)器上。

因此，要與同事共享代碼、配置和數(shù)據(jù)，首先要定義遠(yuǎn)程存儲池。保存遠(yuǎn)程存儲定義的配置文件由 SCM 跟蹤。接下來，將 SCM 存儲庫傳送到共享服務(wù)器，該服務(wù)器附帶 DVC 配置文件。當(dāng)你的同事克隆存儲庫時(shí)，他們就可以立即從遠(yuǎn)程緩存中提取數(shù)據(jù)。

這意味著你的同事不用再費(fèi)心思量如何運(yùn)行你的代碼。他們可以輕松復(fù)現(xiàn)你的確切步驟，充分利用精確數(shù)據(jù)來生成結(jié)果。

 

 

圖源：http://dvc.org/

結(jié)論

復(fù)現(xiàn)結(jié)果的關(guān)鍵是，不僅要確保數(shù)據(jù)的正確版本，還要保證代碼和配置文件的正確版本，并自動執(zhí)行各個(gè)步驟。成功的項(xiàng)目有時(shí)需要與同事協(xié)作，而這可以通過云存儲系統(tǒng)更輕松地實(shí)現(xiàn)。有些工作要求在云計(jì)算平臺上運(yùn)行 AI 軟件，因此需要將數(shù)據(jù)文件存儲在云存儲平臺上。

借助 DVC，機(jī)器學(xué)習(xí)研究團(tuán)隊(duì)可以確保他們的數(shù)據(jù)、配置和代碼全部同步。它是一個(gè)易于使用的系統(tǒng)，可以有效地管理共享數(shù)據(jù)存儲庫和 SCM 系統(tǒng)(如 Git)，以存儲配置和代碼。

原文鏈接：https://towardsdatascience.com/why-git-and-git-lfs-is-not-enough-to-solve-the-machine-learning-reproducibility-crisis-f733b49e96e8

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。