監控生產環境中的機器學習模型

持續創作，加速成長！這是我參與「掘金日新計劃 · 10 月更文挑戰」的第15天，點擊查看活動詳情

簡介

一旦您將機器學習模型部署到生產環境中，很快就會發現工作還沒有結束。

在許多方面，旅程才剛剛開始。你怎麼知道你的模型的行為是否符合你的預期？下週/月/年，當客户（或欺詐者）行為發生變化並且您的訓練數據過時時呢？這些都是複雜的挑戰，而且機器學習監控在工具和技術方面都是一個快速發展的領域。似乎這還不夠，監控是一項真正的跨學科工作，但“監控”一詞在數據科學、工程、DevOps 和業務中可能意味着不同的東西。鑑於這種複雜性和模糊性的強硬結合，許多數據科學家和機器學習 (ML) 工程師對監控感到不確定也就不足為奇了。

本綜合指南旨在至少讓您瞭解在生產中監控機器學習模型的複雜性來自何方，為什麼它很重要，此外還將為實施您自己的機器學習監控解決方案提供一個切實可行的起點。如果您正在尋找示例代碼、教程和示例項目，您可能會對我們專門針對該主題的在線課程感興趣：測試和監控機器學習模型部署。

目錄

1. 機器學習系統生命週期
2. 是什麼讓機器學習系統監控變得困難
3. 為什麼需要監控
4. 監控機器學習系統的關鍵原則
5. 瞭解機器學習風險管理的範圍
6. 數據科學監控問題
7. 運營監控問題
8. 將 Ops 和 DS 結合在一起 - Prometheus 和 Grafana 的 Metrics
9. 將 Ops 和 DS 結合在一起 - 日誌
10. 不斷變化的局勢

1. 機器學習系統生命週期

機器學習模型的監控是指我們從數據科學和運營角度跟蹤和了解生產中模型性能的方式。 不充分的監控可能導致不正確的模型在生產中未經檢查，過時的模型停止增加業務價值，或者模型中的細微錯誤隨着時間的推移而出現並且永遠不會被發現。 當 ML 成為您業務的核心時，未能捕捉到這些類型的錯誤可能會引發破產事件——尤其是當您的公司在受監管的環境中運營時。

Martin Fowler 普及了機器學習持續交付 (CD4ML) 的概念，該概念的圖表為機器學習生命週期和監控發揮作用提供了有用的可視化指南：

此圖概述了 ML 模型生命週期中的六個不同階段：

• 模型構建：理解問題、數據準備、特徵工程和初始代碼。典型的製品是粗糙的 Jupyter notebook。
• 模型評估和實驗：特徵選擇、超參數調整以及比較不同算法在給定問題上的有效性。典型的製品包括帶有統計數據和圖表的notebook，用於評估特徵權重、準確度、精度和ROC。
• 產品化模型：獲取“研究”代碼並對其進行準備以便可以部署。典型的製品是生產級代碼，在某些情況下將使用完全不同的編程語言或框架。
• 測試：確保生產代碼按照我們預期的方式運行，並且其結果與我們在模型評估和實驗階段看到的結果相匹配。典型的製品是測試用例。
• 部署：將模型投入生產，它可以通過提供預測來開始增加價值。典型的製品是用於訪問模型的 API。
• 監控和可觀察性：最後階段，我們確保我們的模型在生產中按照我們期望的那樣工作。這篇博文的主題。

在圖中，請注意週期性方面，其中在最終“監控和可觀察性”階段收集的信息反饋給“模型構建”。對於大多數公司來説，這是一個從業務角度評估模型影響的非自動化過程，然後考慮現有模型是否需要更新、放棄或可能從補充模型中受益。在更先進的公司中，這可能意味着在監控階段收集的數據以自動方式直接輸入到模型更新的訓練數據中（這帶來了很多額外的挑戰）。

您可以將圖表的前兩個階段（“模型構建”和“模型評估”）視為研究環境，通常是數據科學家的領域，而後四個階段則更多地屬於工程和 DevOps 領域，儘管這些區別各不相同從一家公司到另一家公司。如果您不確定部署階段需要什麼，我已經寫了一篇關於該主題的帖子。

監控場景

與軟件中的大多數事情一樣，真正的挑戰在於可維護性。 在 Flask 中部署和服務 ML 模型並不太具有挑戰性。 事情變得複雜的地方在於以可重複的方式執行此操作，尤其是在模型頻繁更新的情況下。 我們的典型更新場景如下所示：

• 第一種場景只是部署一個全新的模型。
• 第二種情況是我們用完全不同的模型完全替換這個模型。
• 第三種情況（右側）非常常見，意味着對我們當前的實時模型進行小幅調整。 假設我們在生產中有一個模型，但有一個變量不可用，所以我們需要在沒有該特性的情況下重新部署該模型。 或者，我們開發了一個我們認為非常具有預測性的超級特徵，並且我們想要重新部署我們的模型，但現在將這個新特徵作為額外的輸入。

無論情況如何，監控都是我們確定模型更改是否產生預期效果的方式，這是我們最終關心的。 這條規則的唯一例外是影子部署，我在這篇文章中對此進行了解釋。 但在我們深入研究監控的細節之前，有必要討論一下 ML 系統構建上下文所固有的一些挑戰。

2. 是什麼讓機器學習系統監控變得困難

機器學習系統具有傳統代碼的所有挑戰，以及一系列針對機器學習的額外考慮因素。 這在谷歌“機器學習系統中的隱藏技術債務”的論文中有很好的記錄。

從上面提到的論文中得到的一個關鍵點是，一旦我們談論生產中的機器學習模型，我們就是在談論 ML 系統。

該模型只是整個 ML 系統的一小部分：

對於 ML 系統，我們從根本上投資於跟蹤系統的行為，這歸結為三個組成部分：

• 代碼（和配置）
• 模型（ML 系統特定要求）
• 數據（ML 系統特定要求）

在 ML 系統中，我們有兩個額外的組件需要考慮，即數據依賴和模型。與傳統軟件系統不同，ML 系統的行為不僅受代碼中指定的規則支配，還受從數據中學習的模型行為支配。更復雜的是，數據輸入是不穩定的，可能會隨着時間而變化。

如果無法理解和跟蹤這些數據（以及模型）更改，您將無法理解您的系統。

但它並沒有就此結束。這不像“好吧，我們有兩個額外的維度要考慮”那麼簡單（這已經足夠具有挑戰性了）。由於以下原因，代碼和配置還會在 ML 系統中增加額外的複雜性和敏感性：

• 纏繞：當輸入特徵發生變化時，其餘特徵的重要性、權重或使用也可能發生變化。這也被稱為“改變任何事情都會改變一切”的問題。 ML 系統特徵工程和選擇代碼需要非常仔細地測試。
• 配置：由於模型超參數、版本和特徵通常在系統配置中進行控制，因此這裏最輕微的錯誤都可能導致完全不同的系統行為，而傳統的軟件測試無法識別這些行為。在模型不斷迭代和微妙變化的系統中尤其如此。

希望機器學習系統的難點開始變得清晰起來。另一個需要考慮的挑戰是系統中涉及的團隊數量之多。

責任挑戰

ML Systems跨多個團隊（也可能包括數據工程師、DBA、分析師等）：

在我們繼續分解監控之前，值得一提的是，這個詞在業務的不同部分有不同的含義。

• 數據科學家：一旦我們解釋説我們談論的是後期生產監控而不是部署前評估（這是我們在研究環境中查看 ROC 曲線等的地方），這裏的重點是模型的統計測試輸入和輸出（更多細節請參見第 6 節）。
• 工程師和 DevOps：當您説“監控”時，請考慮系統運行狀況、延遲、內存/CPU/磁盤利用率（更多細節請參見第 7 節）

對於 ML 系統，您需要這兩種觀點。雖然在傳統的軟件實踐中，監控和可觀察性往往落在 DevOps 上，但在 ML 系統中，您的 DevOps 團隊不太可能具備正確監控 ML 模型所需的專業知識。這意味着：

1. 整個團隊需要共同努力進行監控並説彼此的語言，以使系統有效
2. 定義我們的術語以避免混淆很重要。

所有這些複雜性意味着，如果您在部署之後只考慮孤立的模型監控，您將非常低效。在我們的 ML 生命週期的生產階段（與測試一起），應在系統級別計劃監控。持續的系統維護、更新和實驗、審計和細微的配置更改會導致技術債務和錯誤累積。在我們進一步進行之前，值得考慮未能監控的潛在影響。

3. 為什麼需要監控

“沒有做好準備，你就是在準備失敗”

監控的設計應旨在為生產環境 ML 模型可能出錯的無數事情提供提前警吿，其中包括：

數據偏差

當我們的模型訓練數據不能代表實時數據時，就會出現數據傾斜。也就是説，我們在研究或生產環境中用於訓練模型的數據並不代表我們在現場系統中實際得到的數據。

發生這種情況的原因有多種：

• 我們錯誤地設計了訓練數據：訓練數據中的變量分佈與實時數據中的變量分佈不匹配。
• 生產中不可用的特徵：這通常意味着我們需要刪除該特徵，將其更改為生產中存在的替代類似變量，或者通過組合生產中存在的其他特徵來重新創建該特徵。
• 研究/實時數據不匹配：我們用於在研究環境中訓練模型的數據來自一個來源，而實時數據來自不同的來源。這可能意味着變量的製造方式可能不同，因此即使管道對相同的輸入數據返回相同的預測（這意味着我們的差異測試通過），不同的數據源可能會導致相同特徵中固有的不同值，這將導致不同的預測。
• 數據依賴：我們的模型可能會攝取由其他系統（內部或外部）創建或存儲的變量。這些系統可能會改變它們生成數據的方式，但遺憾的是，這種情況通常不會被清楚地傳達。連鎖反應是今天產生的變量與幾年前產生的變量不等價。特徵的代碼實現會發生變化，產生略有不同的結果，或者特徵的定義可能會發生變化。例如，外部系統可能會將投票年齡從 18 歲調整為 16 歲。如果投票年齡是模型中的一個重要特徵，這將改變其預測。

模型陳舊

• 環境變化：如果我們使用歷史數據來訓練模型，我們需要預測當前的人口及其行為可能不同。例如，如果我們使用經濟衰退時期的數據來訓練我們的財務模型，那麼在經濟健康時期預測違約可能無效。
• 消費者行為的變化：客户偏好隨着時尚、政治、道德等方面的趨勢而變化。特別是在推薦機器學習系統中，這是一個必須不斷監控的風險。
• 對抗場景：不良行為者（欺詐者、犯罪分子、外國政府）可能會積極尋找模型中的弱點並相應地調整他們的攻擊。這通常是一場持續的“軍備競賽”。

負反饋循環

當模型根據生產中收集的數據自動訓練時，會出現更復雜的問題。如果該數據以任何方式受到影響/損壞，那麼隨後基於該數據訓練的模型將表現不佳。此處為 Twitter 的 Cortex AI 團隊的 Dan Shiebler 描述這一挑戰：

我們需要非常小心，我們部署的模型如何影響我們正在訓練的數據，一個已經試圖向用户展示它認為他們會喜歡的內容的模型正在破壞反饋到分佈正在發生變化的模型。

4. 監控機器學習系統的關鍵原則

雖然學術機器學習起源於 1980 年代的研究，但機器學習系統在生產中的實際實施仍然相對較新。除了少數開創性的例外，大多數科技公司在大規模開展 ML/AI 方面才幾年，而且許多公司才剛剛開始漫長的旅程。這意味着：

• 這些挑戰經常被誤解或完全忽視
• 框架和工具正在迅速變化（對於數據科學和 MLOps）
• 最佳實踐通常是灰色的
• 監管要求一直在變化

沒有什麼比監控更真實的了，這或許可以解釋為什麼它經常被忽視。

由具有大規模 ML 部署經驗的公司撰寫的詳細介紹系統設計、流程、測試和監控最佳實踐的研究論文非常有價值。畫出共同的主題和問題可以為您和您的公司節省大量的鮮血、汗水和淚水。機器學習領域最有經驗的兩家公司，谷歌和微軟，已經發表了這方面的論文，以幫助其他面臨類似挑戰的人。這兩篇論文是：

• The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction(2017) Breck 等人。（谷歌）
• 機器學習軟件工程：案例研究(2019) Amershi 等人。（微軟）

谷歌論文更多地關注機器學習系統測試和監控策略，這些策略可用於在可靠性、減少技術債務和減輕長期維護負擔方面改進此類系統。谷歌的論文圍繞 28 個測試進行了結構化，這是一個衡量給定機器學習系統對生產準備就緒程度的標準。這些測試“來自廣泛的生產機器學習系統的經驗”。

微軟的論文采取了更廣泛的視角，着眼於將 AI 功能集成到軟件中的最佳實踐。該論文介紹了對微軟約 500 名工程師、數據科學家和研究人員的調查結果，這些工程師、數據科學家和研究人員參與了創建和部署 ML 系統，並提供了對所識別挑戰的見解。

這兩篇論文都強調，應用傳統軟件開發技術（例如：測試）以及一般可操作 ML 系統階段的流程和標準尚未完善。

論文中與監測相關的關鍵原則

• 監視器 1：依賴項更改導致一個通知
• 監視器 2：數據不變量在訓練和服務輸入中保持不變，即監控訓練/服務偏斜

  有效監控學習模型的內部行為的正確性可能很困難，但輸入數據應該更加透明。因此，分析和比較數據集是檢測世界正在以可能混淆 ML 系統的方式變化的問題的第一道防線。

• 監視器 3：訓練和服務特徵計算相同的值
• 監視器 4：模型不太陳舊
• 監視器 5：模型在數值上是穩定的
• 監視器 6：該模型在訓練速度、服務延遲、吞吐量或 RAM 使用率方面沒有出現劇烈或緩慢的泄漏迴歸
• 監視器 7：模型在服務數據上的預測質量沒有出現迴歸

也許最重要且實施最少的測試是用於訓練/服務偏差的測試（監視器 3）。這種錯誤會導致大量團隊的生產問題，但它是最不常實施的測試之一。部分原因是因為這很困難。

儘管缺乏優先級，但值得稱讚的是，谷歌論文明確呼籲採取行動，特別是將其測試作為清單應用。我非常同意這一點，任何熟悉 Atul Gawande 的清單宣言的人都同意。

值得注意的是，這些最佳實踐中的許多都依賴於可重複性。

5. 瞭解機器學習風險管理的範圍

所有測試和監控最終歸結為風險管理。這兩種技術都是我們用來增加我們對系統功能是我們所期望的功能的信心的技術，即使我們對系統進行了更改。有一系列風險管理。

一方面，我們擁有沒有測試和監控的系統。這是一個前景黯淡的系統（甚至不太可能投產），但也確實是一個非常容易調整的系統。

另一方面，我們擁有經過最嚴格測試的系統，具有所有可以想象的可用監控設置。在這個系統中，我們對其行為有非常高的信心，但是對系統進行更改是非常痛苦和耗時的。這樣，測試和監控就像戰甲一樣。太少了，你很脆弱。太多了，你幾乎不能動。

還要注意，測試和監控的價值隨着變化而最明顯。大多數機器學習系統一直在變化——業務增長、客户偏好發生變化以及新法律的頒佈。

上圖詳細説明了您可以使用的所有生產前和生產後的風險緩解技術。

當我們談論監控時，我們關注的是生產後的技術。 我們的目標是確定與我們的預期相沖突的 ML 系統行為的變化。

從廣義上講，我們可以將 ML 系統出錯的方式分為兩類：

• 數據科學問題（數據監控、預測監控）
• 運營問題（系統監控）

正如我們將在接下來的部分中看到的那樣，要獲得有效的解決方案，這兩個領域需要結合在一起，但是隨着我們越來越熟悉，首先單獨考慮它們是有用的。

6.數據科學監控

當然，我們對生產中運行的模型的準確性感興趣。然而，在許多情況下，不可能立即知道模型的準確性。以欺詐檢測模型為例：只有在發生警方調查或進行其他檢查（例如與已知欺詐者交叉檢查客户數據）的情況下，才能在新的實況案例中確認其預測準確性。類似的挑戰也適用於我們無法獲得即時反饋的許多其他領域（例如：疾病風險預測、信用風險預測、未來財產價值、長期股市預測）。考慮到這些限制，監控代理值以在生產中建模準確性是合乎邏輯的，特別是：

• 模型預測分佈（迴歸算法）或頻率（分類算法），
• 模型輸入分佈（數字特徵）或頻率（分類特徵），以及缺失值檢查
• 模型版本

模型輸入監控

給定一組輸入特徵的預期值，我們可以檢查

a）輸入值是否在允許的集合（對於分類輸入）或範圍（對於數字輸入）內，

b）集合內每個值的頻率是否與我們過去看到的一致。

例如，對於“婚姻狀況”的模型輸入，我們將檢查輸入是否在圖中所示的預期值範圍內：

根據我們的模型配置，我們將允許某些輸入特性為空或不為空。這是我們可以監控的。如果我們預期的特性通常不會是空的開始更改，這可能表明數據傾斜或消費者行為的更改，這兩個都是進一步調查的原因。

模型預測監控

在自動化或手動流程中，我們可以將模型預測分佈與統計測試進行比較：

基本統計數據：中值、平均值、標準差、最大值/最小值

例如，如果變量是正態分佈的，我們期望平均值在平均區間的標準誤差範圍內。當然，這是一種非常簡單的統計方法。

模型版本

這是一個經常被忽視的需要監控的基本領域——您希望確保能夠在配置錯誤發生時輕鬆跟蹤模型的哪個版本已經部署。

高級技術：

我們還可以實施全面的統計測試來比較變量的分佈。哪個測試？這取決於變量特性。

如果變量是正態分佈的，我們可以進行t檢驗或方差分析，

如果它們不是正態分佈，也許像Kruskall Wallis或Kolmogorov Smirnov這樣的非參數檢驗更合適。

如果訓練數據中的變量分佈與生產中看到的變量類似，我們希望逐個變量進行比較。

實際上，在監測系統中實施高級統計測試可能很困難，儘管理論上是可行的。更典型的是隨着時間的推移自動化基本統計測試（尤其是輸入/輸出的標準偏差），並進行特別的手動測試以應用更高級的檢查。我們現在將深入探討自動化選項。

7.運營監控問題

軟件工程領域的監控是一個成熟得多的領域，也是站點可靠性工程的一部分。谷歌的SRE手冊是一本很棒的（免費）參考書。我們ML系統的運營問題包括以下方面：

• 系統性能（延遲）
• 系統性能（IO/內存/磁盤利用率）
• 系統可靠性（正常運行時間）
• 可審計性（儘管這也適用於我們的模型）

在軟件工程中，當我們談論監控時，我們談論的是事件。事件幾乎可以是任何事情，包括： - 接收HTTP請求 - 發送HTTP 400響應 - 輸入函數（可能包含或不包含ML代碼） - 到達if語句的else - 離開函數 - 登錄的用户 - 將數據寫入磁盤 - 從網絡讀取數據 - 從內核請求更多內存

所有事件都有上下文。例如，HTTP請求將具有其發出和發送的IP地址、請求的URL、設置的cookie以及發出請求的用户。涉及函數的事件上面有函數的調用堆棧，以及觸發堆棧這一部分的任何內容，例如：HTTP請求。掌握所有事件的所有上下文對於調試和理解系統在技術和業務方面的表現都是很好的，但處理和存儲這些數據量並不實際。

因此，監控被分解為不同的領域，每個領域都與將數據量減少到可行的程度有關。

所謂的“可觀察性三大支柱”描述了我們可以利用事件上下文並將上下文數據簡化為有用數據的關鍵方法。他們是：

• Metrics
• Logs
• 分佈式跟蹤

根據您詢問的對象，偶爾會有一些額外的成員，例如： - Profiling - 警報/可視化（儘管這通常被納入metrics/logs中）

監控與可觀察性對比

那麼監控和可觀察性之間有什麼區別呢？簡單地説，可觀察性是指你通過觀察系統外部來回答系統內部發生的任何問題的能力。要了解可觀性的偉大歷史，我建議Cindy Sridharan撰寫的這篇文章，以及她的書分佈式系統可觀性

此時，維恩圖很有用：

此圖包含：

• 測試-我們盡最大努力驗證正確性
• 監控-我們盡最大努力跟蹤可預測的故障

可觀察性是監控和測試的超集：它提供了無法監控或測試的不可預測故障模式的信息。

監控和警報是相互關聯的概念，共同構成監控系統的基礎。監控系統負責存儲、聚合、可視化，並在值滿足特定要求時啟動自動響應。

在監控ML系統時，分佈式跟蹤的細節往往與非ML系統的設置非常相似。因此，我不會在這裏討論它們。然而，對於日誌和metrics，有一些值得注意的ML系統注意事項，我現在將深入探討。

8.將Ops和DS結合在一起-Prometheus和Grafana的指標

Metrics表示可以在整個系統中觀察和收集的資源使用或行為的原始度量。這些可能是運營系統提供的低級使用概要，也可能是與組件的特定功能或工作相關聯的高級數據類型，如每秒處理的請求或特定函數的輸出。

Metrics的優點：（來自分佈式系統可觀察性（Distributed Systems Observability）中豐富的解釋）

• 與日誌生成和存儲不同，metrics傳輸和存儲的開銷是恆定的。
• 由於數字針對存儲進行了優化，因此，指標可以延長數據保留時間並簡化查詢。這使得指標非常適合創建反映歷史趨勢的儀表盤，可以每週/每月切片等。
• 度量非常適合於統計轉換，例如：採樣、聚合、彙總和關聯。度量也更適合觸發警報，因為，對內存中的時間序列數據庫運行查詢要高效得多。

Metrics的缺點：

• Metrics允許您從整個流程收集有關事件的信息，但通常不超過一個或兩個上下文字段。
• 基數問題（集合元素的數量）：使用高基數值（如ID）作為metrics標籤可能會淹沒時間序列數據庫。
• 作用域為一個系統（即一組微服務中只有一個服務）

機器學習指標

鑑於上述利弊，指標非常適合我們的ML系統的兩個運營問題：

• 調用ML API端點時的延遲
• 執行預測時的內存/CPU使用率
• 磁盤利用率（如果適用）

以及以基本統計指標為中心的預測監測：

• 給定時間段內的中值和平均預測值
• 最小/最大預測值
• 給定時間段內的標準偏差

實際工具

Prometheus和Grafana的組合是監控指標最流行的開源堆棧之一。

為了避免這篇文章變成一本書，我不會詳細解釋這些技術。瞭解更多信息的最佳場所是Brian Brazil的書籍和培訓課程。文檔中的快速摘要：

Prometheus直接或通過中介推送網關從插入指令的作業中獲取度量值，用於短期作業。它將所有收集的樣本存儲在本地，並對這些數據運行規則，以便從現有數據中聚合和記錄新的時間序列，或生成警報。Grafana或其他API使用者可用於可視化收集的數據。

來源：Prometheus文檔

我們可以使用Prometheus&Grafana創建儀表盤，以跟蹤我們的模型標準統計指標，可能如下所示：

您可以使用這些儀表板創建警報，當模型預測超出特定時間段內的預期範圍（即異常檢測）時，通過電子郵件/SMS通知您，從而調整此處描述的ML方法。然後，這將提示對常見疑似點進行全面調查，例如：

• 流水線中有bug嗎？
• 我們部署了錯誤的模型嗎？
• 數據集有問題嗎？
• 模型過時了嗎？

9.將Ops和DS結合在一起-日誌

事件日誌（通常稱為“日誌”）是一個不可變的、帶有時間戳的記錄，記錄了一段時間內發生的離散事件。

日誌的優點：

• 日誌很容易生成，因為它只是一個字符串、一個JSON blob或類型化鍵值對。
• 事件日誌在提供有價值的洞察力和足夠的上下文方面表現出色，提供了平均值和百分位數無法顯示的細節。
• 雖然指標顯示服務或應用程序的趨勢，但日誌關注特定事件。日誌的目的是保存關於特定事件的儘可能多的信息。日誌中的信息可用於調查事件並幫助進行根本原因分析。

日誌的缺點：

• 日誌記錄過多會對系統性能產生負面影響
• 由於這些性能問題，日誌上的聚合操作可能代價高昂，因此應謹慎處理基於日誌的警報。
• 在處理方面，原始日誌幾乎總是由Logstash、fluentd、Scribe或Heka等工具進行規範化、過濾和處理，然後再保存到Elasticsearch或BigQuery等數據存儲中。設置和維護此工具會帶來巨大的運營成本。

機器學習日誌

如果我們考慮監控ML的關鍵領域，我們在前面看到了如何使用指標來監控預測輸出，即模型本身。然而，通過指標調查數據輸入值可能會導致高基數挑戰，因為許多模型都有多個輸入，包括分類值。雖然我們可以在一些關鍵輸入上檢測指標，但如果我們想在沒有高基數問題的情況下跟蹤它們，最好使用日誌來跟蹤輸入。如果我們使用的是帶有文本輸入的NLP應用程序，那麼由於語言的基數非常高，我們可能不得不更加依賴日誌監視。

我們將檢查輸入的危險信號，例如：

• 某個特徵變得不可用（要麼從輸入中消失，要麼大量NA）
• 關鍵輸入值分佈的顯著變化，例如，在訓練數據中相對罕見的分類值變得更加常見
• 特定於模型的模式，例如，在NLP場景中，訓練數據中看不到的單詞數量突然增加

實際工具

Kibana是一個開源分析和可視化平台，它是彈性堆棧的一部分，以前是ELK堆棧。您可以使用Kibana搜索、查看和交互存儲在Elasticsearch索引中的日誌。您可以輕鬆執行高級數據分析，並在各種圖表、表格中可視化日誌。這是構建日誌監控系統最常見的開源堆棧之一

在Kibana中，您可以設置儀表板來跟蹤和顯示ML模型輸入值，以及在值出現意外行為時自動發出警報。這樣的儀表板可能看起來有點像：

這是日誌記錄系統的一種可能選擇，還有logz.io和Splunk等選項。

10. 不斷變化的局勢

希望本文能讓您更清楚地瞭解機器學習監控的真正含義以及它的重要性。正如我希望的那樣，這是一個需要跨學科努力和規劃才能有效的領域。有趣的是，這些工具將如何發展以滿足許多企業日益增長的挫敗感，這些企業經歷了 ML 部署的高峯期，但隨後卻沒有能力監控該部署，並因幾個月後環境的變化而被燒燬。值得關注的有趣發展包括：

• 大型 AI 玩家努力改進他們的機器學習模型解決方案監控，例如：微軟在 Azure ML Studio 中引入了“數據漂移“。自然的，這些都伴隨着通常的供應商鎖定和非內部構建的靈活性限制。
• 零星創業公司試圖構建創新工具以簡化模型監控，例如：Seldon、Data Robot、MLFlow、superwise.ai 和 hydrosphere.io 等。
• MLOps 領域的開源倡議。我認為 KF Serving 可能會提供一些急需的標準化，這可以簡化構建監控解決方案的挑戰。

到明年這個時候，局勢可能看起來會大不相同……

原文鏈接：Monitoring Machine Learning Models in Production