譚中意：從Model-Centric到Data-Centric MLOps幫助AI多快好省的落地

作者：千山 2022-08-27 12:13:05

AI已經(jīng)從以模型為中心的研究范式向以數(shù)據(jù)為中心的研究范式轉(zhuǎn)變

　　嘉賓：譚中意

　　整理：千山

　　吳恩達(dá)曾在多個場合表達(dá)過AI已經(jīng)從以模型為中心的研究范式向以數(shù)據(jù)為中心的研究范式轉(zhuǎn)變，數(shù)據(jù)是AI落地最大的挑戰(zhàn)。如何保證數(shù)據(jù)的高質(zhì)量供給是關(guān)鍵問題，而要解決好這個問題，需要利用MLOps的實(shí)踐、工具等，幫助AI多快好省的落地。

日前，在51CTO主辦的?? AISummit 全球人工智能技術(shù)大會??上，開放原子基金會TOC副主席譚中意帶來了主題演講《從Model-Centric到Data-Centric——MLOps幫助AI多快好省的落地》，和與會者重點(diǎn)分享了MLOps的定義、MLOps能解決什么問題、常見的MLOps項目，以及如何評估一個AI團(tuán)隊MLOps的能力和水平。

　　現(xiàn)將演講內(nèi)容整理如下，希望對諸君有所啟發(fā)。

從Model-Centric到Data-Centric

　　當(dāng)前，AI界有個趨勢是——“從Model-Centric到Data-Centric”。具體是什么含義？首先來看一些來自科學(xué)界和工業(yè)界的分析。

AI科學(xué)家吳恩達(dá)（Andrew NG）分析，目前AI落地的關(guān)鍵在于如何提升數(shù)據(jù)質(zhì)量。
業(yè)內(nèi)工程師和分析師有報告表明，AI項目經(jīng)常失敗。而導(dǎo)致失敗的原因值得進(jìn)一步探討。

吳恩達(dá)曾分享過演講《MLOps：From Model-centric to Data-centric》，在硅谷引起了極大反響。在演講中，他認(rèn)為“AI= Code + Data”（此處Code包括模型和算法），通過提升Data而非Code來提升AI system。

具體來說，采用Model-Centric的方法，即保持?jǐn)?shù)據(jù)不變，不斷的調(diào)整模型算法，比如使用更多網(wǎng)絡(luò)層，更多超參數(shù)調(diào)整等；而采用Data-Centric的方法，即保持模型不變，提升數(shù)據(jù)質(zhì)量，比如改進(jìn)數(shù)據(jù)標(biāo)簽，提高數(shù)據(jù)標(biāo)注質(zhì)量等。

　　對于同一個AI問題，改進(jìn)代碼還是改進(jìn)數(shù)據(jù)，效果完全不同。

實(shí)證顯示，通過Data-centricapproach能夠有效提升準(zhǔn)確率，而通過改進(jìn)模型、更換模型能提升準(zhǔn)確率的程度極為有限。例如，在如下鋼板缺陷檢測任務(wù)當(dāng)中，baseline準(zhǔn)確率為76.2%，各種換模型調(diào)參數(shù)的操作之后，對準(zhǔn)確率幾乎沒有提升。但是對數(shù)據(jù)集的優(yōu)化卻將準(zhǔn)確率提升了16.9%。其它項目的經(jīng)驗(yàn)也證明了這點(diǎn)。

之所以會這樣，是因?yàn)閿?shù)據(jù)比想象中更重要。大家都知道“Data is Food for AI”。在一個真實(shí)的AI應(yīng)用中，大概有80%的時間是處理跟數(shù)據(jù)相關(guān)的內(nèi)容，其余20%則用來調(diào)整算法。這個過程就像烹飪，八成時間用來準(zhǔn)備食材，對各種食材進(jìn)行處理和調(diào)整，而真正的烹調(diào)可能只有大廚下鍋的幾分鐘?？梢哉f，決定一道菜是否美味的關(guān)鍵，在于食材和食材的處理。

在吳恩達(dá)看來，MLOps（即“Machine learning Engineering for Production”）最重要的任務(wù)就是在機(jī)器學(xué)習(xí)生命周期的各個階段，包括數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練、模型上線，還有模型的監(jiān)控和重新訓(xùn)練等等各個階段，始終保持高質(zhì)量的數(shù)據(jù)供給。

　　以上是AI科學(xué)家對MLOps的認(rèn)識。接著來看一下AI工程師和業(yè)內(nèi)分析師的一些觀點(diǎn)。

首先從業(yè)內(nèi)分析師看來，目前AI項目的失敗率是驚人的高。2019年5月Dimensional Research調(diào)研發(fā)現(xiàn)，78%的AI項目最終沒有上線；2019年6月，VentureBeat的報告發(fā)現(xiàn)，87%的AI項目沒有部署到生成環(huán)境中。換句話說，雖然AI科學(xué)家、AI工程師做了很多工作，但是最終沒有產(chǎn)生業(yè)務(wù)的價值。

為什么會產(chǎn)生這種結(jié)果？2015年在NIPS上發(fā)布的論文《Hidden Technical Debt in Machine Learning Systems》中提到，在一個真實(shí)上線的AI系統(tǒng)里面，包含了數(shù)據(jù)采集、驗(yàn)證、資源管理、特征抽取、流程管理、監(jiān)控等諸多內(nèi)容。但真正跟機(jī)器學(xué)習(xí)相關(guān)的代碼，僅僅只占整個AI系統(tǒng)的5%，95%都是跟工程相關(guān)的內(nèi)容，跟數(shù)據(jù)相關(guān)的內(nèi)容。因此，數(shù)據(jù)是最重要的，也是最容易出錯的。

　　數(shù)據(jù)對一個真實(shí)的AI系統(tǒng)的挑戰(zhàn)主要在于以下幾點(diǎn)：

Scale：海量的數(shù)據(jù)讀取是一個挑戰(zhàn)；
Low Latency：在serving的時候如何滿足高QPS低延遲的需求；
Data change cause model decay：現(xiàn)實(shí)世界是不斷變化的，如何應(yīng)對模型效果的衰減；
Time Travel：時序特征數(shù)據(jù)處理容易出問題；
Training/Serving skew：訓(xùn)練和預(yù)測使用的數(shù)據(jù)不一致。

　　以上列舉的都是機(jī)器學(xué)習(xí)里面數(shù)據(jù)相關(guān)的一些挑戰(zhàn)。此外，在現(xiàn)實(shí)生活中，實(shí)時數(shù)據(jù)會帶來更大的挑戰(zhàn)。

　　那么，對于一個企業(yè)來說，AI落地如何才能做到規(guī)?；?？以大企業(yè)為例，它可能會有超過1000多個應(yīng)用場景，同時有1500多個模型在線上跑，這么多模型如何支撐？在技術(shù)上怎么能夠做到AI“多、快、好、省”的落地？

　　多：需要圍繞關(guān)鍵業(yè)務(wù)的流程落地多個場景，對大企業(yè)來說可能是1000甚至上萬的量級。

　　快：每個場景落地時間要短，迭代速度要快。比如推薦場景中，常常需要做到每天1次全量訓(xùn)練，每15分鐘甚至每5分鐘做到1次增量訓(xùn)練。

　　好：每個場景的落地效果都要達(dá)到預(yù)期，至少要比沒有落地前強(qiáng)。

　　省：每個場景的落地成本比較節(jié)省，符合預(yù)期。

　　要真正做到“多、快、好、省”，我們需要MLOps。

在傳統(tǒng)的軟件開發(fā)領(lǐng)域，遇到上線慢、質(zhì)量不穩(wěn)定等類似問題，我們用DevOps來解決。DevOps大大提升了軟件開發(fā)和上線的效率，促進(jìn)了現(xiàn)代軟件的快速迭代和發(fā)展。而在面臨AI系統(tǒng)的問題時，我們可以借鑒DevOps領(lǐng)域的成熟經(jīng)驗(yàn)去發(fā)展MLOps。所以如圖所示，“Machine learning development+Modern software development”就變成了MLOps。

MLOps到底是什么

　　對于MLOps是什么，目前業(yè)界并沒有標(biāo)準(zhǔn)定義。

來自wikipedia的定義：MLOps is a set of practices that aims to deploy and
maintain machine learning models in production reliable and efficiently。
來自Google cloud的定義：MLOps 是一種機(jī)器學(xué)習(xí)工程文化和做法，旨在統(tǒng)一機(jī)器學(xué)習(xí)系統(tǒng)開發(fā)和運(yùn)維。
來自Microsoft Azure的定義：MLOps 能幫助數(shù)據(jù)科學(xué)家和應(yīng)用工程師來讓機(jī)器學(xué)習(xí)的模型在生產(chǎn)領(lǐng)域發(fā)揮更大的作用。

　　上述說法都比較繞口，我個人對此的理解相對簡單：MLOps是“Code+Model+Data”的持續(xù)集成、持續(xù)部署、持續(xù)訓(xùn)練和持續(xù)監(jiān)控。

　　上圖展示的是一個典型的機(jī)器學(xué)習(xí)的生命場景。定義項目階段之后就開始定義和收集加工數(shù)據(jù)，就要觀察對解決當(dāng)前問題有幫助的數(shù)據(jù)究竟是哪些？要怎么加工，怎么做特征工程，怎么轉(zhuǎn)換和存儲。

　　收集完數(shù)據(jù)之后就開始進(jìn)行模型的訓(xùn)練和迭代，需要不斷調(diào)整算法，然后不斷訓(xùn)練，最后得出一個符合預(yù)期的結(jié)果。如果對這個結(jié)果不滿意，就需要返回上層，此時需要獲取更多的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行更多的轉(zhuǎn)換，之后再進(jìn)行訓(xùn)練，循環(huán)往復(fù)，直到得出比較滿意的模型算法出來，然后再開始部署到線上。

　　在部署和監(jiān)控環(huán)節(jié)，如果模型效果不一致，這時候要觀察訓(xùn)練和部署出了什么問題。在部署了一段時間后，可能會面臨模型衰退的問題，此時就需要重新訓(xùn)練。甚至有時候在部署過程中發(fā)現(xiàn)數(shù)據(jù)有問題，此時就需要返回到數(shù)據(jù)處理這一層。更有甚者，部署效果遠(yuǎn)未達(dá)到項目預(yù)期，也可能需要返回初始原點(diǎn)。

　　可以看到，整個過程是一個循環(huán)迭代的過程。而對于工程實(shí)踐來說，我們需要不斷地持續(xù)集成、持續(xù)部署、持續(xù)訓(xùn)練、持續(xù)監(jiān)控。其中持續(xù)訓(xùn)練和持續(xù)監(jiān)控是MLOps所特有的。持續(xù)訓(xùn)練的作用在于，即使代碼模型沒有發(fā)生任何改變，也需要針對其數(shù)據(jù)改變進(jìn)行持續(xù)訓(xùn)練。而持續(xù)監(jiān)控的作用在于，不斷監(jiān)控數(shù)據(jù)和模型之間的匹配是否發(fā)生問題。這里的監(jiān)控指的不僅是監(jiān)控線上系統(tǒng)，更要監(jiān)控系統(tǒng)跟機(jī)器學(xué)習(xí)相關(guān)的一些指標(biāo)，如召回率、準(zhǔn)確率等。綜合來說，我認(rèn)為MLOps其實(shí)就是代碼、模型、數(shù)據(jù)的持續(xù)集成，持續(xù)部署，持續(xù)訓(xùn)練和持續(xù)監(jiān)控。

　　當(dāng)然，MLOps不僅僅只是流程和Pipeline，它還包括更大更多的內(nèi)容。比如：

　　(1) 存儲平臺：特征和模型的存儲和讀取

　　(2) 計算平臺：流式、批處理用于特征處理

　　(3) 消息隊列：用于接收實(shí)時數(shù)據(jù)

　　(4) 調(diào)度工具：各種資源（計算/存儲）的調(diào)度

　　(5) Feature Store：注冊、發(fā)現(xiàn)、共享各種特征

　　(6) Model Store：模型的特征

　　(7) Evaluation Store：模型的監(jiān)控/ AB測試

Feature Store、Model store和Evaluation store都是機(jī)器學(xué)習(xí)領(lǐng)域中新興的應(yīng)用和平臺，因?yàn)橛袝r候線上會同時跑多個模型，要實(shí)現(xiàn)快速迭代，需要很好的基礎(chǔ)設(shè)施來保留這些信息，從而讓迭代更高效，這些新應(yīng)用、新平臺就應(yīng)運(yùn)而生。

MLOps的特有項目——Feature Store

　　下面簡要介紹一下Feature Store，即特征平臺。作為機(jī)器學(xué)習(xí)領(lǐng)域特有的平臺，F(xiàn)eature Store具有很多特性。

　　第一，需要同時滿足模型訓(xùn)練和預(yù)測的要求。特征數(shù)據(jù)存儲引擎在不同的場景有著完全不同的應(yīng)用需求。模型訓(xùn)練時需要擴(kuò)展性好、存儲空間大；實(shí)時預(yù)測則需要滿足高性能、低延遲的要求。

　　第二，必須解決特征處理在訓(xùn)練時候和預(yù)測階段不一致的問題。在模型訓(xùn)練時，AI科學(xué)家一般會使用Python腳本，然后用Spark或者SparkSQL來完成特征的處理。這種訓(xùn)練對延遲不敏感，在應(yīng)付線上業(yè)務(wù)時效率較低，因此工程師會用性能較高的語言把特征處理的過程翻譯一下。但翻譯過程異常繁瑣，工程師要反復(fù)跟科學(xué)家去校對邏輯是否符合預(yù)期。只要稍微不符合預(yù)期，就會帶來線上和線下不一致的問題。

　　第三，需要解決特征處理中的重用問題，避免浪費(fèi)，高效共享。在一家企業(yè)的AI應(yīng)用中，經(jīng)常會出現(xiàn)這一情況：同一個特征被不同的業(yè)務(wù)部門使用，數(shù)據(jù)源來自同一份日志文件，中間所做的抽取邏輯也是類似的，但因?yàn)槭窃诓煌牟块T或不同的場景下使用，就不能復(fù)用，相當(dāng)于同一份邏輯被執(zhí)行了N遍，而且日志文件都是海量的，這對存儲資源和計算資源都是巨大的浪費(fèi)。

綜上所述，F(xiàn)eature Store主要用于解決高性能的特征存儲和服務(wù)、模型訓(xùn)練和模型預(yù)測的特征數(shù)據(jù)一致性、特征復(fù)用等問題，數(shù)據(jù)科學(xué)家可以使用Feature Store進(jìn)行部署和共享。

　　目前市面上主流的特征平臺產(chǎn)品，大致可分為三大類。

各個AI公司自研。只要業(yè)務(wù)有實(shí)時訓(xùn)練的需求，這些公司基本都會自研一個類似的特征平臺，用于解決上面的三個問題。但這個特征平臺是為業(yè)務(wù)所深度綁定的。
云廠商提供的SAAS產(chǎn)品或者機(jī)器學(xué)習(xí)平臺的一部分。比如AWS提供的SageMaker、Google提供的Vertex、微軟提供的Azure機(jī)器學(xué)習(xí)平臺。它們在機(jī)器學(xué)習(xí)平臺里會內(nèi)置一個特征平臺，方便用戶進(jìn)行各種復(fù)雜特征的管理。
一些開源的和商業(yè)的產(chǎn)品。舉幾個例子，F(xiàn)east，開源的Feature Store產(chǎn)品；Tecton提供完整的開源商業(yè)特征平臺產(chǎn)品；OpenMLDB，開源的Feature Store產(chǎn)品。

MLOps的成熟度模型

　　成熟度模型是用來衡量一個系統(tǒng)、一套規(guī)則的能力目標(biāo)，在DevOps領(lǐng)域經(jīng)常用成熟度模型來評估一個公司的DevOps能力。而在MLOps領(lǐng)域也有相應(yīng)的成熟度模型，不過目前還沒有形成規(guī)范。這里簡要介紹一下Azure的關(guān)于MLOps的成熟度模型。

　　按照機(jī)器學(xué)習(xí)全流程的自動化程度的高低，把MLOps的成熟模型分成了（0，1，2，3，4）個等級，其中0是沒有自動化的。（1,2,3）是部分自動化，4是高度自動化.