導(dǎo)語：作者在《基于內(nèi)容的推薦算法》這篇文章中對基于內(nèi)容的推薦算法做了比較詳細(xì)的講解，其中一類非常重要的內(nèi)容推薦算法是基于標(biāo)簽的倒排索引算法，也是工業(yè)界用的比較多的算法，特別是新聞資訊類、短視頻類產(chǎn)品大量采用該類算法。在本篇文章中作者會結(jié)合電視貓的業(yè)務(wù)場景及工程實(shí)踐經(jīng)驗(yàn)來詳細(xì)講解基于標(biāo)簽的倒排索引算法的原理及工程落地方案細(xì)節(jié)。

本文會從基于標(biāo)簽的推薦算法應(yīng)用場景、基于標(biāo)簽的推薦算法原理介紹、整體架構(gòu)及工程實(shí)現(xiàn)、召回與排序策略、冷啟動策略、未來優(yōu)化方向等6個方面來介紹基于標(biāo)簽的實(shí)時視頻推薦系統(tǒng)。

希望讀者讀完本文，可以完整地了解基于標(biāo)簽的倒排索引算法的產(chǎn)品形態(tài)、算法原理、工程實(shí)現(xiàn)方案，并且能夠基于本文的思路，具備從零開始搭建一套基于標(biāo)簽的算法體系的能力。

如上篇文章《基于Erlang的相似視頻推薦系統(tǒng)》所講，電視貓有長視頻和短視頻各6大類，長視頻對實(shí)時性要求相對沒有那么高，所以本文主要以短視頻的實(shí)時個性化推薦為例來講解。

一、基于標(biāo)簽的推薦算法應(yīng)用場景

在講具體的算法原理及工程實(shí)踐之前，我們先對基于標(biāo)簽的推薦算法可行的產(chǎn)品形態(tài)做簡單介紹，讓讀者知道該類算法可以用到哪些業(yè)務(wù)場景中，從而有一個直觀的印象，方便更好地理解后續(xù)講解的內(nèi)容。這些產(chǎn)品形態(tài)電視貓都落地到了真實(shí)業(yè)務(wù)場景中，下面的圖例也是拿電視貓的產(chǎn)品形態(tài)來舉例說明的。

在《基于內(nèi)容的推薦算法》這篇文章第三節(jié)我們簡單描述了基于內(nèi)容的推薦算法的應(yīng)用場景，而基于標(biāo)簽的推薦是內(nèi)容推薦的一種，應(yīng)用場景也是類似的：完全個性化推薦、標(biāo)的物關(guān)聯(lián)標(biāo)的物推薦(相似視頻推薦)、主題推薦這3類應(yīng)用場景都是可行的，我們下面對這3大業(yè)務(wù)場景簡單一一說明。

1.1完全個性化推薦

完全個性化推薦是為每個用戶生成不一樣的推薦結(jié)果，下圖是電視貓小視頻實(shí)時個性化推薦，基于用戶的(標(biāo)簽)興趣畫像，為用戶推薦跟用戶興趣偏好相似的視頻，用戶可以無限右滑(由于電視貓是客廳端的視頻軟件，靠遙控器交互，所以產(chǎn)品交互方式上跟頭條等手機(jī)端的下拉交互是不一樣的)獲取自己感興趣的推薦結(jié)果，整個算法會根據(jù)用戶的興趣變化實(shí)時為用戶更新推薦結(jié)果。

圖1：電視貓小視頻實(shí)時個性化推薦

1.2標(biāo)的物關(guān)聯(lián)標(biāo)的物推薦（相似視頻推薦）

短視頻相似推薦基于視頻標(biāo)簽構(gòu)建視頻之間的相似度，為每個視頻推薦相似的視頻。

下圖是電視貓短視頻的相似推薦，采用的產(chǎn)品形態(tài)是連播推薦的形式，當(dāng)用戶播放主視頻后，相關(guān)聯(lián)的相似視頻會按照相似度列表連續(xù)播放，最大程度提升用戶體驗(yàn)。

圖2：電視貓短視頻信息流連播推薦

1.3主題推薦

主題推薦根據(jù)用戶播放行為歷史，構(gòu)建用戶興趣畫像，這里是基于節(jié)目的標(biāo)簽來構(gòu)建用戶畫像，基于用戶畫像標(biāo)簽為用戶推薦最感興趣的標(biāo)簽關(guān)聯(lián)的節(jié)目。

下圖是電視貓音樂頻道的主題推薦，根據(jù)作者最近看過的音樂視頻，為作者推薦了“國語”和“器樂教學(xué)”兩個主題相關(guān)的音樂短視頻。

圖3：電視貓音樂頻道主題推薦

講解完了基于標(biāo)簽的推薦產(chǎn)品形態(tài)，相信讀者對基于標(biāo)簽的推薦有了較直觀的認(rèn)知，那么我們在實(shí)際業(yè)務(wù)中怎么實(shí)現(xiàn)這些產(chǎn)品形態(tài)呢？怎么構(gòu)建合適的基于標(biāo)簽的推薦算法呢？在下節(jié)我們會詳細(xì)講解算法基本原理。

二、基于標(biāo)簽的推薦算法原理介紹

我們在《基于內(nèi)容的推薦算法》中對基于標(biāo)簽的個性化推薦算法原理已經(jīng)做過初略介紹，讀過該文章的讀者應(yīng)該有印象，不熟悉也沒關(guān)系，本節(jié)我們會對上節(jié)提到的三個產(chǎn)品形態(tài)：個性化推薦、相似視頻推薦、主題推薦的算法實(shí)現(xiàn)原理做細(xì)致的介紹，方便讀者深入理解算法的實(shí)現(xiàn)細(xì)節(jié)。

2.1個性化推薦（完全個性化范式）

基于標(biāo)簽的個性化推薦算法具體推薦過程見下面圖4：從用戶畫像中獲取用戶的興趣標(biāo)簽，基于用戶的興趣標(biāo)簽從標(biāo)簽->節(jié)目倒排索引表中獲取該標(biāo)簽對應(yīng)的節(jié)目，這樣就可以從用戶關(guān)聯(lián)到節(jié)目了。其中用戶的每個興趣標(biāo)簽及標(biāo)簽關(guān)聯(lián)到的節(jié)目都是有權(quán)重的。

圖4：基于倒排索引的視頻推薦

假設(shè)用戶的興趣標(biāo)簽及對應(yīng)的標(biāo)簽權(quán)重如下，其中?是標(biāo)簽，?是用戶對標(biāo)簽的偏好權(quán)重。

??

假設(shè)標(biāo)簽?關(guān)聯(lián)的視頻分別為：

......

其中、分別是標(biāo)的物及對應(yīng)的權(quán)重，那么

上式中U是用戶對視頻的偏好集合，我們這里將視頻 ??看成向量空間的基，所以有上面的公式。不同的標(biāo)簽可以關(guān)聯(lián)到相同的視頻(因?yàn)椴煌囊曨l可以有相同的標(biāo)簽)，上式中最后一個等號右邊需要合并同類項(xiàng)，將相同基前面的系數(shù)相加。合并同類項(xiàng)后，視頻(基)前面的數(shù)值就是用戶對該視頻的偏好程度了，我們對這些偏好程度降序排列，就可以為用戶做topN推薦了。

上面只是基于用戶興趣畫像來為用戶做推薦的算法原理，實(shí)際業(yè)務(wù)中，用戶的興趣有長期興趣、短期興趣，同時還需要考慮給用戶提供多樣性的推薦及根據(jù)用戶播放過程中的實(shí)時反饋調(diào)整推薦結(jié)果，所以實(shí)際工程上會非常復(fù)雜，這一塊我們會在第三節(jié)的架構(gòu)及工程實(shí)現(xiàn)、第四節(jié)的召回和排序中詳細(xì)說明。

2.2視頻相似推薦（標(biāo)的物關(guān)聯(lián)標(biāo)的物范式）

在本節(jié)我們先來講解怎么利用視頻的標(biāo)簽來計(jì)算兩個視頻之間的相似度，有了視頻之間的相似度就很容易做視頻的相似推薦了。

假設(shè)視頻集合是?，其中?是對應(yīng)的視頻。假設(shè)所有視頻標(biāo)簽集合是?，其中是對應(yīng)的標(biāo)簽。一般n和m都是非常大的數(shù)，從幾十萬到上百萬，甚至更大。每個視頻只有很少的標(biāo)簽，所以將視頻表示成標(biāo)簽的向量的話，一定是稀疏向量，我們可以采用視頻的標(biāo)簽向量表示的余弦相似度來計(jì)算兩個視頻之間的相似度，具體計(jì)算過程如下：

假設(shè)兩個視頻??的向量表示如下(我們按照中標(biāo)簽的順序來編碼向量)，??是對應(yīng)的權(quán)重，如果采用one-hot編碼，?=0 或者??=1，如果標(biāo)簽是有權(quán)重的，?就是對應(yīng)標(biāo)簽的權(quán)重。

?? ? ?

?? ? ?

我們可以采用如下cosine余弦相似度公式來計(jì)算之間的相似度：

? ? ? ?

我們可以計(jì)算出與所有其他視頻(除去?自身)的相似度：

那么?的相似推薦就可以利用上述列表降序排列后取topN作為最終推薦列表。

2.3主題推薦

有了1中介紹個性化推薦的算法原理，就很容易說明怎么做主題推薦了。

首先我們根據(jù)用戶畫像獲取用戶的幾個最感興趣的標(biāo)簽，每個興趣標(biāo)簽就是一個主題，將每個興趣標(biāo)簽關(guān)聯(lián)的節(jié)目推薦給用戶就可以了，下面簡要說明一下。

假設(shè)用戶的興趣標(biāo)簽及對應(yīng)的標(biāo)簽權(quán)重如下，其中是標(biāo)簽，是用戶對標(biāo)簽的偏好權(quán)重。

我們可以將上述集合按照權(quán)重降序排序，選擇k個權(quán)重最大(用戶最喜歡)的標(biāo)簽 ?作為待推薦的主題。再從每個標(biāo)簽關(guān)聯(lián)的節(jié)目(在實(shí)際工程實(shí)現(xiàn)上，我們會事先構(gòu)建標(biāo)簽->節(jié)目的倒排索引表，方便從標(biāo)簽關(guān)聯(lián)到節(jié)目)中選擇對應(yīng)的節(jié)目推薦給用戶。

上面我們簡要講解了三類基于標(biāo)簽的推薦算法的算法原理，下面我們會結(jié)合電視貓的實(shí)踐經(jīng)驗(yàn)來講解這三類推薦產(chǎn)品在工程上是怎么實(shí)現(xiàn)的。

三、整體架構(gòu)及工程實(shí)現(xiàn)

本節(jié)我們來詳細(xì)講解上述三類算法的整體架構(gòu)、核心功能模塊及工程實(shí)現(xiàn)。

這里我們重點(diǎn)只講解個性化推薦和相似視頻推薦兩種推薦產(chǎn)品的架構(gòu)和實(shí)現(xiàn)，主題推薦跟個性化推薦非常相似，我們會簡單說明一下。

電視貓基于標(biāo)簽的個性化短視頻推薦是基于Spark平臺來實(shí)現(xiàn)的，其中流式處理采用Spark Streaming組件，離線處理采用Spark，整個代碼工程整合到了Doraemon框架(不了解的讀者可以參考《推薦系統(tǒng)的工程實(shí)現(xiàn)》這篇文章)中。下面架構(gòu)圖的每一個處理邏輯都抽象為一個算子，封裝在Doraemon框架中，便于業(yè)務(wù)的復(fù)用、拓展和工程維護(hù)。

為了讓各個模塊之間解耦，我們大量采用消息隊(duì)列(RabbitMQ和Kafka)來傳輸消息(數(shù)據(jù))，讓整個推薦系統(tǒng)更加模塊化、結(jié)構(gòu)化。只要定義好兩個模塊(算子)之間的(數(shù)據(jù))協(xié)交互議，就可以獨(dú)立對各個子模塊進(jìn)行優(yōu)化升級而不會互相影響。

節(jié)目倒排索引及用戶畫像是存儲在HBase集群中，方便算法分布式讀取，HBase的數(shù)據(jù)結(jié)構(gòu)如下圖，不熟悉的讀者可以網(wǎng)上搜索了解一下。最終的推薦結(jié)果存儲在CouchBase及Redis中，個性化推薦、主題推薦這類為每個用戶都生成一個推薦結(jié)果的產(chǎn)品形態(tài)，數(shù)據(jù)量會更大，推薦結(jié)果存儲在CouchBase(一個分布式文檔數(shù)據(jù)庫，可以方便橫向擴(kuò)容)中，而相似視頻數(shù)據(jù)量相對較小存儲在Redis這類key-value內(nèi)存數(shù)據(jù)庫中。

圖5：HBase數(shù)據(jù)結(jié)構(gòu)

有了上面的背景知識，現(xiàn)在我們正式來介紹各類算法的工程實(shí)現(xiàn)。

3.1個性化推薦

個性化推薦分為離線模塊和實(shí)時模塊兩部分，離線部分每天更新一次，為全量用戶生成推薦結(jié)果，而實(shí)時部分基于用戶實(shí)時的行為實(shí)時更新推薦列表。離線推薦和實(shí)時推薦相互配合，”交替進(jìn)行“(嚴(yán)格不是交替進(jìn)行，在離線任務(wù)運(yùn)行過程中，只要有用戶在用產(chǎn)品，實(shí)時推薦也是在運(yùn)行的，只不過離線一般在凌晨跑，跑的時間也不會很長，這時用戶比較少，其他時間都是實(shí)時推薦在起作用，所以簡述為交替進(jìn)行)，為用戶提供全天候的推薦服務(wù)(見下面圖6)。

圖6：離線推薦&實(shí)時推薦”交替“，離線每天更新一次，兩次離線推薦之間采用實(shí)時推薦

下圖是基于標(biāo)簽的個性化推薦的整體架構(gòu)，分兩條線，一條線從媒資系統(tǒng)生成節(jié)目標(biāo)簽的倒排索引，另一條線從用戶行為日志生成基于標(biāo)簽的用戶興趣畫像，最終倒排索引和用戶畫像供推薦程序(算子5)使用，為用戶生成推薦。這里為了簡單起見，我們只考慮基于用戶畫像來為用戶做推薦，不考慮其他的各種召回策略，更多的召回策略放到第四節(jié)來講解。

圖7：基于標(biāo)簽的個性化推薦整體架構(gòu)

整個算法實(shí)現(xiàn)主要包括大5核心模塊(對應(yīng)上圖中標(biāo)注1、2、3、4、5的5個算子)，每個算子是作為一個獨(dú)立程序運(yùn)行的，互不影響，其中算子5是最核心的推薦模塊。我們來分別描述一下各個模塊的核心功能及工程實(shí)現(xiàn)。

(1) 新增節(jié)目及標(biāo)簽注入

媒資系統(tǒng)是視頻行業(yè)的內(nèi)容管理系統(tǒng)，負(fù)責(zé)所有內(nèi)容的管理、運(yùn)營、輸出。推薦系統(tǒng)依賴媒資系統(tǒng)的內(nèi)容來源?；跇?biāo)簽的視頻推薦系統(tǒng)從消息隊(duì)列中獲取新增/修改的節(jié)目及標(biāo)簽信息，利用這些消息來構(gòu)建標(biāo)簽<->節(jié)目倒排索引表。該模塊將推薦需要依賴的信息通過消息的方式發(fā)送到消息隊(duì)列的固定topic中，后續(xù)模塊通過監(jiān)聽該topic來獲取新的消息做進(jìn)一步處理。

下面圖7給出了信息的一個簡化版本，消息通過json的方式來組織，包括type(是新入庫的節(jié)目還是對老節(jié)目標(biāo)簽的更新)、sid(節(jié)目唯一標(biāo)識)、title(節(jié)目標(biāo)題)、tags(標(biāo)簽)。

圖8：信息隊(duì)列中消息的結(jié)構(gòu)

標(biāo)簽也是有唯一識別的，即是上圖中的tid，類似視頻的sid，在構(gòu)建倒排索引及用戶畫像過程中通過使用標(biāo)簽的tid可以簡化比較及處理邏輯，減少存儲空間。

標(biāo)簽也是有權(quán)重或者層級結(jié)構(gòu)的，電視貓的標(biāo)簽就有分類標(biāo)簽->欄目標(biāo)簽->內(nèi)容標(biāo)簽三級體系，從粗到細(xì)，這個層級結(jié)構(gòu)跟行業(yè)有很大關(guān)系，不同行業(yè)有不同的分級策略和方法。標(biāo)簽也是有權(quán)重的，權(quán)重衡量標(biāo)簽對節(jié)目的重要程度。在實(shí)際做算法時可以整合這些信息，讓算法更加精準(zhǔn)。本文為了簡化起見，不考慮分級的標(biāo)簽，只考慮平展化的一級標(biāo)簽。

通過消息隊(duì)列來獲取消息的好處有兩點(diǎn)：首先，可以將媒資系統(tǒng)跟推薦系統(tǒng)解耦(一般是兩個不同的團(tuán)隊(duì)來負(fù)責(zé))，方便兩邊系統(tǒng)獨(dú)立擴(kuò)展和升級，只要保持消息格式不變，不影響兩邊業(yè)務(wù)。其次，通過消息隊(duì)列來傳輸信息，可以讓系統(tǒng)做到更加實(shí)時。

在我們的項(xiàng)目中(1)對接的消息隊(duì)列采用RabbitMQ，這一模塊可以由媒資團(tuán)隊(duì)來提供基礎(chǔ)服務(wù)，由媒資團(tuán)隊(duì)來維護(hù)，算法團(tuán)隊(duì)可以給媒資團(tuán)隊(duì)提需求，按照推薦算法需要的字段及規(guī)范提供數(shù)據(jù)即可。

(2) 生成標(biāo)簽節(jié)目倒排索引

該步驟(近)實(shí)時從消息隊(duì)列中獲取節(jié)目的標(biāo)簽信息，為每個節(jié)目構(gòu)建標(biāo)簽<->節(jié)目的倒排索引，方便從節(jié)目關(guān)聯(lián)到標(biāo)簽及從標(biāo)簽關(guān)聯(lián)到節(jié)目。我們采用Spark Streaming流式處理組件來構(gòu)建倒排索引，做到實(shí)時更新索引，索引存儲到HBase集群中，方便后續(xù)實(shí)時處理程序分布式讀取。

標(biāo)簽->節(jié)目倒排索引具體的數(shù)據(jù)存儲格式如下，其中tid是標(biāo)簽的唯一識別碼(編號)、sid是節(jié)目的編號、publishTime是節(jié)目的發(fā)布時間，hot(新聞)、game(游戲)、sports(體育)是不同的短視頻類型，節(jié)目->標(biāo)簽的倒排索引結(jié)構(gòu)類似。

圖9：標(biāo)簽->節(jié)目的HBase存儲結(jié)構(gòu)

基于圖8中消息隊(duì)列中的數(shù)據(jù)結(jié)構(gòu)，算子2(Spark Streaming程序)近實(shí)時(一個時間窗口幾秒鐘)處理消息隊(duì)列中新增的節(jié)目，對標(biāo)簽進(jìn)行簡單處理，獲得標(biāo)簽與節(jié)目的對應(yīng)關(guān)系，并更新到標(biāo)簽->節(jié)目的倒排索引表中。由于處理操作很簡單，這里不細(xì)說。

(3) 用戶行為ETL并注入消息隊(duì)列

用戶行為日志通過簡單的ETL處理，提取關(guān)鍵信息，并將該信息插入對應(yīng)的消息隊(duì)列，供后續(xù)的構(gòu)建用戶畫像模塊生成用戶畫像。

用戶行為日志的核心信息里面一定要包括用戶唯一識別碼和節(jié)目sid及用戶對節(jié)目的偏好(可以用用戶觀看時長來衡量)(見下面圖10)，通過節(jié)目sid我們可以從節(jié)目->標(biāo)簽倒排索引表中查到對應(yīng)的標(biāo)簽。

圖10：用戶核心行為信息

這里對接用戶行為日志的組件，我們采用的是Kafka，整個電視貓的日志分為批和流兩條鏈路，批日志按小時通過ETL入數(shù)據(jù)倉庫，流日志打入Kafka，供后端的實(shí)時處理業(yè)務(wù)(如實(shí)時推薦、實(shí)時報(bào)表、業(yè)務(wù)監(jiān)控等)消費(fèi)。

(4) 生成用戶畫像&播放歷史

該模塊通過從消息隊(duì)列中實(shí)時獲取用戶行為數(shù)據(jù)，為用戶生成基于標(biāo)簽的用戶畫像及播放歷史記錄。

為了能夠反映用戶長期和短期興趣，我們可以生成多個不同時間階段的畫像，如長期畫像(根據(jù)用戶過去幾個月或者更長期的行為)、中期用戶畫像(一天到幾天時間)、短期用戶畫像(幾分鐘到幾個小時)。長期、中期用戶畫像可以采用批處理的方式，每天定時生成一次。而短期用戶畫像最好采用流式處理，實(shí)時捕捉用戶興趣變化。

用戶的歷史記錄用于記錄下用戶播放過的或者跳過的內(nèi)容，這些內(nèi)容對用戶來說是沒有價(jià)值的。記錄下來是為了方便在最終推薦時過濾掉這些內(nèi)容，提升用戶體驗(yàn)。

下圖是短期用戶畫像和用戶歷史行為的HBase數(shù)據(jù)結(jié)構(gòu)，算子4通過從Kafka讀取實(shí)時用戶行為日志，從日志中獲取節(jié)目sid、標(biāo)簽等，最終生成實(shí)時的用戶畫像和更新用戶的播放歷史記錄。

為避免誤解，這里簡單提一些，圖7只展示了利用Spark Streaming實(shí)時的從消息隊(duì)列生成用戶畫像的流程，而離線生成畫像的部分并未展示，離線用戶畫像是利用Spark直接從數(shù)倉讀取離線行為數(shù)據(jù)，通過類似的處理生成用戶中長期戶畫像的(存放在不同的HBase用戶畫像表中)。

圖11：短期用戶畫像(Persona)和用戶歷史行為(action) HBase數(shù)據(jù)結(jié)構(gòu)

(5) 基于用戶畫像和標(biāo)簽節(jié)目倒排索引為用戶做推薦

有了基于標(biāo)簽的用戶畫像及標(biāo)簽->節(jié)目倒排索引，就可以為用戶實(shí)時生成推薦結(jié)果了，通過用戶畫像可以獲取用戶的偏好標(biāo)簽，再基于標(biāo)簽->節(jié)目倒排索引，就可以為用戶關(guān)聯(lián)到節(jié)目了。

這里我們簡單介紹一下利用Spark為用戶離線計(jì)算推薦的方法(實(shí)時推薦在第四節(jié)介紹)，首先Spark從HBase中讀取所有用戶行為數(shù)據(jù)，我們將用戶分為N個Partition，為每個Partition內(nèi)的用戶更新個性化推薦(具體流程參考下面圖12)，將最終推薦結(jié)果通過Kafka插入CouchBase集群，供推薦接口調(diào)用，返回前端展示給用戶。將用戶分為N個Partition的目的是方便做分布式計(jì)算，將推薦結(jié)果通過Kafka插入CouchBase是為了將推薦過程跟接口提供服務(wù)過程解耦合。

其中為單個用戶生成個性推薦(第二節(jié)1中的個性化推薦算法)我們可以封裝成獨(dú)立算子，每個Partition循環(huán)調(diào)用該算子，為該P(yáng)artition中的所有用戶生成個性化推薦。

圖12：基于Spark Streaming為用戶計(jì)算推薦業(yè)務(wù)流

順便說一下，最終的推薦結(jié)果除了要插入CouchBase外，還需要插入一份到HBase中，方便實(shí)時推薦模塊基于該推薦結(jié)果實(shí)時調(diào)整用戶興趣。

這里的難點(diǎn)是怎么基于用戶不同時間階段的興趣畫像來為用戶生成個性化推薦，以及怎么保證內(nèi)容的多樣性，并且要整合用戶實(shí)時的反饋，為用戶提供近實(shí)時的個性化推薦。詳細(xì)的分析我們會在下一節(jié)的召回、排序、實(shí)時更新策略中講解。

3.2相似視頻推薦

下圖是相似視頻推薦的整體架構(gòu)，包含3個部分(對應(yīng)下圖1、2、3三個算子)，其中1、2跟個性化推薦完全一樣，這里不再講解。

下面只針對3來說明。

圖13：基于標(biāo)簽的相似視頻推薦整體架構(gòu)

基于倒排索引生成相似推薦

在前面一節(jié)我們已經(jīng)講解過怎么計(jì)算視頻相似度了，在這里我們簡單描述一下計(jì)算視頻相似度的業(yè)務(wù)流程。

當(dāng)消息隊(duì)列中有新視頻注入時，從節(jié)目倒排索引表中將所有節(jié)目及其標(biāo)簽取出，與新注入的節(jié)目計(jì)算相似度，得到最終的TopN最相似的節(jié)目。這個相似推薦列表我們會插入HBase一份(具體的數(shù)據(jù)結(jié)構(gòu)如下面圖14)，同時通過Kafka消息隊(duì)列插入一份到Redis，插入Redis的這份作為最終推薦結(jié)果，供接口調(diào)用返回前端提供給用戶。插入HBase的這份相似推薦，會用于實(shí)時個性化推薦，根據(jù)用戶實(shí)時行為更新用戶推薦列表，具體怎么用會在下一節(jié)實(shí)時更新策略中講解。

圖14：相似視頻在HBase的數(shù)據(jù)結(jié)構(gòu)

下面我們針對單個節(jié)目怎么利用Spark Streaming來計(jì)算topN相似度做簡單說明，首選將所有需要與節(jié)目A計(jì)算相似度的節(jié)目取出存放到一個RDD中，在計(jì)算時，所有節(jié)目分布在N個Partition中，我們分別計(jì)算A與每個Partition中節(jié)目的topN相似度，最終將N個Partition中topN相似度合并，獲得最終的topN推薦，整個過程參考下面圖15。

圖15：基于Spark Streaming計(jì)算topN相似度算法邏輯

對于新聞、體育等時效性要求高的短視頻，沒必要將庫中所有的視頻都取出來，只需要取最近幾天的就可以了，這樣可以大大減少計(jì)算量。即使取出來了也可以先過濾掉不包含A中標(biāo)簽的節(jié)目(我們是基于標(biāo)簽計(jì)算相似度，如果B的標(biāo)簽跟A的標(biāo)簽都不一樣，相似度肯定為0)，再計(jì)算相似度，也會少好多計(jì)算量(因?yàn)闃?biāo)簽是稀疏的)。

除了上面的計(jì)算外，還需要處理一種情況：我們需要更新已經(jīng)計(jì)算過相似度的視頻的相似度列表，這是因?yàn)樾录尤氲墓?jié)目A可能與B的相似度比B的相似度列表中的節(jié)目相似度更大，這時更新B的相似度列表是必要的。具體更新策略我們這里不講，在《基于Erlang語言的相似視頻推薦系統(tǒng)》中有很詳細(xì)的講解，用Spark做這個更新的過程是類似的，只是實(shí)現(xiàn)方式不一樣。

上面講的整體架構(gòu)是實(shí)時為新視頻生成相似推薦列表。當(dāng)我們第一次啟動工程或者為新的短視頻類型做相似推薦時，是需要一次性計(jì)算所有的視頻相似度的?？尚械姆椒ㄓ袃蓚€，一是將所有視頻導(dǎo)入到消息隊(duì)列中采用實(shí)時的計(jì)算相似度程序計(jì)算，另外一種方式是實(shí)現(xiàn)一套離線的計(jì)算相似度的程序，只用于工程啟動或者新增視頻類型第一次計(jì)算相似度的情形。第一種方法可能一段時間導(dǎo)致隊(duì)列堆積，特別是視頻總量比較大的情況下。我們團(tuán)隊(duì)是采用的第二種方案。

3.3主題推薦

為用戶生成主題推薦的整體架構(gòu)跟個性化推薦類似，我們需要獲取用戶的一批偏好標(biāo)簽，通過標(biāo)簽再關(guān)聯(lián)到一組節(jié)目。

唯一的不同是，個性化推薦會將所有標(biāo)簽及標(biāo)簽關(guān)聯(lián)的節(jié)目根據(jù)權(quán)重合并在一起形成一個匯總的推薦列表，而主題推薦將每個偏好標(biāo)簽形成一個主題，而每個標(biāo)簽關(guān)聯(lián)的節(jié)目就是這個主題的推薦。這里不細(xì)講。

四、個性化推薦的召回與排序策略

在整體架構(gòu)這一節(jié)，我們講解了怎么基于用戶畫像和節(jié)目標(biāo)簽倒排索引為用戶做個性化推薦，重點(diǎn)聚焦在怎么根據(jù)用戶興趣偏好來為用戶生成滿足用戶興趣的推薦。

在本節(jié)我們來深入介紹一下怎么利用更多的召回策略來為用戶生成更加多樣性的內(nèi)容，滿足用戶多樣性的興趣需要，同時怎么實(shí)時捕捉用戶興趣變化。由于短視頻每條時長短，這些處理策略是很有必要的。只根據(jù)用戶興趣推薦會導(dǎo)致“越推薦約窄”的現(xiàn)象，不利于內(nèi)容的分發(fā)及用戶體驗(yàn)的維護(hù)。通過推薦多樣性的內(nèi)容，既可以拓展用戶的興趣空間，也更利于內(nèi)容分發(fā)。

下圖是短視頻推薦召回和排序的流程，首先通過多種召回策略來為用戶生成推薦，通過排序策略來將這些內(nèi)容糅合在一起推薦給用戶。下面我們分別對召回策略和排序策略做簡單講解。

圖16：個性化推薦召回與排序

4.1召回策略

對于短視頻來說，除了基于用戶的興趣來為用戶做推薦外，還可以通過多種方式來為用戶做推薦，具體來說，可行的召回策略有如下6類：

(1) 基于用戶近期興趣的召回

對于短視頻來說，特別是新聞，用戶的興趣是隨著時間變化的，所以我們有必要基于過去較短時間(幾天甚至更短時間內(nèi))生成用戶的興趣畫像，在推薦中整合用戶的近期興趣。

(2)基于用戶長期興趣的召回

用戶的興趣也是穩(wěn)定及緩慢變化的，這要求我們可以為用戶生成較長期(幾個月或者更長)的興趣畫像，在推薦中整合用戶長期興趣。

(3)基于用戶地域的召回

在電視貓APP我們根據(jù)用戶IP是知道用戶所在地區(qū)的，很多內(nèi)容是有地域?qū)傩缘模脩粢矁A向于關(guān)注本地相關(guān)的信息，所以我們可以基于用戶的地域，為用戶召回匹配特定地域的內(nèi)容(部分內(nèi)容是有地域標(biāo)簽的)。

(4) 基于用戶最后一個節(jié)目的關(guān)聯(lián)召回

用戶最后喜歡的的節(jié)目(用戶看完了、有強(qiáng)烈的喜歡偏好)，代表了用戶最近的興趣點(diǎn)，那么我們完全有理由猜測用戶喜歡該節(jié)目的相似節(jié)目，所以我們可以將該節(jié)目相似的節(jié)目推薦給用戶作為召回。電視貓實(shí)時個性化推薦采用該召回策略。

(5) 基于新熱的召回

人對未知的好奇的特性決定了人對新的東西會感興趣，而人從眾的一面又決定了我們很大概率會喜歡大家都喜歡的東西。所以為用戶召回出新熱內(nèi)容是一種非常保險(xiǎn)的策略。一般這類召回也會作為新用戶的默認(rèn)推薦，用于解決冷啟動問題。

(6) 基于差異化類別的召回

為了避免給用戶推薦的內(nèi)容太窄，我們有必要為用戶推薦多樣性的內(nèi)容，挖掘用戶新的興趣點(diǎn)。我們可以將內(nèi)容按照標(biāo)簽分成多類(滿足不同類的內(nèi)容差異性較大)，從每類中隨機(jī)篩選出幾個節(jié)目匯總起來形成一個“大雜燴”，作為一種滿足用戶多樣化需求的召回推薦給用戶。

對于某些產(chǎn)品，如果有關(guān)注某個頻道或者某個作者的功能，這些頻道或者作者來源的內(nèi)容也可以作為一種召回策略。另外，時間對用戶的興趣也是有影響的，不同的內(nèi)容可能適合在不同時段觀看，所以也可以基于時間為用戶生成相關(guān)的推薦作為一種召回策略。

4.2排序策略

前面介紹完了各種可行的召回策略，那么這么多的召回推薦怎么推薦給用戶呢？肯定是不可能一股腦兒都推薦給用戶的。我們需要對這些內(nèi)容進(jìn)行整合、過濾、篩選、排序形成一個更加精細(xì)化的列表推薦給用戶，這就是排序策略需要解決的問題，最終的目的還是提升推薦列表的點(diǎn)擊率，提升用戶的體驗(yàn)。一般來說說排序策略可以分為基于規(guī)則的排序和基于模型的排序，我們在這里分別做簡單介紹。

(1) 基于規(guī)則的排序

基于規(guī)則的排序主要是基于運(yùn)營或者人工策略來進(jìn)行排序，比較主觀，需要一定的業(yè)務(wù)常識和行業(yè)經(jīng)驗(yàn)。比如可以從上面的6種召回策略中每種取一個，循環(huán)選取，直到達(dá)到最終給用戶推薦的數(shù)目為止。假設(shè)下面 是六個召回列表，那么??就是按照上面循環(huán)排序的策略。

?? ? ?

?? ? ?

?? ? ?

?? ? ?

?? ? ?

?? ? ?

? ? ? ?

上面只是給出了一種最直觀簡單的排序策略，根據(jù)不同的產(chǎn)品形態(tài)及業(yè)務(wù)形式還有其他各種不同的排序和合并策略。比如，可以給不同的隊(duì)列不同的權(quán)重，采用一定的概率選擇一個隊(duì)列，不同隊(duì)列也可以選擇不同數(shù)量的節(jié)目。

(2) 基于模型的排序

基于模型的排序，方法跟上面的規(guī)則不一樣，通過用戶行為數(shù)據(jù)訓(xùn)練一個機(jī)器學(xué)習(xí)模型(logistic回歸、深度學(xué)習(xí)等)，該模型可以為每個用戶、節(jié)目對輸出一個用戶對該節(jié)目偏好的概率或者評分，我們會根據(jù)所有召回隊(duì)列中節(jié)目的概率或者評分來降序排列，并將排在前面的TopN推薦給用戶。

基于模型的方法更加客觀可靠，不會受到人類很多主觀因素的影響，可以整合用戶在產(chǎn)品上的所有行為數(shù)據(jù)及用戶自身和標(biāo)的物的數(shù)據(jù)，一般來說效果會更好。這里作者不細(xì)講，未來會單獨(dú)講解排序?qū)W習(xí)方面的知識。

不同召回策略可能會召回重復(fù)的內(nèi)容，我們在排序階段還需要考慮過濾掉重復(fù)的內(nèi)容。排序策略還跟具體的產(chǎn)品交互方式有關(guān)，比如今日頭條APP采用下滑的方式，每次下滑更新12條新的內(nèi)容，這12條新內(nèi)容即是根據(jù)各類召回來為你統(tǒng)一排序推薦給你的。對于電視貓這類OTT端的采用遙控器交互的產(chǎn)品，我們采用圖1這種“無限”右滑的方式來跟用戶交互。

講解完了召回和排序策略，下面針對電視貓短視頻個性化推薦，我們來詳細(xì)講解怎么基于用戶實(shí)時行為為用戶近實(shí)時更新推薦列表。

4.3電視貓個性化實(shí)時更新策略

下面我們對電視貓短視頻實(shí)時個性化推薦的排序方案進(jìn)行簡單描述，供大家參考。我們的推薦分為離線推薦和實(shí)時推薦兩部分。在離線階段，每天我們會根據(jù)上述規(guī)則的方式生成推薦列表，為用戶推薦200個節(jié)目。當(dāng)用戶在使用過程中會實(shí)時更新用戶的推薦列表，整合用戶實(shí)時的興趣變化。

下圖是電視貓實(shí)時更新的架構(gòu)圖，算子1根據(jù)用戶行為日志生成實(shí)時消息到消息隊(duì)列，算子2從消息隊(duì)列獲取待更新的用戶及操作行為，按照一定的規(guī)則來更新原來的推薦列表。推薦列表備份一份在HBase中，在具體更新某個用戶的推薦時讀取HBase中該用戶的推薦列表，對推薦列表進(jìn)行調(diào)整整合用戶實(shí)時興趣變化，調(diào)整完后更新到HBase中，同時再通過Kafka同步一份到CouchBase中，供推薦接口返回前端展示給用戶，這樣用戶的推薦列表就真正更新了，用戶就可以感知到了。

圖17：電視貓實(shí)時個性化推薦實(shí)時更新架構(gòu)

下面我們來說說具體怎么根據(jù)用戶最近的行為更新推薦列表的。

我們將給用戶推薦的200個視頻看成是一個環(huán)(如下面圖18)，每20個節(jié)目看成一頁，當(dāng)用戶起播時，根據(jù)用戶在第一頁的播放行為(第一頁20個節(jié)目中用戶會播自己感興趣的，不感興趣的會跳過，每一頁的內(nèi)容是根據(jù)離線階段用不同的召回策略及規(guī)則排序策略生成的推薦)。我們采用Spark Streaming來處理，假設(shè)5秒是一個窗口(Window)，當(dāng)計(jì)算下一個窗口時，在第二頁最前面插入用戶在第一頁感興趣的節(jié)目的相似節(jié)目，插入的節(jié)目數(shù)量跟用戶在第一個窗口播放過的加上跳過的一樣多，同時第一個窗口播放過的和跳過的節(jié)目從環(huán)中剔除，由于刪除的和插入的一樣多，總隊(duì)列還是保持200個。這時從當(dāng)前用戶播放的位置開始是新的第一頁，回到了隊(duì)列最初的狀態(tài)，整個過程是一個可以“無限右滑”的環(huán)。

圖18：電視貓實(shí)時個性化推薦實(shí)時更新推薦方案

五、冷啟動策略

基于標(biāo)簽的相似視頻推薦基本不存在冷啟動問題，因?yàn)槿魏涡伦⑷氲囊曨l都是包含標(biāo)簽的，并且我們是近實(shí)時為新節(jié)目計(jì)算相似視頻，在極短的時間內(nèi)就會為新節(jié)目計(jì)算出相似推薦。本節(jié)我們來說說實(shí)時個性化推薦冷啟動問題。

因?yàn)槭腔趦?nèi)容的推薦，冷啟動問題沒有那么嚴(yán)重，只要用戶看過一個視頻，這個視頻的標(biāo)簽就是用戶的興趣標(biāo)簽，我們可以為用戶推薦具備該標(biāo)簽的節(jié)目。但是，如果用戶一個節(jié)目都沒看，那要怎么為用戶做推薦呢？

我們可以采用如下3大策略：

(1) 利用新熱節(jié)目作為推薦；

(2) 基于用戶特征(比如用戶地域)來為用戶生成相關(guān)推薦列表；

(3) 從所有視頻中選擇不同類別的視頻推薦給用戶，總有一款是用戶喜歡的。

六、未來優(yōu)化方向

基于標(biāo)簽的推薦算法在電視貓APP上整體效果還不錯，但是還有很多地方是可以做得更好的，現(xiàn)在列舉一些可能的優(yōu)化點(diǎn)，作為后續(xù)我們優(yōu)化的方向，也供大家參考。

6.1增加模型排序模塊

雖然該算法有很多召回策略，但是最終排序展示給用戶時是根據(jù)人工規(guī)則進(jìn)行的，實(shí)時更新也是基于規(guī)則的，多少有一些主觀，可行的優(yōu)化方向是增加一層實(shí)時模型排序算法，將多個人工召回策略丟給排序模塊進(jìn)行算法排序，將排序好的結(jié)果推薦給用戶。

基于模型的排序策略是根據(jù)用戶點(diǎn)擊行為及各類特征進(jìn)行訓(xùn)練的，可以更好地反應(yīng)用戶點(diǎn)擊情況，增加用戶點(diǎn)擊的概率。Google提出的FTRL(Follow-the-regularized-Leader)算法可以有效地構(gòu)建實(shí)時的排序模型，對多類召回結(jié)果進(jìn)行排序，目前在國內(nèi)互聯(lián)網(wǎng)公司有大量應(yīng)用案例，有興趣的讀者可以參考文獻(xiàn)11。目前很多深度學(xué)習(xí)算法(如Wide & Deep)也大量用于推薦排序中。

6.2對重復(fù)的節(jié)目做過濾

特別是新聞、短視頻類APP，會從不同源獲取相關(guān)內(nèi)容，不同來源的內(nèi)容有可能是重復(fù)的，簡單的方法是通過標(biāo)題來判定兩個內(nèi)容是否重復(fù)，雖然相對簡單一些，但是某些時候不一定可靠，比如兩個視頻標(biāo)題差別較大，但是實(shí)際上內(nèi)容是很重復(fù)的。這時就需要通過視頻內(nèi)容(或者文章內(nèi)容)來判定是否重復(fù)了，但是這樣處理成本相對太高，特別是對于視頻。所以，往往通過標(biāo)題來區(qū)分代價(jià)相對較小，精度還可以接受。

處理重復(fù)的方法一般有兩種：事先處理和事后處理。事先處理就是在新視頻入庫時，從所有節(jié)目庫中排查是否有重復(fù)的節(jié)目，如果有就丟棄，否則插入。一般可以采用為每個視頻生成信息指紋，方便做比對。事后處理就是在生成推薦列表后，再做一次過濾，將重復(fù)的視頻去掉只保留其中一個。

6.3整合用戶負(fù)反饋

如果用戶播放某個視頻直接切換到下一個，或者播放很短時間就不播放了，這是一個用戶不喜歡的信號。那么在基于標(biāo)簽的算法中，我們怎么整合這種負(fù)反饋呢？一種可行的策略是，對該視頻包含的標(biāo)簽做負(fù)向處理，即如果用戶畫像中包含該標(biāo)簽，那么我們可以從該標(biāo)簽的權(quán)重中減去一個數(shù)值，代表對該標(biāo)簽的懲罰。目前在我們的算法中是沒有整合負(fù)反饋機(jī)制的。

6.4針對標(biāo)簽的優(yōu)化

基于標(biāo)簽的推薦算法，標(biāo)簽的質(zhì)量直接關(guān)系到推薦的質(zhì)量。在實(shí)際業(yè)務(wù)中標(biāo)簽是存在一些問題的，主要表現(xiàn)為如下幾個方面：

(1) 標(biāo)簽之間是有相關(guān)關(guān)系的，比如恐怖和驚悚就有相似的含義；

(2) 有些標(biāo)簽出現(xiàn)特別頻繁而有些又出現(xiàn)特別稀少；

針對(1)，我們可以盡量將意思相近的標(biāo)簽合并，讓不同標(biāo)簽意思有一定的區(qū)分度。

針對(2)，我們可以剔除掉出現(xiàn)非常稀少的標(biāo)簽(比如只有幾個視頻才有的標(biāo)簽)，這些標(biāo)簽有可能是臟數(shù)據(jù)，對計(jì)算相似度幫助不大，對于出現(xiàn)太過頻繁的標(biāo)簽(非常多的節(jié)目具備該標(biāo)簽)，這類標(biāo)簽區(qū)分度也不大，建議也可以剔除掉。

七、寫在最后

到此為止，基于標(biāo)簽的實(shí)時視頻推薦系統(tǒng)講完了，整個算法及工程實(shí)現(xiàn)細(xì)節(jié)基本上是基于我們在電視貓短視頻推薦的經(jīng)驗(yàn)總結(jié)而成。

基于標(biāo)簽的算法是一類非常常用的推薦算法，算法原理簡單，可解釋性強(qiáng)，在真實(shí)業(yè)務(wù)中得到大量使用，通過我們團(tuán)隊(duì)使用經(jīng)驗(yàn)，效果還是很不錯的，今日頭條的推薦也是將基于標(biāo)簽的推薦算法作為核心模塊之一。

基于標(biāo)簽的推薦算法最大的問題是強(qiáng)依賴于標(biāo)簽的質(zhì)量，標(biāo)簽質(zhì)量好壞直接影響算法效果。

如果要做好標(biāo)簽推薦，需要根據(jù)相關(guān)業(yè)務(wù)事先定義好一套完善的標(biāo)簽體系，需要投入極大的人力成本，并且對團(tuán)隊(duì)NLP方面的技術(shù)也有較高的要求。