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