1.緣起

糖豆作為國內(nèi)最大的廣場(chǎng)舞平臺(tái)化漆，全網(wǎng)的MAU已經(jīng)超過4000萬，每月PGC和UCG生產(chǎn)的視頻個(gè)數(shù)已經(jīng)超過15萬個(gè)，每月用戶觀看的視頻也超過100萬個(gè)伍绳。然而之前糖豆APP首頁主要還是依賴內(nèi)容編輯手工推薦來發(fā)現(xiàn)內(nèi)容，每天的推薦量也是幾十個(gè)而已乍桂。明顯可見千人一面的內(nèi)容分發(fā)效率比較低下冲杀，繼而我們于2016年12月初，啟動(dòng)了糖豆推薦系統(tǒng)的設(shè)計(jì)以及開發(fā)睹酌，目前截止到2017年1月初权谁，已經(jīng)完成第一期推薦系統(tǒng)的開發(fā)與評(píng)估。推薦項(xiàng)目立項(xiàng)伊始憋沿，我撰寫了一篇整體架構(gòu)與設(shè)計(jì)旺芽，本文和架構(gòu)一文在部分內(nèi)容有所重復(fù)东囚，本文主要專注闡述推薦系統(tǒng)的開發(fā)播瞳、實(shí)現(xiàn)以及評(píng)估的細(xì)節(jié)扛施。

推薦系統(tǒng)的目的也可以簡單總結(jié)成為以下兩點(diǎn)：

• 根據(jù)用戶個(gè)人興趣分發(fā)內(nèi)容欣喧，為生產(chǎn)者和消費(fèi)者打造更加合理的流量分發(fā)體系畜挨。
• 提高用戶觀看時(shí)長泞坦，從而進(jìn)一步到達(dá)提升產(chǎn)品留存患整。

可以看到核心評(píng)估目標(biāo)是用戶的觀看時(shí)長溯香，相對(duì)直接易理解砸民。當(dāng)然評(píng)估過程抵怎，我們遵循數(shù)據(jù)科學(xué)的評(píng)估體系奋救，衡量了包括多種優(yōu)化目標(biāo)(RMSE,P@K,AUC/ROC,覆蓋率等等)的指標(biāo)。同時(shí)還根據(jù)AB測(cè)試反惕，評(píng)估了整體推薦模塊的CTR,播放時(shí)長等多項(xiàng)業(yè)務(wù)統(tǒng)計(jì)指標(biāo)尝艘。

2.架構(gòu)

相信自從Netfix公布他們的推薦架構(gòu)之后[1]，后續(xù)的推薦系統(tǒng)基本都會(huì)按照在線(online),近線(near line),離線(off line)三個(gè)部分來構(gòu)建姿染。雖然劃分成三個(gè)模塊背亥，本質(zhì)是推薦算法迭代時(shí)間窗口問題，根據(jù)用戶行為數(shù)據(jù)盔粹，構(gòu)建一個(gè)持續(xù)進(jìn)化的系統(tǒng)隘梨。

糖豆推薦系統(tǒng)架構(gòu)基本也是按照三個(gè)模塊來構(gòu)建。限于人力和時(shí)間舷嗡，第一期主要實(shí)現(xiàn)了離線部分轴猎。架構(gòu)圖如下：

推薦系統(tǒng)架構(gòu)1.0

整個(gè)系統(tǒng)架構(gòu)主要由數(shù)據(jù)、算法进萄、策略捻脖、評(píng)估和服務(wù)層組成，相對(duì)清晰明了中鼠。

1. 數(shù)據(jù)層可婶，主要數(shù)據(jù)來源包括用戶行為日志以及數(shù)據(jù)庫。我們?cè)?6年10月份~11月份援雇，對(duì)整個(gè)日志收容矛渴、分析和挖掘流程做了改造。

• 收容：同時(shí)將日志離線和在線的pipeline徹底分離惫搏。
• 解析：原本基于MR的ETL全部改為Spark任務(wù)具温，在集群機(jī)器數(shù)量不變情況下，整體效率基本提高了兩倍以上筐赔，Spark具備很好的取代MR的潛力铣猩。
• 挖掘：Spark MLib集成了多種機(jī)器學(xué)習(xí)算法，原有基于Mahout的算法基本可以替代實(shí)現(xiàn)茴丰。

2. 算法層架構(gòu)一圖中达皿，黑字部分是我們實(shí)現(xiàn)了的算法，藍(lán)字部分都是計(jì)劃中但未實(shí)現(xiàn)的算法贿肩。
3. 策略層：

• 融合算法峦椰，主要包括以下三種，目前我們同時(shí)使用了級(jí)聯(lián)聯(lián)合以及混合融合汰规。
• 業(yè)務(wù)過濾汤功，目前暫時(shí)沒做。
• 推薦排序控轿，目前的排序?qū)τ脩綦[式反饋行為(包括播放時(shí)長冤竹、下載、收藏等指標(biāo))做線性加權(quán)以及歸一化處理茬射，得到一個(gè)0~5分之間的評(píng)分鹦蠕，作為LFM的數(shù)據(jù)集，通過模型得到預(yù)測(cè)的打分在抛，最后按照視頻打分以及視頻創(chuàng)建時(shí)間做倒序排序钟病。后續(xù)我們會(huì)引入學(xué)習(xí)排序(LTR)算法，來持續(xù)改進(jìn)推薦結(jié)果排序質(zhì)量刚梭。LTR肠阱，包括PointWise,PairWise,ListWise三類算法。預(yù)期未來先使用PointWise類別的算法朴读。

3.算法實(shí)現(xiàn)

推薦系統(tǒng)算法在過去幾十年有非常長足的發(fā)展和應(yīng)用屹徘，總結(jié)下來基本包括基于內(nèi)容、基于鄰域衅金，基于矩陣分解等類型噪伊。

1. 基于鄰域：核心思想是，為用戶推薦與之屬性氮唯、行為相似的物品鉴吹。鄰域就是興趣相似的數(shù)學(xué)表達(dá)。它包括UserCF和ItemCF惩琉，基礎(chǔ)研究深入豆励，在性能、可解釋性上效果都不錯(cuò)瞒渠，所以應(yīng)用也十分廣泛良蒸。
2. 基于矩陣分解：也就是隱語義模型，在文本挖掘范圍首先被提出在孝。矩陣分解是一系列復(fù)雜算法(LSM,LSI,LDA,Topic Model)的數(shù)學(xué)基礎(chǔ)诚啃。它包括特征值分解、奇異值分解等私沮，有具體計(jì)算方法包括SVD,Funk-SVD,ALS,SVD++等始赎。

3.1 LFM

隱語義模型其核心思想是通過潛在特征聯(lián)系用戶和物品,根據(jù)用戶行為統(tǒng)計(jì)的自動(dòng)聚類。LFM模型能夠劃分出多維度仔燕、軟性造垛、不同權(quán)重的分類。它通過以下數(shù)學(xué)公式來表達(dá)用戶對(duì)物品的興趣晰搀，由兩個(gè)低秩的矩陣來近似表達(dá)原有高階矩陣五辽。

矩陣分解

可以看到從矩陣計(jì)算問題，轉(zhuǎn)化成優(yōu)化問題外恕。優(yōu)化目標(biāo)的數(shù)學(xué)形式化：

優(yōu)化形式化

這個(gè)形式化問題有多種解法杆逗，包括SVD,ALS等乡翅。Spark提供了包括mlib里的ALS，以及graphx里的SVD++罪郊。

3.1.1 ALS(最小交替二乘法)

ALS將矩陣計(jì)算轉(zhuǎn)化成為一個(gè)最優(yōu)化函數(shù)問題,通過最小化誤差的平方和計(jì)算最佳函數(shù)匹配蠕蚜。ALS在每次迭代期間，一個(gè)因子矩陣保持恒定悔橄，而另一個(gè)使用最小二乘法求解靶累。同樣在求解另一因子矩陣，保持新求解的因子矩陣固定不變癣疟。

Spark ALS的實(shí)現(xiàn)挣柬，每次迭代過程了為了減少通訊消耗，只會(huì)傳輸兩個(gè)因子矩陣(用戶睛挚、物品)之一參與計(jì)算邪蛔。這個(gè)實(shí)現(xiàn)是通過預(yù)計(jì)算矩陣的元數(shù)據(jù)，得到一個(gè)meta矩陣扎狱。這樣就可以在用戶和物品block之間只傳輸一組特征向量店溢，來更新計(jì)算。

ALS

• 優(yōu)點(diǎn)委乌，不受到用戶和數(shù)據(jù)質(zhì)量影響床牧。全局性求解，單一模型效果最好遭贸。
• 缺點(diǎn)戈咳，增量更新緩慢。

3.1.2 Spark實(shí)現(xiàn)

spark mlib實(shí)現(xiàn)了ALS算法壕吹，調(diào)用比較簡單著蛙，稍微麻煩的是調(diào)參和評(píng)估。貼段python代碼耳贬，注釋比較詳細(xì)了踏堡。

##初始化sparksession(spark 2.0以上引入)
spark = SparkSession.builder.master('yarn-client').appName('recy_als_model:'+inUVMDate).config('spark.sql.warehouse.dir', '/user/hive/warehouse').enableHiveSupport().getOrCreate()
#讀入用戶視頻評(píng)分全量表
rateSql =  "select * from da.recy_als_data_uvm where dt='"+inUVMDate+"'"
#spark 讀hive表
rating = spark.sql(rateSql)
#分割訓(xùn)練集和測(cè)試集,0.8,0.2
(training, test) = rating.randomSplit([0.8, 0.2])
#ALS模型參數(shù)
ranks = [8, 10]
lambdas = [0.01,0.05, 0.1]
numIters = [20]
bestModel = None
bestValidationRmse = float("inf")
bestRank = 0
bestLambda = -1.0
bestNumIter = -1
#調(diào)參
for rank, lmbda, numIter in itertools.product(ranks, lambdas, numIters):
    als = ALS(rank=rank,maxIter=numIter, regParam=lmbda, userCol="f_diu", itemCol="f_vid", ratingCol="f_rating", nonnegative=True)
    model = als.fit(training)
    #!!注意是隨機(jī)取樣，使用測(cè)試集評(píng)估模型咒劲，通過RMSE來評(píng)估模型顷蟆。由于測(cè)試集中可能有模型中沒出現(xiàn)過的user,那就會(huì)有預(yù)測(cè)值為nan。drop即可
    predictions = model.transform(test).dropna('any')
    evaluator = RegressionEvaluator(metricName="rmse", labelCol="f_rating",
                                    predictionCol="prediction")
    validationRmse = evaluator.evaluate(predictions)
    print "RMSE (validation) = %f for the model trained with " % validationRmse + \
          "rank = %d, lambda = %.1f, and numIter = %d." % (rank, lmbda, numIter)
    if (validationRmse < bestValidationRmse):
        bestModel = model
        bestValidationRmse = validationRmse
        bestRank = rank
        bestLambda = lmbda
        bestNumIter = numIter
# evaluate the best model on the test set
print "The best model was trained with rank = %d and lambda = %.1f, " % (bestRank, bestLambda) \
  + "and numIter = %d, and its RMSE on the test set is %f." % (bestNumIter, bestValidationRmse)
#保存預(yù)測(cè)結(jié)果
predictions = bestModel.transform(rating).dropna('any')
predictPath =  "hdfs://Ucluster/olap/da/recy_als_predict/"+inUVMDate+"/"
predictions.repartition(200).write.mode('overwrite').save(predictPath, format="parquet")

spark.stop()

spark ml庫在逐步取代mlib庫腐魂，我們使用了ml帐偎，上面代碼片段需要引入pyspark.ml相關(guān)的類。

3.1.3 候選集問題

我們訓(xùn)練模型數(shù)據(jù)量基本在10億量級(jí)蛔屹，我們計(jì)算集群總共16臺(tái)8核削樊，24G的datanode，訓(xùn)練時(shí)間大概30分鐘。按照我們用戶和物品規(guī)模漫贞，如果直接使用模型預(yù)測(cè)推薦結(jié)果甸箱，候選集規(guī)模在萬億級(jí)別，是集群無法承受的迅脐。所有需要對(duì)預(yù)測(cè)的候選集做過濾摇肌，目前采用三種過濾方法。

1. 看過的作者仪际。將用戶過去30天看過的作者的作品作為候選集。這個(gè)做法合理清晰昵骤，但是存在所謂的“信息繭房”問題树碱，也就是說容易出現(xiàn)多樣性不足。
2. 看過的相似的視頻变秦。根據(jù)ItemCF算法得到相似的視頻成榜。將過去看過30天的Top10的類似視頻當(dāng)作候選集。
3. 看過的相似的標(biāo)簽的視頻蹦玫。將用戶看過的視頻相同類型標(biāo)簽的視頻作為候選集赎婚。依賴專家知識(shí)，在具體到我們的舞蹈視頻上樱溉，我們編輯提供的標(biāo)簽只能覆蓋極少的視頻挣输。由于這種做法傾向于PGC作者，在測(cè)試后期不再使用福贞。

3.2 ItemCF(基于物品的協(xié)同過濾)

基于物品的協(xié)同過濾算法是目前應(yīng)用最廣泛的推薦算法撩嚼，由亞馬遜提出[2]，核心思想給用戶推薦那些和他們之前喜歡物品相似的物品挖帘。相似度是基于用戶對(duì)物品的行為來計(jì)算的完丽，而非物品本身的屬性。

3.2.1 算法原理

基于物品的協(xié)同過濾算法主要分為以下兩步：

1. 計(jì)算物品之間的相似度
2. 根據(jù)物品的相似度和用戶歷史行為給用戶生成推薦列表

核心是計(jì)算物品之間的相似度拇舀，我們使用余弦相似度逻族。

余弦相似度

該算法懲罰了熱門物品的權(quán)重，減輕熱門視頻和大量視頻相似的可能性骄崩。

3.2.2 Spark實(shí)現(xiàn)

我們基于spark sql實(shí)現(xiàn)了ItemCF聘鳞，貼一段

   spark = SparkSession.builder.master('yarn-client').appName('recy_icf_similarity:'+inDate).config('spark.sql.warehouse.dir', '/user/hive/warehouse').enableHiveSupport().getOrCreate()
   #指定spark 分區(qū)數(shù)
   spark.sql("SET spark.sql.shuffle.partitions=2000")
   spark.sql("drop table if exists da.recy_icf_similarity_mid ")
   spark.sql("create table da.recy_icf_similarity_mid as select a.vid vid_1 , b.vid vid_2 , a.num num_1, b.num num_2, count(1) num_12 from da.recy_icf_similarity_pre a join da.recy_icf_similarity_pre b on (a.diu=b.diu) where a.vid<b.vid group by a.vid, b.vid, a.num, b.num")
   #計(jì)算余弦相似度
   similarSql = " select vid_1, vid_2, num_12/sqrt(num_1*num_2) similarity from da.recy_icf_similarity_mid"
   similarDF = spark.sql(similarSql)
   similarDF.printSchema()
   # 保存結(jié)果
   similarDF.repartition(300).write.mode('overwrite').save(similarDir, format="parquet")
   spark.stop()

3.3 抄底策略

抄底策略其實(shí)是一個(gè)冷啟動(dòng)的問題，策略也非常多要拂。

• 近期熱門item搁痛、新item。
• 編輯精選宇弛。
• 新品類上線鸡典。
• 同城熱門。

我們目前只生效了熱門策略枪芒，采用了Hack News的熱門算法作為抄底策略彻况，如下圖：

熱門算法

• P表示視頻觀看次數(shù)谁尸。
• T表示距離視頻發(fā)布時(shí)間(單位為小時(shí)),加上2是為了防止最新的視頻導(dǎo)致分母過小。
• G表示"重力因子"(gravityth power),即為視頻衰減系數(shù)纽甘。

熱門算法衰減系數(shù)

我們根據(jù)實(shí)驗(yàn)結(jié)果良蛮，確定了G的取值。該算法同時(shí)保證了視頻的熱門程度和新鮮度悍赢。sql代碼如下：

SELECT vid,title,createtime,hits_total,(if( hits_total>=1, hits_total - 1,hits_total)/power((TIMESTAMPDIFF(hour,createtime,now())+2),1.8)) as sc FROM `video` WHERE date(createtime) >=NOW() - INTERVAL 3 DAY ORDER BY `sc`

3.4 算法融合

融合策略主要包括以下三類决瞳，當(dāng)然還有ensemble相關(guān)的方法：

• 加權(quán)融合(Weight Merge):根據(jù)經(jīng)驗(yàn)值對(duì)不同算法賦給不同的權(quán)重，對(duì)各個(gè)算法產(chǎn)生的候選集按照給定的權(quán)重進(jìn)行加權(quán)左权，然后再按照權(quán)重排序
• 級(jí)聯(lián)融合(Cascade Merge): 優(yōu)先采用效果好的算法皮胡，當(dāng)產(chǎn)生的候選集大小不足以滿足目標(biāo)值時(shí)，再使用效果次好的算法赏迟。
• 混合融合(Mix Merge): 不同的算法按照不同的比例產(chǎn)生一定量的候選集屡贺，然后疊加產(chǎn)生最終總的候選集。

我們主要在候選集上使用了mix merge锌杀，在結(jié)果產(chǎn)出時(shí)甩栈，采用了cascade merge合并LFM和ItemCF的結(jié)果。

4.服務(wù)實(shí)現(xiàn)

4.1 AB分桶服務(wù)

根據(jù)用戶diu糕再，使用crc32 hash函數(shù)對(duì)用戶取余量没，分別賦予AB兩個(gè)類型⊥幌耄客戶端拿到abtag后根據(jù)服務(wù)端數(shù)據(jù)流實(shí)現(xiàn)展示和數(shù)據(jù)埋點(diǎn)允蜈。

4.2 推薦服務(wù)

個(gè)性化推薦系統(tǒng)服務(wù)會(huì)在app首頁打開后被調(diào)用，具體服務(wù)流程步驟如下：

1. 通過用戶DIU獲取推薦模型導(dǎo)出的數(shù)據(jù)列表
2. 判斷推薦的數(shù)據(jù)列表是否為空
3. 推薦的數(shù)據(jù)列表如果不為空蒿柳，則執(zhí)行5
4. 推薦的數(shù)據(jù)列表如果為空饶套，則獲取抄底的推薦列表，然后執(zhí)行5
5. 從推薦的數(shù)據(jù)列表中過濾點(diǎn)目前首頁已經(jīng)展現(xiàn)的視頻
6. 根據(jù)推薦的分?jǐn)?shù)和視頻創(chuàng)建時(shí)間垒探，將列表進(jìn)行排序
7. 返回結(jié)果

流程圖

4.3 存儲(chǔ)選型

推薦系統(tǒng)每天出一次推薦結(jié)果妓蛮， 因此推薦結(jié)果需要按天區(qū)分, 同時(shí)需要按diu來快速查詢，可以采用的存儲(chǔ)有hbase圾叼，redis等鍵值對(duì)數(shù)據(jù)庫蛤克，mongodb等文檔型數(shù)據(jù)庫，或者
mysql等傳統(tǒng)關(guān)系型數(shù)據(jù)庫

• hbase 鍵值對(duì)存儲(chǔ)夷蚊，存儲(chǔ)量大构挤，查詢速度快，穩(wěn)定性取決于集群是否高可用惕鼓，如高可用筋现，可優(yōu)先選擇
• redis 鍵值對(duì)存儲(chǔ)，存儲(chǔ)量較大，熱數(shù)據(jù)基于內(nèi)存存儲(chǔ)矾飞，查詢速度快一膨，可以考慮，不過當(dāng)每個(gè)人的推薦結(jié)果N較大時(shí)洒沦，要考慮存儲(chǔ)大小
• mongodb 文檔型數(shù)據(jù)庫豹绪，存儲(chǔ)量大，熱數(shù)據(jù)同樣存儲(chǔ)在內(nèi)存申眼，索引速度接近于redis瞒津， 結(jié)構(gòu)化，易維護(hù)括尸，可以考慮
• mysql 關(guān)系型數(shù)據(jù)庫巷蚪， 存儲(chǔ)量較大，基于文件索引機(jī)制姻氨，查詢速度較上述存儲(chǔ)來說，理論值較低剪验，可以作為備選肴焊。

每個(gè)用戶的推薦數(shù)N=60， 存儲(chǔ)占用180g功戚，決定采用hbase 根據(jù)rowkey字段做索引娶眷， 當(dāng)我們指定diu和date時(shí)，會(huì)快速返回rowkey在該范圍內(nèi)的結(jié)果啸臀。

5.效果評(píng)估

5.1 離線評(píng)估

采用融合多維度用戶行為數(shù)據(jù)線性轉(zhuǎn)換成顯式反饋評(píng)分届宠。由于采用了多維度數(shù)據(jù)，算法模型效果大幅提升乘粒，結(jié)果如下：

• RMSE從4.1提升到1.0豌注。(Netfix大賽冠軍大概在0.8左右)
• P@K從0.6705提升到0.938。
• 預(yù)測(cè)覆蓋率為99%,推薦覆蓋率為90%灯萍。

5.2 A/B測(cè)試

猜你喜歡模塊已經(jīng)在官方渠道測(cè)試將近三周轧铁，展現(xiàn)形式如下圖：

猜你喜歡

通過AB測(cè)試，可以看到首頁模塊的點(diǎn)擊率整體提升了10%旦棉，人均觀看時(shí)長整體提升5%齿风。目前可以看到，猜你喜歡模塊效果略優(yōu)于每日精選绑洛。

6.改進(jìn)與展望

第一期開發(fā)的時(shí)間相對(duì)較短救斑，人力也非常不足，期間還有很多數(shù)據(jù)分析真屯、挖掘工作需要兼顧脸候，整體工作相對(duì)簡單。未來第二期，主要精力集中在近線和在線的模塊開發(fā)纪他，以及學(xué)習(xí)排序鄙煤。