導語：作者在《基于內容的推薦算法》這篇文章中對基于內容的推薦算法做了比較詳細的講解，其中一類非常重要的內容推薦算法是基于標簽的倒排索引算法，也是工業界用的比較多的算法，特別是新聞資訊類、短視頻類產品大量采用該類算法。在本篇文章中作者會結合電視貓的業務場景及工程實踐經驗來詳細講解基于標簽的倒排索引算法的原理及工程落地方案細節。

本文會從基于標簽的推薦算法應用場景、基于標簽的推薦算法原理介紹、整體架構及工程實現、召回與排序策略、冷啟動策略、未來優化方向等6個方面來介紹基于標簽的實時視頻推薦系統。

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

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

一、基于標簽的推薦算法應用場景

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

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

1.1完全個性化推薦

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

圖1：電視貓小視頻實時個性化推薦

1.2標的物關聯標的物推薦（相似視頻推薦）

短視頻相似推薦基于視頻標簽構建視頻之間的相似度，為每個視頻推薦相似的視頻。

下圖是電視貓短視頻的相似推薦，采用的產品形態是連播推薦的形式，當用戶播放主視頻后，相關聯的相似視頻會按照相似度列表連續播放，最大程度提升用戶體驗。

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

1.3主題推薦

主題推薦根據用戶播放行為歷史，構建用戶興趣畫像，這里是基于節目的標簽來構建用戶畫像，基于用戶畫像標簽為用戶推薦最感興趣的標簽關聯的節目。

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

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

講解完了基于標簽的推薦產品形態，相信讀者對基于標簽的推薦有了較直觀的認知，那么我們在實際業務中怎么實現這些產品形態呢？怎么構建合適的基于標簽的推薦算法呢？在下節我們會詳細講解算法基本原理。

二、基于標簽的推薦算法原理介紹

我們在《基于內容的推薦算法》中對基于標簽的個性化推薦算法原理已經做過初略介紹，讀過該文章的讀者應該有印象，不熟悉也沒關系，本節我們會對上節提到的三個產品形態：個性化推薦、相似視頻推薦、主題推薦的算法實現原理做細致的介紹，方便讀者深入理解算法的實現細節。

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

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

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

假設用戶的興趣標簽及對應的標簽權重如下，其中?是標簽，?是用戶對標簽的偏好權重。

??

假設標簽?關聯的視頻分別為：

......

其中、分別是標的物及對應的權重，那么

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

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

2.2視頻相似推薦（標的物關聯標的物范式）

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

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

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

?? ? ?

?? ? ?

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

? ? ? ?

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

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

2.3主題推薦

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

首先我們根據用戶畫像獲取用戶的幾個最感興趣的標簽，每個興趣標簽就是一個主題，將每個興趣標簽關聯的節目推薦給用戶就可以了，下面簡要說明一下。

假設用戶的興趣標簽及對應的標簽權重如下，其中是標簽，是用戶對標簽的偏好權重。

我們可以將上述集合按照權重降序排序，選擇k個權重最大(用戶最喜歡)的標簽 ?作為待推薦的主題。再從每個標簽關聯的節目(在實際工程實現上，我們會事先構建標簽->節目的倒排索引表，方便從標簽關聯到節目)中選擇對應的節目推薦給用戶。

上面我們簡要講解了三類基于標簽的推薦算法的算法原理，下面我們會結合電視貓的實踐經驗來講解這三類推薦產品在工程上是怎么實現的。

三、整體架構及工程實現

本節我們來詳細講解上述三類算法的整體架構、核心功能模塊及工程實現。

這里我們重點只講解個性化推薦和相似視頻推薦兩種推薦產品的架構和實現，主題推薦跟個性化推薦非常相似，我們會簡單說明一下。

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

為了讓各個模塊之間解耦，我們大量采用消息隊列(RabbitMQ和Kafka)來傳輸消息(數據)，讓整個推薦系統更加模塊化、結構化。只要定義好兩個模塊(算子)之間的(數據)協交互議，就可以獨立對各個子模塊進行優化升級而不會互相影響。

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

圖5：HBase數據結構

有了上面的背景知識，現在我們正式來介紹各類算法的工程實現。

3.1個性化推薦

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

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

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

圖7：基于標簽的個性化推薦整體架構

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

(1) 新增節目及標簽注入

媒資系統是視頻行業的內容管理系統，負責所有內容的管理、運營、輸出。推薦系統依賴媒資系統的內容來源。基于標簽的視頻推薦系統從消息隊列中獲取新增/修改的節目及標簽信息，利用這些消息來構建標簽<->節目倒排索引表。該模塊將推薦需要依賴的信息通過消息的方式發送到消息隊列的固定topic中，后續模塊通過監聽該topic來獲取新的消息做進一步處理。

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

圖8：信息隊列中消息的結構

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

標簽也是有權重或者層級結構的，電視貓的標簽就有分類標簽->欄目標簽->內容標簽三級體系，從粗到細，這個層級結構跟行業有很大關系，不同行業有不同的分級策略和方法。標簽也是有權重的，權重衡量標簽對節目的重要程度。在實際做算法時可以整合這些信息，讓算法更加精準。本文為了簡化起見，不考慮分級的標簽，只考慮平展化的一級標簽。

通過消息隊列來獲取消息的好處有兩點：首先，可以將媒資系統跟推薦系統解耦(一般是兩個不同的團隊來負責)，方便兩邊系統獨立擴展和升級，只要保持消息格式不變，不影響兩邊業務。其次，通過消息隊列來傳輸信息，可以讓系統做到更加實時。

在我們的項目中(1)對接的消息隊列采用RabbitMQ，這一模塊可以由媒資團隊來提供基礎服務，由媒資團隊來維護，算法團隊可以給媒資團隊提需求，按照推薦算法需要的字段及規范提供數據即可。

(2) 生成標簽節目倒排索引

該步驟(近)實時從消息隊列中獲取節目的標簽信息，為每個節目構建標簽<->節目的倒排索引，方便從節目關聯到標簽及從標簽關聯到節目。我們采用Spark Streaming流式處理組件來構建倒排索引，做到實時更新索引，索引存儲到HBase集群中，方便后續實時處理程序分布式讀取。

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

圖9：標簽->節目的HBase存儲結構

基于圖8中消息隊列中的數據結構，算子2(Spark Streaming程序)近實時(一個時間窗口幾秒鐘)處理消息隊列中新增的節目，對標簽進行簡單處理，獲得標簽與節目的對應關系，并更新到標簽->節目的倒排索引表中。由于處理操作很簡單，這里不細說。

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

用戶行為日志通過簡單的ETL處理，提取關鍵信息，并將該信息插入對應的消息隊列，供后續的構建用戶畫像模塊生成用戶畫像。

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

圖10：用戶核心行為信息

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

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

該模塊通過從消息隊列中實時獲取用戶行為數據，為用戶生成基于標簽的用戶畫像及播放歷史記錄。

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

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

下圖是短期用戶畫像和用戶歷史行為的HBase數據結構，算子4通過從Kafka讀取實時用戶行為日志，從日志中獲取節目sid、標簽等，最終生成實時的用戶畫像和更新用戶的播放歷史記錄。

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

圖11：短期用戶畫像(Persona)和用戶歷史行為(action) HBase數據結構

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

有了基于標簽的用戶畫像及標簽->節目倒排索引，就可以為用戶實時生成推薦結果了，通過用戶畫像可以獲取用戶的偏好標簽，再基于標簽->節目倒排索引，就可以為用戶關聯到節目了。

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

其中為單個用戶生成個性推薦(第二節1中的個性化推薦算法)我們可以封裝成獨立算子，每個Partition循環調用該算子，為該Partition中的所有用戶生成個性化推薦。

圖12：基于Spark Streaming為用戶計算推薦業務流

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

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

3.2相似視頻推薦

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

下面只針對3來說明。

圖13：基于標簽的相似視頻推薦整體架構

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

在前面一節我們已經講解過怎么計算視頻相似度了，在這里我們簡單描述一下計算視頻相似度的業務流程。

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

圖14：相似視頻在HBase的數據結構

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

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

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

除了上面的計算外，還需要處理一種情況：我們需要更新已經計算過相似度的視頻的相似度列表，這是因為新加入的節目A可能與B的相似度比B的相似度列表中的節目相似度更大，這時更新B的相似度列表是必要的。具體更新策略我們這里不講，在《基于Erlang語言的相似視頻推薦系統》中有很詳細的講解，用Spark做這個更新的過程是類似的，只是實現方式不一樣。

上面講的整體架構是實時為新視頻生成相似推薦列表。當我們第一次啟動工程或者為新的短視頻類型做相似推薦時，是需要一次性計算所有的視頻相似度的。可行的方法有兩個，一是將所有視頻導入到消息隊列中采用實時的計算相似度程序計算，另外一種方式是實現一套離線的計算相似度的程序，只用于工程啟動或者新增視頻類型第一次計算相似度的情形。第一種方法可能一段時間導致隊列堆積，特別是視頻總量比較大的情況下。我們團隊是采用的第二種方案。

3.3主題推薦

為用戶生成主題推薦的整體架構跟個性化推薦類似，我們需要獲取用戶的一批偏好標簽，通過標簽再關聯到一組節目。

唯一的不同是，個性化推薦會將所有標簽及標簽關聯的節目根據權重合并在一起形成一個匯總的推薦列表，而主題推薦將每個偏好標簽形成一個主題，而每個標簽關聯的節目就是這個主題的推薦。這里不細講。

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

在整體架構這一節，我們講解了怎么基于用戶畫像和節目標簽倒排索引為用戶做個性化推薦，重點聚焦在怎么根據用戶興趣偏好來為用戶生成滿足用戶興趣的推薦。

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

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

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

4.1召回策略

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

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

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

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

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

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

在電視貓APP我們根據用戶IP是知道用戶所在地區的，很多內容是有地域屬性的，用戶也傾向于關注本地相關的信息，所以我們可以基于用戶的地域，為用戶召回匹配特定地域的內容(部分內容是有地域標簽的)。

(4) 基于用戶最后一個節目的關聯召回

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

(5) 基于新熱的召回

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

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

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

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

4.2排序策略

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

(1) 基于規則的排序

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

?? ? ?

?? ? ?

?? ? ?

?? ? ?

?? ? ?

?? ? ?

? ? ? ?

上面只是給出了一種最直觀簡單的排序策略，根據不同的產品形態及業務形式還有其他各種不同的排序和合并策略。比如，可以給不同的隊列不同的權重，采用一定的概率選擇一個隊列，不同隊列也可以選擇不同數量的節目。

(2) 基于模型的排序

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

基于模型的方法更加客觀可靠，不會受到人類很多主觀因素的影響，可以整合用戶在產品上的所有行為數據及用戶自身和標的物的數據，一般來說效果會更好。這里作者不細講，未來會單獨講解排序學習方面的知識。

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

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

4.3電視貓個性化實時更新策略

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

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

圖17：電視貓實時個性化推薦實時更新架構

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

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

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

五、冷啟動策略

基于標簽的相似視頻推薦基本不存在冷啟動問題，因為任何新注入的視頻都是包含標簽的，并且我們是近實時為新節目計算相似視頻，在極短的時間內就會為新節目計算出相似推薦。本節我們來說說實時個性化推薦冷啟動問題。

因為是基于內容的推薦，冷啟動問題沒有那么嚴重，只要用戶看過一個視頻，這個視頻的標簽就是用戶的興趣標簽，我們可以為用戶推薦具備該標簽的節目。但是，如果用戶一個節目都沒看，那要怎么為用戶做推薦呢？

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

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

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

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

六、未來優化方向

基于標簽的推薦算法在電視貓APP上整體效果還不錯，但是還有很多地方是可以做得更好的，現在列舉一些可能的優化點，作為后續我們優化的方向，也供大家參考。

6.1增加模型排序模塊

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

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

6.2對重復的節目做過濾

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

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

6.3整合用戶負反饋

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

6.4針對標簽的優化

基于標簽的推薦算法，標簽的質量直接關系到推薦的質量。在實際業務中標簽是存在一些問題的，主要表現為如下幾個方面：

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

(2) 有些標簽出現特別頻繁而有些又出現特別稀少；

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

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

七、寫在最后

到此為止，基于標簽的實時視頻推薦系統講完了，整個算法及工程實現細節基本上是基于我們在電視貓短視頻推薦的經驗總結而成。

基于標簽的算法是一類非常常用的推薦算法，算法原理簡單，可解釋性強，在真實業務中得到大量使用，通過我們團隊使用經驗，效果還是很不錯的，今日頭條的推薦也是將基于標簽的推薦算法作為核心模塊之一。

基于標簽的推薦算法最大的問題是強依賴于標簽的質量，標簽質量好壞直接影響算法效果。

如果要做好標簽推薦，需要根據相關業務事先定義好一套完善的標簽體系，需要投入極大的人力成本，并且對團隊NLP方面的技術也有較高的要求。