上一篇從總體上介紹了推薦系統(tǒng)，推薦系統(tǒng)online和offline是兩個(gè)組成部分，其中offline負(fù)責(zé)數(shù)據(jù)的收集，存儲(chǔ)，統(tǒng)計(jì)，模型的訓(xùn)練等工作；online部分負(fù)責(zé)處理用戶的請(qǐng)求，模型數(shù)據(jù)的使用，online learning等。本篇因?yàn)閛nline中有比較復(fù)雜的ranking，ranking又分為離線訓(xùn)練和online learning，本篇主要介紹online部分的reall，ranking部分下篇介紹。先從整體流程圖開始紹，數(shù)據(jù)流分為兩部分：
用戶請(qǐng)求數(shù)據(jù)，一般是由用戶下拉刷新或APP發(fā)送的默認(rèn)請(qǐng)求，通過連接網(wǎng)關(guān)，請(qǐng)求發(fā)送到推進(jìn)引擎；
用戶產(chǎn)生[隱式反饋或顯示反饋]1，這部分?jǐn)?shù)據(jù)是由APP從后臺(tái)收集，通過網(wǎng)關(guān)進(jìn)入flume，然后進(jìn)入kafka為后面模塊使用做準(zhǔn)備。
下面會(huì)根據(jù)這兩部分展開討論。
這部分包括流量分配和ABTest兩個(gè)模塊，流量分配模塊主要是根據(jù)需求來動(dòng)態(tài)進(jìn)行流量的分配，需要做到線上實(shí)時(shí)修改實(shí)時(shí)響應(yīng)；ABTest是為Web和App的頁面或流程設(shè)計(jì)兩個(gè)版本（A/B）或多個(gè)版本（A/B/n），同時(shí)隨機(jī)的分別讓一定比例的客戶訪問，然后通過統(tǒng)計(jì)學(xué)方法進(jìn)行分析，比較各版本對(duì)于給定目標(biāo)的轉(zhuǎn)化效果。你們可能覺得這兩個(gè)模塊功能有些冗余，其實(shí)并非如此，有一些單純營(yíng)運(yùn)的需求是不需要進(jìn)ABTest的。以視頻推薦為例解釋一下 這個(gè)問題，假設(shè)營(yíng)運(yùn)有這樣的需求：“他們根據(jù)數(shù)據(jù)發(fā)現(xiàn)，iOS用戶觀看視頻更喜歡購買會(huì)員進(jìn)行免除廣告，Andriod用戶更傾向于觀看網(wǎng)劇”（當(dāng)然這只是一種假設(shè)），所以iOS在進(jìn)行流量分配的時(shí)候會(huì)把付費(fèi)視頻比例提高，而Andriod會(huì)把原創(chuàng)網(wǎng)劇比例提高。然后新的一種算法或者UI希望知道是否會(huì)表現(xiàn)更好，這種情況就需要進(jìn)行ABTest了，對(duì)照組和實(shí)驗(yàn)組里面iOS和Android都是包含的。這個(gè)部分并非是推薦系統(tǒng)的重點(diǎn)，以后有機(jī)會(huì)再開專題講ABTest，所以這里就不再詳細(xì)介紹了。
推薦引擎主要就包括，gateway，recall（match），ranking，其中reall主要offline通過各種算法，最經(jīng)典的就是基于用戶行為的矩陣分解，包括itemCF、userCF、ALS，還有基于深度學(xué)習(xí)的wise&&deep等方法，后面講offline的時(shí)候會(huì)著重說各種算法如何使用和適合的場(chǎng)景。
現(xiàn)在我們就默認(rèn)為，各種算法已經(jīng)訓(xùn)練完畢，然后會(huì)生成一些二進(jìn)制文件，如下圖，這些就是offline算法收斂后的權(quán)重向量結(jié)果
文件格式都是二進(jìn)制，打開我們也看不懂，這里就不打開了，如果有人好奇可以私信我。這些產(chǎn)生后，如何到線上使用呢？用最土的辦法，通過腳本每天定時(shí)cp到線上的server。也可以通過sql或者nosql數(shù)據(jù)庫等方法，但是這個(gè)文件一般比較大，圖里展示的只是我其中一個(gè)實(shí)驗(yàn)，日活大約百萬級(jí)用戶的訓(xùn)練結(jié)果數(shù)據(jù)，如果后面用戶更多，item更豐富這個(gè)文件也就越大，使用數(shù)據(jù)庫是不是好方式有待商榷。
這個(gè)模塊只要負(fù)責(zé)用戶請(qǐng)求的處理，主要功能包括請(qǐng)求參數(shù)檢查，參數(shù)解析，結(jié)果組裝返回。gateway業(yè)務(wù)比較輕量級(jí)，其中只有一個(gè)問題就是“假曝光”，假曝光是相對(duì)真曝光而言的，真曝光是指推送給用戶的內(nèi)容且用戶看到了，假曝光就是指，推送給用戶，但是未向用戶展示的內(nèi)容。推薦系統(tǒng)為了避免重復(fù)推薦，所以基于UUID存儲(chǔ)推薦歷史，存儲(chǔ)時(shí)間是幾小時(shí)，或者1天，再或幾天，這個(gè)需要根據(jù)各自的業(yè)務(wù)情況，也要考慮資源庫的大小。假曝光的處理可以在gateway中，把推送的message_id在gateway寫入到nosql中，然后根據(jù)真曝光數(shù)據(jù)在離線pipeline中可以獲取到，在離線pipeline定時(shí)運(yùn)行時(shí)把假曝光的message_id的數(shù)據(jù)歸還到recall隊(duì)列中。
用戶請(qǐng)求到recall引擎后，會(huì)根據(jù)用戶行為和相關(guān)配置，啟動(dòng)不同的召回器，下發(fā)召回任務(wù)，用戶行為只要是看是否為新用戶進(jìn)冷啟動(dòng)，相關(guān)配置可能就是地區(qū)，國(guó)家等差異。用戶的userprofile如果少于幾個(gè)行為，一般建議為5-10個(gè)點(diǎn)擊行為，少于這個(gè)標(biāo)準(zhǔn)屬于冷啟動(dòng)用戶，那么在recall manager的隊(duì)列里只有冷啟動(dòng)召回器和熱門召回器。熱門召回器是為了保證推薦內(nèi)容的熱門度，而冷啟動(dòng)召回器是保證推薦結(jié)果的新鮮度。recall引擎還要負(fù)責(zé)任務(wù)分配，根據(jù)推薦場(chǎng)景，按召回源進(jìn)行任務(wù)拆分，關(guān)鍵是讓分布式任務(wù)到達(dá)負(fù)載均衡。
在各個(gè)召回器返回后recall manager收集返回結(jié)果，也就是各個(gè)召回器的返回的message_id的倒排隊(duì)列，然后再進(jìn)行一次整體的ranking。
下面再展開介紹一下召回器內(nèi)部框架
召回階段，獲取候選集，一般從基于用戶畫像、用戶偏好、熱門label等維度進(jìn)行召回，如果是用戶畫像中點(diǎn)擊少于10個(gè)會(huì)使用冷啟動(dòng)服務(wù)進(jìn)行召回；
過濾階段，基于人工規(guī)則，和政策規(guī)則，避免涉黃，避免政治明感等內(nèi)容，例如最近的未成年孕婦等進(jìn)行過濾，總之計(jì)算保留合法的，合乎運(yùn)營(yíng)需要的結(jié)果；
特征計(jì)算階段，結(jié)合用戶實(shí)時(shí)行為、用戶畫像、知識(shí)圖譜，計(jì)算出召回的候選集的特征向量；
排序階段，使用算法模型對(duì)召回候選集進(jìn)行粗排序，因?yàn)橐话阌脩粽?qǐng)求10條數(shù)據(jù)，召回樣本大概在200-400個(gè)所以在召回器的排序內(nèi)會(huì)進(jìn)行序列重新調(diào)整，然后總體ranking時(shí)會(huì)選取粗排序的前100或前200結(jié)果，并非召回結(jié)果都是用，避免不必要的計(jì)算，增加響應(yīng)時(shí)間。
在召回、排序階段都是基于message_id，并沒有包含文章內(nèi)容或是視頻信息，這些內(nèi)容會(huì)在ranking后，在detial服務(wù)中對(duì)推薦的返回結(jié)果的進(jìn)行拼裝，detail服務(wù)后還會(huì)有一層對(duì)整體結(jié)果的調(diào)整服務(wù)即tuner，下篇會(huì)詳細(xì)介紹。
聯(lián)系客服
