首先，我们先顺着作者的思路去看佳缘经历的推荐算法：
在2011年到2013年的算法年，佳缘尝试了两个算法方向，与我的想法非常背离，第一个不是最基本的Content-based，而是Item-based，相信Item-based算法大家都再了解不过，所以就不多做解释。我们只来分析算法的业务应用。Item-based是在构建一个User-Item矩阵，然后计算Item-Item之间的相似度。那么具体到婚恋网站的业务场景，其实也就是构建了一个Man-Woman的矩阵，将Woman当做Item，计算Woman之间的相似度，这个算法场景基于背后的假设是认为，如果一个男人喜欢一个女人，那么他必然喜欢和这个女人相似的女人，换句更直白的话说，每个男人都喜欢自己女朋友的闺蜜。相似，我们将User-Item矩阵做转置后，可以继续做Man的相似度，不再复述。
那么这个算法解决的出发点很好，但是实话实说，其实paper一共就那么多，我总结着看了下，并没有真正有用的东西，也没有创造性的模型产生，只是对于传统推荐算法的一个后过滤，整体思路就是把曾经的无向图变成了有向图，分别求出Man-->Women，Woman->Man的双向关系，然后或者相乘，或者搞一些奇怪的公式去做拟合。作者说不太靠谱，但是我认为这个算法从思路上来说是对路的，无论是不是用他们那些莫名其妙的模型，但是作为思想的参考还是值得借鉴的。
接下来佳缘推荐算法的阶段步入了2014的工程年，作者根据佳缘的团队及业务特点将佳缘推荐做了战略上的调整，从比拼算法模型改成了比拼特征工程。我不了解佳缘的实际情况，不敢多做评价，只是从个人感觉来说也许作者从一个极端走到了另一个极端。从外界来猜测一下佳缘的实现思路：抽出各种各样的特征，例如用户的基本人口学信息，加上用户的行为属性信息等等，然后针对每个用户训练一个分类器，来预测他是不是对对方感兴趣。
那我们来聊聊逻辑回归的根本问题吧：
我相信接下来我说的很多尝试和做法，佳缘都已经尝试过了，但是站在局外者的角度，我认为除了传统的特征工程以及算法模型的优化外，其实接下来的这些才是婚恋网站推荐算法成功的关键(结合佳缘的模式:收取用户的看信费用，其实我没用过)：
说归说，我很佩服作者几年来一直坚持着做着同一个产品的推荐算法，也希望大家可以多多讨论。
在<商品推荐算法&推荐解释>一文中，@飞林沙表示，我们做推荐算法的时候要考虑：
但是从工程角度上，并不适合上来就搭建这么复杂的模型，所以我们可以适当做简化，例如：
@飞林沙认为，数据挖掘或推荐系统只要达到目的就足够了，用什么模型其实真的没有那么重要，优化了好久的模型还真的不如加两条规则，或者人工清洗一下数据好用。模型真正的价值是泛化，但是对于工业界来说，泛化能力不需要太强，只要限定在当前的产品线就够了，如果产品形态改变可以再来一个算法。
@breezedeus在原文中提出了自己的感想：
技术为产品服务，而不是直接面向用户数据质量是地基，保证好的质量很不容易如何制定正确的优化指标真的很难业务理解>工程实现数据>系统>算法快速试错
很多刚工作的同学，最喜欢干的事就是套算法，认为懂了算法就什么都会了。真实产品基本都是数据>特征>算法。算法真不是那么重要！
2011年8月我加入世纪佳缘，开始时主要负责佳缘的交友推荐系统优化，后来我这个团队也负责其他的机器学习事情，比如佳缘的网警系统（抓恶意用户）。刚来时团队加上我只有3个人，做的事基本集中在推荐系统，以及对业务部门新产品的接口支持。当时我自己并没有推荐系统应用于工业界的实际经验，所以很想当然地就从自己了解的推荐算法开始工作了。
Item-basedkNN算法的尝试最开始是基于最大化佳缘用户发信量的业务理解，但后来我们发现这个理解跟业务部门的需求偏差很大。比如给男性展示美女，男性的发信就会暴涨，但这样就会导致少量的女性收到大部分信，而大部分女性则没信可收。这是业务部门不愿意看到的。虽然我们尝试在item-basedkNN基础上做调整来平衡其他的业务指标（如收信人数，看信人数等），但效果不理想。
第二个尝试是学术界的可逆（Reciprocal）推荐算法1，即在考虑用户体验的同时也兼顾item（对佳缘来说也是人）的体验。这个尝试基本是失败的，学术界发明的那些算法基本都有各种前提假设，真用起来都不太靠谱。
虽然到2013年我们团队人数上升到了六七人，但基本在推荐算法上做事的人还是只有两个左右。
从2013年底开始我逐渐意识自己对算法的理解过于学术而无法满足业务部门的实际需求。所以从2013年底我开始从业务出发重新梳理推荐算法团队的工作方向。相对于给用户推荐物品的场景，佳缘的在线交友推荐有以下几个特点：
转化链很长，反馈延迟
佳缘业务的高复杂性，加上团队在使用算法上经验不够，让我决定把接下来的算法优化方向放在特征工程上，而算法就限制在最简单的逻辑回归（LogisticRegression）。团队在处理特征的过程中可以积累对数据的处理经验，以及对业务的理解。逻辑回归足够简单，解释性好，也有很好的开源实现。从它开始也可以让团队在算法使用上积累心得。这是“战术”上的第一个选择。我们把上图中每一步转化作为单独的问题分别进行优化，这样逻辑回归就适用于每一步。这是“战术”上的第二个选择。
上面说的“战术”，其实针对的只是推荐系统里的排序系统。当时我对推荐系统整体的想法是把运营需求和用户需求分开，然后分别对他们进行独立优化。具体说就是第一步以满足运营需求为目标获得候选集，而第二步是根据用户（双方）的喜好对候选集进行排序，系统流程图见下图。这样，在优化用户需求时就不需要考虑佳缘复杂的业务逻辑，可以极大地简化问题。同样，我们也可以比较独立地优化满足运营需求的候选系统。这可以认为是推荐系统的“战略”方向。
佳缘推荐系统流程图（2014）
2014年无疑是工程年。
2014年工程年的效果还是不错的，多个转化模型的分别构建和组合使用，使得业务上的各个指标都有所提升，很多指标的提升幅度都超过了50%。
例如，按照上面的流程图，第一步的候选系统通过考虑运营需求来产生候选集，然后候选集由考虑用户需求的排序系统进行排序。如果产生的候选集很小，那排序系统的优化空间就很小，作用自然也不会大；而如果候选集很大，那通过排序系统排序后获得最终推荐结果的做法就会降低运营需求的控制力度。
推荐系统通用流程图
再仔细说明下上面这个流程中的前两步：
相对于2014年运营需求与用户需求独立优化的“战略”，2015年的优化思路有所调整：
那么，为什么把2015年叫做推荐系统的产品年？因为今年推荐系统的目标是优化产品目标！
推荐系统是为产品服务的，而不是直接为用户服务。
上面这句话听起来很简单，但其实很多时候我们会在不知不觉中认为推荐系统是直接在为用户服务的。我们在最早的时候就是犯了这个错误。
本节的最后，汇总罗列下我这几年做推荐的感想：
这节我只是简单罗列下最近几年自己接触的比较有代表性的一些技术，跟工作关系不大。
了解DP主要是因为当时在看Mahout源代码的时候发现有个算法以前竟然没接触过，觉得挺有意思就仔细学了下。DP不太好理解，它被称为分布的分布。从DP抽取出的每个样本（一个函数）都可以被认为是一个离散随机变量的分布函数，这个随机变量以非零概率值在可数无穷个离散点上取值。DPM是非参数贝叶斯聚类模型，聚类时可以让模型自动学习类数。虽然听着好像很不错，其实有很多槽点，具体可见参考文献2（参阅参考文献请点击原文链接）。
LDA是文本处理里的利器，经常被用于对文本进行聚类，或者预处理。更详细的理论介绍可见参考文献3。当时我尝试把它用于佳缘的发信数据，看看能不能找出一些有明显特征的发信群体。聚类结果整体上基本不可解释，但有一个类别意义很明显，这类人主要给离婚异性发信。大家可以想想这类人是什么人。尝试感想是LDA直接用于聚类未必靠谱，但是可以把它用于数据的预处理，比如降维什么的。
ADMM是个优化算法框架，它把一个大问题分成可分布式同时求解的多个小问题。理论上，ADMM的框架可以解决大部分实际中的大尺度问题。槽点很多，谨慎使用！更详细的介绍可见参考文献4。
算法预测的效果还是不错的，准确度达到了87%。这还是在很小训练集上训练后获得的精度。DL麻烦是训练时需要调整的超参数实在是太多了，改一次超参数就要重跑一次，真的是很耗时。没有好的计算资源的话，建议别考虑DL。
实在想不出更多的有用特征？尝试下Facebook提出的利用GBDT来构造新特征的方法吧。我们的使用经验表明确实还是挺靠谱的，只要你效率能扛得住。具体介绍可见参考文献5。
很多个性化特征？特征数量太多？试试特征哈希的方法吧。此方法我们目前也没使用过，欢迎有经验的人发表意见。具体介绍可见参考文献5。
正负样本数量差异太大？训练样本太多机器跑不动？尝试下参考文献7中的抽样方法吧。我们之前的尝试表明还是有点作用的。不过如果你的数据不是大得跑不动，那尝试的必要性就不太大了。