揭祕阿里中臺!一文看懂阿里推薦業務的兩項利器

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

從工程的角度看,搜索和推薦既有差異點,又有共同點。阿里巴巴集團的搜索和推薦系統由同一個部門研發,因此很多工程能力是複用的,如搜索和推薦業務的算分服務引擎都是RS/RTP。

本文介紹阿里巴巴推薦的中臺產品—BE召回引擎和RTP算分服務,這是阿里巴巴推薦業務的兩項利器。

召回引擎BE

BE(Basic Engine)是基於阿里巴巴集團另一個更底層的框架服務Suez構建的。在Suez框架服務的基礎上,BE實現了與推薦業務相關的各種功能組件,如向量召回技術、多表join召回,以及以自定義插件形式提供的排序和算分插件接口。

1.架構及工作原理

BE是一個典型的多列searcher+proxy架構,如圖1所示。

image


圖1 BE集羣部署

圖1中的proxy集羣有3個實例,完全對等,互爲備份。searcher集羣有2行4列,這表示I2I等數據被劃分成4份放到4列機器上。每一列上的數據各不相同,但是執行的計算邏輯完全相同,4列合在一起組成完整的一行。2行之間完全對等,互爲備份。

各種I2I/S2I/B2I的召回(search)、合併(union)、關聯(join)、過濾(filter)和排序(sorter)均在searcher本地完成,最後經過proxy的合併排序(merge sorter)返回,如圖2所示。

image


圖2 BE內部邏輯

圖2中的I2I、S2I、C2I都是BE支持的召回功能,BE底層是基於阿里巴巴搜索事業部研發的通用索引和檢索模塊indexlib實現的,這裏主要用到了indexlib的KV和KKV檢索的功能。

顧名思義,KV檢索是輸入一個或者多個K,返回一個或者多個V。KKV檢索是輸入pkey和skey,返回單個值;如果只輸入pkey,不輸入skey,則返回的是值序列。在實際的推薦業務中,主要就是用這兩種檢索召回機制。

合併功能(union):指的是對多張表的檢索結果進行合併,取並集,並記錄召回的來源表的信息和是否被兩張表同時召回的信息。這些召回過程中記錄下來的信息可以用在算分階段,比如不同的來源表權重不同,則最終得分不同;以及如果是兩張表同時召回的,說明被召回的元素命中多種召回策略,則兩張來源表的權重相加作爲最終權重用於算分,得分就更高了。

關聯功能(join):由於左表所存儲的信息有限,從左表召回元素集合之後,還有一些信息存在右表,通過join功能可以獲取右表的信息,讓記錄的字段更豐富。該功能用於算分階段和返回給調用方。

排序功能(sorter):按某個字段或者表達式進行排序,支持用自定義插件實現。

最後,對不同的列(partition)的結果進行合併,然後返回給調用方,這是一個完整的BE召回過程。

2、BE向量召回和應用

時下有一種非常流行的召回機制叫作向量召回,它通過將元素(實體)進行向量化表徵來構建便於高效檢索的索引。在檢索端,也用相同的方式對檢索元素(實體)進行向量化處理,利用檢索技術進行檢索召回,得到距離相近的商品或者元素(實體)集合,並根據距離遠近進行排序。

實際上,這裏用到的底層向量索引和檢索技術是由阿里巴巴達摩院研發的,一方面將其封裝成通用的底層功能庫,集成到BE服務中,用於詞向量和短文本向量召回的場景;一方面將其集成到其他服務(如HA3引擎)中,用於在文本搜索場景下解決文本匹配不足而造成的零少結果問題。

在BE中,向量召回也是一種召回方式,可以與BE最擅長的KV和KKV召回形式同時使用,也可以作爲一種獨立的召回方式實現完整的業務召回。

目前,向量召回已在阿里巴巴集團的大量場景(如猜你喜歡、貓客、SEO等場景)中應用,並取得了不錯的效果。在1688的業務實踐中,我們用BE的向量召回功能實現了SEO內鏈系統的重構,取得了不錯的業務結果。

SEO(Search Engine Optimization,搜索引擎優化)是一種重要的營銷手段,商家通過影響用戶搜索引擎內的自然排名從搜索引擎中獲得儘可能多的免費流量。SEO流程爲:發現→抓取→解析→索引→排名→展現→轉化。其中,內鏈系統就佔了其中的3個重要環節:通過構建內鏈系統擴大搜索發現率、提高網頁爬蟲抓取量。因此,優化SEO內鏈系統對於SEO站內優化非常重要。

1688.com之前的SEO內鏈系統存在覆蓋率不高且不均勻、相關性不佳、零少結果較多的問題。使用BE的向量召回功能重構SEO內鏈系統後,完美地解決了以上問題,召回成功率、覆蓋率、相關性均有大幅提升。從整體效果看,爬蟲量和索引量指標均得到大幅提升。

1688.com的SEO系統的架構如圖3所示。

image


圖3 1688的SEO系統架構

BE是推薦系統負責在線召回的引擎,基於DII算法在線服務平臺實現,融合了搜索從離線到在線的全鏈路技術體系,並依託管控系統,實現了從開發、上線到運維的全生命週期管理。

從邏輯上講,BE主要負責從多種類型的索引表中召回商品,並根據對應的商品信息進行過濾和粗排。其中filter和sorter是算法插件,可以靈活配置在檢索流程的各個環節,具體的過濾和排序邏輯由算法工程師根據業務場景進行編寫。同時,BE也內置了大量的通用組件。在靈活性和可擴展性方面,BE具備一箇中臺產品支持多種推薦業務的能力。

算分服務RTP

爲滿足推薦和搜索兩大業務對score/rank的需求,阿里巴巴搜索事業部在2016年開發了最初的RTP系統Rank Service排序服務器。它是一個支持數據分區、function函數插件化、實時feature特徵和model模型更新的分佈式服務。基於Rank Service我們可以搜索業務的match匹配和rank排序拆分爲兩個獨立的模塊,從而提升業務迭代效率及整體集羣性能。

爲更好地支持算法團隊快速迭代深度模型,賦能業務,搜索事業部又對RTP系統進行了大幅度的迭代和升級。2017年引入了TensorFlow,將整個RTP框架改造成一個圖執行引擎,從而可以支持任意的可用圖描述的機器學習模型。在此基礎上,又進一步增加了按模型分partition的功能,從而解決了超大模型單機無法容納的問題。

在阿里巴巴內部,推薦業務使用了RTP的在線打分功能;搜索業務不僅使用了在線打分功能,還使用RTP對打分的結果進行在線排序。

  1. RTP和TensorFlow Serving

TensorFlow在2017年提供了Tensorflow Serving,可以將訓練好的模型直接上線並提供服務,RTP也支持將TensorFlow的模型上線並提供服務。那麼,問題來了,既然已有TensorFlow Serving,爲什麼還要用RTP?引用RTP開發團隊資深技術專家以琛的觀點,相比TensorFlow Serving,RTP有如下3方面特點和優勢。

對於大規模打分場景而言,大部分的數據從請求中帶入是不合適的,而RTP系統本地有數據存儲的能力,而且是基於Suez框架的表存儲,有高效的壓縮讀取機制,同時還能完全支持實時鏈路。

RTP系統額外增加的feature產生、數據讀取、插件等機制,使其能夠做到靈活支撐業務邏輯。

RTP系統是基於Suez框架開發的,因此能繼承其管控系統、分佈式行列服務等能力,這使得我們的系統擁有了數據分片、模型分片的能力,從而在大規模模型或者數據應用場景中,發揮巨大優勢。

Suez在線服務框架是搜索事業部自研的大數據在線服務的通用抽象(要求具備秒級數據更新的最終一致性)。Suez框架統一了以下3個維度的工作。

索引存儲(全文檢索、圖檢索、深度學習模型)

索引管理(全量、增量及實時更新)

服務管理(最終一致性、切流降級擴縮容等)

下面用一張圖來描述RTP與Suez框架的關係。

圖4是RTP系統的架構圖。圖中Tf_search是RTP的內核,基於Indexlib和Suez Worker承載對外提供端口服務。Suez Worker的部署由Suez admin完成和管理,而Suez worker和Suez admin的機器資源(如CPU、內存等)都是通過一個叫作Hippo的資源調度框架來管理的。

image


圖4 RTP系統架構

RTP和TensorFlow Serving一樣,基本的功能就是將模型進行加載並提供端口對外服務。下面,首先從阿里巴巴網站的搜索和推薦業務來闡述RTP在其中的位置;然後,介紹RTP的模型和數據更新機制;

接着,從RTP提供對外服務接口開始,一步步深挖RTP是如何借鑑TensorFlow的圖化思想來實現既支持TensorFlow的原生深度模型,又支持LR模型、GBDT等傳統模型的;最後,介紹在面對海量的數據和模型時,RTP在工作效率、穩定性及性能方面具備的獨特優勢。

  1. RTP在阿里巴巴的應用

RTP應用在阿里巴巴的搜索和推薦業務中。對於搜索業務,RTP不僅用於對商品集合進行在線打分,也用於對商品集合按規則進行排序。對於推薦業務,RTP主要用於對商品集合批量打分。

圖5是從搜索架構的視角看RTP的位置和作用。Rank Service和RTP內部其實是基於同一份二進制文件拉起的服務,都可以認爲是寬泛意義上的RTP。兩者的差異在於加載的模型不同,因而作用不同。

圖中左下角的Rank Service加載的是Hobbit和Unicorn的Graph,作用是打分和排序;圖中右下角的RTP加載的是深度模型的Graph,如WDL模型,作用是打分。

Rank Service將商品集合信息請求RTP,RTP算分後將結果返回給Rank Service,然後按分值進行排序,這些都是在Hobbit和Unicorn的Graph中完成的。

image


圖5 RTP架構角色

我們接下來再從推薦架構的視角看RTP的位置和作用。推薦架構相對簡潔,基於RTP使用模型對商品集合進行在線打分。

在阿里巴巴,ABFS(Ali Basic Feature Service)提供的是用戶實時行爲特徵服務。IGraph既可以提供商品維度的信息,也可以提供用戶行爲的信息,是一個非常重要的圖存儲引擎,而BE則是推薦召回引擎。

圖6中的TPP是將上述在線服務編排、處理、整合的一個平臺。首先,TPP使用買家ID請求ABFS和IGraph,獲取用戶實時行爲和離線行爲特徵;然後,將這些行爲作爲條件去請求BE,進行商品集合的召回;

最後,將商品集合、商品特徵、用戶特徵一起請求RTP,對商品進行打分。在打分完成後,還會在TPP內部進行排序及翻頁處理,然後再傳出給調用方。

image


圖6 推薦系統架構

上述典型的搜索和推薦業務是對批量的商品進行打分或者排序,除此之外,RTP還承接了其他類似的推薦業務,如對榜單、直播、短視頻等進行打分。另外,RTP還承接了打分和排序以外的模型服務,例如1688的智能文案在線生成服務。

  1. RTP模型和數據更新

原生的TensorFlow模型(如saved model)是不區分模型和數據的,只有模型的概念。這裏的模型實際包含了兩類信息:一類是圖的結構,一類是參數的權重數據。在一個目錄下存了多個文件,共同存儲上述兩類信息。RTP也支持saved model格式,不過這並不是RTP在生產環境的主流使用方式。

在生產環境的主流使用方式中,RTP出於對性能和數據容量的考慮,會將TensorFlow的原生模型按RTP的格式要求進行轉換,分成兩部分:一部分是抽取和轉成網絡結構,可以認爲是模型的元數據,採用GRAPH.def的文件存放和使用;

另一部分是參數和對應的權重信息,採用KV表的形式進行分發和使用。RTP藉助Suez框架將上述兩部分信息進行分發並加載到內存中。上述網絡結構的更新是非實時的,可以做到小時級別的更新,而參數和對應的權重支持實時更新,已應用在2019年的天貓“雙11”大促中。

另外,RTP還有一部分信息可以做到實時更新,這就是內容表(item table)。在主流的應用場景中,內容表是一個超級大表,也是一個KV表,Key是商品ID,Value是商品維度的原始特徵。

這麼做是爲了減小從請求串中傳遞的參數大小。大部分商品維度的特徵可以從服務器本地的KV表中讀取,而不是從請求串中解析。試想一下,如果數千個商品維度的特徵都從請求串中傳遞,這個請求串會非常大,僅解析請求串、反序列化對象就會消耗不少時間。

  1. RTP對外接口服務

一個系統想在競爭對手如林的環境中生存下來並推廣開去,不斷提升系統的用戶體驗很重要。在不同的業務場景和開發場景中,不同的使用者會要求不同的調用方式。RTP的對外接口支持用多種請求調用的方式來滿足多種場景的需求,如圖7所示。

image


圖7 RTP請求模式

RTP支持基於HTTP和ARPC兩種協議的請求方式。其中,基於HTTP協議的請求方式與其他平臺差別不大,整體過程就是在HTTP客戶端將所有的輸入拼裝成JSON對象,按POST協議進行請求;

然後在RTP服務端將JSON對象解析爲tensor input張量輸入和tensor fetch張量讀片以及其他的相關信息,調用TensorFlow Graph的執行器運行模型,得到fetch讀片的具體內容;最後用同樣的方式封裝成JSON對象並返回給客戶端。

對於基於ARPC協議的請求方式,其支持兩種請求對象:一種是PBRequest,也就是JSON對象封裝成了PB對象,其優點是對於單個請求附帶了大量的商品id集合的場景,有比較大的性能提升;

一種是GraphRequest,這種請求是通過RTP客戶端的SDK封裝好tensor的input、fetch以及其他信息,存儲到GraphRequest對象中,通過ARPC調用RTP,在RTP協議轉換層將這些tensor信息傳遞給Tensor-Flow圖執行器運行模型,得到輸出的fetch的tensor。

基於HTTP協議的請求格式主要用於開發過程中的調試,在生產環境中會使用基於ARPC協議的請求格式。

  1. RTP內部實現原理

前面講到,RTP將模型拆分成兩部分:一部分是純粹的圖結構,一部分是參數和權重數據。RTP會對圖進行轉化,將Training Graph訓練圖轉成Inference Graph推理圖,並對某些節點進行替換改寫,使之能夠讀取本地數據KV表。圖8所示是對訓練出來的模型圖進行添加和裁剪的過程。

image


圖8 模型加載

添加一些節點,如Placeholder,用於外部請求數據的輸入;也會添加一些Feature Generator特徵生成器相關的節點,用於對請求串中輸入的數據進行特徵生成。

這些特徵生成節點如果涉及商品維度的特徵生成,往往會和本地的內容表關聯,在節點執行時,會檢索本地內容表,獲取商品維度的數據,然後進行特徵生成。另外,會對某些節點(如Loss節點)進行刪除,因爲前向預測時,這些節點是用不上的。

RTP在阿里巴巴集團的搜索和推薦體系中佔據了非常重要的位置,工程實現的管控系統對訓練和上線流程的封裝讓整個過程非常順暢,讓算法工程師能專注於模型的優化,從而大大提高算法的生產效率。

RTP基於圖化的內核設計思想,支持將各種原生的算法模型都轉成圖化模型的形式,具備極強的通用性,這也是RTP在集團內部如此受歡迎的原因之一。同時,RTP結合Suez框架提供的本地數據存儲和查詢機定製開發了一些圖化操作算子,提升了模型預測的計算性能。

RTP服務端具備分佈式存儲數據和分片部署的能力,讓數以億計的商品維度的數據不再通過網絡傳輸,減少了網絡傳輸,極大提升了模型執行的性能。RTP依託Suez框架實現了模型和數據的實時更新能力,讓模型能快速捕捉當前的變化,提升準確性。

本文摘編於《阿里巴巴B2B電商算法實戰》經出版方授權發佈。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-29
本文作者: 阿里CBU技術部
本文來自:“CSDN”,瞭解相關信息可以關注“CSDN

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章