阿里推薦與搜尋引擎-AI·OS綜述

拉爾夫沈發表於2018-10-10

7747f1892043e5dc1790d378b36fb21c4f145f48

AI·OS(Online Serving),大資料深度學習線上服務體系,由我們工程、演算法、效率的同事們砥礪十年而成,支撐起海內外阿里電商全部的搜尋和推薦業務,時刻置身大資料主戰場,引導成交佔據集團大盤主體;此外,作為中颱技術中堅,AI·OS已是包括電商、阿里雲、優酷、菜鳥、盒馬、釘釘等等在內全集團的基礎設施;更為重要的是,AI·OS體系的雲產品矩陣服務於全球開發者,今年預期在數千萬級的營收規模。

AI·OS聚焦於深度學習的線上服務,其元件Jarvis甚至已經執行於手機上,但從功能角度來看,在體系中處於關鍵地位的有5個服務元件:TPP推薦業務平臺、RTP深度學習預測引擎、HA3搜尋召回引擎、DII推薦召回引擎、iGraph圖查詢引擎。AI·OS上的主要的演算法場景,比如手淘的搜尋、猜你喜歡、AIO以及海神等,都以圖化(運算元流程圖定製)的模式對元件快速組合與部署並承擔實驗流量,讓線上服務不拖模型訓練的後腿隨訓隨上,這是我們對迭代效率的最高水平的新演繹。

AI·OS這些關鍵服務元件能夠幻化異彩紛呈的演算法場景和技術產品,絕非機械組合可成。引擎圖化的基礎,尤其是對元件快速組合與部署並接流的能力,得益於我們對大資料線上服務的通用抽象(要求具備秒級資料更新的最終一致性),它就是Suez線上服務框架。Suez框架統一了3個維度的工作:1. 索引儲存(全文檢索、圖檢索、深度學習模型),2. 索引管理(全量、增量以及實時更新),3. 服務管理(最終一致性、切流降級擴縮容等)。每一個服務元件比如iGraph,孤立的做好這幾個維度至少要3年時間,哪怕是共享大部分程式碼,而做好它們只是一個線上服務的基本前提,畢竟我們都知道頻繁的業務迭代一定是發生在圖的計算層面。近日回顧,將iGraph遷移到Suez框架上,出於對使命的認同團隊精銳盡出不計投入,使得AI·OS可以合圍而成。

AI·OS體系裡Hippo承擔著叢集物理資源的排程任務,這裡是中臺容器和隔離技術與搜尋工程交匯之地,更是模型訓練PAI-TF與實時計算Blink通過AOP成為體系友員的橋頭堡。今天推薦與搜尋的訓練任務都執行在Hippo混部資源池上,演算法鼎盛時期我見證過最大2千臺、七天均值1300臺百核機器滿負荷運轉,這些資源是免費獲得的,而這些作業創造的價值大到無法估量。

AI·OS自身也是預測與優化演算法的用武之地,其中AIOps更是集大成者,在metrics服務KMon解決了秒級實時可靠性之後,在TPP成功推升ajdk的負載極限之後,在廣大無狀態服務元件彈性擴縮成功之後,AIOps終於可以再邁進一步推動Hippo池內大部分引擎服務元件執行彈性策略,雙11當日力爭摸高50%的負載峰值。彈性擴縮據我們所知在大資料線上服務領域是開拓性的工作。

AI·OS得以自成體系完成演算法迭代閉環,離不開嵌於手淘皇冠上的搜薦服務端和客戶端兩顆明珠,這裡是演算法工程產品融合亦是相關各方博弈的主場,高效的產品迭代和完善的實驗機制配合支援體系不斷實現眾望所歸的開疆闢土。近年來端上智慧的探索逐步明晰,助力拍立淘突破數千萬UV,技術上反哺手淘也給AI·OS體系帶來新的發展空間。

AI·OS深入骨髓的產品化理念支撐我們自居中臺技術中堅,TPP、TisPlus以及OpenSearch這些精準定位的推薦與搜尋中臺產品成就眾多事業部的大資料場景和基礎檢索服務。國際化大潮中,AI·OS體系化部署無需定製開發,技術中臺優勢獨顯。索引更新鏈路的設計欠缺造成負面影響,鞭策我們的同時側面也佐證AI·OS的基礎地位。

雲上擴充不僅是機遇更是AI·OS產品化的使命和終極歸宿,一批早期的引擎開發者富有遠見志同道合殊途同歸勇於開拓,如今OpenSearch和ES(基於AI·OS體系的基礎設施)已經全球部署成長為兩款千萬級的搜尋產品,而名為AIRec的智慧推薦產品即將問世,明年我們的公有云大資料產品矩陣有望營收有新突破。

總結一下,AI·OS體系的基石是Hippo它為體系劃定了資源的剛性邊界,資源為線上服務發展所必須,凡支援混部在資源角度能形成雙贏的即為體系友員(比如PAI-TF),目前我們也在不斷擴充Hippo邊界即將與Yarn合體甚至合池;往上的Suez是體系裡大資料線上服務的基礎框架,支援Suez即為體系成員,除運維成本大幅降低外還很自然的參與AIOps彈性擴縮排一步提升系統效率;進而再具備圖化能力即成為深度學習線上服務體系的核心成員,可以在業務場景裡任意馳騁,未來我們寄望於全圖化引擎與離線高效對接大幅提升演算法迭代效率。Hippo到Suez(iGraph)再到圖化引擎(RTP、HA3、DII),再延伸到手淘搜薦服務端與客戶端,乃至其上的AIOps和幾大技術產品TPP、TisPlus、OpenSearch,其核心線索是優化演算法迭代效率,這乃是AI·OS體系的精髓所在。從今天AI·OS達到的境界而言,我在所知範圍內還沒有見到同行到達過。

 

AI·OS與演算法

直白的講,面對大資料業務挑戰, AI·OS至多能起到30%的作用,隨後是演算法解決30+%,其餘的靠產品和機緣,只不過AI·OS的30%是個前提條件,這容易被忽視,在早期淘寶搜尋,不久前的手淘推薦在上演。很難想象有另外的技術領域會像這兩個領域一樣樂於相互成就,對彼此同事的職級、規模和疆域的成長感受到的只有羨慕。我們需要永遠銘記,AI·OS發展的核心線索是優化演算法迭代效率。

 

AI·OS與Blink

Blink孵化自早期的AI·OS體內,今天已蓬勃發展為通用實時計算引擎,不過二者間關係永遠的凝結於實時二字之上:AI·OS體系的引擎服務都要求具備秒級資料更新的最終一致性,而Blink在AI·OS的場景之外再難尋覓真正的技術挑戰。這就很容易解釋為什麼Blink團隊珍視AOP,而AI·OS狂熱的推動Blink上混部,甚至落地Hippo與Yarn合體合池。AI·OS與Blink的互補特性,僅次於AI·OS與演算法。

 

AI·OS與PAI

稍早時PAI希望獨立發揮作用卻總不能得門而入,原因是忽視了AI·OS體系尤其是Hippo的混部資源池的剛性訴求,儘管大家都認同PAI在Blink和AI·OS之間有很大的發揮空間。所幸三方的開放心胸最終達成分工默契,放棄自己的資源池後,PAI-TF成功地撐起了搜尋和推薦演算法全部的模型訓練任務,而且也支援了AI·OS的圖化執行引擎。展望未來PAI-TF可以在AI·OS發展的核心線索上發揮更大作用。

對比Blink和PAI,梳理一下AI·OS的發展脈絡,不難發現規律:AI·OS首先服務於集團頭部客戶發展基礎體系,然後具備產品化能力服務於集團內中長尾,最後再完善產品化成為雲上服務。Blink誕生於AI·OS優化實時計算效率服務好了頭部客戶,然後發展SQL走產品化的路服務好中長尾集團內得以統一,現在也在雲上大力發展。而PAI之前只能服務集團內中長尾,反觀幾家頭部客戶均有自己的訓練平臺,這絕非任性,主因是當時PAI並不足以支撐頭部客戶迭代需求。而今天PAI-TF做出改變相容AI·OS體系,格局會本質改觀,徹底落地的PAI將會同時具備頭部和中長尾的服務能力,集團內統一深度學習的訓練平臺將會水到渠成。

 

AI·OS與圖計算

圖計算在計算引擎學界引領熱潮,在離線場景(包含迭代計算)有豐富的論作,向線上服務領域擴充尋求更快速的驗證在所必然,但在網際網路大資料技術業界鮮有堪稱經典的對標實現,是因為業界技術能力不夠嗎?學界熱潮容易理解,圖論本是經典傾倒無數英雄,而業界缺乏對標更刺激學界投入。只不過業界見到的多數大資料業務場景完整抽象後並非經典的圖計算問題,比如AI·OS對此的抽象是運算元流程圖快速定製,這至多算是一個泛化的圖計算模型。不過在AI·OS體系之上的區域性,經典的圖計算技術的確大有空間,iGraph乃至整個體系準備好隨時被顛覆,不過顛覆之前,需要摸透具備秒級資料更新的最終一致性的線上服務的特點,從Hippo到Suez的能力要素都要逐步具備。是融入體系在iGraph或Suez上快速落地,還是像PAI一樣相容於體系,還是獨立於AI·OS體系之外從頭開始,選擇決定成敗。OLAP與圖計算相似,走向線上也將面臨類似的選擇。對於這類具備面向最終一致性的線上服務,獨立於AI·OS建設,還意味著要開闢獨立資源池,因而也更加需要提供足夠獨特的價值,這方面我還沒有看的很清楚。最後一個和AI·OS關係密切的技術方向是OLTP,因之在資料更新的一致性上要求更高,AI·OS不會妄自涉足。

需要指出的是,集團內外流行的Graph Embedding從線上服務角度來看,和圖計算無關,這個技術叫向量召回,是影像檢索的泛化應用,該技術集團內實現以達摩院機器智慧實驗室最為突出(拍立淘核心技術之一),這部分已是AI·OS體系能力的一部分。


相關文章