您已準備好部署可預測獨角獸外觀的獨角獸模型！在部署時，機器學習 (ML) 管道應能順利執行、更新及提供服務。如果部署模型的操作方式，就像按下大型「Deploy」按鈕一樣簡單就好了。很抱歉，完整的機器學習系統需要進行以下測試：
- 驗證輸入資料。
- 驗證特徵工程。
- 驗證新模型版本的品質。
- 驗證放送基礎架構。
- 測試管道元件之間的整合。
許多軟體工程師都偏好採用測試驅動開發 (TDD) 做法。在 TDD 中，軟體工程師會先編寫測試，再編寫「實際」的來源程式碼。不過，在機器學習中實施 TDD 可能會有些棘手。舉例來說，在訓練模型前，您無法編寫測試來驗證損失函式。相反地，您必須先在模型開發期間找出可達成的損失，然後再針對可達成的損失測試新模型版本。
關於獨角獸模型
本節將說明獨角獸模型。以下是一些注意事項：
您使用機器學習建立分類模型，用於預測獨角獸的出現情形。您的資料集詳細列出 10,000 次獨角獸出現和 10,000 次獨角獸未出現的資料。資料集包含位置、時段、高度、溫度、濕度、樹冠覆蓋率、彩虹是否出現等多項要素。
使用可重現的訓練方式測試模型更新
或許您想繼續改善獨角獸模型。舉例來說，假設您對某個特徵進行額外的特徵工程，然後重新訓練模型，希望能獲得更好 (或至少相同) 的結果。不過，有時很難重現模型訓練。如要提高重現性，請遵循下列建議：
為隨機號碼產生器設定決定性的種子。詳情請參閱「資料產生過程中的隨機化」
請按照固定順序初始化模型元件，確保元件每次執行時都能從隨機號碼產生器取得相同的隨機號碼。機器學習程式庫通常會自動處理這項需求。
計算多次執行模型的平均值。
請使用版本控制 (即使是初步的迭代作業)，這樣您就能在調查模型或管道時找出程式碼和參數。
即使您遵循這些規範，仍可能會出現其他非決定性來源。
測試對機器學習 API 的呼叫
您如何測試 API 呼叫的更新內容？您可以重新訓練模型，但這需要花費大量時間。請改為編寫單元測試，產生隨機輸入資料並執行單步梯度下降。如果這個步驟完成後沒有任何錯誤，表示 API 的任何更新都不會破壞模型。
為管道元件編寫整合測試
在 ML 管道中，某個元件的變更可能會導致其他元件發生錯誤。編寫整合測試，以端對端方式執行整個管道，檢查元件是否能相互運作。
除了持續執行整合測試外，您也應在推送新模型和新軟體版本時執行整合測試。由於整個管道的執行速度緩慢，因此會使持續整合測試更加困難。如要加快整合測試的速度，請使用部分資料或較簡單的模型進行訓練。詳細資料取決於模型和資料。為了持續涵蓋測試，您可以調整快速測試，讓這些測試能夠在每個新版本的模型或軟體中執行。同時，慢速測試會持續在背景執行。
在提供模型前驗證模型品質
將新模型版本推送至實際工作環境前，請測試以下兩種品質降級情形：
突然降級。新版本中的錯誤可能會導致品質大幅下降。將新版本的品質與先前版本進行比較，驗證新版本。
緩慢降解。針對突然惡化的情況進行測試時，可能無法偵測到多個版本的模型品質緩慢惡化情形。請改為確保模型在驗證資料集上的預測結果符合固定閾值。如果驗證資料集與即時資料有所出入，請更新驗證資料集，並確保模型仍符合相同的品質門檻。
在提供服務前驗證模型與基礎架構的相容性
如果模型的更新速度比伺服器快，則模型可能會與伺服器有不同的軟體依附元件，可能會導致不相容。在沙箱版伺服器中建置模型，確保模型使用的作業會在伺服器中執行。