嘉賓：譚中意

　　整理：千山

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

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

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

從Model-Centric到Data-Centric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　好：每個場景的落地效果都要達到預期，至少要比沒有落地前強。

　　?。好總€場景的落地成本比較節(jié)省，符合預期。

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

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

MLOps到底是什么

　　對于MLOps是什么，目前業(yè)界并沒有標準定義。

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

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

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

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

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

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

　　當然，MLOps不僅僅只是流程和Pipeline，它還包括更大更多的內容。比如：

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

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

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

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

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

　　(6) Model Store：模型的特征

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

      Feature Store、Model store和Evaluation store都是機器學習領域中新興的應用和平臺，因為有時候線上會同時跑多個模型，要實現(xiàn)快速迭代，需要很好的基礎設施來保留這些信息，從而讓迭代更高效，這些新應用、新平臺就應運而生。

MLOps的特有項目——Feature Store

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

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

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

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

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

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

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

MLOps的成熟度模型

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

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

　　成熟度為0，即沒有MLOps。這一階段意味著數(shù)據(jù)準備是手動的，模型訓練也是手動的，模訓部署也都是手動的。所有的工作全都是手動完成，適合于一些把AI進行創(chuàng)新試點的業(yè)務部門來做。

　　成熟度為1，即有DevOps沒有MLOps。其數(shù)據(jù)準備工作是自動完成的，但模型訓練是手動完成的。科學家拿到數(shù)據(jù)之后進行各種調整和訓練再完成。模型的部署也是手動完成的。

　　成熟度為2，即自動化訓練。其模型訓練是自動化完成的，簡言之，當數(shù)據(jù)更新完了之后，立馬啟動類似的pipeline，進行自動化的訓練，不過對訓練結果的評估和上線還是由人工來完成。

　　成熟度為3，即自動化部署。模型自動化訓練完成之后，對模型的評估和上線是自動完成的，不需要人工干涉。

      成熟度為4，即自動化重訓和部署。它在不斷監(jiān)控線上的模型，當發(fā)現(xiàn)Model DK發(fā)生線上模型能力退化的時候，會自動會觸發(fā)重復訓練。整個過程就全部自動化完成了，這就可以稱之為成熟度最高的系統(tǒng)。

　　更多精彩內容見大會官網(wǎng)：??點擊查看??