機器學習項目如何管理：工作內容

前一篇文章介紹了機器學習的基本過程，然後討論了如何對機器學習項目設置期望的問題。我們了解到，度量準確率的指標可以有多種，需要根據應用場景來選擇。一旦選好了度量指標，接下來就可以圍繞這個指標來劃分任務、監控進度、管理風險。

機器學習項目涉及哪些工作

站在非常宏觀的角度，機器學習系統工作的方式是：你有一個模型，你把一堆數據輸入給它，然後你以某種方式使用它提供給你的輸出。所以機器學習項目要完成的任務也是三大塊：處理輸入；獲得模型；提供產出。

1. 處理輸入

   a. 你需要獲得已有的數據

   b. 你需要對數據做矢量化操作，把原本豐富多樣的數據變成有若干列的矢量
   c. 你需要對數據做特徵工程，找出可能蘊涵了知識、值得被學習的那些特徵項
2. 獲得模型
   a. 實際上很多時候你可以使用現成的模型，包括：（i）下載現成的離線模型，或者（ii）使用在線的人工智慧服務

   b. 如果沒有現成的模型，你也可以考慮使用現有的數據來自行訓練模型

3. 提供產出
   a. 機器學習的結果可能通過某種人-機（UI）或機-機界面（API）被用戶直接使用
   b. 作為項目的產出，機器學習模型需要被嵌入到整個數據流水線中
   c. 作為項目的產出，機器學習模型的開發、測試、部署需要有DevOps的支撐

在所有這些任務中，只有2.b「自行訓練模型」（上圖右下角標星星的部分）需要新的技能和管理方法，其他都是傳統的軟體開發任務，可以用標準的Scrum等敏捷方法拆分任務和管理。也就是說，如果你需要的人工智慧能力已經有一個現成的模型提供，那麼整個項目就是一個傳統的軟體開發項目，只是需要使用一些新的工具或API而已。

下面我們聚焦討論需要自行訓練模型時，這部分工作應該如何拆分、如何管理進度和風險。

自行訓練模型的流程

在自行訓練模型的情況下，如上圖所示，你會用歷史數據（X和Y）來訓練一個模型，然後用這個模型對未來的生產數據（X-hat）做預測（算出Y-hat）。不論採用什麼指標來度量準確率，模型在訓練數據上的表現一定好於在生產數據上的表現，這是因為模型從訓練數據中「學到」的知識不一定在生產數據中完全重現，或者用黑話來說，模型在訓練過程中「擬合」了訓練數據的特徵。也就是說，如果一個模型對訓練數據表現出了95%的準確率（先不管採用哪個準確率指標），其實你並不知道這個模型對生產數據會表現什麼水平的準確率，於是你也不知道這個模型是否好到可以上線運行。

為了更有效地衡量模型的表現，我們會在開始訓練模型之前先拿出一小部分歷史數據（例如全部歷史數據的10%）用於測試，整個訓練過程不接觸這部分數據。於是我們就有了「訓練集」（training set）和「測試集」（test set）。很多時候我們還會分出一小部分數據作為「驗證集」（validation set），為了簡化問題，我們可以先採用「訓練集+測試集」這種設置。

把歷史數據分成訓練集和測試集以後，可以預期，模型在訓練集上的表現會優於在測試集上的表現，這兩個表現通常都會低於項目期望值。我們把「【模型在訓練集上的表現】與【期望值】之間的差距」叫做Bias，把「【模型在訓練集上的表現】與【模型在測試集上的表現】之間的差距」叫做Variance。

於是就有3種可能的情況：

1. High Bias：模型在訓練集上的表現遠低於期望，模型還不能實用（此時Variance如何並不重要）；
2. Low Bias, High Variance：模型在訓練集上表現好，但是在測試集上表現差，模型還不能實用；
3. Low Bias, Low Variance：模型在訓練集和測試集上表現都好，可以投入實用。

我們通常會從簡單的機器學習演算法、手邊立即能獲得的數據開始嘗試。這時候通常Bias會高，因為過於簡單的模型不足以呈現數據背後的知識，這時我們說模型「擬合不足」（Under-fitting）。在這種情況下，可以採用的措施包括：

• 使用更複雜的機器學習演算法
• 使用更複雜的神經網路架構

用更複雜的機器學習演算法和神經網路訓練出來的模型，通常能更好地擬合訓練集，進入「Low Bias」的狀態。這時我們再關注模型在測試集上的表現，如果測試集的表現遠差於訓練集的表現，就說明模型過度地針對訓練集的特徵做了優化，我們說模型「過度擬合」（Over-fitting）訓練數據。在這種情況下可以採用的措施包括：

• 引入Regularization通常能降低over-fitting的程度
• 通過特徵工程可以避免一些over-fitting的情況，例如排除掉一些嚴重過度擬合的特徵
• 引入更多的訓練數據，包括數據量和特徵量

最終我們的目標是得到Bias和Variance雙低的模型。

潛在風險點

從上述的工作流程中，我們可以預先識別一些潛在的風險：

• 在Under-fitting的狀態下，如果人員能力不足，就無法應用更複雜的演算法
• 在Under-fitting的狀態下，如果計算資源不足，就無法訓練更複雜的模型
• 在Over-fitting的狀態下，如果數據質量不足，就無法開展有效的特徵工程
• 在Over-fitting的狀態下，如果數據數量不足，就無法訓練高效的模型
• 如果整個項目涉及的數據基礎設施不足，就無法快速迭代實驗

於是，訓練一個機器學習模型就不再是一個神秘的、盲目的、隨機的過程。藉助Bias、Variance、迭代實驗的頻率等量化數據，IT管理者和不懂技術的業務代表能更清晰地看到項目的進展，整個團隊能更好地判斷接下來需要做什麼：是需要嘗試更高級的神經網路呢？還是需要想辦法獲得更多的數據？或者是需要更多的計算資源？還是需要尋找某些特定的知識和技能？這樣就避免了業務代表懷有不切實際的期望、又不知道技術團隊在做什麼而感到恐慌。

在下一篇文章里，我會更加具體地介紹，如何借鑒Scrum和看板等敏捷方法的思路，把訓練一個機器學習模型的工作拆分成更小粒度、更易於管理的任務，以及如何對機器學習項目進行可視化管理。

（本文作者熊節是ThoughtWorks的總監諮詢師）

? 作者保留一切權利，未經許可請勿轉載