需求與匹配 從數據挖掘角度看世紀佳緣推薦系統

昨天看到同事在朋友圈以及機器學習日報推薦的這篇文章：《佳緣用戶推薦系統》，再結合自己之前的幾年的推薦系統經驗，以及在婚戀網站半年多的經驗，來談談我眼中的婚戀市場的推薦系統。

如作者所說，佳緣作為第一家也是中國最大的婚戀網站，的確在推薦系統上走了很多的彎路，但也正是這些彎路以及作者的分享精神，才給后來者的我們提供了許多一線的參考價值。我相信任何在今天看來不完善的，甚至有一些可笑的設計，在當時都是有著合理性和必要性的。那么我再回顧自己的2011年如果開始從頭搭建這樣一套系統，是否能做成這個樣子，自認也沒有這樣的把握。所以這篇文章純粹是站在我今天的角度來做點評和分析，也望大家多多探討。

首先，我們先順著作者的思路去看佳緣經歷的推薦算法：

在2011年到2013年的算法年，佳緣嘗試了兩個算法方向，與我的想法非常背離，第一個不是最基本的Content-based，而是Item-based，相信Item-based算法大家都再了解不過，所以就不多做解釋。我們只來分析算法的業務應用。Item-based是在構建一個User-Item矩陣，然后計算Item-Item之間的相似度。那么具體到婚戀網站的業務場景，其實也就是構建了一個Man-Woman的矩陣，將Woman當做Item，計算Woman之間的相似度，這個算法場景基于背后的假設是認為，如果一個男人喜歡一個女人，那么他必然喜歡和這個女人相似的女人，換句更直白的話說，每個男人都喜歡自己女朋友的閨蜜。相似，我們將User-Item矩陣做轉置后，可以繼續做Man的相似度，不再復述。

這個算法設計有如下幾個問題：

1. 如作者所說，給男性展示美女，男性的發信就會暴漲，這樣少量女性收到大部分信，而大多數女性卻收不到信。但是作者可能沒有把這部分給說透，如果單純從這一點來看，這并不是協同過濾算法本身的原因。這其實是一個惡性循環，算法本身就是基于了一個嚴重有偏的User-Item矩陣來計算相似度，于是產生的推薦結果最終會造成給所有人都推薦美女。

2. 但是這并非是一個無解的問題，我們回歸Item-based的本源思考為什么熱門的條目會受到額外的照顧，拋出業務場景，其實根源在于Cosine-Similarity里分母開的那個根號惹的禍，可以想象10000的平方根和1000的平方根到底有多大差別，其實罪魁禍首就是平方根弱化了熱門條目的作用，如果一定希望去調整，可以根據實際的業務情況去調整指數。

3. 稀疏性問題。對于婚戀網站來說，長尾性和稀疏性比傳統的條目網站都大得多，大家可以想象一下大多數人來婚戀網站的目的，以及走在大街上看到美女的概率即可，所以單純的Item-based是無法解決問題的，只會造成大部分人可能一輩子都收不到一封信。但是這其實也有解，最粗暴的方法就是對于一部分用戶配合Content-based做隨機展示(對于展示哪一部分，我們之后再來具體說)。

4. 協同過濾的傳統問題，就不多說了，比如說實時性，參數調整的復雜性等等。

5. 具體到婚戀業務上來說，“如果一個男人喜歡一個女人，那么他必然喜歡和這個女人相似的女人”這句話結合業務場景和業務目標是有著悖論的，我們做個邏輯推演，如果我喜歡某個女人，就會給這個女人發信，如果這個女人理我了，我就愿意和她“結婚”(記住，這里不是約炮)，那么我就不會也不應該再去找其他女人。 如果這個女人看不上我，那么和她相似的人也不會看上我….. 所以…..我想大家應該可以明白這個其中的問題了。

第二個嘗試也是我曾經有段時間努力探索的：Reciprocal Recommendation。也許大家對這個不熟悉，我大概講一下，這種推薦算法廣泛地應用于雙向選擇的業務場景下，例如求職網站，交友婚戀網站。不同于傳統的網站推薦系統，搭建的是基于條目的推薦系統，或者是基于用戶單向關注的推薦關系。求職網站給我推薦了一份Google CEO的工作，我會感興趣，但是他對我不感興趣是沒有意義的?；閼偻扑]也是如此。

那么這個算法解決的出發點很好，但是實話實說，其實paper一共就那么多，我總結著看了下，并沒有真正有用的東西，也沒有創造性的模型產生，只是對于傳統推薦算法的一個后過濾，整體思路就是把曾經的無向圖變成了有向圖，分別求出Man–>Women，Woman->Man的雙向關系，然后或者相乘，或者搞一些奇怪的公式去做擬合。作者說不太靠譜，但是我認為這個算法從思路上來說是對路的，無論是不是用他們那些莫名其妙的模型，但是作為思想的參考還是值得借鑒的。

接下來佳緣推薦算法的階段步入了2014的工程年，作者根據佳緣的團隊及業務特點將佳緣推薦做了戰略上的調整，從比拼算法模型改成了比拼特征工程。我不了解佳緣的實際情況，不敢多做評價，只是從個人感覺來說也許作者從一個極端走到了另一個極端。從外界來猜測一下佳緣的實現思路：抽出各種各樣的特征，例如用戶的基本人口學信息，加上用戶的行為屬性信息等等，然后針對每個用戶訓練一個分類器，來預測他是不是對對方感興趣。

那我們來聊聊邏輯回歸的根本問題吧：

1. 大部分信息大多都是離散值，而這些離散值之間并非是按照數字本身的意義有著明確的大小關系，這個如果用邏輯回歸，就會面臨讓人絕望的離散值連續化問題。

2. 如果把希望寄往于特征工程，就需要對每個特征都做深入的業務和數學化理解，而且調參這個事兒結合到婚戀網站超長的訓練反饋鏈，幾乎是無解的。不要去討論非監督化的特征工程了，因為婚戀網站的業務特別明確，人工特征往往比泛化的非監督特征工程好用得多。

3. 高維特征下邏輯回歸一樣會面臨維度爆炸的問題。

4. 邏輯回歸本質上是廣義線性模型，但是這個假設是不是適用。

5. 最關鍵的是，邏輯回歸其實和最基本的感知機有什么不一樣，從圖形上面最基本的理解，其實就是把最兩端的長尾巴給壓縮了一下，但是對于婚戀網站來說，恰恰最需要的就是這些長尾巴的東西，因為這些長尾巴是最能讓人付費的動力。

我相信接下來我說的很多嘗試和做法，佳緣都已經嘗試過了，但是站在局外者的角度，我認為除了傳統的特征工程以及算法模型的優化外，其實接下來的這些才是婚戀網站推薦算法成功的關鍵(結合佳緣的模式: 收取用戶的看信費用，其實我沒用過)：

1. 明確推薦評價指標，這一點是老生常談，做任何一個系統前，尤其是數字化系統時，最重要的就是明確建立這個系統的指標。對于婚戀推薦系統來說，最核心的指標無外乎付費的轉換率，那么繼承OKR的思路，我們來對這個指標進行拆解Key Result，想提高付費轉換率有幾點需要提高: A. 收信人的覆蓋率 B. 發信者的動力 C. 收件人的看信意愿(付費意愿)，那么接下來逐漸說

2. 識別優質資源，對于婚戀系統來說，帥哥就那么多，美女也就那么多，付費用戶更是就那么多，所以識別用戶成為了婚戀網站的重中之重。所以婚戀網站的第一步不是推薦問題，而是一個用戶從多維度的分類問題。

3. 懂得取舍。我們繼續做邏輯推演，用戶到底愿意給什么人發信，但是到底什么人才愿意讓用戶看信。接下來什么用戶才會愿意為了一封信而付費。其實這個時候問題已經變成了，如何給優質用戶看到他感興趣的人，而這個人又對他感興趣，而且這個人恰恰又愿意付費。這個邏輯鏈條太長了。根本沒辦法來做，我們來精簡邏輯鏈條，發信其實是成本最低的，而且可以通過鼓勵或者產品引導來讓用戶發信，所以我們把第一層邏輯去掉。我們倒著來推，把問題轉換為識別出最愿意付費的那些用戶，然后找到這些用戶感興趣的用戶，通過產品引導讓這些用戶發信。

4. 推薦理由。對于婚戀推薦來說，推薦理由比傳統的網站要重要得多，因為你要明確給用戶一個付費的理由，關于傳統的推薦理由，就不再復述了，無外乎你們具有相同的屬性，喜歡這個人的也喜歡，等等。但是最近的那篇<New Direction in Recommender System>也許會給我們一些額外的啟發，大家也可以直接看我之前的博文：<商品推薦算法 & 推薦解釋>。

5. Reciperocal Recommendation思想的業務化應用。在之前，我簡化了發信者發信這一鏈條的聯系，但是如果精細化來說，不妨用這樣的思想來做發信者和收信者之間的平衡。

6. 在做分類以及評分預測時，不妨針對業務的長尾現象來做模型改造和模型選擇，因為只有小部分用戶是必須要牢牢抓住的用戶，從這一點來說，邏輯回歸確實不合適。

7. 我掃了下作者2015的展望，我很期待，尤其是ADMM的應用，目測我還沒見過身邊有人搞過，期待作者的嘗試結果。但是特征哈希這個事兒真的不靠譜，因為如果決心做特征工程，那么特征哈希這個事情就顯得太遠離業務本身而注重于泛化了，這樣子不適合邏輯回歸+特征工程這樣的戰略。

8. 從數據和算法出發的產品形態改進。這個沒什么好說的了，其實我一直認為婚戀網站的出路不在于算法和數據本身，而是能不能從數據跳出來對產品提出一些創意性改進從而產生的產品模式和收費模式的變革。去年我和很多VC聊過現在國內資本市場對于婚戀市場的看法，大家無一例外都是搖頭，婚戀市場太久沒人去變革過了，至今的幾大網站仍然是十年前的玩法。