企業智能轉型對AI技術的挑戰及應對，答案是MLOps
前言：筆者在參加12月20日舉行的，由LF AI & Data基金會和OpenI啓智社區聯合舉辦的2021新一代人工智能院士高峯論壇上分享對於企業智能轉型，以及AI技術面臨的挑戰和應對。
首先什麼是企業智能轉型？
筆者認爲企業智能轉型是企業數字化轉型的一個較高的階段，是AI在企業的大規模應用，不是單純的人臉識別、OCR、語言識別等單個場景的落地，而是用AI來徹底改變企業的核心業務流。達到的效果是：或者徹底改變企業的商業模式，或者在覈心效率上有巨大的提升，從而達到企業智能轉型的目的。舉個例子來說，對於一個連鎖餐飲消費企業，它的核心業務流程包括選門店地址、選擇商品品類、總店對分店進行鋪貨和補貨、商品促銷和線上推薦等，這條核心流程上的多個場景，都採用AI的技術進行優化和重整，從而在多個場景上都取得效率的較多或者較少的提升，累加起來就是效率的巨大提升，從而跟競爭對手相比建立起較大的競爭優勢，達到了智能轉型的目的。
第四範式在長期幫助多家企業進行智能轉型的過程中，形成了自己獨特的企業智能轉型方法論---從量變到質變。
把企業的智能轉型分成如下循環的四步：
- 識別企業當前的核心痛點
- 分析痛點相關的核心業務流程（包含多個場景）
- 在多個場景落地AI並不斷提升效果
- 多個效果提升累計產生質變
然後再進行新的分析，痛點有可能變爲另外一個，然後按照上述四步依次進行。
那麼，企業智能轉型對技術的需求是什麼呢？
簡單來說就是機器學習技術在企業在覈心業務流相關的場景上“多、快、好、省”的落地：
- 多：圍繞關鍵業務流程落地多個場景
- 快：每個場景落地時間短，迭代速度快
- 好：每個場景的效果都達到預期
- 省：每個場景落地成本比較節省，符合預期
但是AI在企業落地的實際情況是：
- 落地慢： 往往一個模型落地時間是實驗室模型調優完成的數倍以上。一個AI科學家在一次分享會上感嘆：”It took me 3 weeks to develop the model. It has been >11 months, and it is still not deployed.”事實上，根據某分析機構2018年的報告顯示，89%以上的模型從來就沒有完成線上部署，即沒有產生實際效果。
- 效果不達預期：一些模型在線下訓練的時候效果很好，各種指標都符合預期，但是當模型被部署到線上，對接真實的線上數據來提供預測服務的時候，發現效果大打折扣。
- 效果還會回退：一個模型上線後一段時間內效果還可以，但是隨着時間推移，效果越來越差，最後導致該模型完全不可用。舉個例子，隨着新冠疫情發生，某國金融系統幾乎所有的風控模型全部失效，因爲新冠疫情導致人們的購物習慣發生了極大改變，很多不喜歡網絡購物的人們都被逼進行網絡購物，導致根據疫情前人們消費習慣進行建模的風控模型，完全不能體現當前規律，所以全面失效。
爲什麼？ 因爲在一個生產環境中運行的機器學習系統，機器學習模型相關的代碼只佔很小很小的部分，大約5%。
此圖來自NIPS 2015一篇著名的論文 “Hidden Technical Debt in Machine Learning Systems“。Google的幾位機器學習的專家在該論文闡述機器學習中的種種技術問題，ML Code只佔整個系統極小的部分。
而我們都知道AI System = Code + Data. Data在機器學習中非常重要，但又是相當難的一個部分。“Data is the hardest part of ML and the most important piece to get right… Broken data is the most common cause of problems in production ML systems”.
---from Uber
這是Uber的機器學習工程師在一篇很有名的博客中提到的。
Data有如下問題和挑戰，筆者簡單列舉了一些：
- Scale： 海量的data for training
- Low Latency：高QPS低延遲的serving
- Data change cause model decay： World change
- Time Travel：時序特徵數據處理容易出問題
- Training/Serving skew：訓練和預測使用的數據不一致
還有，Live Data給這些問題提出了更多的挑戰。
這個圖是AI價值分析圖，橫軸是機器學習系統的技術能力，縱軸是系統的商業價值。從圖上可以看出，Real-Time ML（實時的機器學習，即具備流式實時數據接入並進行在線預測能力的機器學習模型，價值最大。可以理解，現實世界中機器學習最產生商業價值的場景莫過於廣告系統的CTR預估模型和電商系統的推薦模型，很顯然，模型如果能得到用戶的最近行爲並進行訓練，然後針對用戶進行推薦，是最能提升預測精準度，並最終體現在商業效果的提升上的。
那麼如何解決這些機器學習中的這些慢，效果不佳，效果甚至回退的問題呢？我們可以回顧一下當年我們是如何解決計算機軟件或者線上系統的質量和效率問題的。我們用一種叫做DevOps的方法，來改進我們的研發模式和工具系統，在保證質量的前提下，更快的提高版本發佈的速度，實現更多更快的部署。爲此我們採用了大量的自動化，來進行流水線（俗稱Pipeline）的自動化作業，即從代碼提交開始，觸發流水線進行自動化工作，完成代碼靜態檢查、代碼編譯、代碼動態檢查、單元測試、自動化接口測試、自動化功能測試、小流量部署、藍綠部署、全流量部署等。在容器成爲計算機系統的主流後，還加上了達成docker鏡像、把鏡像部署到容器倉庫等步驟。
借鑑DevOps領域內的成熟經驗，業內發展了MLOps，即把機器學習開發和現代軟件開發結合起來形成一整套的工具和平臺以及研發流程。
那麼什麼是MLOps？
用如下的圖可以表示，即機器學習系統從第一步的定義項目，到第二步的特徵數據加工，到第三步的模型訓練和迭代，到第四步的模型部署和監控，也採用流水線的方式連續進行，其中有若干小循環，例如模型訓練不理想，可能需要重新進行數據加工；模型監控下發現線上模型的效果有回退，需要重新訓練等。簡單來說就是實現Code、Model、Data這三者的CI（Continuous Integration）+ CD（Continuous Deploy）+ CT （Continuous Training）+CM（Continuous Monitoring）。
當然MLOps不只是流水線和自動化，還包含很多的工具和平臺。在這裏簡單列舉了一些，它們是：
- 存儲平臺：特徵和模型的存儲和讀取
- 計算平臺：流式、批處理用於特徵和模型
- 消息隊列：用於接收實時數據
- 調度工具：各種資源（計算/存儲）的調度
- Feature Store：註冊/發現/共享各種特徵
- Model Store： 模型的註冊/存儲/版本等
- Evaluation Store：模型的監控/AB測試等
下面筆者將重點介紹第四範式開源的一個項目：OpenMLDB。
OpenMLDB是一個開源機器學習數據庫，爲企業提供全棧的FeatureOps解決方案。可能某些同學有點暈了，怎麼又出了一個FeatureOps了。其實featureOps是MLOps的一部分，它專注於feature即特徵相關的操作，包括抽取、變換、存儲和計算等等。用下面的圖可以很清楚的表示這兩者之間的關係。
這是MLOps的完整的生命週期，它包含了離線部分的DataOps（內容主要是數據採集、數據的存儲），FeatureOps（離線特徵計算、存儲和共享），ModelOps（模型的訓練和調優）；也包含了在線部分的DataOps（實時數據流的接入，和響應實時請求），FeatureOps（實時特徵計算，特徵服務），ModelOps（在線推理，結果數據迴流等）。
對於FeatureOps（即特徵操作），其中一個相當大的挑戰是如何保證線下和線上的一致性，避免出現Training/Serving skew。我們來看下典型的AI科學家和AI工程師的工作流程。離線情況下，AI科學家從一個離線的數據倉庫中拿到特徵的原始數據，然後經過抽取/變換之後，餵給模型，然後進行訓練；如果效果不滿意，可能會增加新的數據作爲特徵，也可能把現有的特徵進行更多的轉化等，然後調整模型網絡架構，調試各種學習超參數，再訓練，直到獲得較好的結果。這個過程，科學家往往使用python，在notebook中工作，訓練生成模型後希望把模型部署到線上，承擔真實流量，即面對真實的數據。這個時候，AI工程師需要部署模型並開發預測服務，需要從數據倉庫中拿到模型所需要的原始數據，再把科學家訓練時候對特徵進行的ETL（Extract，Transform，Load）過程轉換爲線上預測服務相關的功能，因爲科學家進行訓練的時候是不太考慮線上服務的性能要求（比如併發、低延遲等），AI工程師是必須要考慮的，所以這個轉化過程是非常耗時的，因爲稍微有些不一致，就會導致訓練和預測結果的差異，導致明明訓練的結果很理想，上線之後效果就大打折扣從而達不到預期，所以需要AI工程師和AI科學家進行反覆的溝通和調試，而這都是非常time-consuming的事情。
而OpenMLDB採用一種創新性的做法，讓AI科學家和AI工程師都採用同一種非常普遍的語言即SQL來進行各自的工作。這樣，AI科學家用一套SQL腳本構建出訓練所需要的特徵數據完成訓練，同樣這套SQL腳本可以被AI工程師原封不動的部署到線上，來用於預估服務。同一套SQL腳本被兩種角色在訓練和預測時候使用，從而創新性的解決了FeatureOps中最大的問題，即訓練和預測不一致的問題。當然OpenMLDB還有其他的一些非常好的特性，例如內置一個高性能低延遲並對時序特徵做特定優化的在線特徵存儲系統等。OpenMLDB今年6月已經在github上對外開源，採用的許可證是商業友好的Apache V2 License，它已經在第四範式的衆多商業客戶實際運行場景中運行，性能和質量得到廣泛的驗證。開源的地址是https://github.com/4paradigm/openmldb。歡迎大家關注此項目。
最後我來總結一下：
- 企業智能化轉型需要多個AI場景落地
- AI落地現狀是很難，很慢，效果不佳而且會回退
- 借鑑DevOps經驗實施MLOps是解決之道
- OpenMLDB是MLOps中一個不錯的工具
最後附上MLOps愛好者討論羣的二維碼，歡迎各位對MLOps感興趣的同學加入，我們一起來討論相關的技術和項目。
Thanks。
