作為一個推薦系統業余愛好者，在機器學習領域的鄙視鏈中，我感覺一直地位不高，時常被搞NLP CV語音等高科技技術的朋友鄙視。
最近甚至被人問，推薦算法開源包多如牛毛，我們為什么還要專門的推薦算法工程師？（難道想要辭退我！？驚）
不得不說，我想吐槽這個觀點很久了。事實上搞推薦的工作不等於 import IBCF 或者 import time SVD++ import tensor啊摔！
於是找回帳號打開N年不用的博客，寫一篇隨想，其中含有大量主觀臆斷以及學術錯誤，盡量不中英夾雜術語之外的英文，如果有不同意見，歡迎回復指正。
說實在現在推薦包太多了，單機小規模實驗的R包recommenderlab；慢的不行但是能夠hadoop擴展的mahout；C++的eigen也給大家指明了一條矩陣運算的活路；matlab里各種memory based、model based、learning to rank算法包更是漫天飛；拿到風投的graphlab更是打出了號稱五行代碼動手寫推薦系統的口號，還附帶各種FM模型以及一健運行deep learning的套餐供大家玩耍；想要自己感受DIY的快樂，還有libFM；嫌慢可以使用SVDfeature簡化套餐，還支持多線程硬盤計算，2G筆記本就可以建模2T數據。
（五行實現一個推薦系統，你怕不怕）
那做一個推薦系統，看來確實不需要專門的推薦算法工程師了，import xx即可。
事實上並不是這樣，其問題在於幾個方面：1.業務轉化數學問題 2.數據特性定義active function 3.根據業務定義合理損失函數 4.損失函數求解調優 5.計算量太大的離線算法優化和線上算法優化。
我們可以看到，一個完整的推薦系統項目不能靠import xx實現的至少有上述幾點。能夠把這5點走通玩好，才是老板養這樣幾個工資萬兒八千天天看起來成天只會看動畫無所事事的推薦算法工程師的原因。
1.業務轉化數學問題
一般一個項目啟動都是老板說，我們公司的現在電話銷售（app下載、商品銷售、淘寶客收入等等）挺不錯的，但是推薦欄的那個IBCF算法太搓，或者人工運營太累，你們能不能搞個推薦提高下轉化率？
和做學術以及競賽不一樣，我們並不知道有哪些數據，也不知道要做成什么形式，推薦位放在哪，UI怎么搞比較好，這些都是需要和業務方一起磋商定稿的。
以電話銷售為例，我們需要給電話銷售人員一個列表，告訴他你今天給這樣幾個人推銷這樣幾個商品會比較好。然后開工了，我們需要跟業務人員在一起商量，到底用什么數據能夠完整的體現一個銷售人員給特定的客戶推銷什么商品會成功？以此為依據決定收集什么樣的數據，而非一般書籍里講述的，僅僅使用用戶商品矩陣這么清爽明快的事情。
以這個特定問題為例，我們需要的是銷售人員數據，用戶數據，商品數據，用戶商品交互數據，銷售人員商品交互數據，銷售人員用戶交互數據。其中用戶商品交互數據中的很小一塊便是很多開源包可用的UI矩陣。
數據收集來了之后對數據做統計，消除特殊活動以及廣告引流等影響，搞定缺失值、默認值、異常值等問題。里面還經常會遇到一些機器學習的子問題要處理，比如垃圾用戶怎么排除（基於強規則弱規則構造特征做一個小分類器之類的）。
填完這些坑，往往半個月一個月過去了，還非常辛苦（我的感覺是：程序員來自地球，業務人員來自火星）。。。。
2.數據特性定義active function
繼續拿上面那個問題說事，數據清洗好該構造特征定義active function了。
active function是我隨便叫的，或者叫model equation？總之我們如果假設特征相互獨立，那么就是 y=wx 這種；如果認為特征集之間會有交互，我們有兩種方法，第一種是做一個 low rank 假設，比如 SVD 的 y=pq這種形式，就是對於用戶商品交互特征進行建模；另外一種就是寫成y=wij*xi*xj這種形式。前面一種是 factorization models 的搞法，后面一種是 用rf或者gbrt的交叉特征的搞法。
對於我們這個問題來看，銷售人員特征、用戶特征、商品特征這種就屬於wx這種形式；而銷售人員商品交互特征、用戶商品交互特征、銷售人員用戶交互特征這種就屬於y=sq+sp+pq（銷售s，用戶p，商品q）這種形式。
所以整體來看我們問題的定義下來，active function應該為y = wx + sq + sp + pq的形式。順便一說，考慮到時間因素，還要再加上好幾個t的項（如果采用pairwise interaction tensor的形式的話）。
定義好形式就可以抽取特征了，然后按照 categorical variables以及noncategorical variables的形式整理好，這時候就可以開心用包啦！
打個比方，libFM就提供了一個建模的通用式子
分別是bias，獨立特征以及交互特征，一般人常說的IBCF，SVD等都是這個式子的特殊形式而已。
順便這里說下，現在搞推薦的，一般兩種流派，一種是用MF的，一種是用LR，RF，GBRT上高維特征的，經常吵的勸都勸不動。
我覺得這個只是數據特性的兩種active function定義的傾向而已。
前者考慮到不同categorical variable的交互。對於wij，我們經常是很難觀測到行為的，比如用戶i給電影j的行為，已經觀測到才能估計wij，但是這表示他已經看了電影了，那推電影j就沒意義了，所以我們使用pi*qj來近似wij。
后者一般不考慮categorical variable的交互，或者他們能觀測到wij對應的xi*xj的行為，所以直接用分類回歸模型求解wij而無需使用low rank假設。比如說天貓商品推薦，用戶想買一個商品，經常會有點擊搜索行為，這種xi*xj就是可觀測的了，所以直接上rf或者gbrt就是合理的。其active function的通式為這個：
所以一句話，沒有所謂推薦算法哪家強，只有合適的應用場景對應的合適的active function，然后影響到我們是用MF還是LR RF這種。觀測不到或者觀測很少用前者，反之用后者。或者兩個都上，做ensamble（有計算資源，就是這么任性）。
3.根據業務定義合理損失函數
這又是一個比較有爭議的話題，不過也是推薦從業人員的工作核心所在，大概要忙活一下午？
一般的損失函數有三種，1.回歸 2.分類 3.排序
比如說：
，
說實在，我干活從來不用前面那種，只有競賽明確指明排行榜按照RMSE排序才會用前者。因為我們經常要做的是top-N的排序，對於用戶給商品打分估計准了，但是轉化率提不上去沒用，因為用戶只考慮買還是不買，很多研究也指出RMSE跟轉化率和top-N不是很搭。
說到損失函數不得不說最近很火的learning to rank，其損失函數是MRR這種直接優化排序的，相比AUC等考慮全局排序或者甚至只是point wise的分類系列損失函數，從理論上來說更加合理。其損失函數是個非凸損失函數，我們一般把其近似為凸函數求解（實際上還是有點坑）。
然后我們要考慮損失函數是否帶權，以及正則的問題。帶權主要是比如一個商品推成功了賺5毛，一個商品推成功了賺50，天壤之別，這就要結合業務來定義了。正則一般上L2，比如這種
另外很多人覺得損失函數定義成怎樣對結果影響不大，我覺得吧，還是很有影響的吧摔。
4.損失函數求解調優
在給定對數據的觀測下定義優化問題求解優化問題一直是機器學習的主旋律，俗話說，數據挖坑一身功力全在調優（並不是）。
我們一般要選擇一個科學的適合現狀的方法，還有搞好超參數。
拿常用的推薦系統優化方法來說，SGD，ALS以及MCMC一般的算法包都會提供。以LibFM為例對比三種方法：
可以看到，新手用MCMC inference最好。在推薦的問題中，一般只需要調兩個超參數就好，factor的dimension k以及對factor初始化的高斯分布的std。k一般從小的着手，5啊8啊都是不錯的做第一次調參的選擇，太大容易過擬合。std對結果影響很大。不過好在也比較好調，一般選擇0.1 0.2 0.5 1.0這種，而且我們一般在迭代的初期就可以通過觀測training error的方式就可以確定了，甚至比常用的開源包的實現方式（從train里摳一部分做holdout set做觀測）還好。
如果是高手，可以挑戰SGD，SGD的參數除了MCMC的那幾個，還有幾個非常不好調的參數，有正則項的lambda以及學習速率。正則項沒辦法，只能靠grid search。學習速率更坑，高了不收斂，低了跑的慢，具體什么速率好只有上帝知道。（最好是0.0127這種，不要是10的倍數，我瞎說的）。
總之，這塊也是一個具有挑戰性和技術性的不能自動化的工作。
5.計算量太大的離線算法優化和線上算法優化
算法一般分好幾個部分，一般有線下部分和線上部分，比如很多做法是線下選離線商品池子，線上CTR預估。這樣就涉及到大量的離線評測和線上算法架構。
一般的公司項目的數據量都是單節點運算支撐不起的。百萬級有行為用戶和幾十萬的商品都是很常見的，小規模也有幾萬，所以要離線評測一般需要並行和分布式。這些也是很難自動化的。
對於數據的預處理和特征的構造，一般都是數據並行，規模不是特別大的log或者不是太多冗余的文本，python腳本nohup也是個不錯的選擇，或者用hadoop寫MR。模型的算法並行看情況，一般的MF類型模型可以O(kN)求解，單機寫的性能高點小時級別還是可以出結果的（比如SVDfeature這種），或者公司有條件上MPI，自己寫spark也可以，但是沒有看到成熟的成功案例？還有用graphlab這種性能也是不錯的。
線上的話架構等模型定下來做LR這種，有實時的特征（最近30個點擊這種），也有離線算好的，一般會對用戶大體離線算個離線池子，這樣線上壓力小，storm都是不錯的選擇，反正不需要實時訓練，數據增量記錄好一天甚至一周一迭代就好。
當然要上線要經歷九九八十一難，某廠一個產品離線到AB test上線到最后，存活率不足1%，還要根據線上結果咔嚓掉一半，這些也是工程師要經歷的磨難。
所以說了這么多，就是說，報告老板，當推薦算法開源包多如牛毛，我們還要專門的推薦算法工程師的！有好多事情可做的！（於是我的飯碗保住了，又可以愉快看動畫片在B站自由飛翔了）
很多地方寫了后面忘記前面，大家有什么想法快來交流，相互提高，郵件交流（我近期興趣點在於如何有效利用外源數據提高推薦效果以及learning to rank調優這塊） flclain@gmail.com