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