“為什麼87% 的資料科學專案沒辦法產品化？”在Transform 2019 of VentureBeat[1] 的一篇報導給予了這樣的宣告。這並不是一個小數字，這樣的數字來自於(1)團隊在執行的時候沒有正確的視野與方向(2)資料來自不同的格式、結構化和非結構化的資料。結構化的資料像是我們一般所熟悉的database裡面所儲存的資料。非結構化的資料如影音、文本和圖像可能保存在不同的地方，電腦用不同的方式理解這這些資料，並且這些資料具有不同的安全和隱私要求(3)系統需要大量的團隊合作，彼此對彼此要做的事情若是不熟悉，就要花去許多時間溝通。如何讓自己所在的團隊不要成為那些87％的專案，我們接下來就來看，透過技術可以怎麼切入。

技術

MLOPs落地的三個關鍵：團隊、技術、流程。在ML專案當中，把模型從實驗階段推向產品化的過程，開發者在資料、模型、程式的管理與合作上都需要有更近一步的要求。近幾年的軟體開發常談到的持續交付，也同樣反映在ML專案上。一個成熟度高的ML產品在CI(持續整合)、CD(持續部署)、CT(持續訓練)上也有系統性的方式維護，讓合作的開發者能夠輕易地接手、維護該專案。

資料

資料的收集可以說是整個專案最重要的步驟之一。(另一個步驟我會說是商業與ML問題的相映，但可以找另外一篇詳述。)

ML模型學習的對象就是我們提供給模型訓練的資料，處理資料的工作包括：

• (1)資料擷取：收集內外部的資料來源。外部來源像是向其他廠商購買資料、爬蟲。內部資料可能包含跨部門以及跨單位的資料授權。
• (2)驗證：驗證資料收集的格式，是否符合需求。
• (3)探索：透過視覺化或者統計指標，來看資料的各特徵是否與我們理解的相符。
• (4)特徵工程：在驗證資料以及探索資料的過程，根據應用情境決定是否要將資料集去除某些資料，或是跟其他部門溝通，將資料整理過轉換成適合這個專案的資料集。
• (5)標記：在監督式學習的情境下，需要標記哪些資料相對應於哪些標籤、類別。
• (6)資料集拆分：訓練、驗證和測試資料集。

這些工作內容時常是Data engineer的工作範疇。當一個資料及被稱作是高品質的資料集，通常符合以下條件：

• (1)內容格式一致：包含(a)檔案編碼(utf-8, 或其他)、(b)同一欄位使用語言統一(非中英夾雜)、(c)資料表裡面沒有空值，當沒有相對應的數值時，至少會有預設值。

• (2)資料邏輯對應商業邏輯：(a)資料表裡面若有分類或是標籤，一率有相對應的號碼解釋對照文件可查閱、(b)若是不同地域性、不同國家，則須標示清楚時區、使用幣別、測量單位(例如公尺、英呎)。

• (3)即時性：(a)資料表具有建立時間和更新時間、(b)資料的更新程度與公司提供的服務熱門程度、使用者使用網站所建立的資料量是相對應的、(c)收集資料的過程當中如果有偶發性事件，或是特殊事件，同時也必須反映在資料及的處理上。

當資料的品質越好，模型就越能反映出在這個資料相對的業務問題。在未來市場擴展的時候，也需要時常回頭看，資料是否因為數據局部性，而不足以反映整個市場的樣貌。開資料取樣則應該調整，針對不同用戶的人口資料收集與訓練。

模型

剛談完資料，模型的部分除了大家時常談到的(1)演算法選擇之外，這部分還包含了(2)超參數(hyper-parameter)訓練、(3)模型測試、(4)模型評估、(5)模型註冊、(6)模型發佈、(7)模型監測。

• (1)演算法選擇：這個問題屬於ML問題的哪一類，根據資料集的特徵，例如資料偏移(data skew)、或是空資料很多的狀況下，有哪些演算法可以克服這些狀況？提供相對好的預測？
• (2)超參數(hyper-parameter)訓練：在設計演算法實驗的時候，有許多參數是可以影響實驗結果的，這些參數少則3-5種，多則20種也是可能的。在這些參數的組合當中，要如何找到最好的組合，常常也是資料科學家在跑實驗的必要過程。關於演算法的選擇跟超參數的選擇，現在都已經有一些工具可以協助完成，資料科學家可以不必再用手動一次次紀錄實驗結果，而是透過自動化的實驗去完成這些選擇。
• (3)模型測試：完成模型與超參數訓練之後，接下來則是要測試模型的訓練結果。由於資料量的大小不同，以及各種演算法的複雜程度不同，有些模型訓練的時間特別長，因此也會花更久的時間才能夠對模型測試，決定要不要修正模型，還是準備要送出模型到下一個階段。在模型訓練期間，資料科學家們也會運用Tensorboard、SageMaker Debugger等工具在訓練進行的過程中，就可以看到模型的訓練以及測試狀況，讓時間的成功與失敗可以被及早觀察，及早修正。
• (4)模型評估：模型測試與評估的不同點在於：模型測試完全注重於演算法的metrics，像是precision、accuracy、F1-score等等。模型評估則必須與商業期待相互對齊，舉例來說，符合公司重要VIP的輪廓的使用者都能夠準確地被預測，因此公司可以帶給重要的客戶更好的品質。或是說公司希望給客戶一個慷慨大方的形象，即便不符合VIP的條件還是有可能會收到獎勵等等。在這個階段確保模型的表現比過去更加優秀、或者更有效地提供使用者好的服務。
• (5)模型註冊：在評估過後，發現新的模型相對過去的版本表現較優良，這時候就可以將模型註冊，將模型的參數檔案送往儲存的地方。以便系統可以使用該檔案發布或者回溯到某一版本。
• (6)模型發佈：模型的發佈與服務使用者的產品息息相關，我們曾經談過，ML產品本身是依附在某一產品之下，也就是說使用者大多會先接觸到使用者面向的產品，該產品的服務後端再去呼叫ML產品。因此模型發布包含的細節像 (a)開發環境 ：模型上線時所對接的服務，同樣也有開發、測試、產品等開發環境，如何讓產品在不同環境，都能使用到預設的模型版本，並確保在各環境的行為都相同。(b)A/B test：另一個則是在發布的過程當中，是否會需要A/B test，將使用者導流到不同版本的模型，這些導流是要從ML產品這邊進行交通引流，抑或是在使用者產品的階段就有規劃引流了。(c)可擴張性：ML產品本身是否支援高穩定度、安全以及可擴張性等等規格，讓使用者產品在呼叫ML產品的時候，可以享有同樣規格的體驗。
• (7)模型監測：模型監測的同時，也須觀察使用者呼叫模型時候的資料，也可能會與過去收集的資料分布不大相同，我們稱這個狀況叫做模型衰減、資料偏移。

程式

將訓練好的模型整合到公司的業務產品的過程。包括 (1)資料前處理、(2)模型預測、(3)預測後資料處理、(4)效能監控和(5)效能日誌記錄 等。其中會使用到的程式碼需要分為訓練和預測這兩個開發週期，以助於確保資料的安全運行環境以及有效的測試週期。

如果對執行細節想要了解，前陣子我也整理了另一篇史丹佛cs329課程內容，談到根據資料驗證、版本控制、模型監測、標籤資料、CI/CD 測試、部署、模型壓縮、推理效能優化、隱私，這幾個主題可以使用的開發框架。

結語

當我們對於MLOps有了一些了解，也知道有哪些工具可以協助我們從技術上實作的時候，也開始對專案的未來覺得更明朗了。在這過程當中其實應該讓ML專案盡量保持簡單，隨持回到初衷去思考：想傳遞的價值是什麼？是不是一定要使用這個架構、實作方式？如果這個功能沒辦法如期完成，或是第三方的產品不支援，可以用什麼方式去完成？

ML專案不是一夜魔法，當我們擁有技術的時候，就是讓自己的產品與使用者回饋可以快速收集資料、快速調整的時候。有了最簡單版本的模型之後，可以再加入更複雜的數據集、更複雜的使用者族群，甚至跨地域性、跨市場的實驗及部署。無論是再怎麽新穎或老舊的技術或是模型，大家的目標都是希望帶給客戶最好的體驗。

Reference
[1]. Why do 87% of data science projects never make it into production?
https://venturebeat.com/2019/07/19/why-do-87-of-data-science-projects-never-make-it-into-production/

[2]. How to Use MLOps for an Effective AI Strategy | Exploring the ML pipeline (CI/CD/CT)
https://www.kdnuggets.com/2021/01/mlops-effective-ai-strategy.html