這個機器學習系統參考架構包含開發、測試和生產環境，並利用容器技術和版本控制系統管理程式碼。資料層則負責資料的準備和儲存，確保模型訓練和佈署的順暢。我們負責後端開發，客戶負責與非 AI 服務的整合，因此我們的服務必須符合功能和品質要求。本專案將任務建模為多類別分類別問題，每個檔案包含多個位置和產品集。早期模型迭代中，每個位置單獨用於推薦，後來使用序列模型確保推薦一致性。模型選擇從易於訓練的 FastText 開始，接著根據效能和需求，考慮使用更複雜的 BERT 模型，並提供推薦的置信度。
在專案合作方面，我們與客戶保持密切溝通，並納入不同層級的利益關係人，例如決策者、業務單位負責人、員工等，以確保專案方向與需求一致。在試點階段 (POC)，我們與客戶多次開會，確保新方法解決了先前試點的問題，並與員工舉辦工作坊，共同制定試點目標和方法。技術實施上，我們使用 Jupyter Notebook 和 Python 指令碼進行資料預處理和模型建構，並專注於需求分析、資料探索和專案資料階段。
在實證證明階段，我們以開發最小可行模型 (MVP) 為目標，並將使用案例視為分類別問題，其中類別標籤為一起銷售的產品包。客戶強調準確度優先於召回率，因此我們選擇了根據分散式嵌入的簡單模型，並使用 Docker 容器化技術簡化佈署和測試流程。評估階段包含量化評估（使用保留測試集計算準確度、召回率和 F1 分數）和質性評估（手動調查模型結果）。最終，實證證明階段成功展示了機器學習模型的潛力，並為後續實施奠定了基礎。
實作機器學習系統的參考架構
在實作機器學習（ML）系統時，我們通常會遵循一個參考架構，以確保系統的可靠性、可擴充套件性和易維護性。這個架構包括三個主要環境：開發環境、測試環境和生產環境。在這些環境之上，我們還有程式碼倉函式庫和容器，用於儲存和管理程式碼。底層的資料層則負責資料的準備和儲存。
在我們的案例研究中，系統的後端部分是由我們負責開發的，而與非 AI 服務元件的整合則是客戶的責任。因此，我們的服務必須滿足功能和品質要求，以便能夠無縫地整合到更大的系統中。
這個參考架構可以根據具體專案的需求，使用適合的工具和框架來實作。在下面的章節中，我們將詳細介紹如何設定和執行我們的專案，包括工具和框架的選擇。
機器學習解決方案的設定
我們的任務被建模為一個多類別分類別問題。每個檔案包含多個位置，每個位置都被分配了一個產品集。在早期的模型迭代中，每個位置都被單獨用於推薦，而後來我們使用了一個序列模型，該模型在位置之間傳遞資訊，以確保推薦的一致性，例如顏色和產品品牌的一致性。
我們從一個根據分散式嵌入的模型（如 FastText）開始，這種模型易於訓練，需要的資源較少，可以作為一個強大的基線。當我們看到這個模型表現出良好的效能，但仍有很大的改進空間時，我們轉向了根據 BERT 的更複雜的模型。BERT 模型是在大量文字上預訓練的，可以透過少量註解樣本對其進行微調。這些模型的一個優點是，它們為使用者提供了推薦的置信度值，使得識別對模型具有挑戰性的資料點變得更容易。
我們決定從易於實作的模型開始，這些模型可以給客戶一個早期的指標，表明他們的使用案例是否可以被解決，然後根據評估結果和反饋，在需要時增加模型的複雜度。通常，這些低資源方法需要更多的註解訓練資料，但是資料可用性並不是本專案的一個挑戰，特別是因為我們選擇先處理最常銷售的產品。
生成式 LLM 的考慮
生成式大語言模型（LLM）並未被使用，原因有幾點。一方面，在專案期間，沒有適合的開源模型可用，而雲端託管模型則被排除在外。此外，由於標籤空間較大，需要可擴充套件性，並且需要為每個推薦獲得置信度，小型編碼器基礎模型被優先於 LLM。然而，自專案結束以來，已經出現了小型開源 LLM，它們可能是替代我們當前模型的一種可行選擇，並且可以約束其預測/推薦的輸出以適應特定類別，甚至可以從中獲得置信度。一般而言，LLM 還具有許多優點，例如需要很少甚至不需要註解訓練資料，因此在處理自然語言處理（NLP）專案時應該被考慮。但是，它們也帶來了一些挑戰。
內容解密：
在實作機器學習系統時，選擇合適的架構和工具至關重要。透過遵循一個參考架構，我們可以確保系統的可靠性、可擴充套件性和易維護性。在具體實作中，我們需要根據專案需求選擇合適的工具和框架，並根據評估結果和反饋不斷調整和改進模型，以達到最佳效能。同時，也需要考慮到不同型別模型的優缺點，例如生成式 LLM，來選擇最適合專案需求的解決方案。
圖表翻譯：
graph LR
A[開發環境] --> B[測試環境]
B --> C[生產環境]
C --> D[資料層]
D --> E[程式碼倉函式庫]
E --> F[容器]
此圖表描述了機器學習系統的參考架構，包括開發環境、測試環境、生產環境、資料層、程式碼倉函式庫和容器。每個部分都在系統中扮演著重要角色，以確保機器學習模型從開發到佈署的過程順暢高效。
專案合作與實施
在人工智慧（AI）和機器學習（ML）專案中，合作與溝通是成功的關鍵。以下是對於一個成功的 AI 專案的描述，包括其挑戰、需求和實施過程。
合作與溝通
在整個專案過程中，客戶方的利益相關者都被充分納入其中。這包括決策者、業務單位負責人、專案負責人、員工（最終使用者）以及 IT 專業人員。員工的參與尤其重要，因為他們提供了有關資料的寶貴見解，幫助做出模型決策，並定期反饋模型輸出的意見。業務單位負責人和決策者則被定期更新專案進展，以便進行期望管理和根據業務目標優先安排下一步驟。
試點階段
試點階段（POC）是專案的關鍵部分。在這一階段，客戶和合作夥伴進行了多次會議，以確保新的方法與之前未成功的試點有明顯的不同，並且之前的問題已經被解決。客戶分享了一部分資料以進行初步調查，並分享了之前試點的經驗和結果。與將使用應用程式的員工一起舉行了一個工作坊，以共同確定試點的目標和方法。
在試點實施階段，主要關注的是機器學習營運（MLOps）迴圈中的需求分析、探索和專案資料階段。由於這一階段的主要目的是分析是否可以使用機器學習解決方案以足夠的品質來解決使用案例及其所有需求，因此尚未建立完整的 MLOps 設定。從技術角度來看，主要執行的是資料預處理和建模任務。這些任務是在開發環境的早期版本中完成的，使用 Jupyter 筆記本和 Python 指令碼。
技術實施
在技術實施方面，使用了 Jupyter 筆記本和 Python 指令碼來進行資料預處理和建模任務。這些工具使得團隊能夠快速地探索資料、開發和測試模型，並與客戶方利益相關者進行溝通和合作。
內容解密：
上述過程中，團隊使用了什麼工具和技術來實施試點階段？為什麼選擇這些工具？
答案：團隊使用了 Jupyter 筆記本和 Python 指令碼來實施試點階段。這些工具被選擇因為它們能夠提供快速的資料探索、開發和測試模型的能力，並且能夠方便地與客戶方利益相關者進行溝通和合作。
圖表翻譯：
flowchart TD
A[客戶需求] --> B[資料探索]
B --> C[模型開發]
C --> D[模型測試]
D --> E[結果反饋]
此圖表示了試點階段中從客戶需求到結果反饋的流程。客戶需求被轉化為資料探索，然後是模型開發，接著是模型測試，最後是結果反饋給客戶方利益相關者。
機器學習模型的實證證明
在實證證明（PoC）階段，我們的目標是開發一個最小可行模型（MVP），即一個能夠展示特定子資料集和標籤上達到一定品質推薦的模型。為了達到這個目標，我們將使用案例視為一個分類別問題，其中類別標籤是指一起銷售的產品包。為了簡化問題，我們選擇了一個只有幾千個產品的子集。
客戶強調了準確度優先於召回率的重要性，因為他們希望模型在推薦時能夠有很高的確信度，即使這意味著不能包括所有產品在內。實證證明的大部分工作都花在了正確解析和預處理給定的「GAEB」格式的招標文字上。為了初步實驗，我們選擇了一個根據分散式嵌入的簡單模型，後來證明這個模型足夠令人信服，以說服客戶進入實施階段。
在實證證明階段期間和之後，客戶和弗勞恩霍夫研究所保持密切聯絡，定期分享有關模型結果的見解。這導致了一份優先改進事項清單，弗勞恩霍夫研究所應該在實施階段解決。為了簡化佈署和測試過程，我們使用了根據 Docker 的虛擬化技術。Docker 容器化提供了許多益處，包括高可攜性、簡化依賴管理以及易於擴充套件。
實證證明評估與結果
實證證明階段成功完成。弗勞恩霍夫研究所進行了量化和質性評估。量化評估使用了一個保留的測試集，具有已知的正確產品集分配。透過將模型應用於此測試集，計算了準確度、召回率和 F1 分數，以估計模型的效能。
作為質性評估的一部分，弗勞恩霍夫研究所和客戶手動調查了模型結果在一個額外的資料集上。這些結果表明，模型在準確度和相關性方面表現出色，從而說服客戶進入實施階段。整體而言，實證證明階段展示了機器學習模型在解決複雜推薦問題方面的潛力，並為未來的實施奠定了堅實的基礎。
圖表翻譯：
graph LR
A[實證證明階段] --> B[資料預處理]
B --> C[模型訓練]
C --> D[模型評估]
D --> E[結果分析]
E --> F[實施階段]
內容解密：
上述流程圖描述了實證證明階段的主要步驟，從資料預處理到模型評估和結果分析。每一步驟都對整體過程至關重要，保證了最終模型的準確性和有效性。在這個過程中，我們使用 Docker 容器化技術來簡化佈署和測試，從而提高了整體效率和可靠性。
從商業價值視角來看，本篇探討的機器學習系統參考架構，在實務落地過程中展現了其顯著的效益。透過將機器學習模型的開發流程拆分為開發、測試和生產三個環境，並輔以容器化技術和版本控制，有效提升了模型開發的效率和可靠性。分析顯示，這種架構能有效降低技術債務，並提升系統的可維護性，尤其在與客戶協作開發的場景下，更能體現其價值。然而，此架構的實施仍需考量企業現有的 IT 基礎設施和技術能力，並非所有企業都能立即套用。技術團隊應著重於資料層的建置和 MLOps 流程的整合，才能最大化發揮此架構的優勢。玄貓認為，隨著機器學習應用日趨普及，此類別參考架構將成為企業構建 AI 能力的根本，值得企業及早規劃與匯入。
