If you don't know the provenance or the source of the artifact, it's not science, it's a pretty thing to look at. — Erin McKean

前言

我們都知道在寫程式的時候要使用版本控制來追蹤、維護程式碼，但在機器學習的領域是否需要類似的方法論呢?
在開始今天的文章之前，先來想想看以下問題該怎麼回答：

• 這個模型使用哪個資料集訓練的？
• 使用哪些超參數？
• 使用了哪個 pipeline 來建立這個模型？
• 使用了哪個版本的 TensorFlow (或其他函式庫)？
• 什麼因素導致模型失效？
• 上次部屬了這個模型的哪一個版本？

這些問題看似無關緊要，反正產品可以用就好，何必對模型進行身家調查，但良好的機器學習系統應該要持續地產生一致的結果，而為了確保可再現性，能流暢的回答這些問題便是關鍵。
但實務上，要釐清這些機器學習生成物 (Artifact) 之間的脈絡與連結可遠比使用簡單的線性日誌來記錄還要複雜。
因此，我們必須導入被稱為資料版本控制 (Data versions control) 的概念。
而且由於資料檔案的尺寸通常比程式碼大的多，所以資料版控的工具在本質上與我們熟悉的程式碼版控 (Git) 以及環境版控 (Docker) 工具有很大的差異。
常被用來進行資料版控的工具有 DVC、 Git LFS (Large Files Storage)，以及今天我們要介紹的 ML metadata (MLMD)，它可以追蹤與回溯資料與模型在訓練過程中的改變，進一步幫助我們除錯、提昇可再現性以及遵守使用資料的相關法規，那我們就開始吧!

Data Pipeline 與旅程

從原始特徵、標籤到最終預測，資料會經過很多不同的轉換，而這一連串的操作就組合成了 Pipeline。
當我們在訓練模型時，資料就在 Pipeline 中隨著模型學習映射函數的過程轉換與改變，
釐清資料在整個產品生命週期 Pipeline 中的 "旅程" 可以幫助我們了解資料的 "血統關係 (provenance & lineage)"，也就是回答前言裡那些問題的關鍵。

因為模型本身就是訓練資料的一種表示法，所以可以將模型視為資料的轉換。

而產品化最重要的工作就是 "重現" 研發時的前處理 Pipeline，以確保演算法在作為產品時接收的輸入資料分佈與研發階段相同，其中兩個階段的工作要點如下：
POC (proof-of-concept)：

• 目標為確認這個應用可行而且值得部署。
• 著重於讓 prototype 可以運作。
• 就算前處理是手動的也 OK，只是要記得註解清楚。

Production：

• 等專案的基礎架構都建立好了之後，使用更優雅的工具來確保資料 pipeline 的再現性：
  • TensorFlow Transform
  • Apache Beam
  • Airflow...

以預測某人是否在找工作為例，可能的 Pipeline 如下圖：

其中 [資料+ML code] 代表使用該資料訓練模型，[模型+資料] 代表使用該模型對資料進行推論。

這種複雜的 Pipeline 在大型商業系統中並不少見 (通常會更複雜)，可以想見如果其中某個資料集做了改變勢必會牽一髮動全身。
為了增加這類系統的可維護性，可以試著追蹤以下兩個資訊：

• 來源 (provenance)：資料的來源，例如 Spam dataset 跟誰買的。
• 族譜 (lineage)：從源頭到 Pipeline 結尾的一系列步驟，也就是上面這張圖。

而目前的做法就是盡可能紀錄各種元資料 (Metadata)，也就是資料的資料。
以瑕疵檢測為例，可以記錄任何與 x、y 有關的資料，像是影像取得的時間、工廠、產線、相機參數，以及標注者的 ID 等。

這麼做的優點在於：

• 幫助錯誤分析，特別是找出預料之外的因素，例如模型表現變差可能來自某條產線的相機問題。
• 追蹤資料來源 (因此記錄中介模型的 ID 也是可以的)。

名詞小整理

這裡整理一下上面出現的名詞：

• Pipeline 部件執行後的結果稱為 Data artifacts，例如不同特徵工程階段產生的資料、訓練後的模型、schema、metrics…
• 與 Data artifacts 相關的資訊稱為 Metadata。
• Data provenance、lineage 則是隨著 Pipeline 運作依序出現的一系列 Artifact，也就是各項轉換之間的連結關係，因此可用來解釋模型產生的結果，進而協助除錯、了解訓練過程與比較不同次訓練之間差別。

ML metadata

MLMD 為追蹤與存取 metadata 的函式庫，它可以被整合進 ML Pipeline 中，也可以單獨使用。
使用 MLMD 時，我們必須知道資料如何在各個 Pipeline 部件之間流動，其中資料流的每一步都可以用一個實體 (entity) 來描述，這些實體又可以被視為單位 (Unit)。
而每個單位又可以使用性質 (property) 來描述額外的細節資訊，這些性質會儲存在相對應的類型 (Types) 中，以下為 MLMD 常用的術語：

• Artifact：進出 metadata store 的基礎資料單位，可以被儲存或作為 Pipeline 部件的輸入與輸出。
• Execution：紀錄任何在 ML pipeline 中執行的部件以及相對應的執行參數 (runtime parameters)。
• Context：所有 Artifact 與 Execution 都只能與一種部件連結，而每種部件的 Artifacts 與 Executions 都能分別整理在一起，這個集合就稱為 Context，例如某個專案、實驗、Pipeline 細節的 metadata。

最後，Relationships 會儲存不同 Unit 之間互動時產生或使用的 Unit，例如 Event 紀錄的就是 Artifact 與 Execution 之間的關係。
簡單來說，MLMD 紀錄各種 Pipeline 部件的相關資訊，這些資訊會被表成 metadata 物件存進後端儲存選項中：

*圖片來源：MLEP — Introduction to ML Metadata

在 MLMD 的整體架構中，最上層為 ML Pipeline 中的各種部件，它們各自與 MLMD 的集中式元資料管理 MetadataStore 連接，因此每個部件都可以在 Pipeline 的各個階段獨立存取 metadata。
MetadataStore 的核心為 Artifact (以相對應 ArtifactType 描述)，它可以作為 Pipeline 部件的輸入值，而其如何被 Pipeline 部件使用則紀錄進 Execution 中。
而 Artifact 作為某部件的輸入會被紀錄為 input Event，相對應地該部件產生新的 Artifact 作為輸出則會紀錄為 output Event。
Artifacts 與 Executions 之間的互動則藉由 Attribution 與 Association Relationships 與 Context 連結在一起。
最後，所有在 MetadataStore 產生的資料都會存進各種不同的後端儲存選項中，例如 SQLite、MySQL，而大型物件則存進 file system、block store。

*圖片來源：ML Metadata

除了追蹤資料的血緣關係以外，使用 MLMD 還有以下好處：

• 建立描述 Pipeline 中各部件執行順序與關係的 DAG，這對除錯很有用，例如驗證執行時使用了哪些輸入。
• 在進行一系列實驗後，統整屬於某類別的所有 Artifacts，例如所有訓練過的模型，如此一來便能比較不同次訓練的模型。

MLMD 實作

實作我一率推薦官方教學，這裡就不重複說明了。

以上就是今天的內容啦，今天也是機器學習產品生命週期資料部分的最後一篇，明天就要再次回朔一步，談談 Scoping 囉。

參考資料

• Coursera — Machine Learning Data Lifecycle in Production
• Coursera — Introduction to Machine Learning in Production
• Building a data pipeline
• ML Metadata: Version Control for ML
• Metadata store