實踐中的資料集版本控制：訓練資料的 Git

您用 Git 對代碼進行版本控制。您用模型登錄表對模型進行版本控制。但當有人問「什麼資料訓練了目前生產環境中的模型？」時——典型的回答是尷尬的沉默，然後有人去查四個月前的 Slack 線索。

這個差距不只是不方便。每次出現問題時，它就是一個可重現性、調試和合規失敗，耗費團隊數週的返工。

資料集版本控制——將代碼版本控制中的分支、差異比較、標籤和回滾概念應用於訓練資料——是成熟 AI 團隊填補這一差距的方式。以下是它在實踐中的樣子。

為什麼資料集版本控制很重要

正確地對訓練資料進行版本控制後，四個問題就消失了。

可重現性

「重新創建訓練了模型 v2.3 的確切資料集。」沒有版本控制，這個請求會觸發一次法證調查：哪些腳本運行了，應用了哪些過濾器，當時的標籤是什麼，哪些資料被排除了。有了版本控制，這只是一個簽出命令。

可重現性不是學術問題。當模型在生產環境中行為異常時，第一個調試步驟是檢查訓練資料。如果您無法精確重新創建那個資料集，您就是在盲目調試。

調試

模型 v3.1 在特定文件類型上的性能比 v3.0 差 8%。什麼改變了？如果您有版本化的資料集，您可以差異比較兩個版本，看到在它們之間添加、刪除或修改了哪些示例。沒有版本控制，調查需要數天，往往以「我們不確定」結束。

在我們見過的一個案例中，一個團隊花了兩週時間調查一個性能退化，結果是由 47 個在資料集版本之間添加的錯誤標記示例引起的。有了適當的差異比較，他們 20 分鐘就能找到它。

合規

歐盟 AI 法案要求組織記錄用於訓練 AI 系統的資料。第 10 條特別規定資料治理涵蓋「相關設計選擇、資料收集過程、資料準備操作，如標注、資料清理和資料豐富」。GDPR 的解釋權創造了類似的要求。

資料集版本控制提供了監管機構期望的審計追蹤：使用了什麼資料、何時收集的、如何轉換的，以及哪個模型在哪個版本上訓練。沒有這個，展示合規需要從碎片中重建歷史——審計員對此持有理由的懷疑。

回滾

您的團隊更新了標記指南並重新標記了 2,000 個示例。重新訓練的模型表現更差。有了資料集版本控制，您回滾到之前的資料集版本並重新訓練。沒有它，您嘗試手動撤銷標記更改——一個引入新錯誤的過程。

回滾能力將資料準備錯誤從災難變成小挫折。能夠回滾的團隊更自由地實驗，從而更快地得到更好的資料集。

資料集版本控制的當前方法

幾個工具實現了資料集版本控制，各有不同的權衡。

DVC（資料版本控制）

採用最廣泛的工具。DVC 用大文件支持擴展 Git——您用 DVC 追蹤資料文件，同時用 Git 追蹤元資料（哈希值、管道定義）。資料存儲在遠端存儲（S3、GCS、Azure Blob）中，而 Git 存儲輕量級指針文件。

優勢： Git 原生工作流，強大的社群，適用於任何存儲後端。劣勢： 需要命令列熟練度，差異比較大型資料集很慢，沒有資料集更改的內建可視化。

lakeFS

直接在資料湖上進行類 Git 操作。lakeFS 為存儲在對象存儲中的資料提供分支、提交和合併。它在存儲層工作，所以對從 S3 兼容端點讀取的工具是透明的。

優勢： 可擴展到 PB 級別，零複製分支（分支不複製資料），與現有資料湖工具一起使用。劣勢： 需要基礎設施設置，針對資料湖而非結構化資料集優化。

Pachyderm

將資料版本控制與管道編排相結合。每個資料轉換都自動版本化，從原始資料到處理輸出創建完整的來源圖。

優勢： 自動來源追蹤、管道感知版本控制、Kubernetes 原生。劣勢： 更重的基礎設施要求、更陡峭的學習曲線，對於只需要版本控制的團隊來說過於複雜。

手動版本控制（時間戳文件夾）

大多數團隊開始的方式：dataset_v1/、dataset_v2/、dataset_20260115/。易於理解，易於實現。

劣勢： 沒有差異比較能力，沒有分支，沒有合併衝突解決，存儲效率低（完整副本），命名慣例在規模上崩潰，沒有關於什麼改變或為什麼的元資料。這種方法在 3 到 5 個版本時有效。在 20 個以上版本時失敗。

要版本控制什麼

並非所有資料工件都需要相同級別的版本控制嚴格性。以下是優先順序：

始終版本控制：

• 標記的資料——模型訓練的直接輸入。每次更改都很重要。
• 匯出配置——決定標記資料如何成為訓練資料的設置（格式、分割、過濾規則）。
• 標記指南——定義每個標籤含義的文件。這裡的更改使先前的標籤無效。

實際可行時版本控制：

• 清理後的資料——後處理、預標記。對調試清理管道很有用。
• 原始資料——任何處理之前的原始文件。對合規很重要，但原始資料通常很大且不常更改。

資源允許時版本控制：

• 增強的資料——合成示例、資料增強輸出。如果管道本身被版本控制了，這些可以從增強管道重新生成，所以版本控制不太關鍵。

版本控制工作流程

實際的資料集版本控制工作流程反映了開發團隊已經熟悉的 Git 分支模型。

主分支

main 分支包含當前生產資料集——訓練了目前生產中模型的資料集。這個分支是受保護的：不允許直接修改。所有更改都通過合併請求進行。

實驗分支

當團隊成員想要修改資料集時——添加新示例、重新標記現有示例、刪除有問題的條目——他們創建一個分支。這個分支是一個隔離的副本（或在高效實現中，是一個寫時複製引用），可以在不影響生產資料集的情況下進行更改。

實驗分支的成本低廉。團隊應該自由地創建它們：add-medical-terminology、relabel-contract-clauses、remove-duplicate-invoices。每個分支在其名稱中記錄其意圖。

審查和合併

在將資料集分支合併到 main 之前，團隊審查差異。關鍵問題：

• 添加、修改或刪除了多少示例？
• 更改是否顯著改變了類別分佈？
• 品質指標（標注者間一致率、格式合規性）是否達到閾值？
• 領域專家是否審查了更改？

這個審查在問題污染生產資料集之前捕獲它們。這是代碼審查的資料等價物——同樣重要。

標記發布

當資料集用於訓練模型時，用模型版本標記它：model-v3.1-dataset。這創建了一個永久的、不可更改的參考點。六個月後，任何人都可以簽出訓練了 v3.1 的確切資料集。

標籤應包含元資料：示例數量、類別分佈摘要、品質分數和訓練運行的日期。

差異比較能力

資料集版本控制最有價值的功能是差異比較兩個版本的能力。與代碼差異比較（比較文字行）不同，資料集差異比較需要捕獲：

行級別更改： 在版本之間添加、刪除或修改了哪些示例。對於有 5,000 個示例的資料集，知道添加了 47 個、重新標記了 12 個立即是有用的。

標籤更改： 具體哪些標籤改變了以及如何改變。示例是否從 A 類別移到了 B 類別？是否有系統性的重新標記？這有助於識別標籤更改是有意的（指南更新）還是意外的（標注者錯誤）。

分佈偏移： 整體資料集分佈如何變化？如果 A 類從資料集的 30% 變為 15%，這是一個顯著的偏移，將影響模型行為。在審查期間應自動標記分佈差異。

架構更改： 輸出格式是否改變？是否添加了新欄位？這捕獲了會破壞訓練的格式不一致性。

存儲策略

樸素的版本控制——為每個版本存儲完整的資料集副本——是浪費的。有 50 個版本的 10GB 資料集將消耗 500GB。

增量編碼只存儲版本之間的更改。第 1 版完整存儲；第 2 版只存儲添加、修改或刪除的行。對於每個版本更改不到 20% 的資料的典型資料集，這將存儲減少 80% 到 95%。

內容可尋址存儲（由 DVC 和 Git LFS 使用）每個唯一的文件塊只存儲一次，並通過哈希值引用。跨版本的相同塊只存儲一次。

遠端存儲將資料保存在雲端存儲（S3、GCS）或網路附加存儲上，同時只在本地保留元資料和指針。對於超過 10GB 的資料集，這是必不可少的。

與模型訓練的整合

當與模型訓練整合時，資料集版本控制的完整價值才能實現。整合點：

訓練元資料： 每次訓練運行都記錄它使用的資料集版本（標籤或提交哈希）。這是訓練配置中的一個字段，但它實現了完整的可追溯性。

自動驗證： 在訓練開始之前，管道驗證資料集版本存在、通過品質檢查並匹配預期的架構。這防止在損壞或不完整的資料集上訓練。

比較運行： 在具有相同超參數的兩個資料集版本上訓練兩個模型。性能差異完全歸因於資料更改。這是您測量資料改進影響的方式。

來源追蹤： 從生產模型，追溯到資料集版本，再到貢獻它的個別標記會話。從預測到來源資料的完整來源。

Ertas Data Suite 實現了具有完整差異比較能力、分支合併工作流程和從標記示例到匯出資料集的自動來源追蹤的資料集版本控制。每次更改都被追蹤，記錄了誰進行了更改、何時以及為什麼——提供可重現性和合規所需的審計追蹤。所有資料都保留在您的基礎設施上，使用存儲效率高的增量編碼，即使對於大型資料集也使版本控制切實可行。

---

延伸閱讀

• 什麼是企業 AI 的資料來源？ — 了解端到端資料來源以及為什麼它對 AI 治理很重要。
• 企業 AI 交付物的資料來源報告 — 如何生成滿足合規和利益相關者要求的來源報告。
• AI 模型版本控制、回滾和漂移 — 資料集版本控制的模型端補充——管理模型版本和資料版本。