從工程的角度看，搜索和推薦既有差異點，又有共同點。阿里巴巴集團的搜索和推薦系統(tǒng)由同一個部門研發(fā)，因此很多工程能力是復用的，如搜索和推薦業(yè)務的算分服務引擎都是RS/RTP。
本文介紹阿里巴巴推薦的中臺產品—BE召回引擎和RTP算分服務，這是阿里巴巴推薦業(yè)務的兩項利器。
召回引擎BE
BE（Basic Engine）是基于阿里巴巴集團另一個更底層的框架服務Suez構建的。在Suez框架服務的基礎上，BE實現了與推薦業(yè)務相關的各種功能組件，如向量召回技術、多表join召回，以及以自定義插件形式提供的排序和算分插件接口。
1.架構及工作原理
BE是一個典型的多列searcher+proxy架構，如圖1所示。
圖1 BE集群部署
圖1中的proxy集群有3個實例，完全對等，互為備份。searcher集群有2行4列，這表示I2I等數據被劃分成4份放到4列機器上。每一列上的數據各不相同，但是執(zhí)行的計算邏輯完全相同，4列合在一起組成完整的一行。2行之間完全對等，互為備份。
各種I2I/S2I/B2I的召回（search）、合并（union）、關聯（join）、過濾（filter）和排序（sorter）均在searcher本地完成，最后經過proxy的合并排序（merge sorter）返回，如圖2所示。
圖2 BE內部邏輯
圖2中的I2I、S2I、C2I都是BE支持的召回功能，BE底層是基于阿里巴巴搜索事業(yè)部研發(fā)的通用索引和檢索模塊indexlib實現的，這里主要用到了indexlib的KV和KKV檢索的功能。
顧名思義，KV檢索是輸入一個或者多個K，返回一個或者多個V。KKV檢索是輸入pkey和skey，返回單個值；如果只輸入pkey，不輸入skey，則返回的是值序列。在實際的推薦業(yè)務中，主要就是用這兩種檢索召回機制。
合并功能（union）：指的是對多張表的檢索結果進行合并，取并集，并記錄召回的來源表的信息和是否被兩張表同時召回的信息。這些召回過程中記錄下來的信息可以用在算分階段，比如不同的來源表權重不同，則最終得分不同；以及如果是兩張表同時召回的，說明被召回的元素命中多種召回策略，則兩張來源表的權重相加作為最終權重用于算分，得分就更高了。
關聯功能（join）：由于左表所存儲的信息有限，從左表召回元素集合之后，還有一些信息存在右表，通過join功能可以獲取右表的信息，讓記錄的字段更豐富。該功能用于算分階段和返回給調用方。
排序功能（sorter）：按某個字段或者表達式進行排序，支持用自定義插件實現。
最后，對不同的列（partition）的結果進行合并，然后返回給調用方，這是一個完整的BE召回過程。
2、BE向量召回和應用
時下有一種非常流行的召回機制叫作向量召回，它通過將元素（實體）進行向量化表征來構建便于高效檢索的索引。在檢索端，也用相同的方式對檢索元素（實體）進行向量化處理，利用檢索技術進行檢索召回，得到距離相近的商品或者元素（實體）集合，并根據距離遠近進行排序。
實際上，這里用到的底層向量索引和檢索技術是由阿里巴巴達摩院研發(fā)的，一方面將其封裝成通用的底層功能庫，集成到BE服務中，用于詞向量和短文本向量召回的場景；一方面將其集成到其他服務（如HA3引擎）中，用于在文本搜索場景下解決文本匹配不足而造成的零少結果問題。
在BE中，向量召回也是一種召回方式，可以與BE最擅長的KV和KKV召回形式同時使用，也可以作為一種獨立的召回方式實現完整的業(yè)務召回。
目前，向量召回已在阿里巴巴集團的大量場景（如猜你喜歡、貓客、seo等場景）中應用，并取得了不錯的效果。在1688的業(yè)務實踐中，我們用BE的向量召回功能實現了SEO內鏈系統(tǒng)的重構，取得了不錯的業(yè)務結果。
SEO（Search Engine Optimization，搜索引擎優(yōu)化）是一種重要的營銷手段，商家通過影響用戶搜索引擎內的自然排名從搜索引擎中獲得盡可能多的免費流量。SEO流程為：發(fā)現→抓取→解析→索引→排名→展現→轉化。其中，內鏈系統(tǒng)就占了其中的3個重要環(huán)節(jié)：通過構建內鏈系統(tǒng)擴大搜索發(fā)現率、提高網頁爬蟲抓取量。因此，優(yōu)化SEO內鏈系統(tǒng)對于SEO站內優(yōu)化非常重要。
1688.com之前的SEO內鏈系統(tǒng)存在覆蓋率不高且不均勻、相關性不佳、零少結果較多的問題。使用BE的向量召回功能重構SEO內鏈系統(tǒng)后，完美地解決了以上問題，召回成功率、覆蓋率、相關性均有大幅提升。從整體效果看，爬蟲量和索引量指標均得到大幅提升。
1688.com的SEO系統(tǒng)的架構如圖3所示。
圖3 1688的SEO系統(tǒng)架構
BE是推薦系統(tǒng)負責在線召回的引擎，基于DII算法在線服務平臺實現，融合了搜索從離線到在線的全鏈路技術體系，并依托管控系統(tǒng)，實現了從開發(fā)、上線到運維的全生命周期管理。
從邏輯上講，BE主要負責從多種類型的索引表中召回商品，并根據對應的商品信息進行過濾和粗排。其中filter和sorter是算法插件，可以靈活配置在檢索流程的各個環(huán)節(jié)，具體的過濾和排序邏輯由算法工程師根據業(yè)務場景進行編寫。同時，BE也內置了大量的通用組件。在靈活性和可擴展性方面，BE具備一個中臺產品支持多種推薦業(yè)務的能力。
算分服務RTP
為滿足推薦和搜索兩大業(yè)務對score/rank的需求，阿里巴巴搜索事業(yè)部在2016年開發(fā)了最初的RTP系統(tǒng)Rank Service排序服務器。它是一個支持數據分區(qū)、function函數插件化、實時feature特征和model模型更新的分布式服務。基于Rank Service我們可以搜索業(yè)務的match匹配和rank排序拆分為兩個獨立的模塊，從而提升業(yè)務迭代效率及整體集群性能。
為更好地支持算法團隊快速迭代深度模型，賦能業(yè)務，搜索事業(yè)部又對RTP系統(tǒng)進行了大幅度的迭代和升級。2017年引入了TensorFlow，將整個RTP框架改造成一個圖執(zhí)行引擎，從而可以支持任意的可用圖描述的機器學習模型。在此基礎上，又進一步增加了按模型分partition的功能，從而解決了超大模型單機無法容納的問題。
在阿里巴巴內部，推薦業(yè)務使用了RTP的在線打分功能；搜索業(yè)務不僅使用了在線打分功能，還使用RTP對打分的結果進行在線排序。
1. RTP和TensorFlow Serving
TensorFlow在2017年提供了Tensorflow Serving，可以將訓練好的模型直接上線并提供服務，RTP也支持將TensorFlow的模型上線并提供服務。那么，問題來了，既然已有TensorFlow Serving，為什么還要用RTP？引用RTP開發(fā)團隊資深技術專家以琛的觀點，相比TensorFlow Serving，RTP有如下3方面特點和優(yōu)勢。
-
對于大規(guī)模打分場景而言，大部分的數據從請求中帶入是不合適的，而RTP系統(tǒng)本地有數據存儲的能力，而且是基于Suez框架的表存儲，有高效的壓縮讀取機制，同時還能完全支持實時鏈路。
-
RTP系統(tǒng)額外增加的feature產生、數據讀取、插件等機制，使其能夠做到靈活支撐業(yè)務邏輯。
-
RTP系統(tǒng)是基于Suez框架開發(fā)的，因此能繼承其管控系統(tǒng)、分布式行列服務等能力，這使得我們的系統(tǒng)擁有了數據分片、模型分片的能力，從而在大規(guī)模模型或者數據應用場景中，發(fā)揮巨大優(yōu)勢。
Suez在線服務框架是搜索事業(yè)部自研的大數據在線服務的通用抽象（要求具備秒級數據更新的最終一致性）。Suez框架統(tǒng)一了以下3個維度的工作。
-
索引存儲（全文檢索、圖檢索、深度學習模型）
-
索引管理（全量、增量及實時更新）
-
服務管理（最終一致性、切流降級擴縮容等）
下面用一張圖來描述RTP與Suez框架的關系。
圖4是RTP系統(tǒng)的架構圖。圖中Tf_search是RTP的內核，基于Indexlib和Suez Worker承載對外提供端口服務。Suez Worker的部署由Suez admin完成和管理，而Suez worker和Suez admin的機器資源（如CPU、內存等）都是通過一個叫作Hippo的資源調度框架來管理的。
圖4 RTP系統(tǒng)架構
RTP和TensorFlow Serving一樣，基本的功能就是將模型進行加載并提供端口對外服務。下面，首先從阿里巴巴網站的搜索和推薦業(yè)務來闡述RTP在其中的位置；然后，介紹RTP的模型和數據更新機制；
接著，從RTP提供對外服務接口開始，一步步深挖RTP是如何借鑒TensorFlow的圖化思想來實現既支持TensorFlow的原生深度模型，又支持LR模型、GBDT等傳統(tǒng)模型的；最后，介紹在面對海量的數據和模型時，RTP在工作效率、穩(wěn)定性及性能方面具備的獨特優(yōu)勢。
2. RTP在阿里巴巴的應用
RTP應用在阿里巴巴的搜索和推薦業(yè)務中。對于搜索業(yè)務，RTP不僅用于對商品集合進行在線打分，也用于對商品集合按規(guī)則進行排序。對于推薦業(yè)務，RTP主要用于對商品集合批量打分。
圖5是從搜索架構的視角看RTP的位置和作用。Rank Service和RTP內部其實是基于同一份二進制文件拉起的服務，都可以認為是寬泛意義上的RTP。兩者的差異在于加載的模型不同，因而作用不同。
圖中左下角的Rank Service加載的是Hobbit和Unicorn的Graph，作用是打分和排序；圖中右下角的RTP加載的是深度模型的Graph，如WDL模型，作用是打分。
Rank Service將商品集合信息請求RTP，RTP算分后將結果返回給Rank Service，然后按分值進行排序，這些都是在Hobbit和Unicorn的Graph中完成的。
圖5 RTP架構角色
我們接下來再從推薦架構的視角看RTP的位置和作用。推薦架構相對簡潔，基于RTP使用模型對商品集合進行在線打分。
在阿里巴巴，ABFS（Ali Basic Feature Service）提供的是用戶實時行為特征服務。IGraph既可以提供商品維度的信息，也可以提供用戶行為的信息，是一個非常重要的圖存儲引擎，而BE則是推薦召回引擎。
圖6中的TPP是將上述在線服務編排、處理、整合的一個平臺。首先，TPP使用買家ID請求ABFS和IGraph，獲取用戶實時行為和離線行為特征；然后，將這些行為作為條件去請求BE，進行商品集合的召回；
最后，將商品集合、商品特征、用戶特征一起請求RTP，對商品進行打分。在打分完成后，還會在TPP內部進行排序及翻頁處理，然后再傳出給調用方。
圖6 推薦系統(tǒng)架構
上述典型的搜索和推薦業(yè)務是對批量的商品進行打分或者排序，除此之外，RTP還承接了其他類似的推薦業(yè)務，如對榜單、直播、短視頻等進行打分。另外，RTP還承接了打分和排序以外的模型服務，例如1688的智能文案在線生成服務。
3. RTP模型和數據更新
原生的TensorFlow模型（如saved model）是不區(qū)分模型和數據的，只有模型的概念。這里的模型實際包含了兩類信息：一類是圖的結構，一類是參數的權重數據。在一個目錄下存了多個文件，共同存儲上述兩類信息。RTP也支持saved model格式，不過這并不是RTP在生產環(huán)境的主流使用方式。
在生產環(huán)境的主流使用方式中，RTP出于對性能和數據容量的考慮，會將TensorFlow的原生模型按RTP的格式要求進行轉換，分成兩部分：一部分是抽取和轉成網絡結構，可以認為是模型的元數據，采用GRAPH.def的文件存放和使用；
另一部分是參數和對應的權重信息，采用KV表的形式進行分發(fā)和使用。RTP借助Suez框架將上述兩部分信息進行分發(fā)并加載到內存中。上述網絡結構的更新是非實時的，可以做到小時級別的更新，而參數和對應的權重支持實時更新，已應用在2019年的天貓“雙11”大促中。
另外，RTP還有一部分信息可以做到實時更新，這就是內容表（item table）。在主流的應用場景中，內容表是一個超級大表，也是一個KV表，Key是商品ID，Value是商品維度的原始特征。
這么做是為了減小從請求串中傳遞的參數大小。大部分商品維度的特征可以從服務器本地的KV表中讀取，而不是從請求串中解析。試想一下，如果數千個商品維度的特征都從請求串中傳遞，這個請求串會非常大，僅解析請求串、反序列化對象就會消耗不少時間。
4. RTP對外接口服務
一個系統(tǒng)想在競爭對手如林的環(huán)境中生存下來并推廣開去，不斷提升系統(tǒng)的用戶體驗很重要。在不同的業(yè)務場景和開發(fā)場景中，不同的使用者會要求不同的調用方式。RTP的對外接口支持用多種請求調用的方式來滿足多種場景的需求，如圖7所示。
圖7 RTP請求模式
RTP支持基于HTTP和ARPC兩種協(xié)議的請求方式。其中，基于HTTP協(xié)議的請求方式與其他平臺差別不大，整體過程就是在HTTP客戶端將所有的輸入拼裝成JSON對象，按POST協(xié)議進行請求；
然后在RTP服務端將JSON對象解析為tensor input張量輸入和tensor fetch張量讀片以及其他的相關信息，調用TensorFlow Graph的執(zhí)行器運行模型，得到fetch讀片的具體內容；最后用同樣的方式封裝成JSON對象并返回給客戶端。
對于基于ARPC協(xié)議的請求方式，其支持兩種請求對象：一種是PBRequest，也就是JSON對象封裝成了PB對象，其優(yōu)點是對于單個請求附帶了大量的商品id集合的場景，有比較大的性能提升；
一種是GraphRequest，這種請求是通過RTP客戶端的SDK封裝好tensor的input、fetch以及其他信息，存儲到GraphRequest對象中，通過ARPC調用RTP，在RTP協(xié)議轉換層將這些tensor信息傳遞給Tensor-Flow圖執(zhí)行器運行模型，得到輸出的fetch的tensor。
基于HTTP協(xié)議的請求格式主要用于開發(fā)過程中的調試，在生產環(huán)境中會使用基于ARPC協(xié)議的請求格式。
5. RTP內部實現原理
前面講到，RTP將模型拆分成兩部分：一部分是純粹的圖結構，一部分是參數和權重數據。RTP會對圖進行轉化，將Training Graph訓練圖轉成Inference Graph推理圖，并對某些節(jié)點進行替換改寫，使之能夠讀取本地數據KV表。圖8所示是對訓練出來的模型圖進行添加和裁剪的過程。
圖8 模型加載
添加一些節(jié)點，如Placeholder，用于外部請求數據的輸入；也會添加一些Feature Generator特征生成器相關的節(jié)點，用于對請求串中輸入的數據進行特征生成。
這些特征生成節(jié)點如果涉及商品維度的特征生成，往往會和本地的內容表關聯，在節(jié)點執(zhí)行時，會檢索本地內容表，獲取商品維度的數據，然后進行特征生成。另外，會對某些節(jié)點（如Loss節(jié)點）進行刪除，因為前向預測時，這些節(jié)點是用不上的。
RTP在阿里巴巴集團的搜索和推薦體系中占據了非常重要的位置，工程實現的管控系統(tǒng)對訓練和上線流程的封裝讓整個過程非常順暢，讓算法工程師能專注于模型的優(yōu)化，從而大大提高算法的生產效率。
RTP基于圖化的內核設計思想，支持將各種原生的算法模型都轉成圖化模型的形式，具備極強的通用性，這也是RTP在集團內部如此受歡迎的原因之一。同時，RTP結合Suez框架提供的本地數據存儲和查詢機定制開發(fā)了一些圖化操作算子，提升了模型預測的計算性能。
RTP服務端具備分布式存儲數據和分片部署的能力，讓數以億計的商品維度的數據不再通過網絡傳輸，減少了網絡傳輸，極大提升了模型執(zhí)行的性能。RTP依托Suez框架實現了模型和數據的實時更新能力，讓模型能快速捕捉當前的變化，提升準確性。
本文摘編于《阿里巴巴B2B電商算法實戰(zhàn)》經出版方授權發(fā)布。
