你的老婆是怎么算出来的？揭秘佳缘用户推荐系统|运营学社

总结、温习，这两点让人生长。而不是你走得有多快！

这句话我写了半年了，这篇文章算是此话付诸实践的初步吧。

本文是我对自己这几年所触摸的技能的总结，有些技能与作业直接相关，有些则纯属个人兴趣。详细说，本文分为两部分，榜首部分介绍佳缘用户引荐体系的开展前史。这部分的介绍很好地反映咱们对这个问题的考虑和了解进程。这期间咱们走了许多弯路，但也正是这些弯路让咱们堆集了许多婚恋结交引荐里共同的实战经历。第二部分首要是罗列了一些我个人这几年触摸的比较有代表性的技能，这些技能许多偏学术，只对实战感兴趣的同学能够疏忽。

佳缘用户引荐体系单纯的算法年：2011-2013

2011年8月我参加世纪佳缘，开端时首要担任佳缘的结交引荐体系优化，后来我这个团队也担任其他的机器学习作业，比方佳缘的网警体系（抓歹意用户）。刚来时团队加上我只需3个人，做的事根本会集在引荐体系，以及对事务部分新产品的接口支撑。其时我自己并没有引荐体系应用于工业界的实践经历，所以很想当然地就从自己了解的引荐算法开端作业了。

2011年到2013年中这段时刻，咱们在算法方面首要做了两个方向的测验。榜首个是测验item-based kNN算法。对这个算法的优化测验表现在以下几个方面：

离线核算功率的优化：从开端的单机核算，到后来的Hadoop散布式核算。离线核算效果的优化：测验了不同的类似度核算办法，以及不同的猜测发生办法，但效果并不显着。离线核算改为线上实时核算：离线的作业办法是先在线下核算好引荐成果，然后把成果存入缓存；线上需求引荐成果时直接从缓存中取即可。显着这种办法关于缓存中没有引荐成果的用户无法发生引荐，而活泼的用户又很简略把缓存中的一切成果都消费完。为了处理这些问题，后来咱们在Dubbo上构建了实时的Java引荐服务。

Item-based kNN算法的测验最开端是依据最大化佳缘用户发信量的事务了解，但后来咱们发现这个了解跟事务部分的需求误差很大。比方给男性展现美人，男性的发信就会暴升，但这样就会导致少数的女人收到大部分信，而大部分女人则没信可收。这是事务部分不愿意看到的。尽管咱们测验在item-based kNN基础上做调整来平衡其他的事务方针（如收信人数，看信人数等），但效果不抱负。

第二个测验是学术界的可逆（Reciprocal）引荐算法1，即在考虑用户体会的一起也统筹item（对佳缘来说也是人）的体会。这个测验根本是失利的，学术界创造的那些算法根本都有各种条件假定，真用起来都不太靠谱。

尽管到2013年咱们团队人数上升到了六七人，但根本在引荐算法上干事的人仍是只需两个左右。

工程年：2014

从2013年末开端我逐步认识自己对算法的了解过于学术而无法满意事务部分的实践需求。所以从2013年末我开端从事务动身从头整理引荐算法团队的作业方向。相关于给用户引荐物品的场景，佳缘的在线结交引荐有以下几个特色：

可逆性：佳缘的物品是异性的人，他们也会有感触。所以在引荐时要考虑到两边的感触。资源独占性：一般一个人在一段时刻内也就和一个人谈恋爱。这与电商卖东西是不同很大的，一本相同的书能够卖几十万册都能够，在佳缘这么干就不行。电商能够搞个热销榜让用户购买最热销的书，这其实也是很好的引荐。但关于佳缘这一招就很糟糕。转化链很长，反应推迟：从展现到发信，再到看信和回信，进程很长，而且看信和回信又会有很长的时刻推迟。别的，收益在转化链的结尾才干表现。公司的收益在看信后才干表现（佳缘的事务方式是收取用户的看信费用），而用户的收益在回信后才干真实表现。

佳缘事务的高杂乱性，加上团队在运用算法上经历不行，让我决议把接下来的算法优化方向放在特征工程上，而算法就约束在最简略的逻辑回归（Logistic Regression）。团队在处理特征的进程中能够堆集对数据的处理经历，以及对事务的了解。逻辑回归满意简略，解说性好，也有很好的开源完成。从它开端也能够让团队在算法运用上堆集心得。这是“战术”上的榜首个挑选。咱们把上图中每一步转化作为独自的问题别离进行优化，这样逻辑回归就适用于每一步。这是“战术”上的第二个挑选。

上面说的“战术”，其实针对的仅仅引荐体系里的排序体系。其时我对引荐体系全体的主意是把运营需求和用户需求分隔，然后别离对他们进行独立优化。详细说便是榜首步以满意运营需求为方针取得候选集，而第二步是依据用户（两边）的喜爱对候选集进行排序，体系流程图见下图。这样，在优化用户需求时就不需求考虑佳缘杂乱的事务逻辑，能够极大地简化问题。相同，咱们也能够比较独登时优化满意运营需求的候选体系。这能够以为是引荐体系的“战略”方向。

佳缘引荐体系流程图（2014）

2014年无疑是工程年。

产品年：2015

2014年工程年的效果仍是不错的，多个转化模型的别离构建和组合运用，使得事务上的各个方针都有所提高，许多方针的提高起伏都超过了50%。

现在看来，2014年的战术是十分正确的。花了一年时刻在特征工程上，团队的确对事务数据的了解更深入了许多，也堆集了模型优化的一些经历。战略上尽管大方向没错，却也存在一些问题。首要，运营需求与用户需求原本便是相关的，它们不行能彻底独立，咱们在优化一个方针的一起很简略对另一个方针发生副效果。

例如，依照上面的流程图，榜首步的候选体系经过考虑运营需求来发生候选集，然后候选集由考虑用户需求的排序体系进行排序。假如发生的候选集很小，那排序体系的优化空间就很小，效果天然也不会大；而假如候选集很大，那经过排序体系排序后取得终究引荐成果的做法就会下降运营需求的操控力度。

2014年末的时分我开端考虑2015年引荐体系团队的作业方向。那段时刻我会集看了许多公司引荐相关的材料，其间几年前百度大引荐部分（现在现已闭幕）揭露的一些讲演材料对我启示最大。许多公司讲引荐的材料都注重讲算法，或许数据和特征；而百度的这些材料首要倾向于从体系方向来讲。这启示我回到排序体系的实质来看引荐体系。

查找，广告和引荐体系，实质都是大规模排序体系。它们都遵从“候选发生 –> 排序 –> 后处理”的一般流程（见下图）。

再细心阐明下上面这个流程中的前两步：

1）候选发生（检索）体系：找与用户相关的候选调集。关于佳缘来说，这儿的相关候选调集能够经过（相互）满意择偶条件来取得，也能够经过算法如kNN，AR等来取得。不管用什么办法，终究意图便是把用户与候选调集联系起来。

2）排序体系：排序体系里的排序意图是最大化产品方针。对佳缘来说，产品方针包含了运营方针和用户满意度。

相关于2014年运营需求与用户需求独立优化的“战略”，2015年的优化思路有所调整：

别离出运营需求中与用户需求耦合小的部分，运用规矩操控。这样做的原因首要仍是佳缘的事务逻辑太杂乱，彻底依托算法达到产品方针很困难，所以参加了一些规矩进行宏观操控。一致优化无法别离的运营需求与用户需求。这种一致不只表现在排序体系会一起考虑这两方面的方针，也会以较弱的方式表现在候选发生体系里，究竟从候选发生体系发生的候选集不行能是一切与用户相关的物品（异性）。

那么，为什么把2015年叫做引荐体系的产品年？由于本年引荐体系的方针是优化产品方针！

引荐体系是为产品服务的，而不是直接为用户服务。

上面这句话听起来很简略，但其实许多时分咱们会在不知不觉中以为引荐体系是直接在为用户服务的。咱们在最早的时分便是犯了这个过错。

本节的最终，汇总罗列下我这几年做引荐的感触：

技能为产品服务，而不是直接面向用户数据质量是地基，确保好的质量很不简略怎么拟定正确的优化方针真的很难事务了解 > 工程完成数据 > 体系 > 算法快速试错一些技能测验

这节我仅仅简略罗列下最近几年自己触摸的比较有代表性的一些技能，跟作业关系不大。

Dirichlet Process 和 Dirichlet Process Mixture模型

了解DP首要是由于其时在看Mahout源代码的时分发现有个算法曾经居然没触摸过，觉得挺有意思就细心学了下。DP不太好了解，它被称为散布的散布。从DP抽取出的每个样本（一个函数）都能够被以为是一个离散随机变量的散布函数，这个随机变量以非零概率值在可数无量个离散点上取值。DPM对错参数贝叶斯聚类模型，聚类时能够让模型主动学习类数。尽管听着如同很不错，其实有许多槽点，详细可见参考文献2。

Latent Dirichlet Allocation (LDA)

LDA是文本处理里的利器，经常被用于对文本进行聚类，或许预处理。更详细的理论介绍可见参考文献3。其时我测验把它用于佳缘的发信数据，看看能不能找出一些有显着特征的发信集体。聚类成果全体上根本不行解说，但有一个类别含义很显着，这类人首要给离婚异性发信。咱们能够想想这类人是什么人。测验感触是LDA直接用于聚类未必靠谱，可是能够把它用于数据的预处理，比方降维什么的。

Alternating Direction Method of Multipliers (ADMM)

ADMM是个优化算法结构，它把一个大问题分红可散布式一起求解的多个小问题。理论上，ADMM的结构能够处理大部分实践中的大标准问题。槽点许多，慎重运用！更详细的介绍可见参考文献4。

Deep Learning

前段时刻，我运用佳缘的用户头像数据，测验了DL里的一些常用算法。为了看算法的效果，我把用户的性别作为猜测方针。这种猜测关于佳缘的事务直接含义不大，由于用户在注册时就被要求填写其性别。

算法猜测的效果仍是不错的，准确度达到了87%。这仍是在很小练习集上练习后取得的精度。DL费事是练习时需求调整的超参数真实是太多了，改一次超参数就要重跑一次，真的是很耗时。没有好的核算资源的话，主张别考虑DL。

运用GBDT模型结构新特征

真实想不出更多的有用特征？测验下Facebook提出的运用GBDT来结构新特征的办法吧。咱们的运用经历标明的确仍是挺靠谱的，只需你功率能扛得住。详细介绍可见参考文献5。

特征哈希（Feature Hashing）

许多个性化特征？特征数量太多？试试特征哈希的办法吧。此办法咱们现在也没运用过，欢迎有经历的人发表意见。详细介绍可见参考文献5。

不平衡数据的抽样办法

正负样本数量差异太大？练习样本太多机器跑不动？测验下参考文献7中的抽样办法吧。咱们之前的测验标明仍是有点效果的。不过假如你的数据不是大得跑不动，那测验的必要性就不太大了

本文转自BreezeDeus