本文介紹一個根據 GitLab Runner 和 Docker 的機器學習模型佈署管線，用於自動化模型佈署和應用程式交付。管線涵蓋安全測試、單元測試、程式碼風格檢查、模型取得、應用程式建構、測試、交付到 Harbour Docker 登入以及最終佈署等步驟。文章以根據 BERT 的預訓練語言模型為例，說明如何將模型封裝到 Docker 映像中，並透過 REST API 提供服務。此外，也說明瞭如何透過持續訓練和模型更新來提升模型在生產環境的可靠性和適應性，並強調與客戶溝通及收集使用者反饋的重要性，以解決實際應用中的挑戰並持續改進模型效能。
佈署管線
佈署管線負責將訓練好的模型佈署到生產環境中。這個過程包括將模型封裝到應用程式中，並提供給使用者。
佈署管線組態
佈署管線使用 Gitlab Runner 組態，包括以下工作：
- 模型佈署：將訓練好的模型佈署到生產環境中。
- 應用程式提供：提供封裝了模型的應用程式給使用者。
佈署管道
在模型訓練和評估完成後，模型的效能會被傳達給客戶。如果模型被批准佈署到生產環境，佈署管道會負責將模型封裝到應用程式的 Docker 映像中，並將應用程式映像儲存在 Harbour 登入中。模型會接收 GAEB 格式的檔案並輸出一組推薦的產品作為 CSV 檔案，透過 REST API 實作實時處理。
應用程式碼被管理在一個單獨的 GitLab 倉函式庫中，具有自己的 GitLab Runner 管道，即佈署管道。一旦程式碼被推播到 GitLab 倉函式庫，該管道就會經歷以下工作（參見圖 12.6；注意，前三個步驟與訓練管道中的相應步驟類別似，但著重於應用程式碼）：
- 安全測試：與訓練管道類別似，這個管道對應用程式碼進行安全測試，以確保機器學習應用程式及其依賴項免受潛在漏洞的影響。
- 單元測試：執行單元測試以驗證機器學習應用程式個別程式碼元件的功能，特別是當輸入預處理或輸出預處理步驟被更新時。
- 程式碼風格檢查：對程式碼進行風格檢查，以強制執行編碼標準並找出機器學習應用程式結構中的潛在問題。
- 取得選定的模型：為了將訓練好的機器學習模型從模型登入中轉移到機器學習應用程式中，管道會選擇最佳評估模型，並確保所有必要的模型依賴項（例如模型和資料組態檔案）被轉移（如果需要）。
- 建構應用程式：透過 Docker 建立一個可複製且隔離的環境來建構機器學習應用程式，包括其依賴項、機器學習模型和任何所需的組態檔案。
- 測試應用程式：在建構好的機器學習應用程式和 Docker 容器上執行全面測試，以驗證功能、效能和與生產環境的相容性。這些測試確保模型的回應性和整個應用程式的可用性，並包括錯誤處理以涵蓋輸入和輸出規格。
- 交付到 Harbour Docker 登入：一旦機器學習應用程式透過所有測試，管道就會將容器化的應用程式交付到 Docker 登入中，以便佈署到生產環境。
- 應用程式佈署：最後，應用程式會被佈署到生產環境。雖然技術上可以使用管道自動佈署應用程式，但根據客戶的偏好，這一步驟是手動實施的。
機器學習解決方案
Fraunhofer 的建模團隊選擇了一個更複雜的模型來取代簡單模型，具體為根據 BERT 的預先訓練語言模型，並對其進行了修改，以便對大型文字進行順序預測。目的是為了減輕簡單模型的弱點，例如建議顏色不協調或來自不同供應商的產品。基礎模型是一個大型德國 BERT 模型，可以從 Hugging Face 模型中心下載。這個模型導致了效能的顯著提高。
該模型得到了玄貓的補充。新的系統滿足了玄貓設定的標準。實施階段被分成兩個建模迭代，伴隨著對建模結果的中間反饋。建模工作得到了玄貓的支援，例如建立可重複使用的建模和佈署管道，以便於重新訓練。值得注意的是，實作所需機器學習解決方案（即模型和相關應用程式）的過程是在圖 1.4 中展示的環境中進行的。最初，期望的模型是在開發環境中探索的。然後，在構建測試環境中進行訓練，在那裡訓練管道處理自動訓練。在訓練完成且模型獲得批准後，佈署管道就會執行，如佈署管道部分所述。然後，生成的應用程式被容器化並儲存在容器登入中。最後，應用程式映像從登入中手動提取並推播到客戶的目標環境。
圖表翻譯
graph LR
A[開始] --> B[安全測試]
B --> C[單元測試]
C --> D[程式碼風格檢查]
D --> E[取得選定的模型]
E --> F[建構應用程式]
F --> G[測試應用程式]
G --> H[交付到Harbour Docker登入]
H --> I[應用程式佈署]
I --> J[結束]
圖表翻譯：
此圖表描述了佈署管道的各個步驟，由安全測試開始，一直到應用程式佈署結束。每一步驟都與前一節中描述的過程相對應。
實施階段結果
實施階段已經成功完成，解決方案已經整合到客戶端並投入生產使用。最終模型在實驗中達到了 0.49 的微 F1 評分和 0.71 的準確率，在員工評估中表現出色。功能性正確的推薦數量，即正確的產品型別但錯誤的屬性（如顏色），甚至更高，表明著重於正確的產品組態有很大的潛力進一步提高模型效能。結果符合玄貓最初設定的成功標準。客戶要求弗勞恩霍夫公司進入生產階段，以便在定期間隔內重新訓練模型。有關此事的詳細資訊將在下一節中提供。
生產階段
成功佈署機器學習應用程式後，下一個階段涉及在營運階段管理應用程式。具體而言，必須保證應用程式按照預期執行，並能夠實作其預先定義的目標，以支援招標過程。
在這個階段，我們深入探討 MLOps 迴圈的第七個方面，即溝通，如 MLOps 方法和技術架構部分所述。建立開發工程師和客戶之間的有效溝通對於協調後續評估 ML 應用程式的技術效能和從員工那裡收集反饋至關重要。這種持續的互動為明智的決策和持續改進奠定了基礎。
與任何機器學習系統一樣，現實世界的動態性會引入變化，影響資料和模型的效能。因此，持續和主動的溝通和協調在各利益相關者之間對於解決和減輕模型效能漂移至關重要。在這個背景下，確保產品招標推薦的準確性至關重要，需要與當前的業務狀態保持一致。
這種方法與確保 ML 應用程式在現實世界中執行的可信度的基本概念密切相關。透過玄貓的觀點，這種方法強調了持續改進和溝通在保持 ML 應用程式效能和可信度方面的重要性。
機器學習模型的可靠性與適應性
在實際應用中，維護機器學習模型的可靠性和適應性至關重要。這需要不斷監控模型的效能，並根據使用者的反饋進行調整和改進。透過這種方式，可以確保模型在面對實際世界的變化時保持其有效性和準確性。
持續訓練和模型更新
現代機器學習模型提供了重新訓練和更新的能力，這使得模型可以根據新的資料和需求進行調整。這個過程可以透過修改訓練和佈署管道中的組態來實作，從而實作模型的無縫更新和調整。
生產階段的挑戰和改進
在生產階段，員工的反饋表明，模型的整體建議是正面的，但模型經常在沒有合適的產品時進行建議。為瞭解決這個問題，模型被重新訓練，以學習何時不建議任何產品。這次更新提高了模型的品質，並交付給客戶。
生產階段的結果
生產階段突出了在生產環境中使用模型的挑戰。員工的反饋顯示，儘管模型在指標上表現良好，但它缺乏判斷何時沒有合適產品的能力。員工的見解導致了改進模型的實施，從而緩解了這些問題。
從商業價值視角來看，這次根據 BERT 模型的產品推薦系統佈署，成功地驗證了機器學習技術驅動商業流程最佳化的可行性。透過多維度效能指標的實測分析，新模型的微 F1 評分和準確率顯著提升，展現了其在提升招標效率和準確性方面的潛力。然而，技術限制深析顯示，初期模型未能有效處理「無合適產品」的場景，突顯了實務落地過程中，使用者經驗反饋的重要性。整合使用者回饋後重新訓練的模型，則有效地解決了此問題，提升了整體商業價值。隨著模型持續學習和迭代，預期能更精準地捕捉市場需求，甚至預測潛在商機。玄貓認為，持續整合使用者回饋、迭代最佳化模型，並密切關注市場動態，是將此技術優勢最大化的關鍵。
