推薦系統之--- 推薦系統實例

前面幾章介紹了各類各樣的數據和基於這些數據的推薦算法。在實際系統中，前面幾章提到的數據大都存在，所以如何設計一個真實的推薦系統處理不一樣的數據，根據不一樣的數據設計算法，並將這些算法融合到一個系統當中是本章討論的主要問題。本章將首先介紹推薦系統的外圍架構，而後介紹推薦系統的架構，並對架構中每一個模塊的設計進行深刻討論。

 

一、外圍框架

通常來講，每一個網站都會有一個UI系統，UI系統負責給用戶展現網頁並和用戶交互。

網站會經過日誌系統將用戶在UI上的各類各樣的行爲記錄到用戶行爲日誌中。日誌可能存儲在內存緩存裏，也可能存儲在數據庫中，也可能存儲在文件系統中。

而推薦系統經過分析用戶的行爲日誌，給用戶生成推薦列表，最終展現到網站的界面上。

 

從上面的結構能夠看到，推薦系統要發揮強大的做用，除了推薦系統自己，主要還依賴於兩個條件——界面展現和用戶行爲數據。

 經過必定方式展現物品，主要包括物品的標題、縮略圖和介紹等。
 不少推薦界面都提供了推薦理由，理由能夠增長用戶對推薦結果的信任度。
 推薦界面還須要提供一些按鈕讓用戶對推薦結果進行反饋，這樣才能讓推薦算法不斷改善用戶的個性化推薦體驗。
在設計推薦界面時，咱們能夠綜合考慮其餘網站的設計並結合本身網站的特色。

數據收集和存儲

個性化推薦算法依賴於用戶行爲數據，而在任何一個網站中都存在着各類各樣的用戶行爲數據。那麼如何存取這些數據就是推薦系統須要解決的首要問題。表7-1展現了一個假想的電子商務網站上的典型用戶行爲數據。如表所示，從產生行爲的用戶角度看，有些行爲是隻有註冊用戶才能產生的，而有些行爲是全部用戶均可以產生的。從規模上看，瀏覽網頁、搜索記錄的規模都很大，由於這種行爲全部用戶都能產生，並且平均每一個用戶都會產生不少這些行爲。

購買、收藏行爲規模中等，由於只有註冊用戶才能產生這種行爲，但購買行爲又是電商網站的主要行爲，因此它們相對於評論來講規模更大，但相對於網頁瀏覽行爲來講規模要小得多，最後剩下的行爲是註冊用戶裏的一小部分人才有的，因此規模不會很大。從實時存取的角度上看，購買、收藏、評論、評分、分享等行爲都是須要實時存取的，由於只要用戶有了這些行爲，界面上就須要體現出來，好比用戶購買了商品後，用戶的我的購買列表中就應當即顯示用戶購買的商品。而有些行爲，好比瀏覽網頁的行爲和搜索行爲並不須要實時存取。

 

推薦系統架構

根據上面的抽象，能夠設計一種基於特徵的推薦系統架構。如圖7-3所示，當用戶到來以後，推薦系統須要爲用戶生成特徵，而後對每一個特徵找到和特徵相關的物品，從而最終生成用戶的推薦列表。

於是，推薦系統的核心任務就被拆解成兩部分，一個是如何爲給定用戶生成特徵，另外一個是如何根據特徵找到物品。

 

用戶的特徵種類很是多，主要包括以下幾類。
 人口統計學特徵 包括用戶的年齡、性別、國籍和民族等用戶在註冊時提供的信息。

 用戶的行爲特徵 包括用戶瀏覽過什麼物品、收藏過什麼物品、給什麼物品打過什麼樣的分數等用戶行爲相關的特徵。同時，用戶行爲從時間上也能夠分爲用戶近期的行爲和長期的行爲。

 用戶的話題特徵 能夠根據用戶的歷史行爲利用話題模型（topic model）將電視劇和電影聚合成不一樣的話題，而且計算出每一個用戶對什麼話題感興趣。好比用戶若是看了《葉問》、《新龍門客棧》和《醉拳》，那麼能夠認爲用戶對「香港武俠電影」這個話題感興趣。

推薦系統的推薦任務也有不少種，以下所示。
 將最新加入的物品推薦給用戶。
 將商業上須要宣傳的物品推薦給用戶。
 給用戶推薦不一樣種類的物品，好比亞馬遜會推薦圖書、音像、電子產品和服裝等。

 給用戶混合推薦，有時須要將圖書和音像製品放到一個推薦列表中展現給用戶。
 對於不一樣的產品推薦不一樣新穎度的物品。好比在首頁給用戶展現比較熱門的推薦結果，在推薦系統頁面給用戶展現長尾中的物品。
 考慮到用戶訪問推薦系統的上下文，好比當你在豆瓣音樂找到「李宗盛」時，右側會有一個連接告訴你能夠在豆瓣電臺收聽「李宗盛」。單擊了這個連接後，豆瓣電臺給你推薦的音樂就考慮了「李宗盛」這個上下文。

若是要在一個系統中把上面提到的各類特徵和任務都統籌考慮，那麼系統將會很是複雜，並且很難經過配置文件方便地配置不一樣特徵和任務的權重。所以，推薦系統須要由多個推薦引擎組成，每一個推薦引擎負責一類特徵和一種任務，而推薦系統的任務只是將推薦引擎的結果按照必定權重或者優先級合併、排序而後返回。

 

兩個好處：
 能夠方便地增長/刪除引擎，控制不一樣引擎對推薦結果的影響。對於絕大多數需求，只須要經過不一樣的引擎組合實現。
 能夠實現推薦引擎級別的用戶反饋。每個推薦引擎其實表明了一種推薦策略，而不一樣的用戶可能喜歡不一樣的推薦策略。有些用戶可能喜歡利用他的年齡性別做出的推薦，有些用戶可能比較喜歡看到新加入的和他興趣相關的視頻，有些用戶喜歡比較新穎的推薦，有些用戶喜歡專一於一個鄰域的推薦，有些用戶喜歡多樣的推薦。咱們能夠將每一種策略都設計成一個推薦引擎，而後經過分析用戶對推薦結果的反饋瞭解用戶比較喜歡哪些引擎推薦出來的結果，從而對不一樣的用戶給出不一樣的引擎組合權重。
將推薦系統拆分紅不一樣推薦引擎後，如何設計一個推薦引擎變成了推薦系統設計的核心部分。

 

三、推薦引擎的架構

推薦引擎架構主要包括3部分。
 該部分負責從數據庫或者緩存中拿到用戶行爲數據，經過分析不一樣行爲，生成當前用戶的特徵向量。不過若是是使用非行爲特徵，就不須要使用行爲提取和分析模塊了。該模塊的輸出是用戶特徵向量。
 該部分負責將用戶的特徵向量經過特徵-物品相關矩陣轉化爲初始推薦物品列表。
 該部分負責對初始的推薦列表進行過濾、排名等處理，從而生成最終的推薦結果。

 

1）生成用戶特徵向量

通常來講，用戶的特徵包括兩種，一種是用戶的註冊信息中能夠提取出來的，主要包括用戶的人口統計學特徵。除了這種特徵，另外一種特徵主要是從用戶的行爲中計算出來的，本節着重討論如何生成特徵。
一個特徵向量由特徵以及特徵的權重組成，在利用用戶行爲計算特徵向量時須要考慮如下因素：

 用戶行爲的種類 在一個網站中，用戶能夠對物品產生不少不一樣種類的行爲。用戶能夠瀏覽物品、單擊物品的連接、收藏物品、給物品打分、購買物品、評論物品、給物品打上不一樣的標籤、和好友分享物品、搜索不一樣的關鍵詞等。這些行爲都會對物品特徵的權重產生影響，但不一樣行爲的影響不一樣，大多時候很難肯定什麼行爲更加劇要，通常的標準就是用戶付出代價越大的行爲權重越高。好比，購買物品須要用戶掏錢，因此用戶必定會三思然後行，所以購買行爲最爲重要。相反，瀏覽物品的網頁代價很小，因此這種行爲對反映用戶的真實興趣的影響很小。
 用戶行爲產生的時間 通常來講，用戶近期的行爲比較重要，而用戶好久以前的行爲相對比較次要。所以，若是用戶最近購買過某一個物品，那麼這個物品對應的特徵將會具備比較高的權重。

 用戶行爲的次數 有時用戶對一個物品會產生不少次行爲。好比用戶會聽一首歌不少次，看一部電視劇的不少集等。所以用戶對同一個物品的同一種行爲發生的次數也反映了用戶對物品的興趣，行爲次數多的物品對應的特徵權重越高。

 物品的熱門程度 若是用戶對一個很熱門的物品產生了行爲，每每不能表明用戶的個性，由於用戶多是在跟風，可能對該物品並無太大興趣，特別是在用戶對一個熱門物品產生了偶爾幾回不重要的行爲（好比瀏覽行爲）時，就更說明用戶對這個物品可能沒有什麼興趣，可能只是由於這個物品的連接處處都是，很容易點到而已。反之，若是用戶對一個不熱門的物品產生了行爲，就說明了用戶的個性需求。所以，推薦引擎在生成用戶特徵時會加劇不熱門物品對應的特徵的權重。

 

2）特徵—物品相關推薦

在獲得用戶的特徵向量後，咱們能夠根據離線的相關表獲得初始的物品推薦列表。離線相關表能夠存儲在MySQL中，其存儲格式如表7-2所示。

從上面的架構圖能夠看到，特徵—物品相關推薦模塊還能夠接受一個候選物品集合。候選物品集合的目的是保證推薦結果只包含候選物品集合中的物品。

3)  過濾模塊

在獲得初步的推薦列表後，還不能把這個列表展示給用戶，首先須要按照產品需求對結果進行過濾，過濾掉那些不符合要求的物品。

通常來講，過濾模塊會過濾掉如下物品。
 用戶已經產生過行爲物品 由於推薦系統的目的是幫助用戶發現物品，所以不必給用戶推薦他已經知道的物品，這樣能夠保證推薦結果的新穎性。
 候選物品之外的物品 候選物品集合通常有兩個來源，一個是產品需求。好比在首頁可能要求將新加入的物品推薦給用戶，所以須要在過濾模塊中過濾掉不知足這一條件的物品。

另外一個來源是用戶本身的選擇，好比用戶選擇了某一個價格區間，只但願看到這個價格區間內的物品，那麼過濾模塊須要過濾掉不知足用戶需求的物品。
 某些質量不好的物品 爲了提升用戶的體驗，推薦系統須要給用戶推薦質量好的物品，那麼對於一些絕大多數用戶評論都不好的物品，推薦系統須要過濾掉。這種過濾通常以用戶的歷史評分爲依據，好比過濾掉平均分在2分如下的物品。

 

4) 排名模塊

通過過濾後的推薦結果直接展現給用戶通常也沒有問題，但若是對它們進行一些排名，則能夠更好地提高用戶滿意度，通常排名模塊須要包括不少不一樣的子模塊，下面將對不一樣的模塊分別加以介紹。
1. 新穎性排名

新穎性排名模塊的目的是給用戶儘可能推薦他們不知道的、長尾中的物品。

對熱門物品進行下降權重能夠提升推薦的新穎度.

2. 多樣性
多樣性也是推薦系統的重要指標之一。增長多樣性可讓推薦結果覆蓋儘量多的用戶興趣。

第一種提升多樣性的方法是將推薦結果按照某種物品的內容屬性分紅幾類，而後在每一個類中都選擇該類中排名最高的物品組合成最終的推薦列表。好比，若是是電影，能夠按照電影的類別（愛情片、動做片、科幻片等）對推薦結果中的電影分類，而後每種類別都選出幾部電影組成最終的推薦結果。

所以，第二種提升推薦結果多樣性的方法是控制不一樣推薦結果的推薦理由出現的次數。本章提出的推薦系統對於每一個推薦出來的物品都有一個推薦理由，這個推薦理由通常是產生推薦結果的重要特徵。那麼，要提升推薦結果的多樣性，就須要讓推薦結果儘可能來自不一樣的特徵，具備不一樣的推薦理由，而不是全部的推薦結果都對應一個理由。

下面的代碼根據推薦理由增長推薦結果的多樣性，這裏輸入的recommendations是按照權重從大到小排序的，程序中每次拿出一個推薦結果，若是這個結果已經被用過了，就會對推薦結果的權重除以2降權（這裏具體除以幾能夠在實際應用中本身調整），最終將推薦結果從新按照權重從大到小排序。

3. 時間多樣性
時間多樣性主要是爲了保證用戶不要天天來推薦系統都看到一樣的推薦結果。

 記錄用戶每次登錄推薦系統看到的推薦結果。
 將這些結果發回日誌系統。這種數據不須要實時存儲，只要能保證小於一天的延時就足夠了。
 在用戶登陸時拿到用戶昨天及以前看過的推薦結果列表，從當前推薦結果中將用戶已經看到的推薦結果降權。

4. 用戶反饋
排名模塊最重要的部分就是用戶反饋模塊。用戶反饋模塊主要經過分析用戶以前和推薦結果的交互日誌，預測用戶會對什麼樣的推薦結果比較感興趣。

若是推薦系統的目標是提升用戶對推薦結果的點擊率，那麼能夠利用點擊模型（click model）預測用戶是否會點擊推薦結果。點擊模型在不少領域獲得了普遍應用，好比搜索結果的點擊預測、搜索廣告的點擊預測、上下文廣告的點擊預測。點擊預測的主要問題是預測用戶看到某個推薦結果時是否會點擊。那麼要進行點擊率預測，首先須要提取特徵。在推薦系統的點擊率預測中能夠用以下特徵預測用戶u會不會點擊物品i：
 用戶u相關的特徵，好比年齡、性別、活躍程度、以前有沒有點擊行爲；
 物品i相關的特徵，好比流行度，平均分，內容屬性；
 物品i在推薦列表中的位置。用戶的點擊和用戶界面的設計有很高的相關性，所以物品i在推薦列表中的位置對預測用戶是否點擊很重要；
 用戶以前是否點擊過和推薦物品i具備一樣推薦解釋的其餘推薦結果；
 用戶以前是否點擊過和推薦物品i來自一樣推薦引擎的其餘推薦結果。
點擊模型須要離線計算好，在線將模型加載到內存中。爲了提升在線預測的效率，通常只可使用線性模型。

本章提出的推薦系統架構基本上是從基於物品的推薦算法衍生出來的，所以本章的架構並不適合用來解決社會化推薦問題。