如何交付機器學習項目：一份機器學習工程開發流程指南

摘要： 本文描述機器學習任務的「OODA環」的概念，迭代地執行四個過程：分析、選擇方法、實現、測量步驟，循環此過程以提高開發效率。

隨着機器學習（ML）成爲每一個行業的重要組成部分，對機器學習工程師（MLE）的需求急劇增加。MLE須要將機器學習技能與軟件工程專業知識相結合，爲特定應用程序找到高性能的模型，並應對出現的實施挑戰——從構建訓練基礎架構到準備部署模型。在新的機器學習團隊中，遇到最多見的障礙之一是工程師習慣傳統軟件工程的開發過程，而開發新ML模型的過程從一開始就是很是不肯定的，須要不斷的嘗試才能找到一個比較合適的模型。

許多類型的專業人員都面臨着相似的狀況：軟件和商業開發人員，尋求產品市場契合的初創公司等，這些職業中的每個都採用了一個共同的框架，以幫助團隊高效地工做：軟件開發中的agile/scrum，初創公司和美國空軍的OODA環。MLE一樣能夠遵循相似的框架來應對不肯定性並快速開發出優質的產品。

ML工程環

在本文中，咱們將描述ML的「OODA環」的概念：ML工程循環，其中ML工程師迭代地

• 1.分析
• 2.選擇一種方法
• 3.實現
• 4.測量

快速有效地發現最佳模型並適應未知的環境。此外，咱們將爲每一個階段，以及優化過程給出具體的提示。

MLE環

ML團隊的成功一般意味着在給定的約束條件下提供高性能模型。例如，實現高預測準確性的模型，同時還受到內存使用、預測時間等約束。性能由與最終產品成功最相關的指標定義，不管是準確性、運行速度、輸出多樣性等。簡單起見，本文選擇將「錯誤率」最小化做爲性能指標。

當剛開始肯定新項目的範圍時，就應該準肯定義成功的標準，而後將其轉換爲模型指標。在產品方面，服務須要達到什麼樣的性能水平？例如，若是在新聞平臺上向我的用戶推薦5篇文章，咱們須要多少相關內容，以及如何定義相關性？鑑於此性能標準和擁有的數據，能夠構建的最簡單的模型是什麼？

ML工程環的目的是圍繞開發過程設置一個死記硬背的框架，簡化決策過程，專一於其中最重要的步驟。當不肯定性增長時，即便是最有經驗的工程師，這個框架仍然是很是有價值，例如，當模型意外地沒法知足要求時、團隊的目標忽然改變等狀況。

入門

要引導下面描述的循環，您應該從一個涉及很是少的不肯定性的最小實現開始。一般咱們但願儘快創建足夠的系統，以便咱們能夠評估其性能並開始迭代開發。這一般意味着：
設置訓練、開發和測試數據集，以及構建好一個簡單的模型。

例如，若是要構建一個樹木探測器來測量一個地區的樹木種羣，可能會使用相似的Kaggle 競賽中的現成訓練集，以及來自目標區域的手工收集的一組照片用於開發和測試集。而後能夠對原始像素進行邏輯迴歸，或者在訓練圖像上運行預訓練網絡（如ResNet）。此時的目標不是一次性地完成項目，而是開始迭代週期。如下是一些有所幫助的提示：

提示

關於測試集：

• 因爲團隊的目標是在測試集上表現良好，因此測試集應該反映產品或業務的需求。例如，若是正在構建一個應用程序來檢測自拍的皮膚情況，請隨意對任何一組圖像進行訓練，但要確保測試集中包含光線不足且質量差的圖片。
• 更改測試集會改變團隊的目標，所以儘早修復測試集並對其進行修改以反映項目、產品或業務目標的變化會頗有幫助。
• 測試集合訓練集大小都設置足夠大，以使得到的性能指標足夠準確，以便在模型之間作出良好區分。
• 儘量地爲開發集和測試集建立對的標籤或註釋。錯誤標記的測試集等同於錯誤指定的產品要求。
• 瞭解人類在測試集上的表現如何，或者現有/競爭系統的表現如何，這將爲你提供最佳的錯誤率，即目前能夠實現的最佳性能。
• 最終目標是使測試性能儘量接近咱們的猜想，以得到最佳性能。

關於開發和訓練集：

• 開發集是團隊的測試性能代理，可用於超參數的調整。所以，它應該與測試集有相同的分佈。一個好方法是首先收集一大堆樣本，而後將它們隨機分紅開發集和測試集。
• 若是認爲生產數據會產生噪音，請確保經過使用數據加強或降級來解決訓練集中的噪音問題。

一旦得到初始原型後，應檢查其在訓練、開發和測試集上的性能，評估測試性能與產品所需性能之間的差距。開始迭代開發模型了！

分析

肯定性能瓶頸

分析階段就像醫療診斷同樣：配備了一套能夠執行的診斷程序，目標是針對限制模型性能的因素提出最可能的診斷。在實踐中，可能會有許多不一樣的重疊問題致使當前的結果。不要試圖全面瞭解每個缺點，而是要了解最重要的因素，由於許多小問題會隨着模型改進而改變甚至消失。

下面，咱們列出了一組經常使用的診斷流程。

每次分析的一個良好起點是查看訓練、開發和測試性能。建議在每次實驗結束時使用代碼執行此操做，以使本身習慣於每次查看這些數字。通常而言，訓練集錯誤<=開發集錯誤<=測試集錯誤（若是每組中的數據遵循相同的分佈）。根據上一次實驗的訓練、開發和測試錯誤率，能夠快速查看這些因素中的哪些是當前的約束約束。

權重直方圖

診斷和治療

若是訓練集錯誤是當前的限制因素，則可能會出現如下問題：

1.優化算法未被精確調整。查看學習曲線，看看loss損失是否在減小，檢查是否過擬合。能夠經過可視化神經元反應的直方圖，以檢查它們是否飽和（致使梯度消失）。
2.訓練集可能包含錯誤標記或損壞的數據。在訓練算法使用以前，在代碼階段手動檢查一些訓練樣例。
3.模型可能過小或泛化能力不強。

若是開發集錯誤是當前限制因素，這多是由如下問題引發的：

1.模型可能太大或過擬合。
2.沒有足夠的訓練數據來學習基礎模式的良好模型。
3.訓練數據的分佈與開發或測試數據分佈不匹配。
4.模型的超參數設置不好。
5.模型概括與數據匹配不佳。

若是測試集錯誤是當前限制因素，這一般是因爲開發集過小或者實驗過程當中過分擬合開發集致使。
對於上述任何一種狀況，能夠經過手動檢查模型出錯的一組隨機示例來了解模型的失敗。

1.嘗試經過可視化數據來識別常見的錯誤類型，而後瀏覽這些示例並記錄每種錯誤發生的頻率。
2.某些樣本可能被錯誤標記或具備多個合理標籤。
3.一些樣本可能比其餘樣本更難預測，或者可能缺乏作出正確決策所需的上下文。

請注意，上述許多診斷都有直接而明顯的應對方法。例如，若是訓練數據太少，那麼只需獲取更多訓練數據便可！咱們仍然發如今心理上將分析階段和選擇階段分開是有用的，由於不少人容易陷入嘗試隨機方法而不真正深刻挖掘潛在的問題。此外，以開放的心態努力迴歸錯誤分析一般會發現更有用的看法，能夠改善作出的決定。

例子

衆所周知，衛星數據噪聲很大，一般須要檢查。以Insight爲例，當AI研究員Jack Kwok正在創建一個幫助災難恢復的分割系統時，他注意到雖然他的分割模型在他的衛星圖像訓練集上表現良好，但它在開發集上表現不佳。緣由是颶風圖像質量較低且比訓練數據更模糊。向訓練管道添加額外的加強操做，對圖像應用模糊有助於縮小訓練和開發性能之間的差距。

選擇方法

找到解決瓶頸的最簡單方法

在進行分析以後，須要很好地瞭解模型所出現的錯誤類型以及影響性能的因素。對於給定的診斷，可能存在幾種可能的解決方案，下一步是枚舉並優化它們。

上面的一些診斷有着潛在的解決方案。例如，若是訓練數據集過小，收集更多訓練數據多是一個至關快速和簡單的解決方案。

建議ML工程師列舉儘量多的想法，而後偏向簡單、快速的解決方案。若是現有解決方案可能有效，請嘗試在此基礎之上使用遷移學習。

提示

根據診斷，如下是一些常見的解決方案。

若是須要調整優化器以更好地適應數據：

• 對於數值優化器，嘗試調整學習速率或動量設置。
• 嘗試不一樣的初始化策略，或從預先訓練的模型開始。
• 嘗試一種更容易調整的模型。在深度學習中，具備批量歸一化的剩餘網絡或網絡可能更容易訓練。

若是模型沒法很好地擬合訓練數據：

• 使用更大或更具表現力的模型類。
• 檢查模型在標記錯誤、缺乏字段等的訓練集上出錯的示例。在訓練數據清理中投入時間能夠顯著改善性能。

若是模型沒有在開發集表現很差：

• 添加更多訓練數據。
• 使用真實訓練示例生成的新樣本擴充數據。例如，若是注意樹檢測器在模糊圖像上始終表現不佳，請使用OpenCV對圖像加強，使圖像看起來有點模糊。
• 搜索更普遍或更細粒度的超參數範圍，以確保在開發集上找到表現最佳的模型。
• 嘗試不一樣形式的正則化（例如權重衰減、dropout或決策樹的修剪）。
• 嘗試不一樣的模型，不一樣類型的模型能夠改變數據擬合程度以及泛化能力。最好先從最簡單的模型開始。

實現

只構建須要構建的內容，並快速完成

這個階段的目標是快速實現基礎模型，以即可以測量出結果，並從中學習，以後快速回到開發循環週期中。所以，建議專一於構建當前實驗所需的內容。

提示

大多數人高估了收集和標記數據所帶來的成本，並低估了在數據匱乏的環境中解決問題的困難。

當收集和標記數據時：

• 按期查看數據。查看原始數據，在預處理後查看、查看標籤。這一點很是重要！經過在每一個步驟中密切關注數據來捕獲許多錯誤。
• 標籤和清洗數據是一項常見任務。大多數人高估了收集和標記數據所帶來的成本，並低估了在數據匱乏的環境中解決問題的困難。一旦進入節奏，能夠輕鬆地每分鐘標記20張圖像。思考下，你是想花一個小時標記圖像，並花一個小時來解決1200個圖像數據集的簡單分類問題，或者花3個星期試圖從5個樣本中學習模型呢？

當構造新的模型時，請從相似的現有實現開始。許多類似的研究論文都開源代碼，這將節省大量的開發時間。對於任何問題，建議連續執行如下步驟：

1.找到解決相似問題的模型的實現。
2.在現有模型（相同數據集和超參數）的條件下重現實驗。
3.慢慢調整模型和數據以知足任務的需求。
4.重寫所需的任何部件。

編寫測試程序以檢查梯度、張量值、輸入數據和標籤是否格式正確。在最初設置模型時執行此操做，這樣一旦捕獲錯誤並解決後，以後不再會遇到了。

測量

打印出須要的測試結果和任何其餘指標。

若是實驗結果的表現有所改善，這可能說明你正走上正軌。在這種狀況下，多是弄清楚運行良好組件的好時機，並確保團隊中的其餘人能夠復現該實驗。

另外一方面，若是性能變差或沒有足夠的改善，你須要決定是再次嘗試（回到分析階段）仍是放棄當前的想法。這點取決於兩者的成本，嘗試成本和沉沒成本。

提示

• 有用的績效指標包括模型的準確性和損失，以及業務價值指標。注意，業務相關的指標最終是重要的，由於它們決定了目前開發的模型的有用性。若是測試指標與業務指標不一樣，則此測量週期結束是中止並考慮更改優化標準或測試集的好時機。
• 因爲在每一個開發循環結束時都打印出相關的指標，此時也是計算其餘指標的時機，能夠在分析階段幫助你看決定是否繼續使用當前的想法。
• 最終會創建一個「儀表板」，其中包含測試指標和業務指標，以及每次實驗結束時能夠看到的其餘有用數據。

優化循環

儘管任務固有的不肯定性，上面的ML工程環將幫助開發者朝着更好的模型方向前進。遺憾的是，它沒法保證馬上開發出正確的模型，還須要咱們須要培養本身在每一個階段作出正確選擇的能力，好比肯定性能瓶頸、決定嘗試哪些解決方案、如何正確實現，以及如何衡量應用程序的性能。此外，還應該花時間考慮提升迭代的質量和速度，以便在每一個週期中取得最大進展，而且能夠快速完成屢次迭代。

提示

• 若是在分析階段的結果並不滿意的話，請建立一個總結實驗結果的腳本，從訓練和開發集中收集錯誤，並對其進行格式化。「儀表板」常用的診斷輸出能幫助你克服這一時刻的思惟。
• 若是以爲本身想要嘗試什麼，那就只選擇一個方向對其進行實驗。試圖一次作太多事情會減慢速度。
• 收集數據是得到更好性能的經常使用方法，投資工具以使數據更易於收集、清理和標記是有意義的。
• 若是感受困在診斷瓶頸或不知道如何選擇一個好的模型來嘗試下一步時，請考慮聯繫該領域的專家。專家一般能夠在錯誤分析期間提供有用的看法，而研究論文或經驗豐富的ML從業者可能會有創造性的解決方案添加到您要嘗試的事物列表中。
• 好的實現技能很重要，編碼規範能夠防止錯誤。
• 若是實驗花費的時間太長，請考慮花一些時間尋找代碼的優化，或者與系統專家討論如何加快訓練速度。

與其餘決策同樣，只有在解決當前的痛點時才能處理這些項目。有些團隊花費太多時間構建「完美」框架，卻發現真正使人頭疼的事情在其餘地方。

結論

機器學習項目具備內在的不肯定性，上面推薦的方法旨在爲開發者提供一些指導。雖然每次實驗的結果沒法預測，很難讓本身對達到特定的準確度目標負責，但至少可讓本身負責完成錯誤分析、制定想法列表、編寫代碼並查看其工做原理。

本文做者：【方向】

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。