機器學習系統整合與備援策略

機器學習模型的整合和佈署對於實際應用至關重要。穩定的系統需要備援方案來應對主要模型失效的情況。次要模型或根據規則的方法可以作為備份，確保系統持續運作。除了備援，覆寫機制允許手動調整模型輸出，以應對特定情況或修正不理想的預測結果。良好的 API 設計對於整合至關重要，清晰的請求和回應格式能簡化系統互動。最後，持續監控系統健康、資料品質和模型效能，才能確保機器學習系統長期穩定可靠地執行。

13.4 覆寫和備用方案

你的系統可能有正當的理由失敗。例如，這種理由可能是外部依賴：你從第三方 API 中提取一塊資料，而在某個時候，它根本不可用。這就是你可能想要有備用方案的情況之一。

備用方案是一種備用計劃或替代解決方案，當主要的計劃或解決方案失敗或不可用時，可以使用它。我們使用它來確保系統仍然可以運作並做出決策，即使主要的 ML 模型因任何原因失敗。

這在用於關鍵任務或行業中，即使最短的停機時間也可能導致嚴重後果的系統中尤為重要。例如，備用方案對於用於預測製造環境中裝置故障的模型至關重要，以確保即使主要模型出現問題，生產也可以繼續。

使用備用方案的另一個原因是，當主要系統無法提供令人滿意的答案或自信的預測時，或者當主要模型的輸出超出可接受範圍時，提供替代解決方案。

有多種不同的方法可以用於實施備用方案。一種常見的方法是使用次要的 ML 模型，可以使用不同的資料集或不同的演算法進行訓練。它可能是一個更簡單的模型，或者是一個更穩健但準確度較低的模型。另一個例子是規則型的方法，其輸出結果僅根據一組固定的規則，主要用於提供快速但可能不那麼準確的答案。

內容解密：

1. 外部依賴風險：文中提到外部依賴（如第三方 API）可能導致系統失敗，因此需要備用方案。
2. 備用方案的重要性：備用方案確保系統在主要模型失敗時仍能運作，尤其是在關鍵任務中。
3. 多種備用方案：可以使用次要 ML 模型或規則型方法作為備用方案，以提供替代解決方案。
4. 實施備用方案的原因：包括主要模型失敗、無法提供滿意答案或輸出超出可接受範圍等情況。

整合設計：確保系統穩定性與效率

在前面的章節中，我們討論了根據機器學習（ML）的模型開發和評估。然而，模型的整合和佈署同樣重要。本章節將探討如何將 ML 模型有效地整合到實際應用中，並確保系統的穩定性和效率。

備援策略與覆寫機制

在模型整合過程中，備援策略（Fallback Strategies）是確保系統穩定性的關鍵。當主模型出現問題或不可用時，備援策略可以提供替代方案，以維持系統的正常運作。常見的備援策略包括：

多層備援系統

Supermegaretail 採用了多層備援系統，以確保庫存預測的準確性和穩定性。

• 主要備援：使用訓練於最關鍵特徵子集的主要模型，當未檢測到特徵漂移或問題時使用。
• 次要備援：採用時間序列模型，如 SARIMA 或 Prophet，這些模型對外部特徵的依賴較低，能夠在特徵漂移發生時提供更穩健的預測。
• 第三備援：作為最後手段，預測與前一週資料相似的銷售情況，並根據預期的事件和假期進行調整。

自動切換機制

系統會監控資料漂移和品質問題，並在檢測到問題時自動切換到適當的備援方案，以確保預測的準確性。

覆寫機制（Overrides）

覆寫機制是一種手動干預手段，用於在模型輸出不理想時進行修正。例如，當模型的預測超出可接受範圍或置信度過低時，可以使用常數或其他規則來覆寫模型的輸出。

覆寫機制的優缺點

• 優點：能夠快速解決特定場景下的問題，提高客戶滿意度。
• 缺點：可能導致技術債的累積，因為覆寫規則需要被追蹤和管理，以便在未來的模型更新中被適當地處理。

利用覆寫機制改進模型

多個覆寫規則的集合可以用於透過多源弱監督（Multisource Weak Supervision）來改進模型。這種技術利用「標註函式」對未標註資料進行標註，從而建立一個用於模型訓練的噪聲資料集。

API 設計

對於 Supermegaretail 而言，API 設計是整合策略中的重要一環。

• HTTP API 處理器：負責管理請求和回應，以結構化的 JSON 格式與使用者介面進行互動。
• 模型 API：直接從模型中提取預測結果。

程式碼範例與解析

以下是一個簡單的 Python 程式碼範例，展示瞭如何實作一個具有備援策略的預測系統：

def predict_sales(features):
    # 主要模型預測
    primary_prediction = primary_model.predict(features)
    
    # 次要備援（時間序列模型）
    secondary_prediction = secondary_model.predict(features)
    
    # 第三備援（前一週資料）
    tertiary_prediction = get_last_week_sales(features)
    
    # 根據資料品質選擇適當的預測結果
    if data_quality_check(features):
        return primary_prediction
    elif secondary_model_available():
        return secondary_prediction
    else:
        return tertiary_prediction

#### 內容解密：
1. **`predict_sales` 函式**：根據輸入特徵進行銷售預測，並根據資料品質和模型可用性選擇適當的備援策略。
2. **`primary_model.predict`**：主要模型的預測函式。
3. **`secondary_model.predict`**：次要備援模型的預測函式，通常是時間序列模型。
4. **`get_last_week_sales` 函式**：取得前一週的銷售資料，用於第三備援。
5. **`data_quality_check` 函式**：檢查輸入資料的品質，以決定是否使用主要模型的預測結果。
6. **`secondary_model_available` 函式**：檢查次要備援模型是否可用。

此範例展示瞭如何在實際應用中實作多層備援系統，以提高系統的穩定性和預測準確性。

整合設計檔案：技術實作與策略分析

在現代化的技術架構中，系統整合扮演著至關重要的角色，尤其是在人工智慧與軟體開發領域。以下將探討兩種不同的整合案例及其技術實作細節。

需求預測 API 整合

請求與回應格式規範

需求預測 API 的請求格式如下：

GET /predictions?query=<query_string>&parameters=<parameters>&version=<version>
&limit=<limit>&request_id=<request_id>&sku=<sku>&entity_id=<entity_id>
&group=<group_type>

回應格式則為：

{
  "predictions": [
    {
      "sku": <sku_id>,
      "demand": <demand>,
      "entity": <entity_id>,
      "period": <time_period_for_demand>,
    },
    ...
  ]
}

發布週期管理

發布週期管理包含兩個主要部分：包裝器（wrapper）發布與模型（model）發布。

包裝器發布考量

1. 發布頻率與時程：包裝器的發布頻率通常低於模型，因為需求模式的變化需要透過訓練納入模型。

2. 相依性：主要取決於軟體更新、第三方服務或系統需求的變化。

3. 測試：必須進行全面的整合測試，以確保所有元件協調運作，並保持向後相容性。

4. 佈署策略：採用標準的軟體佈署策略，視情況選擇是否使用藍綠佈署。

5. 監控重點：系統健康狀態、執行時間、回應時間及錯誤率。

模型發布考量

1. 發布頻率與時程：模型發布更為頻繁，與新資料的可用性、資料模式的變化或建模技術的改進相關。

2. 相依性：主要依賴新訓練資料的品質和數量。

3. 測試：進行嚴格的離線驗證，並可能在影子模式下測試新模型的預測效能。

4. 佈署注意事項：除了佈署模型檔案，還需確保前處理步驟、特徵工程等流程與模型期望一致。

5. 監控重點：模型效能指標及資料漂移監控。

包裝器與模型發布的協調

當基礎設施更新影響模型時，兩者的發布協調至關重要。模型的重大變更可能需要更新包裝器以配合。因此，在保持系統穩定性的同時，仍需持續改進其功能。

營運注意事項

為了持續改進預測結果，應建立回饋機制，包括覆寫功能，讓內部使用者能夠根據即時洞察調整預測。

非工程考量

整合策略還需考慮非工程因素，如管理面板、公司層級儀錶板的整合、額外報告及覆寫功能等，以提升系統的可管理性和可見性。

佈署策略

由於主要服務物件為內部客戶且涉及頻繁的批次作業，因此無需採用藍綠佈署或金絲雀佈署，簡化了佈署流程。

PhotoStock Inc. 的整合策略

API 設計

PhotoStock Inc. 的搜尋引擎需要暴露一個 HTTP API 處理器，接收查詢字串和可選的篩選條件，回傳按照相關性排序的照片 ID 清單。

請求與回應格式

請求格式如下：

GET /search?query=<query_string>&filters=<filters>&version=<version>
&limit=<limit>&request_id=<request_id>

回應格式則為：

{
  "results": [
    {
      "id": <photo_id>,
      "score": <score>
    },
    ...
  ]
}

技術實作細節

在技術實作上，系統將採用簡單的級聯方式來縮小搜尋結果。首先根據可選篩選條件進行篩選，接著在嵌入空間中擷取查詢字串的最近鄰居，最後根據最終模型進行相關性排序。計劃使用 Qdrant 作為快速向量資料函式庫，但需先進行適當測試。

機器學習系統的整合與監控

在開發機器學習（ML）系統時，整合與監控是兩個至關重要的環節。整合涉及將不同的系統元件結合在一起，以形成一個完整的系統，而監控則確保系統在上線後能夠持續穩定地運作。

整合的連續性

整合不是一個一次性事件或專案階段，而是一個從專案開始到系統退役的連續過程。在設計 ML 系統的 API 時，應考慮其簡單性和可預測性。有效的 API 實踐包括設計至少兩層 API，分離 ML 和 IO 元件，建立客戶端函式庫，以及嵌入功能切換或其替代方案。

API 設計的最佳實踐

我們的內部 API 使用 JSON 格式進行請求和回應。底層 API 應該分層設計：

• HTTP API 處理程式僅作為底層 API 的代理，不包含任何業務邏輯。
• 向量資料函式庫（Vector DB）API 負責根據查詢字串的嵌入（embedding）篩選和擷取候選專案。
• 模型 API 負責從字串中提取嵌入並對候選專案進行評分。
• 排名 API 負責根據相關性對候選專案進行排序，並套用可能的覆寫（override）。

{
  "query": "example query",
  "results": [
    {"id": 1, "score": 0.9},
    {"id": 2, "score": 0.8}
  ]
}

內容解密：

上述 JSON 程式碼展示了一個簡單的 API 回應格式，其中包含了查詢結果及其相關的分數。這種格式簡單直觀，便於擴充套件。

發布週期

由於訓練模型需要大量時間，我們預計模型更新的頻率相對較低，大約每 1 到 2 個月發布一次新模型和相關的 API。同時，大多數熱更新（hot update）將與索引和覆寫相關。

索引更新

索引是搜尋引擎的核心，需要定期更新。我們可以每天新增專案（例如，每天晚上執行批次作業），並準備根據需要更新索引（例如，移除被禁止的圖片或根據 VIP 使用者的特別請求新增圖片）。

營運關注點

內部使用者可以提供大量有關搜尋結果的回饋，因此我們需要為他們提供適當的工具。首先，我們可以在搜尋結果頁面為內部 PhotoStock Inc. 使用者新增一個「回報不良比對」（Report bad match）按鈕。它將向資料閘道（data gateway）傳送請求，以便將包含照片 ID、搜尋引擎結果頁面位置和查詢字串的事件儲存到資料湖（data lake）。然後，我們可以在模型重新訓練階段和錯誤分析中使用這些資料，並進行手動覆寫。

覆寫和備用方案

作為備用方案，我們將使用現有的根據 Elasticsearch 的搜尋引擎。雖然它的相關性不如新的搜尋引擎，但仍然是一個不錯的搜尋引擎。對於覆寫，我們可以為某些查詢手動設定覆寫，並將其儲存在單獨的資料函式庫中。這可以是一個簡單的鍵值儲存，其中鍵是查詢字串的正規表示式（regex），值是將在搜尋引擎結果頁面中使用的照片 ID 列表。

監控與可靠性

傳統軟體開發根據一個簡單的原則：品質良好的產品將具有高穩定性、高效率和可預測性。然而，機器學習的世界更加複雜，開發 ML 系統並不隨著其發布而結束。模型不可避免地會隨著時間而退化，並且由於訓練資料與實際資料之間的差異而出現意外行為。

監控作為機器學習系統設計的一部分

本章涵蓋了監控在機器學習系統設計中的重要性，包括軟體系統健康、資料品質和完整性、模型品質和相關性等方面。

軟體系統健康

監控軟體系統的健康狀態對於確保其穩定運作至關重要。這包括監控系統資源使用情況、錯誤率等指標。

資料品質和完整性

資料品質和完整性直接影響模型的效能。監控資料的品質和完整性可以幫助及時發現問題，避免模型效能下降。

此圖示說明瞭機器學習工作流程中的資料流動和處理步驟，從資料輸入到模型佈署，每一步都至關重要。

為何監控至關重要

在機器學習（ML）系統的設計中，監控扮演著舉足輕重的角色。隨著時間的推移，模型可能會因資料變化而開始退化，特別是在重大事件發生時，例如COVID-19疫情。實施監控系統有助於識別和解決資料品質問題，確保模型持續提供可靠的預測。

簡化的機器學習系統架構

一個典型的機器學習系統可以簡化為以下結構：

• 輸入資料
• 模型
• 模型輸出
• 後處理

只有當所有階段都保持固定，且資料透過相同的模型（相同的結構和權重）時，才能期望得到確定性的輸出。然而，在實際應用中，這種情況發生的機率極低，因為輸入資料、模型本身、以及後處理過程都可能發生變化。

輸入資料的挑戰

輸入資料的複雜性使得重複的輸入幾乎不可能。此外，資料特徵的分佈可能會隨著時間而改變，影響下游階段的處理。資料管道的中斷或惡意輸入也可能對系統造成嚴重影響。

模型的挑戰

模型的結構和權重可能會因線上訓練或定期更新而發生變化。即使是相同的資料，更新後的模型也可能產生不同的輸出。這種變化可能是必要的，但需要確保模型的更新是合理的。

機率性模型的挑戰

一些模型，如生成式AI，是機率性的，這使得檢查系統的健康狀態更加困難。以ChatGPT為例，相同的輸入可能會得到不同的輸出，這使得評估系統的可靠性變得更加複雜。

模型輸出的挑戰

概念漂移（concept drift）可能導致模型的輸出變得無關緊要。例如，稅法變更可能會影響稅務服務的行銷模型的有效性。

圖示：ChatGPT的非確定性輸出

此圖示展示了ChatGPT對相同輸入的不同回應，突顯了機率性模型的非確定性特性。

此圖示說明瞭簡化的機器學習系統架構及其各個階段之間的關係。

內容解密：

此圖表展示了一個簡化的機器學習系統流程，包括輸入資料、模型處理、模型輸出及後處理階段。輸入資料首先進入模型進行處理，然後產生模型輸出，最後經過後處理得到最終輸出。每個階段都至關重要，並直接影響最終輸出的品質和可靠性。圖表中每個節點代表一個關鍵階段，並透過箭頭表示資料的流動方向。這種視覺化表示有助於理解機器學習系統的工作流程，並強調了監控每個階段的重要性，以確保系統的整體穩定性和可靠性。

監控與可靠性：機器學習系統的關鍵要素

在機器學習（ML）系統的佈署和營運中，監控和可靠性是至關重要的組成部分。一個設計良好的監控系統能夠幫助我們及時發現並解決問題，從而確保ML系統的穩定執行和持續提供價值。

14.1 機器學習系統中的潛在問題

在機器學習系統的生命週期中，可能會出現各種問題，包括資料品質問題、模型效能下降、以及業務流程變化等。這些問題如果不及時發現和處理，可能會對業務造成嚴重影響。

14.1.4 後處理/決策制定

確保ML模型的品質與其預期提供的業務價值之間的比對是非常重要的。多種因素可能導致這種不比對，包括模型使用環境的變化以及模型使用方式的改變。

14.2 軟體系統健康

軟體後端是ML系統監控的基礎。監控軟體效能以確保其正常運作、有效執行任務以及快速回應請求是非常重要的。忽視軟體後端的穩定性和效能可能會對ML系統的整體效能產生不利影響。

監控指標

根據ML系統的佈署架構，可以監控多種指標，包括服務使用指標（如模型呼叫總次數、每秒請求數和錯誤率）、系統效能指標（如執行時間、延遲、冷啟動時間、錯誤率）和資源利用率指標（如記憶體和GPU/CPU利用率）。選擇少數關鍵指標來量化服務效能的不同方面是非常重要的。

事件和預測記錄

記錄事件和預測及其時間戳對於監控和除錯ML系統是非常重要的。建議記錄每次預測的資料，包括輸入特徵和模型輸出，以便追蹤模型的效能並識別可能出現的問題。

監控ML系統的核心元件

根據Elena Samuylova的文章，ML系統監控有四個核心元件，分別是軟體系統健康、資料品質和完整性、模型品質和相關性，以及業務關鍵績效指標（KPIs）。這些元件共同構成了ML系統監控的金字塔。

金字塔結構

1. 軟體系統健康：基礎層，關注軟體後端的穩定性和效能。
2. 資料品質和完整性：第二層，確保輸入資料的品質和完整性。
3. 模型品質和相關性：第三層，監控模型的效能和相關性。
4. 業務關鍵績效指標（KPIs）：頂層，關注ML系統對業務的影響。

透過監控這些核心元件，我們可以及時發現並解決問題，確保ML系統的穩定執行和持續提供價值。

ML 系統監控金字塔

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
skinparam arrow {
    color #262626
    thickness 2
}
skinparam package {
    borderColor #262626
    backgroundColor #F2F2F2
    fontColor #262626
}
skinparam component {
    borderColor #262626
    backgroundColor #FFFFFF
    fontColor #262626
}

title 機器學習系統整合與備援策略

actor "使用者/系統" as User

package "API 整合" {
    [HTTP API 處理] as HTTP_API
    [模型 API 封裝] as Model_API
    [JSON 請求/回應] as JSON_Format
}

package "核心預測流程" {
    [主要模型] as PrimaryModel
    
    package "自動切換機制" {
        [資料漂移偵測] as DriftDetection
        [品質問題監控] as QualityMonitor
    }
}

package "備援與覆寫" {
    package "多層備援策略" {
        [次要時序模型] as SecondaryModel
        [規則型備援] as RuleBasedFallback
    }
    
    package "覆寫機制" {
        [手動輸出調整] as ManualOverride
        [置信度門檻] as ConfidenceThreshold
    }
}

User -> HTTP_API : 請求
HTTP_API -> Model_API : 格式化請求
Model_API -> JSON_Format : 使用

Model_API -> DriftDetection
Model_API -> QualityMonitor

QualityMonitor --> PrimaryModel : 資料品質良好
DriftDetection --> PrimaryModel : 無漂移

PrimaryModel --> HTTP_API : 主要預測

QualityMonitor --[#red]> SecondaryModel : 資料品質問題
DriftDetection --[#red]> SecondaryModel : 偵測到漂移

SecondaryModel --> HTTP_API : 次要預測

SecondaryModel --[#red]> RuleBasedFallback : 次要模型失效
RuleBasedFallback --> HTTP_API : 規則型預測

Model_API -> ConfidenceThreshold
ConfidenceThreshold --[#orange]> ManualOverride : 低置信度
ManualOverride --> HTTP_API : 手動調整結果

@enduml

圖表說明

此圖示呈現了ML系統監控的金字塔結構，從基礎的軟體系統健康到頂層的業務關鍵績效指標（KPIs），每個層級都對於確保ML系統的穩定執行和持續提供價值至關重要。