模型部署模式

本文說明透過預備和進入生產環境移動 ML 成品的兩種常見模式。 模型和程式碼變更的非同步本質表示 ML 開發程式可能遵循的多個可能模式。

模型是由程式碼所建立,但產生的模型成品和建立模型的程式碼可以非同步作業。 也就是說,新的模型版本和程式碼變更可能不會同時發生。 例如,請考慮下列案例:

  • 若要偵測詐騙交易,您可以開發每週重新定型模型的 ML 管線。 程式碼可能不會非常頻繁地變更,但模型每週可能會重新定型,以納入新的資料。
  • 您可以建立大型的深度神經網路來分類檔。 在此情況下,定型模型的成本很高且耗時,而且重新定型模型可能不常發生。 不過,部署、服務及監視此模型的程式碼可以更新,而不需重新定型模型。

部署模式

這兩種模式的差異在於 模型成品產生模型成品的定型程式碼 會升階至生產環境。

在大部分情況下,Databricks 建議使用「部署程式碼」方法。 此方法會併入 建議的 MLOps 工作流程中。

在此模式中,用於定型模型的程式碼是在開發環境中開發。 相同的程式碼會移至預備環境,然後移至生產環境。 模型會在每個環境中定型:一開始在開發環境中作為模型開發的一部分、暫存 (在整合測試中有限子集的資料) ,以及在生產環境中 (完整生產資料) 產生最終模型。

優勢:

  • 在限制存取生產資料的組織中,此模式可讓模型在生產環境中的生產資料上定型。
  • 自動化模型重新定型更安全,因為定型程式碼已檢閱、測試及核准生產環境。
  • 支援程式碼遵循與模型定型程式碼相同的模式。 這兩者都會經歷預備中的整合測試。

缺點:

  • 資料科學家將程式碼交給共同作業者的學習曲線可能很困難。 預先定義的專案範本和工作流程很有説明。

此外,在此模式中,資料科學家必須能夠檢閱生產環境中的定型結果,因為他們具備識別和修正 ML 特定問題的知識。

如果您的情況需要在完整生產資料集的預備環境中定型模型,您可以藉由將程式碼部署至預備、定型模型,然後將模型部署至生產環境,來使用混合式方法。 這種方法可節省生產中的定型成本,但會在預備環境中增加額外的作業成本。

部署模型

在此模式中,模型成品是由開發環境中的定型程式碼所產生。 成品會在預備環境中進行測試,再部署到生產環境。

如果適用下列一或多個選項,可以考慮此選項:

  • 模型定型非常昂貴或難以重現。
  • 所有工作都是在單一 Azure Databricks 工作區中完成。
  • 您無法使用外部存放庫或 CI/CD 程式。

優勢:

  • 資料科學家的簡單交接
  • 如果模型定型成本很高,只需要定型模型一次。

缺點:

  • 如果無法從開發環境存取生產資料, (可能基於安全性考慮) ,此架構可能無法運作。
  • 自動化模型重新定型在此模式中很棘手。 您可以在開發環境中自動重新定型,但負責在生產環境中部署模型的小組可能不會接受產生的模型作為生產就緒。
  • 支援程式碼,例如用於特徵工程、推斷和監視的管線,必須分別部署到生產環境。

下圖對比上述部署模式在不同執行環境中的程式碼生命週期。

圖表中顯示的環境是執行步驟的最後一個環境。 例如,在部署模型模式中,最終單元和整合測試會在開發環境中執行。 在部署程式碼模式中,單元測試和整合測試會在開發環境中執行,而最終單元和整合測試會在預備環境中執行。

部署模式生命週期