個性化推薦系統及在已有系統上的應用

徐立 李超

摘? 要： 針對信息過載而中小企業又無力為其用戶提供推薦服務的現狀，提出了一種個性化的推薦系統，為中小企業已有系統的用戶提供推薦服務。該推薦系統采用基于用戶行為和基于好友推薦的推薦方法，可以有效的發掘用戶顯性和隱性需求，為其提供個性化的推薦服務;數據來源于原有系統的數據庫及操作日志，運算模塊采用map-reduce的方式運算，保障了系統的運算速度和可擴展性。最后以某平臺為例，簡要介紹了個性化推薦系統和已有系統對接的實施方案。

關鍵詞： 推薦系統; 推薦功能; 用戶行為; 好友推薦

中圖分類號： TP 399? ? ? ? ? 文獻標志碼： A? ? ? ? ? 文章編號： 1671-2153（2019）01-0093-05

0? 引 言

作為解決當前“信息過載”現象的一種有效途徑，推薦系統吸引了越來越多的專家、學者及企業的研究和關注，其研究的熱點在于各種各樣的推薦算法、優劣比較等[1];大型互聯網企業也紛紛上線自己的推薦系統（如電商中淘寶、京東、亞馬遜[2];視頻中優酷、土豆;社交網絡中人人網;新聞中今日頭條等）。這些推薦系統極大的方便了用戶，能夠發掘用戶的潛在需求，將合適的、個性化的內容或商品推薦給不同的用戶;企業因推薦了合適的內容或商品，用戶粘合度和訂單轉換率大大提高，企業、用戶雙方受益。

然而，對于一般中小型企業，由于技術和資金實力限制，既不能將專家研究出的優秀推薦算法付出實施，又不能像大型企業一樣上線自己的推薦系統，錯失了享受推薦系統紅利的機會。本文提出了一種個性化的推薦系統以及將其應用到某些已有系統的實施方案，借助該系統，一般中小企業的已有系統可以為用戶提供個性化的推薦服務。

1? 推薦系統的總體設計

推薦系統的定位是：為中小企業已有系統的用戶個性化的推薦該系統下的資源（被推薦對象的種類繁多，如：頁面、新聞、知識條目、商品、視頻等，為了描述的方便，以下統稱為資源），其原理是從已有系統中提取數據，經過數據清洗后，按相關推薦算法運算，最終將得到的“用戶-資源”的推薦結果進行存儲，以某種規則和形式推薦給用戶，由于對推薦服務的實時性要求不高，大型企業的推薦系統也是采用離線計算的方式，才使得該設計在實時性方面能夠達到同型系統的一般要求，其總體結構如圖1所示。

要對已有系統增加推薦功能，首先要提取已有系統中的數據，這些數據包括：用戶和資源的基本信息、用戶推薦的資源信息（這是在系統中增加的小功能），這類數據屬于從已有系統的數據庫中提取的結構化數據;原有系統訪問日志（一般系統都會有這種日志，一般形式為某用戶通過某一個鏈接操作了某一資源），這些數據屬于非結構化數據。

圖1中，數據清洗模塊主要對提取的數據進行運算前的處理，處理重點在于日志文件，不同的系統提供的日志形式不完全一樣，需要對接原有系統時稍作改動，在開發時要遵循面向接口編程的規則，對接時推薦系統的代碼可以不受影響;也可事先分別對幾種常見的開源系統的日志進行編程，對接時通過配置文件選擇某一種處理方式，避免硬編碼。

算法計算模塊是推薦系統的核心，由于系統中已有大量真實數據，算法的運算復雜度又較高，因此對運算資源的要求較高，單結點運算顯然是無法滿足性能需求的，因此需要將運算任務分配到不同結點，運算結束后將結果回收。

結果存儲模塊將運算得到的結果持久化，存儲結果比較簡單：用戶—資源。一般單臺服務器即可滿足存儲需求，數據量大時，可考慮數據庫橫向拆分，拆分時要保證同一用戶的所有推薦結果在一臺服務器上。

結果推送模塊主要負責將存儲起來的推薦結果按照某個規則（推送多少條、過濾掉已采納資源等）和某種形式推送到原有系統。

2? 推薦算法的設計

常見的推薦方法有：基于內容的推薦、協同過濾推薦和基于關聯規則的推薦，這些方法各有優缺點，適用場景不同[3]。資源的多樣性決定了采用的推薦方法不能單一，通過分析用戶和資源的特征、推薦系統的應用場景（應用于已有系統，已存在大量用戶行為數據，不存在冷啟動的問題），主要采用的推薦方法有：基于用戶行為的推薦和基于好友的推薦兩種。

2.1? 基于用戶行為的推薦

用戶在使用系統時，無論是有目標的使用還是無意識的隨意瀏覽，其行為數據都有很大價值，這些有價值的數據會被系統的操作日志記錄，這部分數據相對互聯網的整個用戶行為數據庫體量要小的多，價值要大的多。

2.1.1? 用戶行為

用戶訪問和使用系統時，其行為可分為以下幾種：創建資源;編輯資源;瀏覽資源;發起提問;回答問題;采納答案;瀏覽答案。經分析論證，為每種行為賦權重，行為權重表如表1所示。

2.1.2? 實現技術及算法

資源類的操作可根據行為權重直接映射到資源，問答由于是用戶發起和回答的，內容無固定格式且沒有關鍵詞，利用Lucene開源全文檢索工具的中文分詞器對提問和被采納答案的內容進行切分后加上行為權重映射到資源。

某用戶對資源的興趣值記為I，其公式為

式中：BW為表1中的行為權重值;D為該行為的持續時間，即在頁面上的停留時間。計時有兩種方式：可以借助Ajax技術來實現，當用戶在頁面上做點擊鼠標、滑動光標或敲擊鍵盤等操作時，會觸發ajax程序向服務器端發送信號，從最早接收到信號到最后一次發送信號之間的時間差可認為是停留時間;如果操作日志較為詳細，也可以通過獲取同一用戶相鄰兩條操作記錄，計算其時間差的方式計算停留時間。

某用戶的興趣集中度記為IR，其公式為

式中：Imax為某用戶的最大資源興趣值;IK為該用戶對資源k的興趣值。IR值越大，則表明用戶的興趣點越集中，其目標性越強，反之亦然。當IR≥50%說明其興趣集中度較高，最大興趣值占據用戶興趣總值半數以上，該用戶對該資源興趣濃厚，只推薦與該資源相似度最高的前N條資源，選取前N（N可靈活配置）條進行推薦。當IR<50%時，說明該用戶目標性不強，可能只是隨便了解些知識，此時取最感興趣的前M（M可靈活配置）資源下首位相似資源推薦。

2.2? 基于好友的推薦

這里的好友與社交網絡中的好友不同：社交網絡中的好友來源很廣，有可能是生活中的朋友，生意上的伙伴，其興趣點有可能截然不同;該“好友”對用戶是不可見的，它是通過用戶相似度計算獲得的，其計算公式與基于用戶的協調過濾算法中的計算公式相同。然而，該方法與后者不同：后者強調用戶A和B相似度高，則推薦給A的資源，也可推薦給B;該方法強調，A主動推薦的資源，可以推薦給B，這樣可以糾正算法計算時的偏差和失真，發揮用戶的主觀能動性，盡可能大的利用互聯網萬千用戶的智力資源，其推薦結果將更準確、效果更好。

3? 系統的部分實現

由2中的算法描述可以看到：基于用戶行為的推薦方法首先要從每個用戶的行為找到其在某段時間內關注最多的數個資源，然后從眾多資源中找出每個資源最相關的數個資源進行推薦;基于好友的推薦也是要找到每個用戶的“好友”，也就是關注點最相關的用戶，運算量是巨大的，單憑一個主機是無法滿足性能需求的。為了提升推薦系統的運算性能必須采用map？螄reduce的方式將計算任務分配給多個運算節點，運算結束后將結果匯總。Hadoop提供了一個很好的并行化分布式計算框架，其兩大核心組件[4]：HDFS用于分布式存儲文件;MapReduce用戶并行化運算。

在實現map？螄reduce計算之前，先看一下獲取推薦給用戶資源列表和用戶“好友”列表的流程，如圖2所示。

圖2中，對應主要代碼段如下：

/*推薦給用戶的資源列表*/

public List itemRecommend（long userID， int howMany， IDRescorer rescorer， boolean includeKnownItems） throws TasteException {

PreferenceArray preFromUser = getDataModel（）.getPreferencesFromUser（userID）;

if （preFromUser.length（） == 0） {return Collections.emptyList（）;}

FastIDSet possItems = getAllOtherItems（userID， preFromUser， includeKnownItems）;

TopItems.Estimator estimator = new Estimator（userID， preFromUser）;

if（concentrating>50%） {

List topItems = TopItems.getTopItems（howMany， possItems.iterator（）.next（）， rescorer，estimator）;}else {List topItems = TopItems.getTopItems（howMany， possItems.iterator（）， rescorer，estimator）;}

return topItems;}

/*獲取用戶的“好友”*/

public long[] getUserNeighbors（long userID） throws TasteException {DataModel dataModel = getDataModel（）;

UserSimilarity userSimImpl = getUserSimilarity（）;

TopItems.Estimator estimator = new Estimator（userSimImpl， userID， minSimilarity）;

LongPrimitiveIterator userIDs = SamplingLongPrimitiveIterator.

maybeWrapIterator（dataModel.getUserIDs（），getSamplingRate（））;

return TopItems.getTopUsers（n， userIDs， null， estimator）;}

MapReduce是用來解決海量數據的計算問題提出的一種多節點并行化運算方式，在Hadoop框架下用戶只需實現map（）和reduce（）方法即可完成并行化運算，具體到資源推薦，定義類ItemRecommend，public class ItemRecommend extends Configured implements Tool，該類集成了org.apache.hadoop.conf包下的Configured，實現了Tool接口。在該類里定義Item Recommend Mapper和Item Recommend Reducer兩個靜態內部類，在main方法中，通過job.set Mapper Class（Item Recommend Mapper.class）和job.set Reducer Class（Item Recommend Reducer.class）運行。

4? 推薦系統的應用舉例

推薦系統可以應用于中小企業的已有系統，為其用戶提供個性化推薦功能，以茶文化知識平臺為例，簡單介紹其應用。

茶文化推廣平臺是一個集知識管理、問答、交友的茶文化綜合平臺，包括茶知識、茶問答、茶友空間和后臺管理等功能，其功能模塊如圖3所示。

推薦的資源為茶文化相關的知識條目，該平臺是基于一些常見開源系統（hdwiki，UCenter等）的二次開發搭建的，主要功能均由開源系統提供。因此，無論從日志的完整性和規范性，還是代碼的規范性來講，都為其開發推薦功能提供了方便。

鑒于推薦系統中基于好友的推薦算法中，需要使用用戶推薦的數據，對系統進行開發增加用戶推薦功能，該功能簡單，數據庫中新增用戶-資源對照表uc_ recommender，用戶推薦后數據庫里新增一條記錄即可，相應的取消推薦功能類似。

獲取數據時：一部分數據來自于數據庫，如wiki_doc（條目基本信息表）、uc_members（用戶基本信息表）、uc_asks（提問表）和uc_anwsers（答案表）以及uc_recommender（用戶推薦條目表）等，這部分數據數據結構型數據，基本不需要處理;另一部分來自于原系統中的操作日志，操作日志中記錄了用戶通過某個類操作了某個資源，這里只關注表1中列舉的操作，需要過濾掉的數據較多，逐條判斷，把符合條件的記錄抽取用戶id，資源id和操作類名等信息，實現起來較簡單。至此，已完成了推薦系統與現有系統之間的無縫對接。

5? 結束語

通過研究推薦系統，提出了一種個性化推薦系統和基于用戶行為和基于好友推薦的方法相結合的推薦方法：推薦算法運算時采用map-reduce的方式，運算能力較強;運算量大時可以任意新增運算節點，可擴展性良好;該系統的實施技術難度不大、成本較低、可以方便的應用到中小企業現有系統中，為其用戶提供個性化的推薦服務。本文以茶文化知識平臺為例，實施了該推薦系統。

參考文獻：

[1] 冷亞軍，陸青，梁昌勇. 協同過濾推薦技術綜述[J]. 模式識別與人工智能，2014，27（8）：720-734.

[2] 洪亮，任秋圜，梁樹賢. 國內電子商務網站推薦系統信息服務質量比較研究——以淘寶、京東、亞馬遜為例[J]. 圖書情報工作，2016，60（23）：97-110.

[3] 黃立威，江碧濤，呂守業，等. 基于深度學習的推薦系統研究綜述[J/OL]. 計算機學報，2018：1-29.

[4] 董新華，李瑞軒，周灣灣，等. Hadoop系統性能優化與功能增強綜述[J]. 計算機研究與發展，2013，50（S2）：1-15.