總結、溫習，這兩點讓人成長。而不是你走得有多快！
這句話我寫了半年了，這篇文章算是此話付諸實踐的開端吧。
本文是我對自己這幾年所接觸的技術的總結，有些技術與工作直接相關，有些則純屬個人興趣。具體說，本文分為兩部分，第一部分介紹佳緣用戶推薦系統(tǒng)的發(fā)展歷史。這部分的介紹很好地反映我們對這個問題的思考和理解過程。這期間我們走了很多彎路，但也正是這些彎路讓我們積累了很多婚戀交友推薦里獨特的實戰(zhàn)經驗。第二部分主要是羅列了一些我個人這幾年接觸的比較有代表性的技術，這些技術很多偏學術，只對實戰(zhàn)感興趣的同學可以忽略。
佳緣用戶推薦系統(tǒng)天真的算法年：2011-2013
2011年8月我加入世紀佳緣，開始時主要負責佳緣的交友推薦系統(tǒng)優(yōu)化，后來我這個團隊也負責其他的機器學習事情，比如佳緣的網警系統(tǒng)（抓惡意用戶）。剛來時團隊加上我只有3個人，做的事基本集中在推薦系統(tǒng)，以及對業(yè)務部門新產品的接口支持。當時我自己并沒有推薦系統(tǒng)應用于工業(yè)界的實際經驗，所以很想當然地就從自己了解的推薦算法開始工作了。
2011年到2013年中這段時間，我們在算法方面主要做了兩個方向的嘗試。第一個是嘗試item-based kNN算法。對這個算法的優(yōu)化嘗試體現在以下幾個方面：
離線計算效率的優(yōu)化：從開始的單機計算，到后來的Hadoop分布式計算。
離線計算效果的優(yōu)化：嘗試了不同的相似度計算方法，以及不同的預測產生方式，但效果并不明顯。
離線計算改為線上實時計算：離線的工作方式是先在線下計算好推薦結果，然后把結果存入緩存；線上需要推薦結果時直接從緩存中取即可。顯然這種方式對于緩存中沒有推薦結果的用戶無法產生推薦，而活躍的用戶又很容易把緩存中的所有結果都消費完。為了解決這些問題，后來我們在Dubbo上構建了實時的Java推薦服務。
Item-based kNN算法的嘗試最開始是基于最大化佳緣用戶發(fā)信量的業(yè)務理解，但后來我們發(fā)現這個理解跟業(yè)務部門的需求偏差很大。比如給男性展示美女，男性的發(fā)信就會暴漲，但這樣就會導致少量的女性收到大部分信，而大部分女性則沒信可收。這是業(yè)務部門不愿意看到的。雖然我們嘗試在item-based kNN基礎上做調整來平衡其他的業(yè)務指標（如收信人數，看信人數等），但效果不理想。
第二個嘗試是學術界的可逆（Reciprocal）推薦算法1，即在考慮用戶體驗的同時也兼顧item（對佳緣來說也是人）的體驗。這個嘗試基本是失敗的，學術界發(fā)明的那些算法基本都有各種前提假設，真用起來都不太靠譜。
雖然到2013年我們團隊人數上升到了六七人，但基本在推薦算法上做事的人還是只有兩個左右。
工程年：2014
從2013年底開始我逐漸意識自己對算法的理解過于學術而無法滿足業(yè)務部門的實際需求。所以從2013年底我開始從業(yè)務出發(fā)重新梳理推薦算法團隊的工作方向。相對于給用戶推薦物品的場景，佳緣的在線交友推薦有以下幾個特點：
可逆性：佳緣的物品是異性的人，他們也會有感受。所以在推薦時要考慮到雙方的感受。
資源獨占性：通常一個人在一段時間內也就和一個人談戀愛。這與電商賣東西是差別很大的，一本相同的書可以賣幾十萬冊都可以，在佳緣這么干就不行。電商可以搞個暢銷榜讓用戶購買最暢銷的書，這其實也是很好的推薦。但對于佳緣這一招就很糟糕。
轉化鏈很長，反饋延遲：從展示到發(fā)信，再到看信和回信，過程很長，而且看信和回信又會有很長的時間延遲。另外，收益在轉化鏈的末端才能體現。公司的收益在看信后才能體現（佳緣的業(yè)務模式是收取用戶的看信費用），而用戶的收益在回信后才能真正體現。
佳緣業(yè)務的高復雜性，加上團隊在使用算法上經驗不夠，讓我決定把接下來的算法優(yōu)化方向放在特征工程上，而算法就限制在最簡單的邏輯回歸（Logistic Regression）。團隊在處理特征的過程中可以積累對數據的處理經驗，以及對業(yè)務的理解。邏輯回歸足夠簡單，解釋性好，也有很好的開源實現。從它開始也可以讓團隊在算法使用上積累心得。這是“戰(zhàn)術”上的第一個選擇。我們把上圖中每一步轉化作為單獨的問題分別進行優(yōu)化，這樣邏輯回歸就適用于每一步。這是“戰(zhàn)術”上的第二個選擇。
上面說的“戰(zhàn)術”，其實針對的只是推薦系統(tǒng)里的排序系統(tǒng)。當時我對推薦系統(tǒng)整體的想法是把運營需求和用戶需求分開，然后分別對他們進行獨立優(yōu)化。具體說就是第一步以滿足運營需求為目標獲得候選集，而第二步是根據用戶（雙方）的喜好對候選集進行排序，系統(tǒng)流程圖見下圖。這樣，在優(yōu)化用戶需求時就不需要考慮佳緣復雜的業(yè)務邏輯，可以極大地簡化問題。同樣，我們也可以比較獨立地優(yōu)化滿足運營需求的候選系統(tǒng)。這可以認為是推薦系統(tǒng)的“戰(zhàn)略”方向。
佳緣推薦系統(tǒng)流程圖（2014）
2014年無疑是工程年。
產品年：2015
2014年工程年的效果還是不錯的，多個轉化模型的分別構建和組合使用，使得業(yè)務上的各個指標都有所提升，很多指標的提升幅度都超過了50%。
現在看來，2014年的戰(zhàn)術是非常正確的?；艘荒陼r間在特征工程上，團隊確實對業(yè)務數據的理解更深入了很多，也積累了模型優(yōu)化的一些經驗。戰(zhàn)略上雖然大方向沒錯，卻也存在一些問題。首先，運營需求與用戶需求本來就是相關的，它們不可能完全獨立，我們在優(yōu)化一個指標的同時很容易對另一個指標產生副作用。
例如，按照上面的流程圖，第一步的候選系統(tǒng)通過考慮運營需求來產生候選集，然后候選集由考慮用戶需求的排序系統(tǒng)進行排序。如果產生的候選集很小，那排序系統(tǒng)的優(yōu)化空間就很小，作用自然也不會大；而如果候選集很大，那通過排序系統(tǒng)排序后獲得最終推薦結果的做法就會降低運營需求的控制力度。
2014年底的時候我開始考慮2015年推薦系統(tǒng)團隊的工作方向。那段時間我集中看了很多公司推薦相關的資料，其中幾年前百度大推薦部門（現在已經解散）公開的一些演講資料對我啟發(fā)最大。很多公司講推薦的資料都注重講算法，或者數據和特征；而百度的這些資料主要偏向于從系統(tǒng)方向來講。這啟發(fā)我回到排序系統(tǒng)的本質來看推薦系統(tǒng)。
搜索，廣告和推薦系統(tǒng)，本質都是大規(guī)模排序系統(tǒng)。它們都遵循“候選產生 –> 排序 –> 后處理”的一般流程（見下圖）。
再仔細說明下上面這個流程中的前兩步：
1）候選產生（檢索）系統(tǒng)：找與用戶相關的候選集合。對于佳緣來說，這里的相關候選集合可以通過（互相）滿足擇偶條件來獲得，也可以通過算法如kNN，AR等來獲得。不管用什么方式，最終目的就是把用戶與候選集合聯系起來。
2）排序系統(tǒng)：排序系統(tǒng)里的排序目的是最大化產品目標。對佳緣來說，產品目標包括了運營目標和用戶滿意度。
相對于2014年運營需求與用戶需求獨立優(yōu)化的“戰(zhàn)略”，2015年的優(yōu)化思路有所調整：
- 分離出運營需求中與用戶需求耦合小的部分，使用規(guī)則控制。這樣做的原因主要還是佳緣的業(yè)務邏輯太復雜，完全依靠算法達成產品目標很困難，所以加入了一些規(guī)則進行宏觀控制。
- 統(tǒng)一優(yōu)化無法分離的運營需求與用戶需求。這種統(tǒng)一不僅體現在排序系統(tǒng)會同時考慮這兩方面的指標，也會以較弱的形式體現在候選產生系統(tǒng)里，畢竟從候選產生系統(tǒng)產生的候選集不可能是所有與用戶相關的物品（異性）。
那么，為什么把2015年叫做推薦系統(tǒng)的產品年？因為今年推薦系統(tǒng)的目標是優(yōu)化產品目標！
推薦系統(tǒng)是為產品服務的，而不是直接為用戶服務。
上面這句話聽起來很簡單，但其實很多時候我們會在不知不覺中認為推薦系統(tǒng)是直接在為用戶服務的。我們在最早的時候就是犯了這個錯誤。
本節(jié)的最后，匯總羅列下我這幾年做推薦的感想：
- 技術為產品服務，而不是直接面向用戶
- 數據質量是地基，保證好的質量很不容易
- 如何制定正確的優(yōu)化指標真的很難
- 業(yè)務理解 > 工程實現
- 數據 > 系統(tǒng) > 算法
- 快速試錯
一些技術嘗試
這節(jié)我只是簡單羅列下最近幾年自己接觸的比較有代表性的一些技術，跟工作關系不大。
Dirichlet Process 和 Dirichlet Process Mixture模型
了解DP主要是因為當時在看Mahout源代碼的時候發(fā)現有個算法以前竟然沒接觸過，覺得挺有意思就仔細學了下。DP不太好理解，它被稱為分布的分布。從DP抽取出的每個樣本（一個函數）都可以被認為是一個離散隨機變量的分布函數，這個隨機變量以非零概率值在可數無窮個離散點上取值。DPM是非參數貝葉斯聚類模型，聚類時可以讓模型自動學習類數。雖然聽著好像很不錯，其實有很多槽點，具體可見參考文獻2。
Latent Dirichlet Allocation (LDA)
LDA是文本處理里的利器，經常被用于對文本進行聚類，或者預處理。更詳細的理論介紹可見參考文獻3。當時我嘗試把它用于佳緣的發(fā)信數據，看看能不能找出一些有明顯特征的發(fā)信群體。聚類結果整體上基本不可解釋，但有一個類別意義很明顯，這類人主要給離婚異性發(fā)信。大家可以想想這類人是什么人。嘗試感想是LDA直接用于聚類未必靠譜，但是可以把它用于數據的預處理，比如降維什么的。
Alternating Direction Method of Multipliers (ADMM)
ADMM是個優(yōu)化算法框架，它把一個大問題分成可分布式同時求解的多個小問題。理論上，ADMM的框架可以解決大部分實際中的大尺度問題。槽點很多，謹慎使用！更詳細的介紹可見參考文獻4。
Deep Learning
前段時間，我利用佳緣的用戶頭像數據，嘗試了DL里的一些常用算法。為了看算法的效果，我把用戶的性別作為預測目標。這種預測對于佳緣的業(yè)務直接意義不大，因為用戶在注冊時就被要求填寫其性別。
算法預測的效果還是不錯的，準確度達到了87%。這還是在很小訓練集上訓練后獲得的精度。DL麻煩是訓練時需要調整的超參數實在是太多了，改一次超參數就要重跑一次，真的是很耗時。沒有好的計算資源的話，建議別考慮DL。
利用GBDT模型構造新特征
實在想不出更多的有用特征？嘗試下Facebook提出的利用GBDT來構造新特征的方法吧。我們的使用經驗表明確實還是挺靠譜的，只要你效率能扛得住。具體介紹可見參考文獻5。
特征哈希（Feature Hashing）
很多個性化特征？特征數量太多？試試特征哈希的方法吧。此方法我們目前也沒使用過，歡迎有經驗的人發(fā)表意見。具體介紹可見參考文獻5。
不平衡數據的抽樣方法
正負樣本數量差異太大？訓練樣本太多機器跑不動？嘗試下參考文獻7中的抽樣方法吧。我們之前的嘗試表明還是有點作用的。不過如果你的數據不是大得跑不動，那嘗試的必要性就不太大了
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
