需求与匹配 从数据挖掘角度看世纪佳缘推荐系统

昨天看到同事在朋友圈以及机器学习日报推荐的这篇文章：《佳缘用户推荐系统》，再结合自己之前的几年的推荐系统经验，以及在婚恋网站半年多的经验，来谈谈我眼中的婚恋市场的推荐系统。

如作者所说，佳缘作为第一家也是中国最大的婚恋网站，的确在推荐系统上走了很多的弯路，但也正是这些弯路以及作者的分享精神，才给后来者的我们提供了许多一线的参考价值。我相信任何在今天看来不完善的，甚至有一些可笑的设计，在当时都是有着合理性和必要性的。那么我再回顾自己的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聊过现在国内资本市场对于婚恋市场的看法，大家无一例外都是摇头，婚恋市场太久没人去变革过了，至今的几大网站仍然是十年前的玩法。