推薦算法評測心得

   ◆版權聲明：本文出自胖喵~的博客，轉載必須註明出處。

    轉載請註明出處：http://www.javashuo.com/article/p-qcrnswee-co.html 

 

 

作推薦算法的質量工做將近一年，這一年嘗試了不少東西，踩了很多坑，也對推薦的評測工做稍微有了些本身的心得，如今分享出來，但願能和作這塊工做的同窗一塊兒交流、探討，也歡迎多拍磚，多提意見。

 

推薦系統

目前推薦技術的應用已經很是較普及了，新聞、商品、問答、音樂，幾乎都會用到推薦算法來爲你呈現內容。下面是淘寶、知乎、微博三個app的推薦模型，能夠看到推薦都在很是重要的位置。

 

 

在介紹推薦算法評測以前，我先簡單說下推薦系統，這裏我以商品爲例，簡單描述下推流程，讓你們更明白一些，通常推薦主要包含如下步驟：

召回->打分排序->透出

召回

召回階段一般的手段是協同過濾比較場景的i2i,u2i等這種x2x（有興趣能夠看下我寫的基於itembase的推薦），也有使用embedding的方式經過向量之間的距離進行召回。以i2i爲例，假如如今要針對我推薦一個商品，那麼首先要找到我感興趣的物品 ，這些數據是經過個人歷史行爲來進行獲取，好比拿到我最近一段時間內的點擊、加購、收藏、購買的物品，將這些商品作爲trigger進行召回，協同算法的具體就再也不這裏敘述了，有興趣能夠看下連接，最終咱們按照協同過濾算法算出商品之間的類似分值，而後按照必定數量進行截斷，由於這裏截斷也是依靠分數來進行的，因此通常這一步也稱粗排。這樣召回截斷就完成了。

打分

召回完商品後，咱們須要對這些商品進行再一次的精排，這裏須要用模型來預估ctr，通常狀況下LR、GBDT、FM用的比較多，這裏深度網絡相對用的少，主要爲了考慮到性能，尤爲是rt，由於絕大部分的精排都是須要實時預測的，全部對耗時有必定的要求。繼續說下模型預測的步驟，首先針對召回的商品進行特徵的補充，例如該商品的一級類目、葉子類目（一級類目表明比較，葉子類目表明最細分的類目）、被多少用戶購買等，而後再加入人的特徵，例如性別、年齡、收入、對類目的偏好等，而後將這些信息作爲feature，用模型進行預測，而後根據模型預測的結果進行排序，輸出。

模型

打分過程當中的模型是須要提早訓練和部署，訓練集的來源就是用戶的實時行爲加上用戶和商品的特徵。feature的構成是用戶的特徵和商品的特徵，label則是用戶是否點擊了該商品。

 

質量方案

接下來講下如何保證這塊的質量。因爲推薦系統最終對用戶須要提供實時的服務化，所以免不了有工程端的技術須要一塊兒配合。所以我這塊主要分爲兩個維度來開展，一方面是工程端的質量保證，一方面是算法側的質量保證。

工程端質量

這一塊能夠將算法當成一個黑盒子，只把他當成一個有結果返回的接口。針對這方面前人已經有了豐富的經驗，咱們能夠作接口的單元測試和冒煙測試，另外就是壓測，在預估的qps下看rt是否知足業務方的要求，load是否過大，超時和錯誤的比例是否符合必定的預期。這裏就不細說了，重點說說第二部分。

算法端質量

這裏我再進行細分一下，分爲三部分介紹：算法數據、算法模型、算法效果；

算法數據：

你們都知道算法在作訓練前數據的處理部分很是的重要，有興趣能夠看下特徵工程相關的內容，數據的來源，特徵的構造，數據抽取、加工整個的過程都有可能會出現錯誤，並且數據通常都是存儲在分佈式系統數據庫裏，所以須要藉助相似hive這樣的工具將sql轉換成MapReduce的任務去進行離線的計算，離線任務的產出一般會耗費很多的時間，而對於一些日更新的模型經過對數據對產出時間有必定的要求。所以數據這塊最主要的保證點爲：數據自己的質量，和數據的產出時間。數據自己的質量通常能夠經過數據大小的總體抖動，以及關鍵字段是否爲空，主鍵是否重複，作法比較簡單能夠經過簡單sql或者udf來完成，而後藉助工程能力作到預警、檢查、出報表等。

算法模型：

模型的自己在迭代過程當中也是須要關注的，不過一般算法同窗的訓練優化也是參考這些指標，因此咱們也能夠把這幾個指標作爲模型自己好壞的評估。具體爲：準確率、召回率、AUC。

算法效果：

那麼這個算法推薦出的效果究竟好很差呢，這個是一個很是主觀的事情，每一個人的感覺也不是同樣的，可是咱們仍然要衡量它的好壞，這裏我參考業內學者的推薦書籍以及本身的一些摸索，總結出下面一些方法，供你們參考。

人工評測：

顧名思義，邀請一幫人來對你的推薦系統的結果進行評測。這裏想法來自於我在作翻譯評測時期的經驗，首先這個成本比較高，另外就是參雜了人的主觀性很是的高，翻譯的好壞咱們能夠經過制定一些細緻的規則來進行約束，可是推薦的好壞咱們卻很差制定詳細的規則，另外就是推薦以前的用戶行爲如何模擬，如何讓評測者進行感知，這些都是比較難的，而且和基準的對比也不是很好作，因此這裏不是很推薦用這個方法，可是仍是要提一下。

指標評估：

指標化推薦結果，也就是將推薦的結果用不一樣的指標來進行說明，經過這些指標，你能夠更加的瞭解你的推薦系統，部分指標不必定越高越好，可是你須要讓它保持在必定的範圍內。說到具體的例子的時候，我會提一下。下面咱們看下這些指標。

覆蓋率

定義：

推薦系統可以推薦出來的「商品/類目」佔「總商品/類目」集合的比例。假設系統的用戶集合爲U，推薦系統給每一個用戶推薦一個長度爲N的物品列表R(u) ，總物品爲N。那麼：

覆蓋率 =  $\frac{\Sigma R(u)}{N}$

意義：

描述推薦結系統對物品長尾發掘能力；

舉個例子，淘寶上商品千千萬萬，推薦系統可否保證讓新的一些商品有足夠的機會曝光出去呢？仍是有些商品永遠都沒法獲得推薦曝光的機會。這個指標反應的就是這個狀況，顯然物品的覆蓋率是達不到100%的，可是咱們能夠看類目的覆蓋率來進行衡量，假設全網全部的一級大類目一共2千個（和全網上億的物品相比很是的少），那麼推薦系統一天以內推薦出去的商品對應的一級類目，這個就是咱們要衡量的標準。若是覆蓋率達不到100%，那麼確定是有問題的。

基尼係數

覆蓋率反應出的分佈狀況是比較有限的，咱們只能知道哪些類目覆蓋了，哪些沒有覆蓋，那類目之間究竟哪一個類目佔的多，哪一個類目佔的少呢？爲了更細緻地描述推薦系統發掘長尾的能力，咱們須要統計推薦列表中不一樣類目出現次數的分佈，引入基尼係數來評價。

基尼係數：按照類目的流行度（曝光次數）從大到小排序後進行統計後進行洛倫茨曲線的繪製。

作法： 以類目分佈基尼係數爲例，算出全部的類目被曝光的次數，須要以天週期爲單位進行數據的統計。

 

這裏須要說明一下，基尼係數越大表明全部類目的分佈越不均勻，係數越小表明類目分佈越均勻。咱們知道，每一個電商網站都有其側重的類目，所以絕對平均不是一件好事，頭部的類目佔比稍多一些可是不能太離譜，舉個例子100個類目，前5個佔比到30～40%是相對比較好的。固然絕對的只看這個數據意義也不是很大，更多的是長期對這個指標進行監控，看是否會發生大的變更。

打散度

定義：描述推薦結果中結果數據的分散程度。

打散度 =  $\frac{2}{k(k-1)} \sum\limits_{i\neq j}^{k} 0.85^{dis((i,j)-1) * sim(i,j)}  $ (dis(i,j) = |i-j|,sim(i,j) 爲 i==j?1!0)

這裏須要解釋一下，這裏首先是對兩兩物品（不一樣的位置）計算爲打散度後，得出總體的打散度。類似函數sim表明兩兩是否相同，相同則爲1，不類似則爲0。關於兩個內容之間距離對打散度的影響，不能是線性的關係，由於隨着兩個商品出現的位置愈來愈大，用戶對重複商品的感覺會逐漸的減弱（很近的位置就有兩個類似的內容以爲會有些重複，可是若是比較遠的位置有兩個類似的通常是能夠接受的），通常雙列流屏幕出現內容大概是4個，0.85^(5-1) 大概在 0.5左右，因此若是是5之內，則打散度會很低，可是若是>5了，打散度就不會衰減的比較厲害了。 類似的兩個物品越靠近，權重越大。

更新率

定義：描述推薦系統不斷迭代過程當中推薦結果變化程度的指標。

更新率 = 1 - $\frac{S_{昨日}  ∩  S_{昨日}}{S_{昨日}  ∪  S_{昨日}}$

上面公式仍是以類目爲例，$S_{昨日}$表明昨天一天出現的全部商品所在的類目的個數，而後兩天的交集除以並集，計算得出推薦出商品所屬類目的更新率。

發現性

定義：推薦系統對用戶未產生過關係的商品的發現能力。

在全網商品中，可能有一些比較好的商品，可是用戶歷來都沒有點擊過相似的物品，這時候推薦系統推薦給用戶的時候，用戶頗有可能會眼前一亮，滿滿驚喜。

發現性 = $\frac{1}{n} \sum\limits_{i=1}^{n}  \frac{ S_{今日點擊（前一週未點擊）}  }{  S_{前一週點擊}}$  

一樣以類目爲例，今天我點擊了一個我感興趣的商品，而這個商品的相似偏偏是我前一週都沒有點擊過過的內容，這就說明推薦系統的爲我推薦了一個我以前都沒有關注過而且我感興趣的內容，也就是系統的發現性，在算出每一個人的值以後，再進行求平均計算。

上新率

定義： 新內容被推薦系統推薦的曝光狀況，這裏能夠從兩個維度產出這項指標。

上新率1 = $\frac{當日曝光的內容中內容爲最近一週生產的內容數}{當日曝光內容數} $

上新率2 = $\frac{當日曝光的內容中內容爲最近一週生產的內容數}{最近一週生產的內容數} $

意義：對於一些社區類產品UGC內容的推薦，用戶生產的優質是整個社區最重要的一部分，及時的曝光用戶的新內容對於增長用戶留存和給社區增添活力都有很大的幫助，所以須要這兩個指標來評估推薦算法對於新內容的推薦能力。

NDCG

有些文章中也推薦使用這個指標，可是我的以爲這個更加適合評價搜索結果，以前寫過一篇關於NDCG的文章，有興趣能夠看下。

失效率

定義： 表示系統沒有推薦或推薦後未被用戶點擊數據佔全集的比例。

失效率 = $\frac{S(0)}{S} $

S(0) 表示實際點擊次數爲 0 的數據個數；S表示推薦集合的總數。

首先須要定義一個時間範圍來計算沒有被推薦出的。其含義爲最終未被用戶真正感知的數據的佔比，未感知包含未推薦和推薦出去後未被點擊的內容。

健壯性

定義：算法健壯性的評測主要利用模擬攻擊。首先，給定一個數據集和一個算法，能夠用這個算法給這個數據集中的用戶生成推薦列表。而後，用經常使用的攻擊方法向數據集中注入噪聲數據，而後利用算法在注入噪聲後的數據集上再次給用戶生成推薦列表。最後，經過比較攻擊先後推薦列表的類似度評測算法的健壯性。

總結：適合在離線環境進行完成，針對模型自己的評測。

除了上面介紹的經過這些指標的方法來進行評估，當推薦真正運用在業務上，經過業務側的一些數據反饋也能夠知道推薦算法的好壞。具體看下面兩項：

負反饋

定義：負反饋至關於一個輕量級便攜的用戶反饋，用戶能夠直接對推薦出的內容給與反饋，推薦系統在拿到了用戶實時反饋後就會馬上針對反饋信息對推薦結果作出相應的調整，而咱們也能夠在過後拿到負反饋的總體數據來評價推薦系統在用戶側是否有重大輿情產生。通常app的推薦都會有負反饋機制，如圖：

ctr

Click-Througt-Rate，即點擊率，點擊數/曝光數。推薦算法效果的最最重要指標，沒有之一。通常算法好很差，都會直接用這個指標直接定義。一般算法模型在迭代的過程當中都會進行ab test，所謂ab test就是有一個基準桶，一個對比桶，經過收集兩個不一樣方案在用戶側的點擊率，來評估算法的好壞，通常來講當流量特別大的時候，基本上一個ab實驗上線幾分鐘就能夠出算法的好壞了。固然算法的分桶不只限只有兩個桶，像下面這個推薦每一個分桶的數據均可以很是直觀的展現出來。通常須要藉助像Blink這樣的實時計算能力來實時的顯示點擊率數據。

 

ctr

Conversation Rate，即轉化率，轉化數/點擊數。一般在廣告上用的比較多，對於商品來講也就是用戶最終點擊而且購買的轉化率。由於最終決定轉化的因素仍是比較多的，不僅僅是推薦算法影響的，因此這個指標一般不作爲模型迭代優化的衡量標準，可是因爲其和最終的"錢"掛鉤，因此通常領導會更加關注這個指標。

 

 

總結

上面說了不少指標，其實單看指標可能沒有特別好的體感，更多的時候，咱們須要真正的將這些內容結合到業務上去，看它究竟反應業務什麼樣的狀況，抽絲剝繭，更加的理解業務、反哺業務，任何一個指標都須要對業務有指導意義，真正幫助業務提高。最後，我將總體的質量方案也畫了一個概要圖，能夠參考看看。