352
推薦係統之眼
前言這半個月除了工作上的事，一直忙於學習機器學習基礎理論，每天背著四五本書上下班，還蠻有讀書時的感覺。之前寫了一篇文章，叫基於用戶畫像的實時異步化視頻推薦係統，應該說隻是完成了一個心髒，整個數據集經過心髒的起博，開始流動起來，並且能夠對外提供服務。然而此時的係統依然是瞎的，我們不知道它的效果如何，給我們帶來了什麼收益，會不會出現糟糕的推薦結果，以及我們有沒有途徑按照自己的想法去調教它。
我們不僅僅希望算法工程師，研發工程師能了解推薦係統的狀態，影響推薦係統的效果，我們還希望客戶，運營人員也有能力去了解並且影響它。
所以一個強大的推薦係統後台是極其重要的，如果沒有他，真個推薦係統就是一個瞎子，並且是不受控製的。
整個後台由四部分組成：
- 轉化率指標
- 覆蓋率指標
- 元信息管理
- 係統狀態監控
這四個模塊分別是解決什麼問題的呢？
這個是衡量推薦係統效果的。推薦係統衡量的核心標準是，我給你推薦的，你會不會進行點擊。當然，不同場景可能要求是不一樣的，比如電商可能核心的效果是購買轉化率。以點擊曝光轉化率為例，我們會計算每個五分鍾的值，從而形成一個點擊轉化率曲線，可以看到趨勢。點擊轉化率是如何計算的呢？點擊轉換率通常是針對一個推薦位而言的，當然我們也可以計算總的效果。
- 點擊曝光轉化率 = 一個統計時間區間內,點擊數/曝光次數
- 曝光次數 = 一個統計時間區間內，視頻被曝光的次數
- 點擊數 = 一個統計時間區間內,視頻被點擊的次數
除了這個，比較重要的還有 用戶轉化率。另外，我們知道，一個頁麵假設是一個城市，每一個欄目塊就像一個商圈了。不同商圈的流量差異是比較大的，有一個指標叫 曝光推薦轉化率 可以衡量是不是有異常情況發生，比如在一個熱門的城市，接口請求量可能特別大，但是發現曝光率卻很小，那麼可能是這個推薦位落在了一個流量非常小的商圈裏，比如可能在頁麵某個疙瘩處。這個指標可以幫助我們校正產品的一些問題。否則流量那麼小，你推薦效果再好，也起不到太大作用。
- 曝光推薦轉化率 = 一個統計時間區間內，視頻曝光次數/視頻推薦數次數
其中食品推薦數來源接口層的日誌。
如果我們隻推熱門的視頻，轉化率肯定應該是不錯的。然而互聯網的一個典型情況是，長尾視頻的流量之和可能大於一些熱門的視頻流量之和。當然這個結論目前我也沒有數據去證實，搜搜的一個LDA 係統(peacock)，說是能覆蓋百萬的主題，長尾的搜索詞產生的流量其實大於一些熱門搜索詞的流量之和的，我想這個應該是可以順延到很多場景中。
既然是千人千麵的推薦，也就是大致大家看到的都是自己喜歡的，重疊度理論上不應該太高。這個時候說明我們的推薦出去的視頻要覆蓋相當一部分媒資裏的視頻。我們做了一個新的指標定義：
- 推薦覆蓋率 = 一個統計時間區間內,總推薦視頻數/總視頻數
此外還有曝光覆蓋率等指標，新視頻覆蓋率，用戶覆蓋率等各種指標。
推薦係統應該是個可以由運營人員來tunning的一個係統。我們將推薦算法，程序計算周期等各種參數暴露給到後台，抽象成元信息管理。通過調整這些參數，我們不但可以讓算法研發去調整，還可以讓運營充分利用自己的經驗，還有結合我們前麵各種轉化率指標，覆蓋率指標，製定更加合理的規則。
比較典型的是，各個候選集的大小，用戶私有隊列的大小以及生存周期，每個算法的每次請求可吐出的數據的數量等。
另外在該界麵，你可以做數據探索，獲得包括一個視頻的訪問人數或者一個用戶的訪問軌跡等。這個主要是我們會將用戶行為存儲到ES裏，借助ES-SQL和Spark-SQL我們可以做非常大規模的探索式查詢。
以前我也不相信一個推薦係統是可以tunning的，他應該完全依賴於研發和算法工程師。但是之前和一個做搜索的人接觸，他在美國兩家知名的搜索服務提供商工作過，對方的搜索係統抽象做的非常好，售後支持可以無需通過編程，和客戶一起當場tunning搜索結果，直到客戶滿意。推薦係統也是一個高度成熟和經過實踐的係統，能做到和我剛剛描述的那樣，算是一個較高的境界了吧。
按之前在基於用戶畫像的實時異步化視頻推薦係統的描述，其實我們推薦係統分成了三大部分：
- 計算/推薦引擎，由眾多的spark 批處理和流式任務組成，也包括一些存儲引擎，包括HDFS,ElasticSearch,HBase,Redis Cluster(其實是Codis)等。
- API服務，單獨的無狀態可實現負載均衡的接口服務。主要功能是操作Redis隊列。
- 後台服務。後台服務包括前麵的兩個指標體係，一個原信息管理，還有就是這個係統狀態監控。其實還有一個，就是一個模擬服務，在該頁麵上你可以看到一個推薦位，並且選定一個虛擬用戶，你的包括點擊行為都會在該頁麵看得到。包括短期興趣模型等實施的變化情況。
在後台，我們還可以看到計算/推薦引擎的工作狀態是不是正常。這個主要針對 計算/推薦引擎模塊。以為這些模塊是有若幹個邏輯上有依賴的任務組成，我們可以在後台的係統狀態監控模塊看到這些任務是不是都按預期的運行了。並且結合前麵的指標體係，我們也能看出 API服務是不是正常的服務。
後台的開發成本其實遠遠高於推薦係統對外的功能。考驗我們對推薦係統有更好的理解和抽象能力。
最後更新：2017-04-01 17:13:52