[TOC] ## **1. 綜述** * 推薦系統是一個有著諸多復雜因素聯動起作用的系統，從誕生到成熟，推薦系統本身就帶著很多不確定性。因此，推薦系統在研發完成后，作為技術人員的我們并不是馬上就結束了戰斗，在往后的日子里，我們必須時時刻刻地知道它當前的狀態好不好，在整體環境中是不是很健康，所以必須有一系列測試方法和評測指標來了解當前的推薦系統的 “系統體征” 信息，以方便我們能夠在復雜因素聯動的背后，抓住一些可能的變化規律，找出一些可能出現的問題，幫助推薦系統健康穩定地做好信息的傳遞和連接工作。 * 此外，推薦系統的評估可以為我們在選擇推薦算法、優化推薦算法、以及進行推薦策略更新的時候提供可靠的參考依據。 * 從商業角度看，很多推薦系統連接著平臺方、內容生產者、用戶三個結點，因此一個好的推薦系統必然是盡可能讓這三方的利益都能夠考慮到，評測指標也就更加多元化，這是與學術界非常大的一個區別。  * **通常推薦系統的評測方法有四種： 業務規則掃描、離線模擬測試、在線對比測試、用戶調查。** 接下來我們分別來解釋。 ## **2. 業務掃描** * 首先，業務規則掃描本質上就是傳統軟件的功能測試。確定的業務規則會對應有確定的規則，這些規則就可以翻譯成單元測試，像是運行單元測試那樣，對推薦系統逐一掃描業務規則。 * 通常這些業務規則對測試的要求也有 “軟的” 和 “硬的” 兩種。前者會對業務規則違反情況做一個基線規定，比如觸發幾率小于萬分之一，在掃描測試時統計觸發次數，只要統計觸發幾率不超過基線，就算是合格。 * 而硬的規則，就是一票否決，例如一些業務黑名單，簡直就是高壓線，測試時碰不得，碰了就是 Bug，就要想辦法修正。 * 除了業務規則，還有一些容易被人忽視的地方，比如絕大多數推薦模型都涉及了數學計算，而數學計算中也有一些潛在的規則不能違反。 * 比如除數不能為 0，比如計算機的浮點數精度有限，經過一些指數運算后可能就出現預期之外的結果，還可能一些連續相乘的計算要防止出現 0 的乘數，類似這些在計算中的潛在業務規則，也需要掃描測試。 ## **3. 線下評測** * 線下評測是推薦系統最常使用的，通常有兩種評測方式，一種是離線模擬評測，一種是使用用戶歷史真實訪問數據進行評測。 * 離線模擬評測是一種軍事演習式的測試。模擬測試當然無法代替真實數據，但是也能暴露一些問題。通常做法是先收集業務數據，也就是根據業務場景特點，構造用戶訪問推薦接口的參數。這些參數要盡量還原當時場景，然后拿這些參數數據去實時訪問推薦推薦，產生推薦結果日志，收集這些結果日志并計算評測指標，就是離線模擬測試。 * 顯然，離線模擬評測是失真的測試，并且評測指標也有限，因為并不能得到用戶真實及時的反饋。但是仍然有參考意義。這些**模擬得到的日志可以統稱為曝光日志，它可以評測一些非效果類指標，例如推薦覆蓋率，推薦失效率，推薦多樣性等。** * 另外就是利用歷史真實日志構造用戶訪問參數，得到帶評測接口的結果日志后，結合對應的真實反饋，可以定性評測效果對比。比如，可以評測推薦結果的 TopK 的準確率，或者排序效果 AUC。**這些模型效果類指標，雖然不能代表最終關注的商業指標，但是兩者之間一般存在一定的相關性。通常來說 TopK 準確率高，或者 AUC 高于 0.5 越多，對應的商業指標就會越好，這是一個基本假設。**通過離線模擬評測每一天的模型效果指標，同時計算當天真實的商業指標，可以繪制出兩者之間的散點圖，從而**回歸出一個簡單的模型，用離線模型效果預估上線后真實商業指標**。 * 線下評測的指標眾多，各有各的作用，實際上這些指標都是 “探索-利用” 問題的側面反映，它們解答了兩個問題： * 一是系統有多好，即推薦系統當前的性能如何，對數據利用得徹不徹底，這類指標我們稱之為利用類指標； * 二是系統還能好多久，即推薦系統長期的健康狀況，是否能夠探索出用戶新的興趣，這類指標我們稱之為探索類指標。 * 下面我們將詳細介紹各類指標。 ### **3.1 利用類指標（系統有多好）** * 利用類指標又分為兩大類，一類是深度類，深度類就是在評分預測和行為預測上面做得是否到位；另一類是廣度類，更加偏向于全局評測。 * 先來看深度類指標，包括評分準確性，分類準確性，排序指標和商業指標。 #### **3.1.1 評分準確度** * 評分準確度考慮推薦算法的預測打分與用戶實際打分的相似程度，在評分類的顯式用戶反饋中，預測準確度非常重要。 * 評測背景和符號說明：系統在已知用戶與物品集合(u，i)的真實評分rui情況下在測試集T上生成預測評分r^ui。 ##### **3.1.1.1 平均絕對誤差（MAE）** :-:  * 推薦算法的整體準確度是所有用戶準確度（對所有物品的評估）的平均。研究表明，如果評分系統是基于整數建立的（即用戶給的評分都是整數），那么對預測結果取整數會降低 MAE 的誤差。 * **優點：** 1）計算方法簡單，易于理解； 2）每個系統的平均絕對誤差唯一，從而能夠區分兩個系統平均絕對誤差的差異。 * **局限性：** * 1）**對 MAE 指標貢獻比較大的往往是那種很難預測準確的低分商品。** 所以即便推薦系統 A 的 MAE 值低于系統 B，很可能只是由于系統 A 更擅長預測這部分低分商品的評分，即系統 A 比系統 B 能更好的區分用戶非常討厭和一般討厭的商品，顯然這樣區分的意義不大。 * ? 2）**在用戶喜好偏差的程度比較小時也并不適用**，因為用戶只關心把好產品錯歸為壞產品，或者把壞產品錯歸為好產品的比例。例如，以 3、5 個星為界區分好壞，那么把 4 預測成了 5，或者把 3 預測成了 2 都對用戶沒有影響。 ##### **3.1.1.2 均方根誤差（RMSE）** :-:  * **優點：** 相比于 MAE，RMSE 加大了對預測不準的用戶物品評分的懲罰（平方項的懲罰），因而對系統的評測更加苛刻。 * **局限性：** 1）**容易受到高頻用戶或高頻物品的影響。** RMSE 需要取一個平均值。這是對所有用戶在所有物品上評分誤差的估計的平均。那么，如果一個用戶在數據集里面對很多物品進行了評分，這個用戶誤差的貢獻就會在最后的平均值里占很大一部分。也就是說，最后的差值大部分都用于描述這些評分比較多的用戶了。這個弊端會造成如果我們得到了一個比較好的 RMSE 數值，往往很可能是犧牲了大部分用戶的評分結果，而對于少部分的高頻用戶的評分結果有提高。說得更加直白一些，那就是RMSE 小的模型，并不代表整個推薦系統的質量得到了提高。 2）**RMSE 指標并沒有反應真實的應用場景。** 真實的應用場景，我們往往是從一大堆物品中，選擇出一個物品，然后進行交互。在這樣的流程下，物品單獨的評分其實并不是最重要的。更進一步說，就算一個推薦系統能夠比較準確地預測評分，也不能證明這個推薦系統能夠在真實的場景中表現優異。 > * **MAE 和 RMSE 的變種** > 歸一化均方誤差（NMRSE）和歸一化平均絕對誤差（NMAE）：在一定評分范圍內歸一化了的 RMSE 和 MAE。由于它們只是 RMSE 和 MAE 的縮減版本， 算法排序結果與未歸一化時相同。 > * **MAE 和 RMSE 在不均衡的測試集下的調整** > 如果測試集的物品分布不均衡，在此測試集上計算出的 MAE 或 RMSE 可能會受到高頻物品產生的誤差的嚴重影響。如果我們需要一個方法來代表任意物品的預測誤差，那么最好分別計算每個物品的 MAE 或 RMSE，然后再取所有物品的平均值。類似地，如果測試集的用戶分布不均衡，有希望推斷出一個隨機抽樣的用戶所要面臨的預測誤差，那么我們可以計算每個用戶的平均 MAE 和 RMSE。 > * **MAE 和 RMSE 在特殊評分語義下的調整** > *  #### **3.1.2 分類準確度** * 分類準確度定義為推薦算法對一個物品用戶是否喜歡判定正確的比例，通常用于行為預測。因此，當用戶只有二元選擇時，用分類準確度進行評價較為合適。 * **分類準確度在稀疏打分情況下的影響及調整** * 應用于實際的離線數據時，分類準確度可能會受到打分稀疏性的影響。當評價一個推薦列表的質量時，列表中的某些物品很可能還沒有被該用戶打分，因此會給最終的評價結果帶來偏差。需注意的是，這里的打分可以有不同的幾種反饋類型，但一定是二元相關度的方式，比如可以是數值評分的二元化（如 MovieLens 數據為 5 分制 ，通常 3～5 分被認為是用戶喜歡的，1～2 分被認為是用戶不喜歡的。），可以是**二元打分（喜歡和不喜歡）**，也可以是**用戶交互行為（有行為反饋和沒有行為反饋）**。 * 1）一個評價稀疏數據集的方法就是忽略還沒有打分的物品，那么推薦算法的任務就變成了 “預測已經打分的物品中排名靠前的物品”。 2）另外一個解決數據稀疏性的方法就是假設存在默認打分，常常對還沒有打分的物品打負分 。這個方法的缺點就是默認打分常常與實際的打分相去甚遠。 3）還有一種方法是計算用戶打分高的物品在推薦列表中出現的次數，即度量系統在多大程度上可以識別出用戶十分喜歡的物品。這種方法的缺點是容易把推薦系統引向偏的方向：一些方法或者系統對某數據集中已知的數據表現非常好，但是對未知的數據表現十分差。 * 分類準確度評價并不直接評價算法的評分是否準確，如果分類的信息準確無誤，與實際打分存在偏差也是允許的，對于分類準確率，我們更加在乎系統是否正確地預測用戶是否會對某個物品產生行為。 *  ##### **3.1.2.1 準確率（Precision）** * 準確率定義為系統的推薦列表中用戶喜歡的物品和所有被推薦物品的比率，也稱為**查準率**，即在推薦（預測）的物品中，有多少是用戶真正（準確）感興趣的。 *  ##### **3.1.2.2 召回率（Recall）** * 召回率表示一個用戶喜歡的物品被推薦的概率，也稱為**查全率**，即用戶喜歡的物品中，有多少是被推薦了的。 *  * **優點：** * 準確率和召回率對比評分準確度指標更能反應推薦系統在真實場景中的表現。 * **局限性：** * 1）**未發生交互行為的物品很難確定用戶是否真正喜歡**。準確率和召回率的定義依賴于用戶喜歡和不喜歡的物品分類 。如何定義用戶是否喜歡一個物品，尤其是用戶是否喜歡一個沒有打分的物品還是十分困難的。在推薦系統中，無法知道用戶是否喜歡某些未知的物品，所以召回率在純粹意義上講并不適合度量推薦系統。因為召回率需要知道每個用戶對未選擇物品的喜好，然而這與推薦系統的初衷是相悖的。 2）**準確率和召回率必須要一起使用才能全面評價算法的好壞**。準確率和召回率是兩個很相似的指標，這兩個指標存在負相關的關系，他們分別從不同的角度來評價推薦系統，單獨的指標不足以說明算法的好壞，必須一起使用才是更加全面的評價。 * **準確率和召回率的兩種應用場景：以用戶為中心和以系統為中心**? * 準確率和召回率可以有兩種計算方法：以用戶為中心和以系統為中心。 * 以用戶為中心的方法中分別計算每個用戶的準確率和召回率，再對所有的用戶進行平均。這種方法的重點在于考慮用戶的感受，保證每個用戶對系統表現的貢獻強度是一致的。以系統為中心的方法以考察系統的總體表現為目的，不需要對所有用戶做平均。 * **準確率和召回率存在負相關關聯，取決于推薦列表的長度，互相牽制** * 1）當準確率很高的時候，表明希望推薦的物品絕大多數是用戶感興趣的，因此推薦較為保守，只推少量最有-把握的物品，這樣的話，有些用戶可能感興趣但排名沒有那么靠前的物品則會被忽略。因此召回率就比較低。 2）如果召回率很高，表明目標是盡可能把用戶感興趣的物品全部召回，則門檻就會降低，為了捕獲更多用戶感興趣的物品，召回的總量就多了，而準確率就低了。 * **在不同的應用場景中需要自己判斷希望準確率比較高或是召回率比較高。**比如系統的任務是發現所有用戶喜歡的產品，召回率就變得很重要，因此需要在一定的召回率水平下考慮準確率。如果是做實驗研究，也可以繪制**Precision-Recall 曲線**來幫助分析。 * 在需求不是很明確的時候，準確率和召回率容易出現的矛盾的情況，為了同時考察準確率和召回率，Pazzani M 等人把二者綜合考慮提出了 F 指標（F-measure）。 ##### **3.1.2.3 F指標（F-measure）** * F 指標又稱綜合評價指標，F-Measure 又稱為 F-Score，來源于是 IR（信息檢索）領域，常用于評價分類模型的好壞。 * **F-Measure 是 Precision 和 Recall 加權調和平均**： *  *  * F 指標把準確率和召回率統一到一個指標，因此得到了廣泛的應用。 * **三個指標的對比圖示** *  #### **3.1.3 排序準確度** * 排序是推薦系統非常重要的一個環節，因為把用戶偏愛的物品放在前面是推薦系統的天職，因此檢測推薦系統排序能力非常重要。 * 關于排序能力的評測指標，我們自然會想到搜索引擎中的排序指標，它們在某種程度是可以應用于推薦系統發的評測，但是會有些問題。**由于推薦系統輸出結果是非常個人化的，除了用戶本人，其他人都很難替他回答哪個好哪個不好，而搜索引擎評價搜索結果和查詢相關性，具有很強的客觀屬性，可以他人代替評價。所以通常評價推薦系統排序效果很少采用搜索引擎排序指標**，比如 MAP、MRR、NDCG。推薦系統評價排序通常采用 AUC。 * 下面我們重點介紹 AUC，對于 MAP、MRP、NDCG 也會給出公式，但不作為重點介紹。 ##### **3.1.3.1 AUC** * 在許多分類學習器中，產生的是一個概率預測值，然后將這個概率預測值與一個提前設定好的分類閾值進行比較，大于該閾值則認為是正例，小于該閾值則認為是負例。如果對所有的排序結果按照概率值進行降序排序，那么閾值可以將結果截斷為兩部分，前面的認為是正例，后面的認為是負例。 * 我們可以根據實際任務的需要選取不同的閾值。如果重視精確率，我們可以設定一個很高的閾值，如果更重視召回率，可以設定一個很低的閾值。 * 到這里，我們會拋出兩個問題： * 1）設定閾值然后再來計算精確率，召回率和 F1-Score 太麻煩了，這個閾值到底該設定為多少呢？有沒有可以不設定閾值來直接評價我們的模型性能的方法呢？ * 2）排序結果也很重要，不管預測值是多少，只要正例的預測概率都大于負例的就好了。 * ROC 和 AUC 便可以解決上面的兩個問題。 * ROC 全稱是 “受試者工作特征”，（receiver operating characteristic）。我們根據學習器的預測結果進行排序，然后按此順序逐個把樣本作為正例進行預測，每次計算出兩個重要的值，分別以這兩個值作為橫縱坐標作圖，就得到了 ROC 曲線。ROC 曲線的橫軸為 “假正例率”（False Positive Rate，FPR），又稱為 “假陽率”；縱軸為 “真正例率”（True Positive Rate，TPR)，又稱為 “真陽率”，而 AUC（area under the curve）就是 ROC 曲線下方的面積，見下圖。 *  * 從上圖可以看出，閾值最大時，對應坐標點為 (0,0), 閾值最小時，對應坐標點 (1,1)，最理想的目標：TPR=1，FPR=0，即圖中 (0,1) 點，故 ROC 曲線越靠攏 (0,1) 點，越偏離 45 度對角線越好，分類效果越好。 * 雖然，用 ROC 曲線來表示分類器的性能很直觀很好用。但是人們更希望能有一個數值來表示分類器的好壞。于是 Area Under ROC Curve(AUC) 就出現了。 * **首先 AUC 值是一個概率值，當你隨機挑選一個正樣本以及負樣本，當前的分類算法根據計算得到的 Score 值將這個正樣本排在負樣本前面的概率就是 AUC 值，AUC 值越大，當前分類算法越有可能將正樣本排在負樣本前面，從而能夠更好地分類。** * **AUC 量化了 ROC 曲線表達的分類能力。這種分類能力是與概率、閾值緊密相關的，AUC 值越大，則說明分類能力越好，那么預測輸出的概率越合理，因此排序的結果越合理。如此 AUC 這個值在數學上等價于：模型把關心的那一類樣本排在其他樣本前面的概率。最大是 1，完美結果，而 0.5 就是隨機排列，0 就是完美地全部排錯。** * 在 CTR 預估中，我們不僅希望分類器給出是否點擊的分類信息，更需要分類器給出準確的概率值，作為排序的依據。所以，這里的 AUC 就直觀地反映了 CTR 的準確性（也就是 CTR 的排序能力）。 **AUC 的計算** * 1）最直觀的，根據 AUC 這個名稱，我們知道，計算出 ROC 曲線下面的面積，就是 AUC 的值。事實上，這也是在早期 Machine Learning 文獻中常見的 AUC 計算方法。由于我們的測試樣本是有限的。我們得到的 AUC 曲線必然是一個階梯狀的（如下圖）。因此，計算的 AUC 也就是這些階梯 下面的面積之和。這樣，我們先把 score 排序 (假設 score 越大，此樣本屬于正類的概率越大)，然后一邊掃描就可以得到我們想要的 AUC。但是，這么做有個缺點，就是當多個測試樣本的 score 相等的時候，我們調整一下閾值，得到的不是曲線一個階梯往上或者往右的延展，而是斜著向上形成一個梯形。此時，我們就需要計算這個梯形的面積。由此，我們可以看到，用這種方法計算 AUC 實際上是比較麻煩的。 *  *  * 3）第三種方法實際上和上述第二種方法是一樣的，是基于上面算法的簡化，使得復雜度減小了。它也是首先對 score 從大到小排序，然后令最大 score 對應的 sample 的 rank 為 n，第二大 score 對應 sample 的 rank 為 n-1，以此類推，其中要注意，如果幾個樣本分數一樣，需要將其排序值調整為他們的平均值。然后把所有的正類樣本的 rank 相加，再減去 M-1 種兩個正樣本組合的情況。得到的就是所有的樣本中有多少對正類樣本的 score 大于負類樣本的 score。然后再除以 M×N（即正負樣本相對排序總共的組合可能性）。 * 整理公式如下： * :-:  * 公式解釋： * 1）為了求的組合中正樣本的 score 值大于負樣本，如果所有的正樣本 score 值都是大于負樣本的，那么第一位與任意的進行組合 score 值都要大，我們取它的 rank 值為 n，但是 n-1 中有 M-1 是正樣例和正樣例的組合這種是不在統計范圍內的（為計算方便我們取 n 組，相應的不符合的有 M 個），所以要減掉，那么同理排在第二位的 n-1，會有 M-1 個是不滿足的，依次類推，故得到后面的公式 M\*(M+1)/2，我們可以驗證在正樣本 score 都大于負樣本的假設下，AUC 的值為 1； * ? 2）根據上面的解釋，不難得出，rank 的值代表的是能夠產生 score 前大后小的這樣的組合數，但是這里包含了（正，正）的情況，所以要減去這樣的組（即排在它后面正例的個數），即可得到上面的公式。 * 關于 AUC，越接近 1 越好是肯定的，但是并不是越接近 0 就越差，最差的是接近 0.5，如果 AUC 很接近 0 的話，只需要把模型預測的結果加個負號就能讓 AUC 接近 1。 * **AUC 實戰** * **1）學會分析 AUC** * AUC 是推薦系統中非常重要的一個指標，在工業界模型的不同階段會有三個不同的 AUC 指標。 *  這三個 AUC 理論上差距應該比較小，但實際中依然可能出現較大的差異，學會對比分析這三個 AUC 值，其實可以看出很多問題。 * train AUC >> test AUC ？ train AUC 遠大于 test AUC，通常情況是模型出現了過擬合。 * test AUC >> Online AUC ？ test AUC 遠大于 online AUC， 通常是因為特征不一致產生的，那特征不一致是如何產生的呢？ 1. test 可能用了未來的數據，這種現象被稱為 “偷窺數據”、“數據穿越”、“時間穿越” 問題，雖然看起來不可思議，但其實在工業界這種錯誤非常常見，所以一定要注意數據在時間上的正交性； 2. 某些特征需行為產生后才能拿到，比如位置信息，test 數據有位置信息，而 serving 沒有獲取到，又如訓練模型的時候把停留時長作為特征，但 serving 也獲取不到； 3. 因模型太大，在線特征可能會做些裁剪，如特征淘汰、模型淘汰、參數淘汰。 * 注意，上面提到的 AUC 不一致并不是一定要讓 online AUC 和 test AUC 一致才行，重點是要分析不一致的原因。有的不一致是合理的，比如 online 端的位置信息，因獲取不到就給一個默認值而導致的不一致，還有很多是由于 bug 導致的不一致，比如時間穿越問題，又如訓練特征和預測特征不一致產生的，尤其是線上實時存的特征和線下拼接的特征不一致。 * 另可參考一篇實戰分析《[\>>AUC 和線上點擊率指標不一致問題分析](https://lumingdong.cn/go/56gr4f)》。 * **2）用戶 AUC** * 除了直接計算全局 AUC，通常還可能會分用戶計算 AUC，然后得到用戶平均 AUC： *  * 這里計算的 AUC 是所有用戶 AUC 的平均。AUC(u) 表示單用戶 AUC，單用戶 AUC 的計算方法可見《[推薦系統中的排序學習](https://lumingdong.cn/learning-to-rank-in-recommendation-system.html#BPR%EF%BC%88%E8%B4%9D%E5%8F%B6%E6%96%AF%E4%B8%AA%E6%80%A7%E5%8C%96%E6%8E%92%E5%BA%8F%EF%BC%89)》BPR 小節中 “BPR 和 AUC 的關系”。 * 為什么需要分用戶算 AUC？ * 1. 不同用戶間比較 AUC 是沒有意義的，因為不同的用戶間習慣和行為都不同，比如有的用戶不喜歡點贊，可能學習到的某個指標值永遠是 0，雖然學習準確但是最終目的還是要給用戶推薦其喜歡的文章、視頻或者物品等。 * 2. 推薦系統希望滿足所有人的需求，比如有的用戶一天瀏覽了一萬個商品，而另外一個用戶只看了十個商品，如果計算全局 AUC，模型會把那些看過特別多的那些用戶的偏好學的特別好，行為比較少的用戶可能完全被忽略了。但對于平臺而言，每個用戶是同樣重要的，所以可以先算每個用戶的 AUC，然后再算一個平均，算是單用戶 AUC 與全局 AUC 各有側重，兩方面考慮吧。 * **3）多高的 AUC 算是好的 AUC？** * AUC 指標與訓練數據有很大關系，無法確切地說達到多少的 AUC 就是好的，AUC 一定是相對來看的，并且是在訓練數據、數據分布和待解決問題在同一度量空間下進行比較，AUC 的值才有意義。不過，如果確實沒有其他可參考的標準線，可以粗略地以訓練集 7.5，測試集 7.2 為參考。 ##### **3.1.3.2 MAP** * **MAP（Mean Average Precision）**：平均精度均值，單個主題的平均準確率是每篇相關文檔檢索出后的準確率的平均值。 *  * 舉例，如下圖表示某個查詢關鍵字的檢索出的網頁排序列表，藍色表示相關，白色表示不相關。 *  *  ##### **3.1.3.3 MRR** * **MRR（Mean Reciprocal Rank）**：倒數排序法，把標準答案在被評價系統給出結果中的排序取倒數作為它的準確度，再對所有的問題取平均。 *  ##### **3.1.3.4 NDCG** * **NDCG（Normalized Discounted Cumulative Gain）：** 直譯為歸一化折損累計增益，計算相對復雜。對于排在結束位置 n 處的 NDCG 的計算公式如下圖所示： *  *  * NDCG 從 DCG 演化而來，DCG 就是 “折損化累計增益”（Discounted Cumulative Gain），我們先來介紹 DCG。 * DCG 的兩個思想： 　　1）高關聯度的結果比一般關聯度的結果更影響最終的指標得分； 　　2）有高關聯度的結果出現在更靠前的位置的時候，指標會越高； * 在介紹 DCG 之前，我們首先假定，位置 1 是排位最高的位置，也就是頂端的文檔，而位置數隨著排位降低而增高，位置 10 就是第一頁最后的文檔。 *  * 接下來我們看如何進行歸一化，由于搜索結果隨著檢索詞的不同，返回的數量是不一致的，而 DCG 是一個累加的值，沒法針對兩個不同的搜索結果進行比較，因此需要歸一化處理，這里是除以 IDCG。 *  #### **3.1.4 商業指標** * 上面提到的三個準確度指標，比較直觀地反映了推薦系統在 “預測” 這件事上對數據開采的深度，實際上由于模型不同，還可以有不同的指標，甚至可以根據場景需要自己設計指標。不過，類似這三個的準確度指標也屬于比較初期的指標，距離最終商業指標還有一定的距離，商業指標要比預測準確度指標更加接近真實效果。 * 商業指標往往與行業領域、產品形態以及用戶場景十分相關，不同的場景下選取的指標也往往不同。通常有兩類值得關注，一個是內容消費滿意度指標，一個是場景轉化率指標。 ##### **3.1.4.1 內容消費滿意度** * 內容消費滿意度指標隨著產品形態和業務場景的不同而不同，主要是應用產品某些環節的交互數據來衡量，下圖的例子分別說明了在新聞資訊、短視頻、電子商務等領域中內容消費滿意度的一些衡量指標。 *  ##### **3.1.4.2 場景轉化率** * 該類指標關注的是將用戶從一個場景轉化到我們希望的場景去的效果。這個過程需要用戶付出主動的行動，如常見的點擊行為。這類指標關注推薦系統的漏斗效果，主要有： * 1）**pv 點擊率（點擊量/pv）**：經典，但易受攻擊； * pv 點擊率是比較經典的指標，計算用戶每次進入頁面的點擊情況。pv 點擊率能粗略衡量轉化效果，但是它的問題是容易受攻擊：少數用戶貢獻大量點擊會掩蓋在這個指標后。 * 2）**uv 點擊率（點擊量/uv）**：不受用戶路徑影響（用戶重復瀏覽頁面），完整單元點擊效果； * 分母是整個產品的 uv，而不是有點擊行為的 uv。uv 點擊率相對 pv 點擊率的優勢在于，它不受用戶行為路徑影響（不受重復瀏覽某個產品的影響），能記錄用戶在一個完整 session 的點擊效果。據了解，阿里不少團隊的指標也由 pv 點擊率改為 uv 點擊率了。 * 3）**曝光點擊率（點擊量/曝光次數）**：上下翻 feed 流，每一屏轉化效果（目前 feed 流，屬主流） * 曝光點擊率適合支持上拉/下拉翻頁的產品，比如 Feed 流。相比 pv 點擊率，曝光點擊率的分母隨用戶刷屏次數增加而變大，能更真實的記錄每一屏的轉化情況。 * 4）**uv 轉化率（點擊 uv/進入 uv）**：吸引用戶的比例，消費寬度。入口型產品，如 APP 首頁。 * 與 uv 轉化率相對的是頁面的流失率。uv 轉化率衡量對用戶的轉化情況，通過我們的產品設計能把多大比例的用戶從一個場景轉化到另一個我們希望的場景去。uv 轉化率相對于前兩個指標，更健壯，不易受到攻擊。 * uv 轉化率尤其適合衡量入口型產品，比如視頻 app 的首頁，如果用 uv 點擊率去衡量會不太科學，因為一般用戶在首頁點擊某個視頻后，會進入詳情頁深度消費，很少會返回首頁繼續消費。這個用戶已經被轉化，但不再貢獻點擊，所以 uv 點擊率不合理，用 uv 轉化率就更加合理。 * 如果某頁面的 uv 轉化率較低，則表示大部分人對該頁面都不感興趣，遵循 “不行就分” 的簡單原則，這樣的頁面去掉可能對產品更好。 * 5）**人均點擊次數（點擊量/點擊 uv）**：每個用戶消費的次數，消費深度 * 人均點擊次數與 uv 轉化率相輔相成。uv 轉化率表示頁面的消費寬度（吸引的用戶比例），而人均點擊次數表示頁面的消費深度（每個用戶消費的次數）。 * 除了比例類的商業指標，還要關注**絕對量的商業指標，常見的有：社交關系數量，用戶停留時長，GMV（Gross Merchandise Volume，成交金額）。** 關注絕對數量，除了因為它才是真正商業目標，還有一個原因，是要看推薦系統是否和別的系統之間存在零和博弈情況。假如推薦系統導流效果提升，搜索引擎導流下降，從整個平臺來看，因為整個平臺的商業目標并沒有那么成績喜人，也需要警惕。 * 講完深度類指標，下面進入廣度類指標。 #### **3.1.5 其他指標** ##### **3.1.5.1 覆蓋率** * 覆蓋率（Coverage）就是看推薦系統在多少用戶身上開采成功了，覆蓋率又細分為 UV 覆蓋率和 PV 覆蓋率。 * UV 覆蓋率計算方法是： *  ##### **3.1.5.2 失效率** * 失效率指標衡量推薦不出結果的情況。也分為 UV 失效率和 PV 失效率。 * UV 失效率計算方法是： *  ##### **3.1.5.3 新穎性** * 新穎性即給用戶推薦未曾見過的物品的度量，因為同一類物品容易讓用戶產生 “審美疲勞”。**新穎性是需要講粒度的，物品粒度、標簽粒度、主題粒度、分類粒度等等。每個粒度上評價用戶沒見過的物品比例。對于物品級別的新穎性，更多是靠直接過濾保證。** * 新穎度還可以通過推薦結果的平均流行度和對用戶進行問卷來獲得。 ##### **3.1.5.4 驚喜性** * 如果推薦結果和用戶的歷史興趣不相似，但讓用戶很滿意，則可以說這是一個讓用戶驚喜的推薦。可以定性地通過推薦結果與用戶歷史興趣的相似度和用戶滿意度來衡量。驚喜性更關注與用戶歷史興趣不相似但比較滿意的物品。 ##### **3.1.5.5 更新率** * 檢測推薦結果更新程度。如果推薦列表每天幾乎一樣，顯然不可取，尤其是新聞資訊類，要求每次刷新都不一樣，對更新率要求更高。更新率可以有很多衡量方式，有一種是衡量每個推薦周期和上個周期相比，推薦列表中不同物品的比例。這個周期，可以是每次刷新，也可以是每天。 * :-:  ### **3.2 探索類指標（是否健康）** * 除了關注系統表現有多好外，你還需要憂慮另一件事，你的系統還能好多久？也就是系統是否健康。 * 在推薦系統中，需要數據不斷更新，這樣系統才是一個活系統，用戶興趣客觀上會變遷，數據源客觀上也是會用光的一天，所以推薦系統如果不能應對這兩個變化，就好不了太久。 * 衡量推薦系統是否健康的指標常用的有三個。 #### **3.2.1 個性化** * 雖然說到推薦系統時，言必稱個性化，但實際上能做到真正個性化很難，那要求用戶每個人都獨立思考、愛好明確、不受群體影響。但是個性化程度的確能夠反映推薦系統的健康程度。 * 按照 “是否需要推薦系統” 的公式來看： * :-:  * 如果沒有個性化，那么分子上增加的連接數，其實是不受分母上增加的物品數影響的，因為所有人都只消費那少數幾個物品，那么你其實不需要推薦系統。 * 個性化如何檢測呢？有一個直觀的方法，取一天的日志，計算用戶推薦列表的平均相似度，如果用戶量較大，對用戶抽樣。 #### **3.2.2 基尼系數** * 基尼系數衡量推薦系統的馬太效應，反向衡量推薦的個性化程度。把物品按照累計推薦次數排序，排在位置 i 的物品，其推薦次數占總次數為 pi。那么基尼系數為： * :-:  * 看這個公式可以知道，如果推薦次數越不平均，那么基尼系數就越趨近于 1。 * 馬太效應，是指強者越強，弱者越弱的效應。推薦系統的初衷是希望消除馬太效應，使得各物品都能被展示給對它們感興趣的人群。但是，很多研究表明，現在的主流推薦算法（協同過濾）是具有馬太效應的。 #### **3.2.3 多樣性** * 多樣性不但要在推薦服務吐出結果時需要做一定的保證，也要通過日志做監測。 * 多樣性可能會損失一些效果指標，但是從長遠上來看，對推薦系統所在平臺是有利的。多樣的推薦結果也會讓產品顯得生機勃勃，提升品牌形象。多樣性衡量方式通常要依賴維度體系選擇，例如常見的是在類別維度上衡量推薦結果的多樣性。方法是下面這樣的。 * :-:  * 多樣性衡量實際上在衡量各個類別在推薦時的熵，一共有 n 個類別，分母是各個類別最均勻，都得到一樣的推薦次數情況下對應的熵。 * 分子則是實際各個類別得到的推薦次數，pi 是類別 i 被推薦次數占總推薦次數的比例，計算它的熵。兩者求比值是為了在類別數增加和減少時，可以互相比較。 * 這種計算多樣性是一個整體的評價，還可以具體評價每次推薦的多樣性，每個用戶的多樣性，也就是 PV 多樣性和 UV 多樣性。 ### **3.3 小結** * **1）不要太依賴算法指標（偏技術的指標）** * 上面我們介紹的準確度指標（評分準確度、分類準確度、排序準確度）都是側重于對算法或模型的評價，它們無法直接體現產品的好壞，對于產品，還要多關心商業指標，以及一些系統的整體評價指標，判斷是否能驅動業務發展、策略調整。 * **2）各項指標都有局限性** * 之所以出現這么多指標，就是因為沒有一個完美的指標能夠反應所有的情況，每個指標都有自身的局限性，這些局限性或側重的角度不同，或為了凸顯某方面指標帶來一些不好的影響，總之，要認清指標都有局限性。 * **3）指標不宜過多** * **最后，產品指標不宜過多，過多的指標不利于最終優化決策。** 本文所述的指標，**每個產品也需根據自身特點和業務需求選擇核心的幾個**。如果真的要關注多個指標，可以試著把這些直觀指標再次綜合成一個更高階的指標，從而減少關注的目標，集中優化精力，幫助決策。 ## **4. 線上評測** * 線上評測的核心就是在線可控實驗，有時候又稱作是在線實驗，主要方式就是在線 A/B 實驗，也稱 AB 測試、A/B testing。 * AB 測試有點類似于生物學實驗，一般會設置 “控制組”（Control Bucket）和 “對照組”（Treatment Bucket）兩個實驗組，實驗時兩個實驗組會保留唯一一個不同的變量，這個變量稱為 “獨立變量”（Independent Variable），是推薦系統中某個改進的部分，而其余保持不變。這樣，我們就希望通過在線實驗以及假設檢驗的工具，來認定這個 “獨立變量” 是否會帶來系統性能上的提高或是降低。這里面還有一個需要提前確定的，就是需要評測的指標，特別是用戶指標，比如網站的點擊率、搜索的數量等。這些指標我們稱之為 “依賴變量”（Dependent Variable）。說白了，我們就是希望能夠在 “獨立變量” 和 “依賴變量” 之間通過假設檢驗建立聯系。 * 接下來我們看看常用的 AB 測試框架。 ### **4.1 單層實驗框架** * 以某種分流的方法 (隨機、UID、時間戳、CookieID 等流量分桶)，給每個實驗組分配一定的流量。每個實驗組配置不同的實驗參數。 *  * AB 測試的在線實驗往往不只有推薦實驗單獨使用，在同一個系統中，UI 測試和廣告實驗也同樣會產生影響。因此，對于獨立變量的控制將變得尤為重要，也不難發現，單層試驗框架會存在以下缺點： * **只能支持少量實驗，不利于迭代** 因為實驗分桶較多，分到單個流量桶的時候，流量已經非常少了，所以只能進行少量實驗，不利于迭代； * **實驗之間不獨立，策略之間可能相互影響** 比如，三方單獨在線下測試都能提高指標，但是上線后，合到一塊兒反而可能造成指標下降，那它們之間可能相互有干擾，所以單層實驗框架中的實驗是不獨立的，全量上線后策略之間相互影響容易造成偏差。 * **分流方式不靈活1** 單層實驗框架的分流方式選擇的維度只能是一種，比如要選 UID 所有的實驗都得按 UID 分流，那此時如果廣告實驗只想看北京用戶的流量，單層實驗框架就無法滿足需求了。 * 也因為單層實驗框架的這些問題，Google 后來提出了一種新的多層重疊實驗框架。 ### **4.2 多層重疊實驗框架** * 多層實驗框架的設計避免了很多單層實驗框架可能出現的問題，保留了單層實驗框架易用、快速的優點的同時，增加可擴展性，靈活性，健壯性。其整體結構如下圖所示： * [](https://lumingdong.cn/wp-content/uploads/2019/03/image-20190327120959482.png) * **多層重疊實驗框架的核心思路**是，將參數或功能點劃分到 N 個子集，每個子集都關聯一個實驗層，每個請求會被 N 個實驗處理，同一個參數或實驗策略不能出現在多個層中。 * 多層重疊實驗框架每一層設置一個策略，比如上圖中第一層 UI、第二次算法、第三層版本、第四層地域，每一層都是正交的，不會互相影響。 * **現在很多一線公司都會使用 Google 提出的這套框架，只是在具體的設計、流量分配維度的選擇、業務邏輯上存在一些差異，基本思想都是這樣的，并且會有相應的 Team 專門維護。** * 多層重疊實驗框架在實際應用中，要根據業務場景，特別注意考慮以下問題： * 分配函數 (流量在每層被打散的方法) 如何設計? 如何保證每層流量分配的均勻性和正交性? 流量的分配是一個非常重要的過程，面對十幾種重要變量（例如，年齡、性別、地域、收入層級等），要想完全做到幾個分桶分布相當，完全正交（正交就是完全獨立，沒有相關性），難度很大。因此，Hash 函數的選取非常關鍵。 * 如何處理實驗樣本的過濾 (例如只選取某個地區的用戶、只選取新用戶)? * 分配多大的流量可以使實驗置信? ## **5. 用戶調查** * 最后一種測試方法就是用戶調查，也稱用戶訪談。前面三種評測方法，背后的思想是數據驅動。 * 數據測量的是系統外在表現，并不反映系統原理，而且數據指標是人設計的，是存在主觀性和片面性的，人的認知廣度和深度各有不同。 * 因此，除了要緊緊團結在 “數據驅動” 這個核心思想周圍，還需要深入用戶，對用戶做最直接的交流，對用戶調查，更重要的意義不是評測推薦系統，而是評測推薦系統的指標，設計是否合理，是否其高低反映了你預先的設定。 * 除此之外，通過前面三種測試方法如果得知系統表現不好，那么結合直接真實的用戶調查和訪談，可以為系統優化找到真實原因。要想真實了解平民百姓的水生火熱，還是得下到基層才行。 ## **6. 評測維度** * 如果推薦系統的評測報告中，包含了不同維度下的系統評測指標，就能幫我們全面了解系統性能。 * 一般評測維度分 3 種： * 用戶維度，主要包括用戶的人口統計學信息、活躍度以及是不是新用戶等； * 物品維度，包括物品的屬性信息、流行度、平均分以及是不是新加入的物品等； * 時間維度，包括季節，是工作日還是周末，白天還是晚上等。 ## **7. 總結** * 一般來說，一個新的推薦算法最終上線，需要完成上述的 4 個實驗和評測。 * 首先，業務模塊開發完成后先進行業務掃描，解決內部可能出現的問題； * 其次，通過離線實驗證明它在很多離線指標上優于現有的算法； * 然后，通過用戶調查確定用戶滿意度不低于現有的算法； * 最后，通過在線 AB 測試確定它在我們關心的指標上優于現有的算法。