今日份 Ferris

當模型成為服務時是最讓人興奮的，就像是親手建造的火箭要升空了！

部署模型與產品化

從 [Day 21] - 機器學習系統設計 🏭 x Rust 🦀 開始，我們討論了開發機器學習模型所需考慮的各項因素，從建立訓練集、特徵工程到如何評估模型。
這些因素構成了 ML 應用程式的邏輯，指引我們一步一步將原始資料變成可用於產品環境的模型：

*圖片修改自 Designing Machine Learning Systems Figure 7-1.
要開發出上述的邏輯需要機器學習專家與領域專家通力合作，在許多公司中，這些人組成了資料科學團隊。

而今天，我們要來討論 ML 產品生命週期中最後一個迭代的部分 — 部署模型：

*圖片修改自 Introduction to Machine Learning in Production

「部署」是很廣義的說法，一般來說都是指讓模型跑起來並且可被存取，而這意味著模型要離開開發環境，進入到測試或產品環境中，今天我們就要介紹模型在這些環境的一些需求。

而所謂的「產品化」也是非常廣義的說法，對某些團隊來說，產品化只代表著在 notebook 中畫出漂亮的圖表給商業團隊參考就好，這使得產品環境與開發環境很接近，並不需要做任何特殊的處理。
但對另一些團隊來說，產品化指的則是讓模型每天都為數百萬用戶提供服務，那麼就需要參考今天所介紹的一些內容了。

事實上，撇除困難的部分，部署是非常容易的 (把大象裝進冰箱也只需要三個步驟！)，如果只是想部署模型來玩一下，我們只需要用 FastAPI 把預測用的函式包裝在 POST 端點中，然後把運行預測函式所需要的一切包裝進容器，再把模型和容器放上 AWS 或 GCP 等雲服務來公開端點即可！
這很簡單，有興趣的孩子可以參考 [Day 07] 使用 fastAPI 部署 YOLOv4 (1/2) — 以內建 Client 進行互動。

而困難的部分其實也不算太多，大概就是以毫秒等級的延遲跟 99% 的保證運行時間向數百萬個用戶提供模型、建立基礎設施、在出現問題時馬上找到正確的人來處理，以及無縫部署更新而已 ☺️

在很多公司中，部署的責任會落在開發模型的人手上，也就是資料科學家，但現在也越來越多公司開出了 MLOps 工程師的職缺，而如果那個人剛好是你，不要害怕！
只需要謹記部署機器學習模型之前，重要的是要制定一個計劃，以確保模型能夠滿足其預期的用途，並且能夠以可擴展和可靠的方式運行。
接下來就來介紹一些常需要做的決策吧！

在線預測 vs. 批次預測

在部署模型作為預測服務時，第一個會遇到的問題就是該用在線預測還是批次預測：

• 線上預測 (Online)：預測會在收到請求後立即生成和返回。
• 批次預測 (Batch)：預測會定期生成或在觸發時生成。

顧名思義，在線預測適用於需要馬上得到結果的情況，但會遇到的挑戰就是模型產生預測的時間可能會太久，使得用戶等到不耐煩。
但如果不需要立即獲得結果且需要大量預測時，就可以考慮使用批次預測，此時會遇到的挑戰為它會降低模型對用戶偏好變化的反應力，並且我們也需要提前知道要為哪些請求生成預測。

模型壓縮

將模型壓縮是減少預測所需時間的好方法，以下為幾種常見的作法：

• Low-Rank Factorization - 使用更低維度的張量替換高維度的張量。
  舉例來說，MobileNet 將大小為 k x k x c 的標準卷積分解為深度卷積 k x k x 1 和逐點卷積 1 x 1 x c：
  
• 知識蒸餾 (Knowledge Distillation) - 訓練小型模型模仿大型模型或集成模型的方法。
• 剪枝 (Pruning) - 本來的做法是去除整個節點，這雖然可以減少參數量，但也會使得模型架構改變。
  因此另一種更常見的方法是把找到對預測最不重要的參數並將其設置為零。
• 量化 (Quantization) - 最通用也是最常用的方法，將模型參數改用更小 bit 的數值型別以減少模型大小。
  舉例來說，我們可以用一個完全由整數組成的模型來代替使用浮點數的模型，而每個整數就可以只使用 8 bits。

運行裝置

另一個要考慮的是在雲端還是邊緣運行機器學習模型。
使用託管雲端服務部署模型是最簡單的，但是，它的成本很高。
而邊緣設備則允許我們的應用程序在雲計算無法運行的地方運行，也可以減少對網絡延遲的憂慮，邊緣計算還可以更輕鬆地遵守法規。
因此越來越多公司將模型由雲服務遷移到自己搭建的運算裝置上！
另外，在 [Day 09] - 從 Python 🐍 到 Rust 🦀｜MLOps 最終比較 ⚔️ 與環境永續 🍀 提到的 WebAssembly 也是目前非常受歡迎的方法，像是 Anaconda 就推出了 PyScript，讓 Python 程式碼也能在瀏覽器執行

持續監控

由於世界不斷在改變，而這對模型最直接的影響就是資料改變，因此我們必須持續地監控輸入資料與模型表現才能確保模型可以正常的運作。
在產品環境中的資料主要有兩種類型的改變：

• Drift — 資料隨著時間的自然改變，這來自於世界的變化，無可避免，依據改變的本質可細分為以下兩類：

  • Data drift — 訓練與服務之間的時間差導致的資料改變，也就是特徵的統計性質改變。
  • Concept drift — 世界改變使得 Ground Truth 改變，也就是標籤的統計性質改變。

• Skew — 概念上是同一個資料集，但在不同版本或來源間存在差異，例如訓練集與產品化後實際接收的資料。
  
  *圖片修改自 MLEP — Detecting Data Issues

  這種類型的改變又可細分為以下兩類：

  • Schema skew — 訓練集與產品化後實際接收資料的 Schema 不相符，例如預期浮點數但實際資料卻是整數。
  • Distribution skew — 訓練集無法反應產品化後實際接收資料，學術一點的說法就是特徵與標籤的聯合機率在訓練與服務時不同，請參考下圖：
    
    *圖片修改自 MLEP — Detecting Data Issues
    
    而這種變化可能會以 Covariate、Concept 等形式顯現：
    • Covariate shift：輸入變數的分佈在訓練於服務時不同，也就是說，特徵 (x) 的邊際分佈不同，但條件分佈不變 (x → y 映射不變)。
      
    • Concept shift：輸入與輸出變數的關係改變，但輸入變數的分佈不變。
      

持續學習

而要讓模型適應上述資料分佈的變化，就得持續更新我們的機器學習模型。
持續學習在很大程度上是一個基礎設施問題，必須有很成熟的基礎設施才能供我們有效率的持續訓練與維護模型。

*圖片修改自 Designing Machine Learning Systems Figure 9-2.

大多數公司會進行無狀態重新訓練，也就是模型每次都是從頭開始訓練。
但持續學習允許有狀態訓練，也就是模型繼續對新數據進行訓練，這讓我們可以使用更少的資料來更新模型。
而我們的基礎設施也應該設置為允許無狀態重新訓練和有狀態訓練。

除了基礎設施的問題，持續學習還會面臨以下三個挑戰：

• 獲取新鮮資料的挑戰：
  從資料倉儲中提取新的訓練資料可能很慢，因此最好直接從像 Kafka 這樣的實時串流中提取資料。
• 評估挑戰：
  確保持續學習時更新的模型表現達到部署的資格。
  但模型的更新越頻繁，出現問題的機會就越多，且持續學習也使您的模型容易受到來自人類的惡意攻擊 (Adversarial Attack)。
  
  因此在每次模型更新時進行測試對確保性能與安全性至關重要。
• 演算法挑戰：
  神經網絡等模型比基於 metric 和 tree 的模型更容易適應持續學習。
  例如，協同過濾 (Collaborative Filtering) 模型需要使用整個資料集來建立用戶的 item metrics。

而依照重新訓練的模式，可將持續學習分為四個階段：

1. 手動無狀態重新訓練
2. 自動化重新訓練
3. 自動化有狀態訓練
4. 持續訓練

部署模式

最後，有幾種部署模式可以幫助我們在產品環境中測試模型的可行性，這裡直接引用前一個系列文 [Day 05] 部署模式 — 我的模型叫崔弟 中提到的三種模式：

• 影子模式 (Shadow mode)：
  人力與機器學習系統同時作業，但機器學習系統的輸出在此階段不作為決策依據。
  主要目的為收集更多可提昇模型表現的資料，與比對預測是否準確。
  影子模式適合用在已有準確系統 (人工或 ML) 的情況，它能幫助我們有效率地驗證新系統是否足以作為決策依據。

• 金絲雀模式 (Canary deployment)：
  最初使用極少部份的流量 (例如 5% 或更少) 啟動系統進行決策，再慢慢增加流量並監測其表現。
  就跟採礦時的金絲雀一樣，此模式能提早預警可能出現的錯誤，讓我們可以滾動式提昇對決策的信心，將預測出錯的影響降至最低。

• 藍綠模式 (Blue green deployment)：
  讓 Router 將原本送至舊系統 (藍) 的流量一次性的全部導引到新系統 (綠)，此模式的優點在於回溯很方便，如果覺得把流量一次全部轉向很可怕也可以先從部份流量開始。
  

• 多臂吃角子老虎機演算法 (Bandit)：
  這是一種允許我們在 exploitation (選擇過去收益最高的老虎機) 和 exploration (選擇可能收益更高的其他老虎機) 之間取得平衡的演算法。
  過去在產品環境中測試模型的標準方法是 A/B 測試。
  在 A/B 測試中，我們會將流量隨機分配給每個模型以進行預測，試驗結束時衡量哪個模型表現更好。
  因此 A/B 測試是無狀態的，但多臂吃角子老虎機演算法是有狀態的，且已被證明比 A/B 測試更有效率，只是會比 A/B 測試更難施行。
  詳細請參考 何謂多臂吃角子老虎機測試（Multi-Armed Bandit Testing）？

好啦，今天討論了很多與將模型產品化相關的內容，事實上，這也是我們在執行 鋼鐵草泥馬 🦙 LLM chatbot 🤖 專案時的考量，所以明天要讓它再次返場。
要來填坑部署它囉～