世纪佳缘用户推荐系统演变的故事

摘要：世纪佳缘用户推荐系统演变史

作为国内最大的婚恋交友系统，世纪佳缘近年来一直在大力发展互联网大数据相亲模式，从成立之初会员自己根据条件“大海捞针”的寻找，到现在的“懂你”系统、“人脸识别”系统，世纪佳缘的用户推荐系统正在一步步的完善和拓展，大数据相亲已经成为互联网婚恋交友网站的发展趋势。

世纪佳缘从2013年开始全力推进业务从PC端向移动端的转移，截至今年第三季度，世纪佳缘向移动端转型的趋势更加明显，移动端App累计激活量已经超过4720万，通过移动端的登录次数占总体的70.3%，而2014年同期这一比例为68%。但在用户在移动端和PC端的行为习惯上有很大的不同。

作为世纪佳缘用户推荐系统的直接参与者与研发者，吴金龙以自己这几年在婚恋交友推荐里独特的实战经验，亲身向大家讲解一下世纪佳缘推荐系统的演变历史。

吴金龙，2010年毕业于北京大学数学院计算数学专业，博士期间研究方向为推荐系统中的协同过滤算法。毕业后加入阿里云计算公司，主要从事PC和云手机的输入法开发。2011年加入世纪佳缘，负责世纪佳缘用户推荐系统的开发，之后负责世纪佳缘数据相关的各项工作。目前领导世纪佳缘技术部，负责世纪佳缘各个事业部数据相关和内部系统相关的工作。

天真的算法年：2011-2013

2011年8月我加入世纪佳缘，开始时主要负责佳缘的交友推荐系统优化，后来我这个团队也负责其他的机器学习事情，比如佳缘的网警系统(抓恶意用户)。刚来时团队加上我只有3个人，做的事基本集中在推荐系统，以及对业务部门新产品的接口支持。当时我自己并没有推荐系统应用于工业界的实际经验，所以很想当然地就从自己了解的推荐算法开始工作了。

2011年到2013年中这段时间，我们在算法方面主要做了两个方向的尝试。第一个是尝试item-based kNN算法。对这个算法的优化尝试体现在以下几个方面：

离线计算效率的优化：从开始的单机计算，到后来的Hadoop分布式计算。

离线计算效果的优化：尝试了不同的相似度计算方法，以及不同的预测产生方式，但效果并不明显。

离线计算改为线上实时计算：离线的工作方式是先在线下计算好推荐结果，然后把结果存入缓存;线上需要推荐结果时直接从缓存中取即可。显然这种方式对于缓存中没有推荐结果的用户无法产生推荐，而活跃的用户又很容易把缓存中的所有结果都消费完。为了解决这些问题，后来我们在Dubbo上构建了实时的Java推荐服务。

Item-based kNN算法的尝试最开始是基于最大化佳缘用户发信量的业务理解，但后来我们发现这个理解跟业务部门的需求偏差很大。比如给男性展示美女，男性的发信就会暴涨，但这样就会导致少量的女性收到大部分信，而大部分女性则没信可收。这是业务部门不愿意看到的。虽然我们尝试在item-based kNN基础上做调整来平衡其他的业务指标(如收信人数，看信人数等)，但效果不理想。

第二个尝试是学术界的可逆(Reciprocal)推荐算法1，即在考虑用户体验的同时也兼顾item(对佳缘来说也是人)的体验。这个尝试基本是失败的，学术界发明的那些算法基本都有各种前提假设，真用起来都不太靠谱。

工程年：2014

从2013年底开始我逐渐意识自己对算法的理解过于学术而无法满足业务部门的实际需求。所以从2013年底我开始从业务出发重新梳理推荐算法团队的工作方向。相对于给用户推荐物品的场景，佳缘的在线交友推荐有以下几个特点：

可逆性：佳缘的物品是异性的人，他们也会有感受。所以在推荐时要考虑到双方的感受。

资源独占性：通常一个人在一段时间内也就和一个人谈恋爱。这与电商卖东西是差别很大的，一本相同的书可以卖几十万册都可以，在佳缘这么干就不行。电商可以搞个畅销榜让用户购买最畅销的书，这其实也是很好的推荐。但对于佳缘这一招就很糟糕。

转化链很长，反馈延迟：从展示到发信，再到看信和回信，过程很长，而且看信和回信又会有很长的时间延迟。另外，收益在转化链的末端才能体现。公司的收益在看信后才能体现(佳缘的业务模式是收取用户的看信费用)，而用户的收益在回信后才能真正体现。

佳缘业务的高复杂性，加上团队在使用算法上经验不够，让我决定把接下来的算法优化方向放在特征工程上，而算法就限制在最简单的逻辑回归(Logistic Regression)。团队在处理特征的过程中可以积累对数据的处理经验，以及对业务的理解。逻辑回归足够简单，解释性好，也有很好的开源实现。从它开始也可以让团队在算法使用上积累心得。这是“战术”上的第一个选择。我们把上图中每一步转化作为单独的问题分别进行优化，这样逻辑回归就适用于每一步。这是“战术”上的第二个选择。

上面说的“战术”，其实针对的只是推荐系统里的排序系统。当时我对推荐系统整体的想法是把运营需求和用户需求分开，然后分别对他们进行独立优化。具体说就是第一步以满足运营需求为目标获得候选集，而第二步是根据用户(双方)的喜好对候选集进行排序，系统流程图见下图。这样，在优化用户需求时就不需要考虑佳缘复杂的业务逻辑，可以极大地简化问题。同样，我们也可以比较独立地优化满足运营需求的候选系统。这可以认为是推荐系统的“战略”方向。

产品年：2015

2014年工程年的效果还是不错的，多个转化模型的分别构建和组合使用，使得业务上的各个指标都有所提升，很多指标的提升幅度都超过了50%。

现在看来，2014年的战术是非常正确的。花了一年时间在特征工程上，团队确实对业务数据的理解更深入了很多，也积累了模型优化的一些经验。战略上虽然大方向没错，却也存在一些问题。首先，运营需求与用户需求本来就是相关的，它们不可能完全独立，我们在优化一个指标的同时很容易对另一个指标产生副作用。

例如，按照上面的流程图，第一步的候选系统通过考虑运营需求来产生候选集，然后候选集由考虑用户需求的排序系统进行排序。如果产生的候选集很小，那排序系统的优化空间就很小，作用自然也不会大;而如果候选集很大，那通过排序系统排序后获得最终推荐结果的做法就会降低运营需求的控制力度。

2014年底的时候我开始考虑2015年推荐系统团队的工作方向。那段时间我集中看了很多公司推荐相关的资料，其中几年前百度大推荐部门(现在已经解散)公开的一些演讲资料对我启发最大。很多公司讲推荐的资料都注重讲算法，或者数据和特征;而百度的这些资料主要偏向于从系统方向来讲。这启发我回到排序系统的本质来看推荐系统。

搜索，广告和推荐系统，本质都是大规模排序系统。它们都遵循“候选产生 –> 排序 –> 后处理”的一般流程(见下图)。