隨著機器學習（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從業者可能會有創造性的解決方案新增到您要嘗試的事物列表中。
• 好的實現技能很重要，編碼規範可以防止錯誤。
• 如果實驗花費的時間太長，請考慮花一些時間尋找程式碼的優化，或者與系統專家討論如何加快訓練速度。

與其他決策一樣，只有在解決當前的痛點時才能處理這些專案。有些團隊花費太多時間構建“完美”框架，卻發現真正令人頭疼的事情在其他地方。

結論

機器學習專案具有內在的不確定性，上面推薦的方法旨在為開發者提供一些指導。雖然每次實驗的結果無法預測，很難讓自己對達到特定的準確度目標負責，但至少可以讓自己負責完成錯誤分析、制定想法列表、編寫程式碼並檢視其工作原理。

原文連結 本文為雲棲社群原創內容，未經允許不得轉載。