中華萬年曆推薦系統實踐

萬年曆的首屏包含日曆、運勢、星座等功能外，也一直提供著大量資訊類內容。這部分內容早期是由運營同學人工編輯篩選並干預展示規則。但純粹以人工生產內容的方式效率較低，並且以人工干預展示的方式經常出現流量分配不合理的情況：大量展示機會往往落在少數內容。而內容的好壞直接由人的感覺衡量也極不客觀。

為了解決信息生產效率受限的狀況，後續逐步引入了外部信息抓取的方案。海納百川，內容漸漸豐富了起來，但抓取的信息量極大提高后，仍然通過人工審核就常常使運營同學們措手不及。每篇內容的審核、編排時間被壓縮，純人工篩選和干預的效果也逐步下降。而這些機械枯燥的工作內容也並不能為我們的運營同學帶來任何快樂和成長。

為了解決上述問題，我們開始了萬年曆推薦系統的設計和實現。

對於推薦系統，必要的是一套大數據平台。同時以我們逐步形成推薦系統的經驗來看，如果在功能沒有完全穩定成型的情況下，起初可以不要一次做出太複雜的推薦邏輯：越複雜的演算法適用面越窄，當面對功能較大變更時很可能出現問題，而複雜的演算法也較難排查和調試。

下面基於萬年曆推薦系統逐步形成的過程，分享一些我們的經驗。

我們在用戶冷啟動、item冷啟動及系統冷啟動上做了一些嘗試。

用戶冷啟動一般可以結合一些註冊信息或主動讓用戶描述興趣等。比如參考用戶註冊時填寫的年齡、性別等信息；進入app后請求用戶勾選一些興趣愛好。但在實踐當中注意到採用註冊信息作為依據並不靠譜：在萬年曆中這類信息支持度偏低，置信度比較難直接衡量。

item冷啟動可以採用基於文本的挖掘方式做標註，但這種方式開銷比較高。我們曾經嘗試使用tensorflow構建卷積神經網路對文本做標籤標註，並使用搜狗公開的文本分類語料庫進行試驗。在權衡計算開銷和準確度的情況下並沒有得到滿意的結果（三層卷積神經網路網路，準確率89%）。最終採用直接由媒體合作方的自身屬性和內容抓取頻道直接做item的相關標記。

對於系統冷啟動可以採取先不做個性化推薦的實現方案。可以製作熱榜數據：計算最近一段時間（區分業務，設置不同的時間窗口）item熱門分數關於點擊率c和上線距今時間差t的函數（公式1）:

其中△uptime為item已上線時間，T為選取的滑動窗口內item上線時間戳集合。α、β、θ為調優參數。

分數隨t增大而衰減，點擊率越高衰減越慢。hacker news和reddit等也有分享過它們使用的熱榜模型可以作為參考。具體模型和參數，各支業務不同沒有統一的套用方案，參數可以通過AB測試來確定。從經驗上來看，除非有極其豐富的數據源，否則盡量不要使用時間的指數函數來做衰減，否則熱榜很容易退化成item上線時間的倒序排序序列。

單單製作幾個熱門榜其實已經比隨機選取內容展示要好很多了。但是對於用戶個性化的反饋還沒有。此時比較簡單的一個方法就是實時生成用戶個性化過濾信息做」負反饋「。對每個用戶的瀏覽、點擊等行為做記錄，作為熱門榜返回給到不同用戶的內容做過濾依據。如果是針對純時效性的內容，這部分過濾信息可以設置失效時間。對於用戶量較大的場景，並不嚴格的要求過濾信息與用戶行為完全一致，可以結合hyperloglog或bloomfilter的數據結構來做存儲的進一步優化。比如我們希望item最多展示K次（K值為較小的正整數）或最多被點擊1次后不再展示，則可以通過如下方案實現：

對每一個item構建K個用戶集合，當請求展示時，向該item最低次不含有該用戶的集合中插入該用戶，當第K個集合已經包含該用戶時，該用戶的候選資訊集合會將此item過濾。上傳點擊日誌會將此item的所有次數的訪問用戶集合加入該用戶。資訊存在時效性，從app下架時則可以同時釋放item對應的訪問用戶集合存儲資源。

雖然在比較嚴格的演算法改進和迭代周期中一般希望先完成離線實驗，再做用戶調查，最後再完成線上實驗和演算法的全流量覆蓋。但一般完成所有的流程，對於體量較小的公司周期太長。 下表是幾種試驗方法的優缺點比較：

我們實際採用流量從小到大逐步覆蓋到所有用戶的方法，如果新策略效果不佳則可以在實驗中途下線。流量劃分可以初期採用各個實驗流量互斥的方式，後續對互不影響的實驗做流量分層。流量劃分可以採用移動設備標識的MD5值。android可以採用imei+mac，ios可以採用idfa。但要注意，在實踐當中，發現android有部分手機在重啟時mac會發生變化。而山寨機往往imei為一串0，所以建議提前做用戶日誌的統計來確定使用何種標識口徑。

最常用的就是協同過濾。可以優先採取modelbased（比如als）和itembased兩種方法。用戶量極其龐大或用戶行為比較稀疏的情況下盡量不要使用userbased。als我們使用spark構建離線推薦集合，itembased我們實現了兩種計算策略：

1.標籤及來源是否相同（公式2）：

2.基於用戶的行為，計算關聯關係（公式3）：

其中N(j)表示消費了資訊j的用戶集合

如果用戶活躍度差異較大還可以對用戶活躍度較高的用戶做降權懲罰（公式4）：

其中u為同時消費過j和k的用戶，active表示用戶u的活躍度。

itembased方法可以用於實時個性化推薦。一個場景是詳情頁的「相關閱讀」。用公式3離線計算關聯關係。如新加入的item取不到離線相關數據則可以降級使用公式2。另一個場景是實時增加用戶偏愛（點擊或停留時間長）的item展示，策略如下：

實時上傳的用戶日誌構建最近消費的item集合，資訊爬蟲抓取進來的新item使用公式2構建出同tag下的item關聯度索引。通過數據倉庫完成ALS演算法給出的用戶離線推薦數據集。通過最近消費的item記錄和關聯關係（優先取離線關聯關係，當取不到時取實時關聯關係）與前文敘述的item過濾器過濾后得到實時item推薦候選集合。

對於中長期的興趣或偏好，包括周期間隔較長的行為，可以沉澱出用戶、item和標籤的圖結構（興趣畫像）。針對這一部分，就需要對item爬取時做標籤標記。當用戶消費item時，用戶也即被關聯了相應的標籤，考慮標籤權重，使用行為計數和時間間隔做加權。我們在數據倉庫中採用hive拉鏈記歷史的方式存儲。離線天增量更新到redis來用於線上數據消費。

目前我們採用的方法是針對不同的場景，制定不同的多個獨立子策略的融合方案。或在通用的場景下根據不同子策略的性能做優先順序排序，優先或多從性能較優的子策略拉取數據。針對不同的業務場景，最後制定一些補丁策略來彌補獨立演算法融合的一些缺陷。後續我們也計劃採用訓練模型（如Logistic Regression）的方式對非定投內容進行重排序優化。

我們採用flume，kafka，storm及spark streaming完成用戶數據的實時收集、解析、初步清洗和實時統計的工作。redis，hbase，hive完成不同時效響應要求的數據存儲，使用hive和spark完成數據倉庫建模及計算複雜度較高的模型。azkaban完成離線任務、准實時任務的調度和任務執行出錯報警功能。

本文介紹了中華萬年曆推薦系統從無到有構建過程中的一些經驗和積累。目前還有很多不完善和需要改進的地方。但在這裡希望分享出來一些我們的經驗，能夠拋磚引玉，給大家提供到一些參考，也歡迎隨時和我們一同討論！