在終於訓練出一個表現十分良好，又符合商業目標的模型之後，接下來就要將模型部署上線啦！這是一個關鍵環節，讓你的模型不只停留在個人電腦中，也可以鑲嵌在產品中，為提供消費者這項功能。

ML 專案生命週期中的兩大挑戰

模型部署需要考慮到許多實際問題，開發者通常會面臨兩類主要挑戰：

資料漂移（data drift）和概念漂移（concept drift）

在實際上線的產品環境中，模型的表現可能會因為資料漂移（data drift）和概念漂移（concept drift）而受影響，不一定會像在訓練階段那樣理想。

圖片來源：https://www.evidentlyai.com/ml-in-production/data-drift

資料漂移（Data Drift）

• 定義：資料漂移指的是模型的輸入特徵可能會隨著時間而變化，這種變化可能導致模型性能下降，因為模型是基於舊的資料分佈進行訓練的。如上圖所示，online 和 offline channel 的比率發生變化，代表模型輸入特徵的分布改變了。

• 舉例

  • 房地產價格預測模型：原本的訓練資料中的房屋特徵分佈隨著時間發生變化，由於房屋越蓋越大，新的資料中房屋面積普遍變得更大，導致模型的預測失準。
  • 社交媒體的情感分析模型：隨著新詞彙、表情符號和網路用語的出現，原本用來建立模型的數據和現有文本已經不同，這種語言使用演變就是資料漂移的一個例子。

• 檢測和處理：為了避免這個狀況，我們需要定期監控輸入數據的統計特性，或是定期重新訓練模型以適應新的數據分佈。

概念漂移（Concept Drift）

• 定義：概念漂移指的是輸入特徵（X）與目標類別（Y）之間的映射關係發生變化，這種變化可能導致模型的預測規則不再有效，即使輸入數據的分佈保持不變。如上圖所示，儘管 online 和 offline channel 的比率不變，但是 offline channel 的平均銷售量隨著時間而下降。

• 舉例

  • 音樂推薦系統：用戶的喜好可能隨時間而改變，例如，用戶的音樂品味隨年齡增長而變化，即使用戶的人口統計學特徵（輸入）沒有變化，但這些特徵與音樂喜好（輸出）的關係發生了變化。
  • 以新冠疫情為例，疫情前後消費者的網購行為發生了巨大變化，這會影響基於過去消費行為建立的模型。

• 檢測和處理：為了處理這個問題，我們需要持續監控模型性能，也可以使用滑動窗口（sliding window）或加權樣本來強調最近數據。另外，也需要定期重新評估和更新特徵工程。

軟體問題

如何將模型整合到實際系統中並保持穩定運行是另一個挑戰，需要解決系統架構和運營問題，例如運算資源的分配、性能要求和營運監控等。

設計預測系統時的考量

在部署模型時，需要仔細考量以下幾點：

• 即時（Real-time）還是批次（Batch）預測？：這取決於程式是否需要即時反應，或是可以在資料累積後進行一起批量處理。
• 雲端（Cloud）還是邊緣設備（Edge）？：根據計算資源、延遲需求或是隱私考量來決定是否在雲端進行預測，還是在邊緣設備上進行。若是要在用戶設備上直接運行模型，需要考慮不同設備的計算能力和內存限制，以及如何設計機制來更新模型。
• 計算資源的分配：模型運行需要的計算資源，如 CPU、GPU 或內存等，這會影響程式效能和成本。
• 延遲與吞吐量（Latency and Throughput）：模型每秒能夠處理多少請求？這會直接影響到用戶體驗。

常見的部署模式

在部署模型時，通常不會直接將新模型取代舊有模型，而是需要一段觀察測試期，或是同時運行兩個版本，方便切換。以下是幾個常見的部署方式：

影子模式（Shadow Mode）

在這種模式下，系統並不使用新模型的預測結果，而是觀察其表現，讓人類對模型的預測進行檢驗和評估。

金絲雀部署（Canary Deployment）

當準備好切換至新系統時，先將一小部分流量（如 5%）導入新系統，並持續監控其表現，隨著系統的穩定性增加，逐步提升流量。

藍綠部署（Blue/Green Deployment）

Blue 代表舊版本，Green 代表新版本。這種方式允許兩個版本同時運行，並且可以在需要時立即切換至新版本，而當出現問題時，能夠快速退回至舊版本。

經過今天的內容後，我們終於將模型部署上線，呈現在用戶面前啦！但是，別以為你的工作就此結束哦，我們還是要持續觀察模型跟資料的狀況，才是一個負責任的好資料科學家！明天讓我們來看看要如何持續監控系統的表現吧！

謝謝讀到最後的你，如果喜歡這系列，別忘了按下喜歡和訂閱，才不會錯過最新更新。
如果有任何問題想跟我聊聊，或是想看我分享的其他內容，也歡迎到我的 Instagram（@data.scientist.min） 逛逛！
我們明天見！