機器學(xué)習(xí)算法和架構(gòu)在 MLOps 框架下的工程實踐

本文主要介紹機器學(xué)習(xí)（以下簡寫為ML）算法和架構(gòu)在MLOps框架下的工程實踐。

當(dāng)從業(yè)者具備了足夠豐富的知識儲備時，就可以開始嘗試ML了。

通常情況下，ML實踐會涉及研究和生產(chǎn)兩個主要環(huán)境。

• 研究環(huán)境可以在本地計算機或工作站上，這通常是為了進(jìn)行小規(guī)模的模型分析和探索。

• 生產(chǎn)環(huán)境是模型投產(chǎn)的環(huán)境，ML在生產(chǎn)環(huán)境中通常需要相對長期的持續(xù)運行，生產(chǎn)環(huán)境中的任務(wù)一般需要自動化和持續(xù)迭代。

下面舉個僅需要在研究環(huán)境中進(jìn)行數(shù)據(jù)分析或建模即可滿足需求的例子，即在文章標(biāo)題中找到與較高點擊率相關(guān)的關(guān)鍵詞。數(shù)據(jù)分析師的交付方式可能是將探索出的規(guī)律和結(jié)論報告給一個運營團隊，這樣運營人員就可以在新的標(biāo)題中嘗試使用探索出的規(guī)律和結(jié)論來提高點擊率。

再舉一個數(shù)據(jù)分析和建模需要在研究環(huán)境中完成而建模結(jié)果需要在生產(chǎn)環(huán)境中發(fā)布的例子，該情況下的模型需要不斷迭代，比如在電商網(wǎng)站上運行的推薦模型。在生產(chǎn)環(huán)境中運行的模型會涉及后續(xù)的管理和運維，當(dāng)運行中出現(xiàn)異?；蚰Ｐ退ネ藭r，需要通過監(jiān)控機制發(fā)出預(yù)警信號。

這兩類環(huán)境對從業(yè)者的要求很不相同。大多數(shù)初級ML圖書講述的是研究環(huán)境中的ML，很少會涉及生產(chǎn)環(huán)境中的ML。

一般來說，一個完備的ML項目的工作流程是，先在研究環(huán)境中探索和開發(fā)ML模型，制作一個ML應(yīng)用程序的原型，然后符合預(yù)期的模型會被推送到生產(chǎn)環(huán)境，進(jìn)行自動化部署和監(jiān)控。開發(fā)一個用于生產(chǎn)環(huán)境的ML應(yīng)用程序的工作比分析、探索的工作要復(fù)雜得多，需要把在研究環(huán)境中運行的ML作業(yè)轉(zhuǎn)換成能在生產(chǎn)環(huán)境中自動運行的作業(yè)，我們通常把這一過程稱為ML的生產(chǎn)化或工程化。

回顧前面ML的定義，從廣義上講，ML是一門通過算法和統(tǒng)計模型從數(shù)據(jù)中學(xué)習(xí)知識的學(xué)科，ML工程顧名思義就是構(gòu)建基于ML的應(yīng)用程序的計算實踐。

ML工程是建立在ML的工作基礎(chǔ)上并將研究環(huán)境中開發(fā)的ML模型應(yīng)用于生產(chǎn)環(huán)境的技術(shù)。ML工程與ML的區(qū)別在于側(cè)重點不同，ML更關(guān)心算法的優(yōu)化和模型的訓(xùn)練，ML工程則更關(guān)心從不同業(yè)務(wù)系統(tǒng)采集數(shù)據(jù)，并訓(xùn)練一個兼顧模型性能和計算性能的模型，使其能在生產(chǎn)環(huán)境中穩(wěn)定運行，保證模型的可監(jiān)控、可維護、可更新、可被業(yè)務(wù)系統(tǒng)使用，為模型生產(chǎn)化提供工程保障。

ML工程包括從數(shù)據(jù)收集、特征工程、模型訓(xùn)練到模型投入應(yīng)用、管理和運維的所有階段。這個過程與高中時期考試的不同階段類似，ML開發(fā)過程相當(dāng)于平時的?？?，關(guān)心的是對知識點的消化和總結(jié)，ML工程相當(dāng)于高考，在兼顧平時模考習(xí)得的知識點的同時，還需要綜合考察實考環(huán)境下的心理壓力、時間分配、考題內(nèi)容等因素。

事實上，數(shù)據(jù)科學(xué)團隊通常專注于研究新穎的算法或訓(xùn)練高精準(zhǔn)的模型，但與實際ML項目中需要的全流程（如特征工程、部署、監(jiān)控等）相比，ML算法只是ML項目非常小的一部分，一個真正要投產(chǎn)的ML項目通常需要大量的工程工作和基礎(chǔ)設(shè)施的配合，以實現(xiàn)ML模型在生產(chǎn)環(huán)境中順利運行。

2015年，谷歌發(fā)布的論文指出，為了避免無休止的“技術(shù)債”纏身，應(yīng)該強調(diào)將ML生產(chǎn)化視為一門學(xué)科的重要性（在當(dāng)前的ML技術(shù)主流中確實如此），通過加強工程技術(shù)的投入來順利實現(xiàn)ML的生產(chǎn)化。如圖1所示，ML模型的生產(chǎn)化是由多個模塊組成的，在實際場景中需要在這些模塊間建立溝通機制來配合完成ML模型的生產(chǎn)化。

圖1  ML生產(chǎn)化模塊

機器學(xué)習(xí)工程模塊的設(shè)計原則

關(guān)注點分離（SoC）是一個可行的設(shè)計原則，指的是計算機科學(xué)中對應(yīng)用程序、代碼塊和其他對象系統(tǒng)進(jìn)行劃分的方式，關(guān)注點被“分離”的程度因系統(tǒng)而異。比如，一個存在相互依存關(guān)系的系統(tǒng)一般是關(guān)注點的弱分離，簡稱弱分離；而一個可以完全獨立負(fù)責(zé)自己工作的系統(tǒng)或模塊，一般認(rèn)為是關(guān)注點的強分離，簡稱強分離。

ML 工程模塊的設(shè)計既可以使用弱分離的設(shè)計原則，也可以使用強分離的設(shè)計原則。在弱分離的設(shè)計原則下，訓(xùn)練和預(yù)測必須在同一臺服務(wù)器上運行，訓(xùn)練步驟和預(yù)測步驟被捆綁在同一個模塊中。比如，在輸入數(shù)據(jù)上調(diào)用一個名為train的函數(shù)，該函數(shù)返回一個模型，該模型會作為predict函數(shù)的輸入，在運行時會按順序依次執(zhí)行train和predict函數(shù)。而在強分離的設(shè)計原則下，訓(xùn)練和預(yù)測可以在兩個不同的服務(wù)器或進(jìn)程中運行。在這種情況下，訓(xùn)練和預(yù)測是相互獨立發(fā)生的，訓(xùn)練步驟和預(yù)測步驟分別歸屬不同的模塊。

一般來說，面向服務(wù)的架構(gòu)（SOA）是符合強分離設(shè)計原則的，我們認(rèn)為在生產(chǎn)場景下使用SOA來設(shè)計和開發(fā)ML系統(tǒng)是可行的。

此外，無論是設(shè)計MLOps平臺還是傳統(tǒng)的ML系統(tǒng)，建議在設(shè)計時考慮以下幾項關(guān)鍵原則。

• 從一開始就為可重復(fù)性而構(gòu)建：保留所有模型的輸入和輸出，以及所有相關(guān)元數(shù)據(jù)，如配置信息、依賴項、操作時間戳等。注意版本控制，包括所用的訓(xùn)練數(shù)據(jù)。

• 將ML過程中的不同管道視為系統(tǒng)的一部分：如特征工程、自動化訓(xùn)練、模型部署和發(fā)布等。

• 提前考慮可擴展性：如果系統(tǒng)需要定期更新模型，則需要在設(shè)計系統(tǒng)的時候就仔細(xì)考慮如何做到這一點。

• 模塊化：盡可能地對ML生命周期的各個環(huán)節(jié)進(jìn)行模塊化，這會極大地提高系統(tǒng)的復(fù)用性。

• 測試：需要預(yù)留一定的時間來測試ML的應(yīng)用程序，包括模型、數(shù)據(jù)及代碼等不同類型實例的測試。

進(jìn)行機器學(xué)習(xí)工程的模塊設(shè)計時需要注意的細(xì)節(jié)

設(shè)計架構(gòu)和模塊的出發(fā)點應(yīng)該是滿足業(yè)務(wù)需求和公司更長遠(yuǎn)的目標(biāo)。在開始設(shè)計和使用最新技術(shù)之前，需要了解現(xiàn)有條件的限制、預(yù)期會創(chuàng)造的價值及在為誰創(chuàng)造價值等，需要考慮當(dāng)前公司的業(yè)務(wù)場景及未來可能會新增的場景。比如，在現(xiàn)有的業(yè)務(wù)場景下是否需要提供實時預(yù)測？如果需要實時預(yù)測，那么業(yè)務(wù)側(cè)允許的延遲是毫秒級的還是秒級的，又或者只需在接收輸入數(shù)據(jù)后的30分鐘或一天內(nèi)交付預(yù)測結(jié)果就能滿足需求。

具體地，以下幾個細(xì)節(jié)值得考慮。

• 針對公司業(yè)務(wù)，希望多久更新一次模型？

• 預(yù)測的需求（流量）是什么？

• 需要處理多大量級的數(shù)據(jù)？

• 希望使用哪些算法？比如，是否會使用深度網(wǎng)絡(luò)類的算法（需要評估是否真的需要）？

• 是否處在一個對系統(tǒng)審計要求非常高的監(jiān)管環(huán)境中？

• 當(dāng)前要設(shè)計的ML系統(tǒng)是在之前的基礎(chǔ)上升級的還是重構(gòu)的？

• 當(dāng)前的工程團隊有多大？是否包含了數(shù)據(jù)科學(xué)家、ML工程師及DevOps工程師等？當(dāng)前團隊是否有開發(fā)ML系統(tǒng)的經(jīng)驗？

一旦團隊對這些基礎(chǔ)問題進(jìn)行了評估，便可以在此基礎(chǔ)上考慮ML系統(tǒng)的一些高級體系結(jié)構(gòu)選項，比如，打造獨立的模型訓(xùn)練系統(tǒng)、模型服務(wù)系統(tǒng)，抑或全流程的MLOps平臺。

需要注意的是，為了避免從業(yè)者在使用上混淆“系統(tǒng)”和“平臺”，這里對二者的定義進(jìn)行說明。

系統(tǒng)通常指的是一個具體的軟件，而平臺則是指進(jìn)行某項工作所需的信息化環(huán)境或條件，是一個相對抽象的生態(tài)環(huán)境。系統(tǒng)強調(diào)的是功能，平臺側(cè)重的是場景。系統(tǒng)有明確的輸入、處理過程和輸出，而平臺則是基于同一套規(guī)則和體系，由多個主體共同參與的生態(tài)圈，這套規(guī)則和體系往往是由系統(tǒng)組成的。

編碼環(huán)境與模型探索

如果數(shù)據(jù)科學(xué)家在研究環(huán)境中使用的編程語言與生產(chǎn)環(huán)境中的一致，那么整個工作流程的處理會輕松一些，這里涉及的編程語言通常是Python語言，因為它擁有豐富的關(guān)于數(shù)據(jù)科學(xué)和數(shù)據(jù)處理的開源代碼和包。然而，如果運行速度是一個要考慮的選項，那么Python語言可能是不可行的（盡管有很多種方法可以幫助其進(jìn)一步優(yōu)化運行速度）。

出于性能的考慮，何時進(jìn)行語言的轉(zhuǎn)換變得格外重要，因為研究團隊和生產(chǎn)團隊之間的額外溝通成本將會成為一個很大的負(fù)擔(dān)。當(dāng)然，如果你周圍所有的數(shù)據(jù)科學(xué)家都精通Scala、Java或C++語言，那么這個問題就變得簡單多了。

當(dāng)然，不同的角色可能會使用不同的工具或編程語言，沒有一個工具可以涵蓋所有任務(wù)，更重要的是，單個任務(wù)通常需要多個角色和多個工具來協(xié)作實現(xiàn)。以分析工程師、數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師為例，如圖2所示，數(shù)據(jù)工程師可能會使用IntelliJ中的Scala創(chuàng)建包含數(shù)億個事件的數(shù)據(jù)集的聚合，分析工程師可能會在相關(guān)業(yè)務(wù)的分析報告中使用SQL和Tableau對該聚合進(jìn)行分析和可視化，而數(shù)據(jù)科學(xué)家可能會使用Python處理該聚合并參考分析工程師的分析結(jié)果進(jìn)行線上營銷模型的構(gòu)建。

圖2  工具和編程語言偏好因角色而異的示例

從表面上看，這三種角色的工作流程看似不同，但其實他們的工作內(nèi)容通常是互補的，不同角色所負(fù)責(zé)的工作流程中的任務(wù)也會有重疊，為了進(jìn)一步促進(jìn)團隊間合作，我們希望盡可能減少平臺需要支持的工具的數(shù)量，在這些工具和語言的上層添加一層抽象，以提供跨工具和編程語言的通用模式，這也是MLOps的理念。

幸運的是，有一個開源項目Jupyter（該項目也是當(dāng)前數(shù)據(jù)科學(xué)家最常用的開源項目之一）的設(shè)計做到了這一點。當(dāng)前市面上很多專攻MLOps領(lǐng)域的公司都是使用Jupyter來提供建?；蚍治霏h(huán)境的，如cnvrg.io、Domino Data Lab、InfuseAI等。其中InfuseAI公司旗下的PrimeHub平臺最初就是從提供在線Jupyter建模環(huán)境開始的，后來才慢慢增加了模型部署和管理等功能，并逐步擴展成為MLOps平臺。

Jupyter提供了一個標(biāo)準(zhǔn)的消息傳遞API協(xié)議與充當(dāng)計算引擎的內(nèi)核進(jìn)行通信，該協(xié)議啟用了一個可組合的架構(gòu)，將編寫代碼內(nèi)容的位置（UI）和執(zhí)行代碼的位置（內(nèi)核）分開。通過將運行時與UI界面隔離（實際上MLOps的設(shè)計也借鑒了類似的思路），Jupyter可以跨越多種編程語言，同時保持執(zhí)行環(huán)境配置方式的靈活性。

具體地，隨著新的ML開發(fā)框架不斷興起并取代傳統(tǒng)工具，不建議對MLOps平臺支持的語言或框架制定限制性的標(biāo)準(zhǔn)。MLOps平臺的設(shè)計應(yīng)該足夠靈活并模塊化，以支持添加新框架，比如，需要能夠隨意加載TensorFlow、PyTorch和Scikit-Learn這些數(shù)據(jù)科學(xué)家必備的工具或框架。不過在MLOps框架內(nèi)搭建Jupyter環(huán)境時要注意一點，需要按用戶或項目生成隔離空間，比如，將新增的Jupyter服務(wù)創(chuàng)建在Python的虛擬環(huán)境中，或者使用容器進(jìn)行創(chuàng)建，因為不同的項目或不同的用戶可能會使用不同版本的ML工具或框架。

當(dāng)我們準(zhǔn)備開發(fā)一個可能在生產(chǎn)中運行的ML原型時，我們喜歡使用一些可視化的開發(fā)工具，如Jupyter。從業(yè)者可以在Jupyter中編寫代碼的同時撰寫模型說明和數(shù)據(jù)探索的結(jié)論。

與使用開發(fā)工具或老式的文本編輯器和Shell終端相比，Jupyter的關(guān)鍵優(yōu)勢在于，它提供了數(shù)據(jù)可視化的功能，可以在線顯示分析圖，為待打印的數(shù)據(jù)框架提供良好的顯示格式，如圖3所示。這使得開發(fā)者在寫腳本的時候可以很容易地檢查中間結(jié)果，這種方式比把輸出內(nèi)容打印到終端或在斷點處檢查變量更直觀、高效。

圖3  Jupyter Notebook中數(shù)據(jù)幀的基礎(chǔ)可視化

數(shù)據(jù)探索是任何ML項目的第一個具體的、手動的步驟，通常也是從業(yè)者最熟悉的步驟。但當(dāng)將一個ML項目推進(jìn)到產(chǎn)品化階段時，往往會產(chǎn)生認(rèn)知偏差，因為這兩個階段需要不同的工具和思維方式。

沒有數(shù)據(jù)就沒有模型，所以數(shù)據(jù)探索很自然地應(yīng)先于模型探索。數(shù)據(jù)探索的目的是理解數(shù)據(jù)。準(zhǔn)備數(shù)據(jù)的時候使用的原始數(shù)據(jù)通常是以表格的形式保存的，這時無法直接對數(shù)據(jù)進(jìn)行探索，因為一個可能有百萬行數(shù)據(jù)的表格并不是人類可以理解數(shù)據(jù)的最佳界面。我們擅長的是用形狀、尺寸和顏色等來理解事物。為了理解單個變量的屬性及多個變量間的關(guān)系，人們需要借助工具。理解數(shù)據(jù)時可以使用特征工程技術(shù)將數(shù)據(jù)轉(zhuǎn)換和處理為更高層次的特征，這些特征在模型探索步驟中將會起到關(guān)鍵作用。

模型探索可以與數(shù)據(jù)探索重疊，但也可以認(rèn)為它是一個獨立的步驟。在模型探索步驟中，數(shù)據(jù)科學(xué)家會分析和評估不同模型的可行性，如評估使用回歸、決策樹或隨機森林等算法在現(xiàn)有數(shù)據(jù)上的表現(xiàn)。

在技術(shù)層面，模型探索比數(shù)據(jù)探索有更高的要求。模型探索時經(jīng)常使用Jupyter，數(shù)據(jù)探索通?？梢栽诒镜豃upyter環(huán)境中完成，而模型探索步驟一般有更高的計算要求。用一組參數(shù)和數(shù)據(jù)測試一個模型的表現(xiàn)，有時需要幾個小時，甚至幾天，一個可自動擴展的云環(huán)境可能會成為合理的選擇。模型探索既要花費時間又要花費金錢，所以版本控制和可重復(fù)性對于所有的探索實驗來說都是必要的。

此外，隨著ML項目的不斷增加，撰寫模型文檔也成為數(shù)據(jù)科學(xué)家開發(fā)模型不可或缺的環(huán)節(jié)，在MLOps平臺內(nèi)嵌Jupyter后，數(shù)據(jù)科學(xué)家不但可以使用相關(guān)功能進(jìn)行模型的訓(xùn)練和部署，而不必關(guān)心底層資源的管理，還可以在Jupyter內(nèi)輕松撰寫數(shù)據(jù)探索和模型建模過程，形成知識庫，以在整個團隊內(nèi)共享。

在完成了數(shù)據(jù)探索和模型探索后，如果需要將模型或分析結(jié)果生產(chǎn)化，那么還有很多工作要梳理和實現(xiàn)。比如，生產(chǎn)中的數(shù)據(jù)在哪里？如何在現(xiàn)實場景中使用模型的結(jié)果？是否需要將模型部署到分布式的機器上來擴大規(guī)模？模型服務(wù)的預(yù)測延遲是否足夠低？如何更新模型？如何知道模型是否有問題？如何處理邊緣案例，如數(shù)據(jù)缺失和異常值的情況？

特征存儲

在ML項目中，通常需要與許多類型的數(shù)據(jù)源打交道，這是因為沒有一個數(shù)據(jù)源適合所有的應(yīng)用。數(shù)據(jù)庫對于存儲大量的數(shù)據(jù)是極方便的，但在返回結(jié)果時相對比較慢，因為它們是從磁盤中讀取數(shù)據(jù)的，而讀取時間或磁盤的I/O通常會限制網(wǎng)絡(luò)應(yīng)用的性能。一些對延遲時間有要求的應(yīng)用可能需要尋求方案來解決這個瓶頸問題，一種常用的方法是使用緩存，即將常用的數(shù)據(jù)存儲起來，使其保存于內(nèi)存中并隨時可用，而不是從磁盤中“分頁”提取。

具體來說，數(shù)據(jù)存儲的方式有多種，如數(shù)據(jù)湖、數(shù)據(jù)倉庫、數(shù)據(jù)集市及最近幾年在ML領(lǐng)域比較火的特征存儲等。它們代表了不同級別的數(shù)據(jù)管理方式。

• 數(shù)據(jù)湖：非結(jié)構(gòu)化原始數(shù)據(jù)的通用存儲裝置，如日志、圖像、電子郵件及結(jié)構(gòu)化的數(shù)據(jù)字典等數(shù)據(jù)適合使用數(shù)據(jù)湖。原始數(shù)據(jù)到數(shù)據(jù)湖的輸入過程不需要過濾任何東西，因此數(shù)據(jù)湖的大小會不斷增長。

• 數(shù)據(jù)倉庫：處理過的數(shù)據(jù)、建模和結(jié)構(gòu)化數(shù)據(jù)的存儲裝置，企業(yè)通常使用數(shù)據(jù)倉庫來存儲和檢索運營指標(biāo)、業(yè)務(wù)指標(biāo)等。數(shù)據(jù)倉庫通常是企業(yè)級的，能為整個企業(yè)各個部門的運作提供數(shù)據(jù)決策支持。

• 數(shù)據(jù)集市：一個簡單的數(shù)據(jù)倉庫，數(shù)據(jù)集市通常是部門級的，用來滿足特定部門和用戶的需求，按照多維的方式進(jìn)行數(shù)據(jù)存儲，包括定義維度、需要計算的指標(biāo)及維度的層次等，從而生成面向決策分析需求的數(shù)據(jù)立方體。

• 特征存儲：數(shù)據(jù)倉庫的一種特殊形式，幫助數(shù)據(jù)科學(xué)家訪問數(shù)據(jù)和管理ML的特征。它包含的特征是經(jīng)過處理的數(shù)據(jù)，可以被ML模型直接消費。與數(shù)據(jù)倉庫不同的是，特征存儲提供了檢索穩(wěn)健性更高和延遲更低的訪問渠道，以實現(xiàn)快速推理（預(yù)測），以及為頻繁的模型持續(xù)訓(xùn)練過程提供訓(xùn)練數(shù)據(jù)。

特征存儲好比數(shù)據(jù)科學(xué)的數(shù)據(jù)倉庫，它的主要目標(biāo)是使數(shù)據(jù)科學(xué)家能夠縮短從數(shù)據(jù)攝取到ML模型訓(xùn)練和推理的時間，填補了MLOps生命周期中的一個重要空白。

在特征存儲模式下，收集數(shù)據(jù)并將其轉(zhuǎn)化為特征的過程是一次性完成的，并可以被重復(fù)使用。特征存儲是將特征工程的過程與特征的消費（例如，在模型的開發(fā)或在線推理時使用）過程解耦，在特征存儲中，特征在模型訓(xùn)練和在線推理服務(wù)之間的消費也使用了不同的技術(shù)進(jìn)行分離，并通過一個通用的SDK來保持這兩種消費模式的一致性。這種共享方式加快了ML的工作進(jìn)程，因為數(shù)據(jù)工程師不必像傳統(tǒng)方式那樣每次建模的時候都重新收集數(shù)據(jù)和進(jìn)行相應(yīng)的轉(zhuǎn)換，而重復(fù)性的工作會造成浪費，也不利于特征的充分利用和管理。此外，通過特征存儲還可以選擇歷史沉淀下來的特征來快速生成訓(xùn)練數(shù)據(jù)以訓(xùn)練不同的模型。

特征存儲的作用是雙重的，它是對特征工程產(chǎn)生的特征進(jìn)行存儲的設(shè)施，也是開發(fā)者可以復(fù)用特征的存儲設(shè)施。本質(zhì)上，特征存儲是人們共享、注釋、發(fā)現(xiàn)和使用處理過的數(shù)據(jù)的地方。具體地，特征存儲涉及兩個不同的存儲方式，一個是低延遲的在線存儲，通常以Redis緩存的形式為模型服務(wù)提供最新、實時的特征，另一個是成本優(yōu)化的離線存儲，用于存儲支持模型訓(xùn)練的歷史數(shù)據(jù)。

當(dāng)前市場上流行的特征存儲有Michelangelo Pallete（Uber）、Feast（Gojek和Google）、Zipline（Airbnb）和Hopsworks（LogicalClocks）。

實驗管理和模型管理

實驗管理和模型管理都與ML模型的迭代、版本化及評估等關(guān)鍵事件息息相關(guān)，應(yīng)確?？芍貜?fù)性，并提供模型和結(jié)果的可視化管理界面。

對模型訓(xùn)練期間產(chǎn)生的特定信息，如變量、特征、屬性、評分、性能指標(biāo)、歷史版本及位置信息的管理屬于實驗管理的范疇。

而對訓(xùn)練、創(chuàng)建、部署、重新評估、重新訓(xùn)練、發(fā)布到生產(chǎn)環(huán)境及模型版本、標(biāo)簽和描述之類的事件的管理都屬于模型管理的范疇。這些事件的標(biāo)簽可以是注釋，如項目、用戶、時間戳和有關(guān)原始值與更新值的詳細(xì)信息。

實驗管理與模型管理的實現(xiàn)通常需要將與數(shù)據(jù)科學(xué)家工作流程相關(guān)聯(lián)的元數(shù)據(jù)進(jìn)行記錄和保存。這里的記錄和保存可以通過API的封裝來實現(xiàn)。除了通過API與元數(shù)據(jù)集進(jìn)行編程交互，還需要有前端界面的功能來實現(xiàn)可視化管理，在前端界面上進(jìn)行操作時所產(chǎn)生和檢索的數(shù)據(jù)也是通過上述API來實現(xiàn)與后端數(shù)據(jù)庫交互的。

服務(wù)

服務(wù)是一個更大系統(tǒng)中的獨立單元，提供一些特定的功能。服務(wù)可以被認(rèn)為是構(gòu)成一個系統(tǒng)的黑盒子。舉個例子，一個大型媒體網(wǎng)站的后端系統(tǒng)可能是由若干個共同為媒體網(wǎng)站的用戶提供文章推薦的服務(wù)組成的。其中，一個服務(wù)提供一組關(guān)于一篇文章的統(tǒng)計數(shù)據(jù)，另一個服務(wù)可能會啟動ML訓(xùn)練作業(yè)，并將訓(xùn)練好的模型提供給一個對ML結(jié)果進(jìn)行后處理的服務(wù)，記為ML推薦服務(wù)，最終網(wǎng)站的前端調(diào)用推薦服務(wù)獲取推薦結(jié)果。

這些工作通常被稱為服務(wù)，每個獨立的服務(wù)都是強分離的。雖然不同企業(yè)定義的服務(wù)標(biāo)準(zhǔn)各不相同，但還是有共性的，如下所述。

• 服務(wù)是黑盒子，它們的實現(xiàn)邏輯對用戶是隱藏的。

• 服務(wù)是自主的，它們要對它們所服務(wù)的功能負(fù)責(zé)。

• 服務(wù)是無狀態(tài)的，要么返回預(yù)期的值，要么返回一個錯誤信息。當(dāng)返回錯誤信息時，需要能夠在不影響系統(tǒng)的情況下重新啟動一個可用的新服務(wù)。

服務(wù)應(yīng)該是可以復(fù)用的，這對MLOps平臺來說特別有用，比如，特征存儲的在線服務(wù)就是可復(fù)用的，可以滿足不同團隊和不同模型的使用要求。

在生產(chǎn)環(huán)境中，在模型服務(wù)化（服務(wù)化后產(chǎn)生的服務(wù)被稱為模型推理服務(wù)或預(yù)測服務(wù)）階段，其對應(yīng)的API通常需要處理大量的請求負(fù)載，很多時候單機很難滿足需求。有許多種方法可以擴展一個生產(chǎn)系統(tǒng)。

第一種方法是垂直擴展，指的是增加網(wǎng)絡(luò)中單個節(jié)點容量的過程。如果模型服務(wù)已經(jīng)在多個節(jié)點上運行，它指的是增加一部分網(wǎng)絡(luò)或整個網(wǎng)絡(luò)的容量。垂直擴展的主要問題是，隨著單個節(jié)點容量的增加，與增加第二個類似規(guī)格的節(jié)點相比，它的成本會非線性地增加。垂直擴展通常是首選的方法。一般來說，這種方法在擴展時不需要修改代碼。

第二種方法是水平擴展，即添加更多的節(jié)點到網(wǎng)絡(luò)中，在節(jié)點之間分配容量。這種方法通常需要引入負(fù)載均衡器，該負(fù)載均衡器將一個給定的請求分流到一個（可能）當(dāng)前不忙的節(jié)點。同樣，這種方法在擴展時也不需要改變應(yīng)用程序的代碼。不過，與垂直擴展相比，它會帶來更多的復(fù)雜性，因為要引入負(fù)載均衡器和增加網(wǎng)絡(luò)規(guī)模。

除了這兩種擴展方式，還有其他很多方式可以優(yōu)化生產(chǎn)系統(tǒng)的性能。最常見的方式是，優(yōu)化應(yīng)用程序代碼本身的性能，比如，尋找方法使代碼片段處理得更快、分批進(jìn)行數(shù)據(jù)庫的調(diào)用、避免不必要的循環(huán)和嵌套，以及將網(wǎng)絡(luò)調(diào)用做成異步的等。有時，我們還需要在低延遲和準(zhǔn)確性之間找到一個折中的方案。在使用這些方法調(diào)整模型服務(wù)之后，模型服務(wù)的響應(yīng)會變得更快。

此外，為了優(yōu)化模型服務(wù)組件（模塊）的成本，托管技術(shù)的選擇至關(guān)重要，比如，在容器中運行多個模型可以最大限度地利用資源（CPU/GPU的內(nèi)存）來處理推理請求。模型服務(wù)組件本身應(yīng)具有模型生命周期管理的功能，以支持版本的推出。自動擴展是MLOps底層基礎(chǔ)設(shè)施的一個重要特性，用于滿足高峰時段的需求及降低非高峰時段的成本。比如，對長時間沒有接收到流量的模型，可以靈活降低對該模型服務(wù)的資源分配。

生產(chǎn)環(huán)境中的模型可以在正常運維范圍內(nèi)運行，通過監(jiān)控組件的可視化指標(biāo)進(jìn)行觀察。當(dāng)模型的運行行為發(fā)生變化時，需要引入持續(xù)訓(xùn)練機制來解決模型的漂移問題。

前面討論過，ML 管道包括傳入數(shù)據(jù)的驗證、模型評估、推理請求的監(jiān)控和日志管理等任務(wù)，這些任務(wù)中的每一個都是管道中的獨立組件。管道中每個組件產(chǎn)生的結(jié)果需要存儲在中央存儲中，以確保模型生命周期的可觀察性。

通過驗證和評估的開發(fā)環(huán)境中的模型，在推送到生產(chǎn)環(huán)境后，其實時性能需要由專門的監(jiān)控模塊進(jìn)行跟蹤，以確保對業(yè)務(wù)的影響正向?？梢酝ㄟ^多種方法來監(jiān)控運行中的模型服務(wù)和預(yù)測行為。理想的方法是，記錄模型服務(wù)被請求時所做的預(yù)測，然后將它們與后續(xù)業(yè)務(wù)系統(tǒng)運行過程中觀測到的用戶反饋結(jié)果結(jié)合起來，最后評估運行中的模型性能是否滿足預(yù)期。