推薦系統(tǒng)是一種信息過濾技術(shù)，通過從用戶行為中挖掘用戶興趣偏好，為用戶提供個性化的信息，減少用戶的找尋時間，降低用戶的決策成本，讓用戶更加被動地消費(fèi)信息。推薦系統(tǒng)是隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展及應(yīng)用深入而出現(xiàn)的，并在當(dāng)前得到廣泛的關(guān)注，它是一種軟件解決方案，是toC互聯(lián)網(wǎng)產(chǎn)品上的一個模塊。用戶通過與推薦模塊交互，推薦系統(tǒng)通過提供的web服務(wù)，將與用戶興趣匹配的標(biāo)的物篩選出來，組裝成合適的數(shù)據(jù)結(jié)構(gòu)，最終展示給用戶。推薦系統(tǒng)web服務(wù)是前端和后端溝通的橋梁，是推薦結(jié)果傳輸?shù)淖詈笸ǖ溃畔鬏斒欠裢〞常瑐鬏斒欠褡銐蚩焖伲瑢τ脩趔w驗是有極大影響的。本文我們就來講解推薦系統(tǒng)提供web服務(wù)的兩種主要方式，這兩種方式是企業(yè)級推薦系統(tǒng)最常采用的兩種形式。
具體來說，這篇文章我們會從什么是推薦系統(tǒng)web服務(wù)、推薦系統(tǒng)提供web服務(wù)的兩種方式、事先計算型web服務(wù)、實時裝配型web服務(wù)、兩種web服務(wù)方式的優(yōu)劣對比、影響web服務(wù)方案的因素及選擇原則等6個部分來講解。通過本文的介紹，期望讀者可以深刻理解這兩種web服務(wù)方式的具體實現(xiàn)方案以及它們之間的差別，并具備結(jié)合具體的業(yè)務(wù)場景來決策采用哪種方式的能力。
一、什么是推薦系統(tǒng)web服務(wù)
作者在《構(gòu)建優(yōu)質(zhì)的推薦系統(tǒng)服務(wù)》第一節(jié)中已經(jīng)對推薦系統(tǒng)web服務(wù)進(jìn)行了簡單介紹，這里為了讓讀者更好地理解本文的知識點(diǎn)，以及為了內(nèi)容的完整性，對推薦系統(tǒng)web服務(wù)進(jìn)行簡略介紹。
用戶與推薦系統(tǒng)交互的服務(wù)流程見下面圖1，用戶在使用產(chǎn)品過程中與推薦模塊(產(chǎn)品上提供推薦能力的功能點(diǎn))交互，前端(手機(jī)、PC、Pad、智能電視等)請求推薦web服務(wù)，推薦web服務(wù)獲取該用戶的推薦結(jié)果，將推薦結(jié)果返回給前端，前端通過適當(dāng)?shù)匿秩緦⒆罱K的推薦結(jié)果按照一定的樣式和排列規(guī)則在產(chǎn)品上展示出來，這時用戶就可以看到推薦系統(tǒng)給他的推薦結(jié)果了。
圖1：用戶通過推薦web服務(wù)獲取推薦結(jié)果的數(shù)據(jù)交互流程
上圖中的綠色虛線框中的數(shù)據(jù)交互能力就是推薦web服務(wù)的范疇，它是前端(也叫終端)與后端的互動，圖中藍(lán)色方塊(推薦web服務(wù)模塊)是部署在服務(wù)器上的一類軟件服務(wù)，它提供HTTP接口，讓前端可以實時與之交互。用戶與終端的交互屬于視覺及交互設(shè)計范疇，雖然與推薦web服務(wù)無直接關(guān)系，但是是整個推薦服務(wù)能力完整實現(xiàn)必不可少的一環(huán)，也是用戶可以肉眼直接感知到的部分，在整個推薦系統(tǒng)中非常重要，對推薦系統(tǒng)發(fā)揮價值有極大影響，不過不在我們這篇文章的討論范圍，對這一塊感興趣的讀者可以參考《推薦系統(tǒng)的UI交互與視覺展示》這篇文章。
為了給前端提供個性化推薦服務(wù)，上圖中的推薦web服務(wù)模塊需要完成3件事情。首先需要獲得該用戶的推薦結(jié)果(直接獲得已經(jīng)計算好的推薦結(jié)果，這就是第三節(jié)要講的，或者通過臨時計算獲得推薦結(jié)果，這就是第四節(jié)要講的)，其次是將結(jié)果組裝成前端最終需要的數(shù)據(jù)結(jié)構(gòu)(第一步獲得的推薦結(jié)果一般是標(biāo)的物id的列表，實際展示給前端還需要標(biāo)的物的各種metadata信息，如名稱，價格，海報圖等，這些信息的組裝就是在這一步完成的，這些信息一般會存放到關(guān)系型數(shù)據(jù)庫中，或者采用json的形式組織存放到redis、文檔型NoSQL中，所以這里至少還有一次額外的數(shù)據(jù)庫訪問)，最后是響應(yīng)前端的HTTP請求(一般是GET請求)，將最終推薦結(jié)果返回給前端。本文我們講解的推薦系統(tǒng)提供web服務(wù)的兩種方式，就是這里講的第一件事情，即推薦web服務(wù)怎么獲得給用戶的推薦結(jié)果。
推薦web服務(wù)模塊是最終為用戶提供推薦能力的部分，它設(shè)計得好不好直接影響用戶體驗，一般來說，該模塊需要滿足穩(wěn)定、響應(yīng)及時、容錯、可以隨著用戶規(guī)模線性擴(kuò)容等多個條件，具體的細(xì)節(jié)讀者可以參考《構(gòu)建優(yōu)質(zhì)的推薦系統(tǒng)服務(wù)》這篇文章。這里提一下，隨著Docker等容器技術(shù)及kubernetes等容器管理軟件的發(fā)展和成熟，推薦web服務(wù)中的各個子模塊都可以分別部署在容器中，采用微服務(wù)的方式進(jìn)行數(shù)據(jù)交互，這樣就可以高效管理這些服務(wù)，更好地進(jìn)行服務(wù)的監(jiān)控、錯誤恢復(fù)、線性擴(kuò)容等。
上圖只是一種簡化的交互模型，在實際企業(yè)級服務(wù)中，往往比這個更加復(fù)雜，在前端和后端之間往往存在一層CDN層做緩存加速，以減輕前端服務(wù)對后端并發(fā)訪問的壓力(在用戶量大的情況下，推薦系統(tǒng)屬于高并發(fā)服務(wù))，并且一般推薦web服務(wù)中還存在一層Nginx代理層，通過Nginx代理，讓推薦web服務(wù)可以水平擴(kuò)容，以滿足推薦系統(tǒng)高并發(fā)的要求。下面圖2就是一種可行的完整推薦系統(tǒng)服務(wù)方案。
圖2：完整的推薦系統(tǒng)業(yè)務(wù)架構(gòu)圖
如前面所講，雖然推薦web服務(wù)包含前端與后端的交互，前端與后端一般還會有CDN層和Nginx代理層，但本文我們著重關(guān)注的是后端真正提供Web服務(wù)接口模塊及數(shù)據(jù)存儲模塊的實現(xiàn)方案，也即上圖中紅色模塊怎么獲取推薦結(jié)果的架構(gòu)實現(xiàn)方案。該模塊的實現(xiàn)方案可以多樣，主流的實現(xiàn)方式有兩種，我們在下面分三節(jié)來進(jìn)行介紹。
二、推薦系統(tǒng)提供web服務(wù)的兩種方式
推薦系統(tǒng)提供web服務(wù)一般有兩種方式，一種是事先計算型，另一種是實時裝配型。在具體介紹之前，這里我先舉一個比較形象的例子，讓大家更好地理解這兩種實現(xiàn)方式。
假設(shè)我們開了一家餐廳專門送外賣，餐廳提供10種不同的備選套餐。在午市或者晚市叫餐高峰時段，餐廳可以采用如下兩種方案來準(zhǔn)備套餐：第一種方案是事先將這10種套餐每種都做若干份，當(dāng)有客戶叫外賣時，將該客戶叫的這個套餐(已經(jīng)做好了)直接送出去；第二種方式是將這10種套餐需要的原材料都準(zhǔn)備好，部分材料做成半成品(比如比較花時間的肉類)，當(dāng)有用戶叫餐時，將該套餐需要的原材料下鍋快速做好再送出去。
通過上面非常簡化的案例介紹，大家應(yīng)該不難理解，上面提到的第一種準(zhǔn)備套餐的方式就是“事先計算型”，事先將套餐做好，而第二種方式就是“實時裝配型”，當(dāng)用戶叫餐時，臨時做并快速做好。
現(xiàn)在讓我們回到推薦web服務(wù)上，來介紹兩種推薦web服務(wù)方案。事先計算型就是將用戶的推薦結(jié)果事先計算好，放到數(shù)據(jù)庫中存放起來，當(dāng)該用戶在使用產(chǎn)品過程中訪問推薦模塊時，推薦web服務(wù)模塊直接將該用戶計算好的推薦結(jié)果取出來，進(jìn)行適當(dāng)加工(比如過濾掉用戶已經(jīng)看過的視頻)，將最終推薦結(jié)果展示給用戶。實時裝配型是將計算推薦結(jié)果需要的數(shù)據(jù)(一般是各種特征)提前準(zhǔn)備好，當(dāng)用戶訪問推薦模塊時，推薦web服務(wù)通過簡單的計算和組裝(利用前面準(zhǔn)備好的各種特征灌入推薦模型)，生成該用戶的推薦結(jié)果，再將推薦結(jié)果返回給前端并展示給用戶。
理解了這兩種不同的web服務(wù)方式的基本原理，我們在接下來的兩節(jié)中分別對它們的實現(xiàn)細(xì)節(jié)進(jìn)行詳細(xì)介紹，讓讀者更好地理解它們的特性及技術(shù)實現(xiàn)細(xì)節(jié)。
三、事先計算型web服務(wù)
這一節(jié)我們來講解推薦系統(tǒng)事先計算型web服務(wù)的架構(gòu)實現(xiàn)與基本原理(參見下面圖3)。這種方式可能是業(yè)界比較多地采用的一種推薦web服務(wù)架構(gòu)實現(xiàn)方式，作者所在公司的所有推薦服務(wù)基本都是采用的該模式。
圖3：事先計算型web服務(wù)架構(gòu)(綠色虛線框中的模塊即是圖2中的紅色模塊的細(xì)化)
該模式最大的特點(diǎn)是事先將每個用戶的推薦結(jié)果計算出來，存到數(shù)據(jù)庫(一般是NoSQL，如Redis、CouchBase等NoSQL數(shù)據(jù)庫，采用key-value的方式存儲，key就是用戶id，value就是給用戶的推薦結(jié)果，如果是用Redis存，value的數(shù)據(jù)結(jié)構(gòu)可以使Sorted Sets，這種數(shù)據(jù)結(jié)構(gòu)比較適合推薦系統(tǒng)，Sorted Sets中的element可以是推薦的標(biāo)的物id，score是標(biāo)的物的預(yù)測評分或者預(yù)測概率值等，還可以根據(jù)Sorted Sets中的score進(jìn)行分頁篩選等操作)中，當(dāng)有用戶請求時，前端訪問web接口服務(wù)器(前端會帶上用戶的唯一識別id進(jìn)行HTTP請求，這樣就知道是哪個用戶，方便找到該用戶的推薦結(jié)果)，web服務(wù)器從推薦結(jié)果庫中獲取該用戶的推薦結(jié)果(推薦結(jié)果一般只存儲給用戶推薦的標(biāo)的物id列表及部分需要的其他信息，比如算法標(biāo)識，方便后面做AB測試，下面圖4就是一種推薦結(jié)果存儲的數(shù)據(jù)格式，其中id就是標(biāo)的物的唯一識別id)，同時還需要訪問標(biāo)的物metadata數(shù)據(jù)庫(一般存放在關(guān)系型數(shù)據(jù)庫中)，將前端展示需要的其他信息(如標(biāo)的物的名稱、價格、縮略圖等)拼接完整，最終以json的形式(下面圖5就是視頻推薦系統(tǒng)最終拼接好的json格式，互聯(lián)網(wǎng)企業(yè)一般采用的數(shù)據(jù)交互協(xié)議，也可以是其他協(xié)議，google內(nèi)部就采用protobuf協(xié)議)返回給前端展示給用戶。
圖4：推薦結(jié)果存儲的數(shù)據(jù)結(jié)構(gòu)(json形式存儲)
圖5：最終返回給用戶的推薦結(jié)果(json格式)
該架構(gòu)既可以支持T+1推薦模式和實時推薦模式，對于T+1型推薦產(chǎn)品形態(tài)，每天為用戶生成一次推薦結(jié)果，生成推薦結(jié)果時直接替換昨天的推薦結(jié)果就可以了。而對于實時推薦，情況會復(fù)雜一些，實時推薦可能會調(diào)整用戶的推薦結(jié)果(而不是完全替換)，對用戶推薦結(jié)果進(jìn)行增刪形成新的推薦結(jié)果，這時可行的方法有兩個：一是從推薦結(jié)果存儲數(shù)據(jù)庫中讀出該用戶的推薦結(jié)果，按照實時推薦算法邏輯對推薦結(jié)果進(jìn)行修改，再將推薦結(jié)果存進(jìn)去替換掉，另外一種做法是，增加一個中間的鏡像存儲(可以采用HBase等，現(xiàn)在業(yè)界很多推薦算法都基于Hadoop/Spark平臺實現(xiàn)，用大數(shù)據(jù)生態(tài)系的HBase是比較好的選擇)，所有的算法邏輯修改只對鏡像存儲進(jìn)行操作，操作完成后，將鏡像存儲中修改后的推薦結(jié)果同步到最終的推薦庫中，這跟T+1更新就保持一致了，只不過現(xiàn)在是實時推薦，同一個用戶可能一天會更新多次推薦結(jié)果。作者公司的短視頻實時推薦更新就是采用后面的這種方案，感興趣的讀者可以參考《基于標(biāo)簽的實時短視頻推薦系統(tǒng)》這篇文章第三節(jié)1中的介紹。
四、實時裝配型web服務(wù)
本節(jié)我們來講解實時裝配型web服務(wù)的實現(xiàn)原理與架構(gòu)(參考下面圖6)。這種方式事先不計算用戶的推薦結(jié)果，當(dāng)有用戶請求時，web接口服務(wù)器從特征數(shù)據(jù)庫(一般也是存放在Redis、HBase這種非關(guān)系型數(shù)據(jù)庫中)中將該用戶需要的特征取出來，并將特征灌入推薦模型，獲得該用戶的推薦結(jié)果，跟事先計算型一樣，還需要加載推薦標(biāo)的物的metadata信息，拼接成完整的推薦結(jié)果，并返回給前端展示給用戶。
圖6：實時裝配型web服務(wù)架構(gòu)(web接口服務(wù)加載推薦模型)
該web服務(wù)架構(gòu)需要將推薦模型加載到web接口服務(wù)中，可以實時基于用戶特征獲得推薦結(jié)果，這就要求推薦模型可以在極短的時間(毫秒級)內(nèi)獲得推薦結(jié)果，計算一定要快，否則會影響用戶體驗。當(dāng)然另外一種可行的方案是，將推薦模型做成獨(dú)立的web模型服務(wù)，web接口服務(wù)通過HTTP或者RPC訪問模型服務(wù)獲得推薦結(jié)果。具體架構(gòu)如下面圖7，這種方式的好處是推薦模型服務(wù)跟web服務(wù)解耦，可以分別獨(dú)立升級模型服務(wù)和推薦接口服務(wù)，互相之間不會影響，只要保證它們之間數(shù)據(jù)交互的協(xié)議不變就可以了。
圖7：通過推薦模型服務(wù)來獲取推薦結(jié)果的實時裝配型web服務(wù)架構(gòu)
實時裝配型架構(gòu)在實際提供推薦服務(wù)時就與具體的推薦范式是T+1推薦還是實時推薦沒有關(guān)系了，因為在任何時候web接口服務(wù)都是臨時調(diào)用推薦模型為用戶生成推薦結(jié)果，只不過T+1推薦的模型可以一天訓(xùn)練一次，而實時推薦的模型是實時訓(xùn)練的(用戶的每一次操作行為都會產(chǎn)生日志，通過實時日志處理，生成實時特征，灌入實時模型訓(xùn)練流程中，最終完成對模型的實時訓(xùn)練，讓實時模型得到更新)。
業(yè)界流行的TensorFlow Serving就是一種實時裝配型服務(wù)架構(gòu)，它提供web服務(wù)的架構(gòu)模式類似上面圖6的形式，下面對其進(jìn)行簡單介紹，讓讀者更好地理解這種模式。讀者可以查看參考資料1、2、3對TensorFlow Serving進(jìn)行更深入的了解。
TensorFlow Serving是一個靈活的、高性能的機(jī)器學(xué)習(xí)模型在線服務(wù)框架，設(shè)計用于生產(chǎn)系統(tǒng)，可以與訓(xùn)練好的TensorFlow模型高效整合，將訓(xùn)練好的模型部署到線上，使用gRPC作為接口接受外部調(diào)用。TensorFlow Serving支持模型熱更新與自動模型版本管理。
下圖為TensorFlow Serving整個框架圖。Client端會不斷給Manager發(fā)送請求，Manager會根據(jù)版本管理策略管理模型更新，并將最新的模型計算結(jié)果返回給Client端。
圖8：TensorFlow Serving架構(gòu)，圖片來源于TensorFlow Serving官方文檔
FaceBook開源的FAISS(見參考資料4)框架也是業(yè)界用的比較多的一款用于實時裝配型web服務(wù)的框架。FAISS包含幾種相似性搜索方法，它假設(shè)用戶或者標(biāo)的物被表示為向量并由整數(shù)標(biāo)識(用戶和標(biāo)的物用整數(shù)來唯一標(biāo)識，即用戶id和標(biāo)的物id)，可以在海量向量庫中搜索出按照某種相似性計算的最相似的向量列表。FAISS提供了向量之間計算L2（歐幾里德）距離或點(diǎn)積距離的方法，與查詢向量最相似的向量是那些與查詢向量具有最小L2距離或最大點(diǎn)積的向量。FAISS具備在極短的時間(毫秒級)內(nèi)計算某個向量最相似的一組向量的能力。它還支持cosine余弦相似性查詢，因為cosine余弦只不過是向量內(nèi)積的歸一化。
FAISS之所以能夠用于推薦系統(tǒng)提供實時推薦服務(wù)，主要是因為很多推薦算法最終將用戶和標(biāo)的物都表示為向量，通過用戶向量與標(biāo)的物向量的內(nèi)積來衡量用戶對標(biāo)的物的偏好程度，典型的矩陣分解算法就是這種形式。FAISS所起的作用相當(dāng)于圖7中的推薦模型服務(wù)，利用它進(jìn)行推薦的web服務(wù)架構(gòu)就是圖7這種架構(gòu)。最終的推薦模型用數(shù)學(xué)公式表示就是
是內(nèi)積計算，u、v分別是用戶和標(biāo)的物標(biāo)向量，它們之間的內(nèi)積表示用戶對標(biāo)的物的偏好程度。FAISS提供計算用戶最相似的標(biāo)的物的能力，并基于該相似度降序排列，取TopN最相似的標(biāo)的物作為最終的推薦結(jié)果。
五、兩種web服務(wù)方式的優(yōu)劣對比
前面兩節(jié)已經(jīng)對推薦系統(tǒng)兩種提供web服務(wù)方案的技術(shù)細(xì)節(jié)進(jìn)行了詳細(xì)介紹，在真實業(yè)務(wù)場景中可能比這個更復(fù)雜，可能不是單純的某種方案，會有一些變體，在這兩種方案的基礎(chǔ)上做適當(dāng)調(diào)整與變化，可能同一產(chǎn)品的不同推薦形態(tài)采用不同的方式，同一種推薦方案也可能會融合這兩種方式。
在這一節(jié)我們對比一下這兩個方案的優(yōu)缺點(diǎn)，讓大家更好地理解這兩種web服務(wù)方案，同時也為大家在具體推薦業(yè)務(wù)中進(jìn)行選擇提供參考。
1.事先計算型web服務(wù)的優(yōu)缺點(diǎn)
事先計算型最大的優(yōu)勢是提前將推薦結(jié)果準(zhǔn)備好了，這樣在提供推薦服務(wù)時可以直接獲取推薦結(jié)果，因此大大提升了接口服務(wù)的響應(yīng)速度，減少了響應(yīng)時間，對用戶體驗是有極大幫助的。另外，事先計算好了，當(dāng)模型出現(xiàn)問題(比如調(diào)度模型計算的服務(wù)掛了)，最壞的情況是不更新推薦結(jié)果(這時無法插入最新推薦結(jié)果)，用戶訪問時還是可以獲得推薦的，只不過給用戶的是過去一天的推薦結(jié)果。如果是實時計算推薦結(jié)果(實時裝配型)，當(dāng)模型出現(xiàn)問題時就無法獲得推薦結(jié)果，如果接口沒做保護(hù)，這時接口可能會掛掉，導(dǎo)致前端出現(xiàn)無法展示任何推薦結(jié)果的故障，出現(xiàn)開天窗現(xiàn)象(不過好的推薦系統(tǒng)web服務(wù)一般會增加保護(hù)，在這種極端情況下，給定一組默認(rèn)數(shù)據(jù)作為推薦結(jié)果，默認(rèn)推薦是提前緩存在前端的，不受短期網(wǎng)絡(luò)故障影響)，因此，有更好的魯棒性。
事先計算型另一個優(yōu)點(diǎn)是架構(gòu)更加簡單，web接口服務(wù)跟生成推薦過程解耦，可以分別對web接口和推薦結(jié)果計算優(yōu)化升級，而不會互相影響。
事先計算型最大的缺點(diǎn)是，由于要事先為每個用戶生成推薦，實際上很多用戶不是每天都訪問的，真正日活用戶占總活躍用戶(比如月活用戶)的比例是很低的(當(dāng)然像微信這類國民級App除外)，推薦模塊訪問用戶數(shù)一般也遠(yuǎn)小于當(dāng)天日活數(shù)，這就浪費(fèi)了很多計算和存儲資源，特別是有海量用戶的APP，這時有大量的用戶沒有登錄反而需要每天為其計算推薦結(jié)果，這時浪費(fèi)是非常明顯的。
事先計算型另外一個缺點(diǎn)是，事先計算好了，這就失去了靈活性，要調(diào)整修改用戶的推薦結(jié)果成本代價更高(信息流推薦等實時推薦產(chǎn)品是需要對推薦結(jié)果進(jìn)行近實時調(diào)整的)。就像前面的案例講的，套餐做好了，沒法滿足用戶特定的口味了，比如用戶想要重辣，那也沒辦法了。
2.實時裝配型web服務(wù)的優(yōu)缺點(diǎn)
實時裝配型跟事先計算型基本是對稱的，事先計算型的優(yōu)點(diǎn)是它的缺點(diǎn)，事先計算型的缺點(diǎn)反而是它的優(yōu)點(diǎn)。
實時裝配型需要臨時為用戶生成推薦結(jié)果，因此web接口服務(wù)需要多做一步處理，對接口性能有一定負(fù)面影響。另外，當(dāng)推薦模型需要升級調(diào)整或者模型服務(wù)出現(xiàn)問題時(實時裝配型另一種實現(xiàn)方案是推薦模型作為一個獨(dú)立web服務(wù))，會有短暫時間的不可用，這時會導(dǎo)致推薦web接口無法計算出推薦結(jié)果，進(jìn)而無法給前端提供反饋信息。這兩種情況都會影響用戶體驗(當(dāng)然做得好的系統(tǒng)會有熱更新，模型升級不會導(dǎo)致無法響應(yīng)的情況出現(xiàn)，TensorFlow Serving就具備這種能力)。
實時裝備型的架構(gòu)也更加復(fù)雜，耦合度更高(在推薦web接口整合了推薦模型這種實時裝配型中，推薦web接口跟推薦結(jié)果計算是完全耦合在一起的，參見圖6)。
實時裝配型由于是實時為用戶計算推薦結(jié)果，因此相比事先計算型不會占用太多的存儲、計算資源，對于節(jié)省費(fèi)用是有極大幫助的，特別是在海量用戶場景下，這種節(jié)省更加明顯。它的另一個優(yōu)點(diǎn)是對推薦結(jié)果調(diào)整空間大，因為是臨時計算，可以在計算過程中增加一些場景化的處理邏輯，對推薦算法有更好的干預(yù)能力，更加適合實時推薦場景。
上面介紹完了這兩種方案的優(yōu)缺點(diǎn)，我們用一個表格整理一下，方便對比查看它們之間的異同點(diǎn)。
六、影響web服務(wù)方案的因素及選擇原則
在上一節(jié)中，我們對兩種推薦web方案的優(yōu)缺點(diǎn)進(jìn)行了對比介紹，每種方案都有各自的優(yōu)缺點(diǎn)，沒有哪一個方案是完全勝于另一個方案的。那么在實際業(yè)務(wù)落地時，有哪些因素是會影響我們選擇具體的方案呢？我們應(yīng)該怎樣選擇？有什么判斷依據(jù)和準(zhǔn)則嗎？在這一節(jié)中我們試圖從多個角度來回答這些問題。
1.推薦產(chǎn)品形態(tài)的實效性對推薦web服務(wù)選擇的影響
如果推薦產(chǎn)品形態(tài)是T+1型推薦，由于每天只更新一次推薦結(jié)果，可以選擇事先計算型先將推薦結(jié)果計算出來。如果產(chǎn)品形態(tài)是實時信息流推薦，需要整合用戶的實時興趣變化，用戶的每一次行為都會觸發(fā)更新推薦結(jié)果，這時采用臨時裝配型是更好的選擇。當(dāng)然這也不是絕對的，作者所在公司的短視頻信息流推薦，就采用的事先計算型，事先計算型也可以做到近實時更新用戶推薦結(jié)果，前面已經(jīng)提到，對實現(xiàn)細(xì)節(jié)感興趣的讀者可以參考《基于標(biāo)簽的實時短視頻推薦系統(tǒng)》這篇文章。
2.團(tuán)隊架構(gòu)能力、工程實現(xiàn)能力對推薦web服務(wù)選擇的影響
實時裝配型架構(gòu)相對復(fù)雜，耦合度相對更高，在推薦時需要處理的邏輯更多，因此各個子模塊都需要相當(dāng)穩(wěn)定，并且需要具備較高的性能，因此對整個推薦軟件系統(tǒng)的要求更高。因此，如果推薦團(tuán)隊架構(gòu)能力強(qiáng)，人力比較充足的情況下可以選擇實時裝配型方案。
為了更好地整合用戶的實時行為，為用戶提供可見即所得的推薦服務(wù)，很多信息流推薦需要對推薦算法進(jìn)行實時訓(xùn)練，比如Google在2013年推廣的FTRL算法就是對logistic在實時推薦場景下的工程實現(xiàn)，具備更高的工程實現(xiàn)難度，因此，對推薦團(tuán)隊的工程實現(xiàn)能力是有較高要求的。實時裝配型一般需要處理用戶的實時行為日志，用于挖掘用戶實時興趣，構(gòu)建實時模型，這就要求整個系統(tǒng)有更高的實時性，需要一套完善的實時處理架構(gòu)體系的支撐， 這也增加了構(gòu)建這類系統(tǒng)的復(fù)雜性。
前面也提到實時計算型一般需要有一套類似FAISS這樣的實時匹配庫，為用戶在極短的時間內(nèi)搜尋到最喜歡的標(biāo)的物。而搭建這樣一套系統(tǒng)，需要將推薦模型做成獨(dú)立的服務(wù)，并且保證推薦模型web服務(wù)具備穩(wěn)定性、高并發(fā)能力、可拓展性等能力，這也對架構(gòu)能力有極高要求。如果希望采用容器等新技術(shù)來更好地管理推薦模型服務(wù)，這也需要新的學(xué)習(xí)成本和運(yùn)維成本。
3.推薦階段對推薦web服務(wù)選擇的影響
我們知道企業(yè)級推薦系統(tǒng)生成推薦結(jié)果的過程一般分為召回和排序兩個階段(參考《推薦系統(tǒng)產(chǎn)品與算法概述》這篇文章第一節(jié)的介紹)，先使用召回推薦算法從海量標(biāo)的物中篩選出一組(一般幾百上千個)用戶可能感興趣的標(biāo)的物，然后在排序階段利用更加精細(xì)化的推薦算法對結(jié)果進(jìn)行重排序。
由于召回是從所有標(biāo)的物中篩選用戶可能感興趣的，當(dāng)標(biāo)的物數(shù)量龐大時(比如今日頭條有千億級文本、淘寶有上億級商品)，即使召回算法簡單，計算量也是非常大的，一般可以采用事先計算型召回策略(為了整合用戶最近的行為，也可以基于用戶的興趣標(biāo)簽或者用戶最近瀏覽的標(biāo)的物進(jìn)行近實時召回，這類召回策略也屬于事先計算型，比如根據(jù)用戶最近瀏覽的標(biāo)的物召回相似的標(biāo)的物，每個標(biāo)的物相似標(biāo)的物是事先計算好的)。而對于排序推薦算法，只需要從有限的(成百上千)的標(biāo)的物中過濾出用戶最喜歡的幾十個，可以在較短時間內(nèi)計算完，因此排序算法可以采用實時裝配型策略。
當(dāng)然，排序階段也是可以采用事先計算型的，這就相當(dāng)于先召回，再排序?qū)⑼扑]結(jié)果計算好，只不過整個推薦過程將事先計算拆解為召回和排序兩個階段來進(jìn)行了。
其實，直接跟推薦接口銜接的是排序階段，召回階段是不直接參與web服務(wù)的，因此根據(jù)第二節(jié)的定義，嚴(yán)格意義上事先計算型、實時裝配型是不能用于描述召回階段的。不過有些產(chǎn)品的標(biāo)的物數(shù)量不大(比如電影只有幾萬個)，也可以將召回排序融合為一個階段，只用一個算法就可以獲得推薦結(jié)果，或者排序可以采用簡單的規(guī)則和策略，這時排序邏輯可以整合到推薦web接口中，這兩種情況召回階段所起的作用就相當(dāng)于排序階段的作用了，這時可以說召回直接跟web接口進(jìn)行了交互，因此也可以用事先計算型、實時裝配型來描述召回階段。
4.算法形態(tài)對推薦web服務(wù)選擇的影響
推薦算法種類繁多，從簡單的KNN、item-based協(xié)同過濾到復(fù)雜的深度學(xué)習(xí)、強(qiáng)化學(xué)習(xí)推薦算法，不同的算法實現(xiàn)方式、需要的數(shù)據(jù)來源、計算復(fù)雜度等都不一樣。這也導(dǎo)致了算法的使用場景不一樣。
像深層深度學(xué)習(xí)這種模型結(jié)構(gòu)非常復(fù)雜的推薦算法，即使為單個標(biāo)的物打分(即計算出用戶對標(biāo)的物的偏好度)，計算時間也是簡單算法的若干倍，這時在短時間內(nèi)(比如100毫秒之內(nèi))為大量的標(biāo)的物打分是不現(xiàn)實的，因此這類算法一般用于排序階段(排序階段只對成百上千的標(biāo)的物打分)，因此比較適合實時裝配性的策略。
簡單的推薦算法，如item-based協(xié)同過濾、矩陣分解，由于計算復(fù)雜度低，一般用于召回階段，因此是比較適合事先計算型的。
總結(jié)
本文講解了推薦系統(tǒng)提供web服務(wù)的兩種主要方式，一種是事先計算型，提前將用戶的推薦結(jié)果計算出來并存放到NoSQL中，當(dāng)用戶使用推薦模塊時，推薦web服務(wù)直接將該用戶的推薦結(jié)果取出來并組裝成合適的數(shù)據(jù)結(jié)構(gòu)最終在前端展示給用戶，另一種是實時裝配型，我們需要將計算推薦結(jié)果需要的原材料準(zhǔn)備成“半成品”(就是各種特征)，將這些中間結(jié)果事先存起來，當(dāng)用戶使用推薦服務(wù)時，推薦web服務(wù)通過簡單的組裝與計算(調(diào)用封裝好的推薦模型)，將“半成品”加工成該用戶的推薦結(jié)果，并最終給到用戶。
這兩種提供web服務(wù)的推薦方案各有優(yōu)缺點(diǎn)，我們需要根據(jù)公司現(xiàn)在的技術(shù)儲備、人員能力、團(tuán)隊規(guī)模、產(chǎn)品形態(tài)等多個維度進(jìn)行評估和選擇。不管采用哪種方式，最終的目的是一樣的，我們需要為用戶提供個性化的、響應(yīng)及時的優(yōu)質(zhì)推薦服務(wù)。
參考資料
- [基于TensorFlow Serving的深度學(xué)習(xí)在線預(yù)估] https://zhuanlan.zhihu.com/p/46591057
- [手把手教你使用TF服務(wù)將TensorFlow模型部署到生產(chǎn)環(huán)境] https://zhuanlan.zhihu.com/p/60542828
- https://www.tensorflow.org/serving
- https://github.com/facebookresearch/faiss
