[會員動態]
2022-12-07 17:42:09 編輯：yl
隨著機器學習技術的日益成熟，ML逐漸從學術研究走向落地商用，我們需要改進ML的部署過程。技術的成熟促使ML操作流程的改進。
你的公司決定研發機器學習（ML）。
你有一個才華橫溢的數據科學家團隊。
他們正在開發模型去解決幾年前遙不可及的重要問題。
所有性能指標都讓人驚喜。
畢竟所有最高級的數學問題都搞定了，日常IT工作能有多難呢？
MLOps是一門工程學科，旨在統一 ML 系統開發(dev)和 ML 系統部署(ops)，以標準化過程生產高性能模型的持續交付。
Deeplearning.ai 報告稱，“只有22%使用機器學習的公司成功部署了模型。是什么讓它這么難？怎么才能改善？
在傳統軟件開發領域，DevOps 的實踐使得在幾分鐘內將軟件交付到生產環境并保持其可靠運行成為可能。DevOps 依靠工具、自動化和工作流來將偶然的復雜性抽象化（因方法不對，導致復雜情況時有發生），讓開發人員專注于需要解決的實際問題。這種方法的有效性已經在大量公司的軟件開發中廣泛實踐。那么為什么我們不能繼續為ML做同樣的事情呢？
雖然代碼是在受控開發環境中精心開發的，但數據來自被稱為‘現實世界’的無盡的熵源。
根本原因是ML和傳統軟件之間存在根本區別：ML不僅僅是代碼，而是代碼加數據。通過將算法應用于大量訓練數據來創建 ML 模型，即最終進入生產的組件，這將影響模型在生產中的行為。最重要的是，模型的行為還取決于我們在預測時提供給它的輸入數據，這讓預測更加無法預測。
雖然代碼是在受控開發環境中精心制作的，但數據來自被稱為“現實世界”的無盡的熵源。它永遠不會停止變化且永不受控。思考代碼和數據之間關系的一種形象比喻是，就好像它們生活在共享時間維度，但在所有其他方面都是獨立的不同平面上。ML過程的挑戰是以受控的方式在這兩個平面之間創建橋梁。
這種根本性的脫節導致了幾個重要的挑戰，任何試圖將 ML 模型成功投入生產的人都需要迎接這些挑戰，例如：上文中我們反復提及“數據”一詞，讓數據變得能用的數據工程確實提供了解決生產中ML難題不可或缺的重要工具和概念。為了破解它，我們需要結合DevOps和數據工程的實踐，添加一些ML獨有的實踐。
MLOps 是機器學習、DevOps 和數據工程的交集。現在，讓我們通過檢查可用于實現 MLOps 目標的各個做法，更詳細地了解這實際上意味著什么。我們已經確定，生產 ML 模型需要一組我們之前認為彼此獨立的技能。為了取得成功，我們需要一個混合團隊，共同涵蓋這些技能范圍。當然，一個人可能在所有方面都足夠好，在這種情況下，我們可以稱這個人為真正的 MLOps 工程師。但更現實的情況是，一個成功的團隊將包括數據科學家或ML工程師，DevOps工程師和數據工程師。讓模型在筆記本上記錄和推導出妙筆生花顯然是不夠的。團隊的確切組成、組織和頭銜可能會有所不同，但關鍵的部分是意識到僅靠數據科學家無法實現 MLOps 的目標。即使一個組織包含所有必要的技能，如果他們不密切合作，它也不會成功。
IT 或 DevOps — 完成部署設置，與科學家一起進行監控
另一個重要的變化是數據科學家必須精通基本的軟件工程技能，如代碼模塊化、重用、測試和版本控制;讓模型在凌亂的筆記本中工作是不夠的。這就是為什么許多公司采用ML工程師的頭銜，強調這些技能。在許多情況下，ML 工程師在實踐中執行 MLOps 所需的許多活動。
數據工程的核心概念之一是數據管道。數據管道是我們應用于源和目標之間的數據的一系列轉換。它們通常定義為一個圖形，其中每個節點都是一個轉換，邊緣表示依賴關系或執行順序。有許多專用工具可幫助創建、管理和運行這些管道。數據管道也可以稱為 ETL（提取、轉換和加載）管道。ML 模型總是需要某種類型的數據轉換，這通常是通過腳本甚至文本中的單元格實現的，這使得它們難以管理和可靠運行。切換到適當的數據管道在代碼重用、運行時可見性、管理和可伸縮性方面提供了許多優勢。由于我們還可以將 ML 訓練視為數據轉換，因此很自然地將特定的 ML 步驟包含在數據管道本身中，將其轉換為 ML 管道。大多數模型需要兩個版本的管道：一個用于訓練，一個用于服務。這是因為通常情況下，數據格式（以及訪問它們的方式）在每個時刻都非常不同，特別是對于我們在實時請求中提供服務的模型（而不是批量預測運行）。Kubeflow Pipelines 中 ML 管道的可視化表示
ML 管道是獨立于特定數據實例的純代碼工件。這意味著可以在源代碼管理中跟蹤其版本，并使用常規 CI/CD 管道自動部署，這是 DevOps 的核心做法。這使我們能夠以結構化、自動化的方式連接代碼和數據平面：
請注意，有兩個不同的 ML 管道：訓練管道和服務管道。它們的共同點是，它們執行的數據轉換需要以相同的格式生成數據，但它們的實現可能非常不同。例如，訓練管道通常在包含所有功能的批處理文件上運行，而服務管道通常聯機運行，僅接收請求中的部分功能，從數據庫中檢索其余功能。但是，確保這兩個管道一致很重要，因此應盡可能嘗試重用代碼和數據。一些工具可以幫助實現該目標，例如：像TensorFlow Transform這樣的轉換框架可以確?；谟柧毤y計數據的計算（如規范化的平均值和標準偏差）是一致的
特征平臺是存儲不屬于預測請求的值的數據庫，例如使用數據流轉換根據用戶歷史記錄計算的特征
為了具有可重現性，一致的版本跟蹤至關重要。在傳統的軟件世界中，版本控制代碼就足夠了，因為所有行為都由它定義。在 ML 中，我們還需要跟蹤模型版本，以及用于訓練它的數據，一些元信息，如訓練超參數。我們可以在像 Git 這樣的標準版本控制系統中跟蹤模型和元數據，但數據通常太大且可變，無法高效實用。避免將模型生命周期與代碼生命周期相關聯也很重要，因為模型訓練通常按不同的計劃進行。還需要對數據進行版本控制，并將每個經過訓練的模型與我們所使用的代碼、數據和超參數的確切版本相關聯。理想的解決方案是專用工具，但到目前為止，市場上還沒有明確的共識，從業者主要基于文件/對象存儲約定和元數據數據庫使用許多不同的方案。
另一個標準的DevOps實踐是測試自動化，通常采用單元測試和集成測試的形式。通過這些測試是部署新版本的先決條件。擁有全面的自動化測試可以給團隊帶來極大的信心，從而大大加快生產部署的步伐。ML 模型更難測試，因為沒有模型能給出 100% 正確的結果。這意味著模型驗證測試本質上必須是統計的，而不是具有二進制通過/失敗狀態。為了確定模型是否足以進行部署，需要確定要跟蹤的正確指標及其可接受值的閾值，通常是經驗性的，并且通常通過與以前的模型或基準進行比較。這是一門令人興奮的新學科，其工具和實踐可能會迅速發展。
跟蹤整個驗證集的單個指標也是不夠的。正如好的單元測試必須測試多個案例一樣，我們需要單獨驗證相關數據段的模型，稱為片段。例如，如果性別可以直接或間接地成為模型的相關特征，那么我們應該跟蹤男性、女性和其他性別的單獨指標。否則，該模型可能會出現公平問題或在重要細分市場中表現不佳。如果您設法以自動化和可靠的方式驗證模型以及 ML 管道的其余部分，您甚至可以關閉循環并實施在線模型訓練（如果它對用例有意義）。
一個良好的數據管道通常從驗證輸入數據開始。常見的驗證包括文件格式和大小、列類型、null 或空值以及無效值。這些都是 ML 訓練和預測所必需的，否則你可能會有一個行為不端的模型，最終會撓頭，尋找原因。數據驗證類似于代碼域中的單元測試。除了任何數據管道執行的基本驗證外，ML 管道還應驗證輸入的更高級別統計屬性。例如，如果特征的平均或標準偏差從一個訓練數據集到另一個訓練數據集發生很大變化，則可能會影響訓練模型及其預測。這可能反映了數據的實際變化，也可能是由處理數據的方式引起的異常，因此必須排除系統錯誤作為可能污染模型的原因，并在必要時修復它們。
TensorFlow Data Validation中的統計數據剖析示例
監控生產系統以使其正常運行至關重要。對于ML系統來說，監控變得更加重要，因為它們的性能不僅取決于我們可以控制的因素，如基礎設施和我們自己的軟件，還取決于數據，但數據的可控性太低了。除了監控延遲、流量、錯誤和飽和度等標準指標外，我們還需要監控模型預測性能。監控模型性能的一個明顯挑戰是，在模型處理新數據時，我們通常沒有一個經過驗證的標簽來比對模型的預測。在某些情況下，我們可能有一種間接的方式來評估模型的有效性，例如通過測量推薦模型的點擊率。在其他的一些情況下，我們可能必須依賴于時間段之間的比較，例如，每小時計算一個正分類的百分比，并在模型偏離該時間的平均值超過百分之幾時設置警報。就像我們驗證模型時一樣，跨片段（而不僅僅是全局）監控指標也很重要，以便能夠檢測影響特定細分的問題。
隨著ML從研究到應用業務解決方案的成熟，我們也需要提高其部署流程的成熟度。幸運的是，我們可以ML之前的學科能給到我們許多實踐經驗。
下表總結了 MLOps 的主要做法以及它們與 DevOps 和數據工程做法的關系：這是一門令人興奮的新學科，其工具和實踐可能會迅速發展，也會有很多機會開發和應用生產技術到ML。
酷芯自研工具鏈可智能地幫助客戶將Pytorch/Tensorflow/Caffe/ONNX/Paddlepaddle 等工具產生的浮點模型量化為可在開發板端直接運行的定點模型，并采用圖優化策略達到性能優化目的，確保量化精度、減少量化損失和上板調試過程，幫助客戶高效驗證NPU的相關性能。服務的客戶覆蓋了安防、車載、熱成像、圖傳、無人機、地面機器人、運動相機等行業的頭部客戶超20余家。用過的客戶都說好哦~
來源：酷芯微電子
作者：Cristiano Breuel
翻譯：酷芯PR團隊
校對：酷芯軟件工程部 & NPU設計部
