[NEW学堂]
养码场的线上课程，以技术人员为核心的学习、交流、分享社群，全方位服务技术人和技术创业者。这里聚集了众多BAT/美团/京东/滴滴/360/小米/网易等知名互联网公司技术总监&技术负责人，他们在这里分享经验、招聘人才，与你一起成长。
NEW学堂的第一课，场主邀请到吆喝科技CTO，原美团研发管理团队成员沈国阳，在养码场社群中展开了时长1小时的线上分享，围绕美团推荐技术、召回层/排序层关键技术、A/BTesting关键技术等进行了分享。
这是一次充满诚意的分享，直达技术关键点。
场主特地整理成篇，分享给参加活动但来不及完全消化与遗憾未能参加的小伙伴！干货长文，高能预警~
推荐关键技术介绍
推荐的基本框架
上面这个框图的最顶层显示的是推荐系统对外的服务接口，每个展位有自己特定的接口形式。
接口层会调用A/Btest配置模块，对接入的流量按照UUID、城市等维度进行分流量的配置。A/Btest对于推荐系统是很重要的基础模块，我们对这个模块的要求，是可以有友好的配置界面，灵活根据不同维度进行分流量配置，并且立即生效，无需重启服务。
A/Btest配置模块之下，是推荐候选集的生成，排序和业务处理模块。候选集生成和排序模块，除了针对不同展位有不同逻辑以外，对同一展位的不同策略也有不同的逻辑。A/Btest模块在配置流量策略的时候，可以根据需要单独配置候选集策略和排序策略。
业务规则处理模块，则有统一的处理逻辑，也有每个展位独特的逻辑，而同一展位的不同策略，通常来说在这一层处理逻辑不会有区别。需要注意的是，在目前的形势下，对于体量较大的业务，这个模块需要有揣摩圣意的能力，以避免政治风险，具体可以参考快手、抖音、内涵段子等App最近的消息。
现在我们重新从接口层开始换个方向来看框架。我们在响应请求的同时，会打印一些必要的日志，记录这次请求的一些必要的上下文信息以及用户及item相关的特征信息，以便生成训练数据。这些日志通过Flume传输到HDFS上面。除了推荐系统以外的美团App其他后台服务，也会把各自的日志传递给HDFS，以方便后续进行数据挖掘。
借助Hadoop，Hive，Spark等平台以及当时我们自己实现的一些机器学习/推荐通用算法，对原始日志进行处理，从而得到需要的各种数据及模型：包括用户的Profile信息，用户之间的相似度，item之间的相似度。
召回层若干关键技术点
在推荐系统的候选集生成这一块，我们当时重度使用了传统的user based，item based协同过滤算法。
这里面需要注意的是，引入了时间衰减的因子，从而使新的行为起的作用大于老的行为，从结果来看，这确实对于效果会有提升。
同时，我在美团推荐组的时候，还参与尝试了不同的相似度计算方式，发现基于llr（loglikelihood ratio）的相似度计算比cosine相似度计算的最终效果要好一些。
在美团首页的“猜你喜欢”这个展位上，我们会发现user based算法比item based效果要好很多。原因和user based算法更容易推荐出有一定新颖性的item有关。
当然，这些经验在不同的产品上不一定能够取得同样的效果，需要进行具体的A/Btest实验，由实验数据来给出结论。
“
从当时的经验来看，排序这块对推荐系统的效果提高，比候选集的贡献要大很多。
”
排序层若干关键技术点
模型及建模
我还在美团推荐组的时候，我们的推荐系统的排序模型主要是Additive Groves模型，另外也在探索FTRL这样的在线学习模型。
AG模型是一种决策树类型的模型，属于非线性模型。这种非线性模型的特点，是一定程度上能够自动进行特征组合的工作，不需要人工进行大量这类工作。
当时我们的建模方法和传统的CTR预估建模方法一样，是Pointwise的模型。每一个item对一个用户的每次展示可以作为一个样本，这个item是否
被点击或者是否被下单作为标记。我们会为这些样本抽取一些item特征，用户特征，上下文特征，item与用户的交叉特征。
样本采样及label处理
由于最终目标是提高item的下单转化效果，所以我们选择重点采用用户下单行为作为标记。但是如果只用下单行为，又会导致数据较为稀疏，有很大比例的用户很长时间内是没有下单行为的。所以我们又使用点击行为作为标记。
而对点击行为和下单行为对于我们训练目标的价值是不一样的，对它们需要做不同的处理。我记得我们尝试了2种方式，在参数取得比较合适的情况下，二者的结果效果都很好。一种方式是提高下单样本的采样比例，比如相对点击样本提高30倍。一种方式是提高标记值。比如下单行为的标记值为30，点击行为的标记值为1。
去除position bias
item在展示列表中的位置，对item的点击概率和下单概率是有非常大影响的，排名越靠前的item，越容易被点击和下单，这就是Position Bias的含义。
在抽取特征和训练模型的时候，就需要去除这种Position Bias。当时我们是在两个地方做这种处理：
1）是在计算item的历史CTR（i_CTR_real）的时候，根据某种假设进行去除position bias。一个常见的假设是，把表现CTR（i_CTR）看成是真实CTR(i_CTR_real)和位置效应的乘积，而位置效应用所有item在某个位置p的CTR的平均值进行表示。这种计算方法可以用公式表示。
2）是在产生训练样本的时候，把展示位置作为特征放在样本里面，并且在使用模型的时候，把展示位置特征设置一个统一置的值，比如0。
冷启动策略
互联网用户的很多行为特征都是遵循幂律分布（Power Law）。
下图显示了一个统计指标遵循幂律分布的情况。横坐标表示用户的单月下单数（取log），纵坐标表示对应的用户量占比（取log）。
这个图表明，大量用户一个月只会购买一次，购买次数每增加一次，对应的用户数占比就指数级下降。这种情况表明，行为稀少的用户对于互联网产品来说是主流。因此做好冷启动策略对于推荐产品来说具有极为重要的意义。
具体的冷启动策略，需要针对不同的产品的特点去做具体的设计。总体思路，可以根据能拿到的用户基础特征，对用户进行适当粒度的分类，对每个类别的用户给出其热门item。
以下以当时我在美团的工作举个实际的例子。美团推荐系统的一个重要的冷启动策略，叫做本地人热单，就是指一定区域内的用户，浏览或者购买较多的top items。
以什么粒度去定义这个“一定区域”呢？当时我们的目标是，使这个区域足够细，同时又能够使这个区域内的用户行为统计有一定的统计意义。
我们选择使用的是商圈，平均覆盖范围在十几平方公里。给用户进行推荐时，我们主要根据用户的实时商圈进行推荐该商圈的本地人热单。但是，用户的实时位置并不总是能够获取到，或者用户的实时商圈，可推荐的item数量太少。这时候，我们采用了其他的替代方案。我们在用户地理位置方面进行了大量挖掘工作。例如，用户周末/平时常去商圈，用户的周末/平时常消费商圈，用户的工作地/居住地附近商圈等，用这些商圈信息，我们可以根据具体情况，丰富推荐的item。
不同时间段的用户需求是不一样的，因此每个时间段的本地人热单应该是变化的。然而划分太细的时间段，数据量往往又太稀疏，因此通过把其他时段的数据根据时间相似度加权统计进来，效果又会有进一步的提高。
Deep Learning在推荐技术中的应用
以上讲的都是传统的推荐技术。近年来,随着Deep Learning技术在多个技术领域攻坚拔寨,推荐领域也开始有很多人尝试使用Deep Learning技术来解决问题。
“
需要注意的是,Deep Learning的优势通常需要在数据量足够大的情况下才能体现,对于业务量较少的应用,可以先采用前述传统的推荐技术来解决问题。
”
下面介绍YouTube的《Deep Neural Networks for You Tube Recommendations》论文里,通过 Deep Learning方法做推荐召回的技术方案。
这篇文章把推荐问题看作是在某一个时刻的用户(user)上下文环境下,给用户展示什么样的视频(item),转化(点击、买单等)效果最好。
这个问题用下面的网络结构进行建模：
其输入是用户的视频观看历史的Embedding,以及用户搜索关键字历史的Embedding,以及用户的人口统计学信息、视频上传时间等信息。
这些Embedding的初始化值可以通过类word2vec的方法获得,可以加速迭代效率,同时对效果提高也是有帮助的。这就是所谓的mui-task方法。
word2vec方法的具体原理网上很多,大概的思路就是把一个时间序列输入给神经网络,神经网络预测这个时间序列是否合法(在历史样本中是否出现过)。其正样本就是历史出现过的时间序列,而负样本就是把历史上出现过的时间序列拿过来,改造出一个错误的样本。这就是所谓的半监督方法。其实任何机器学习都需要有监督,只是有的监督可以通过简单的规则造出来,不需要人工标注,所以看上去是似乎是没有监督的。
现在回头来看上面的神经网络的输出层,是个Softmax层,其输入的向量长度和视频(item)的 Embedding向量长度一致,输出是个item个数长度的概率值向量,概率值最大的就是用户在当前时刻最可能点击的item。
而这个Softmax层的输入向量,可以认为是用户当前状态下的兴趣向量,可以用来和视频(item)的 Embedding向量进行相似度计算,从而筛选出相似度较高的视频(item)投放给用户。
到这里也可以看出来,虽然这个神经网络模型看似要直接给用户推荐视频,事实上也只是一个中间模型,模型中的用户Embedding向量才是用来给用户做推荐的基础。
A/B Testing技术
为什么要进行 A/BTest
在公司,团队里面推动做 A/B Testing往往会遇到一些反对意见。常见的有如下两种：
1.在我接触的一些团队leader中,流行着这样一种说法: 好的PM不用做A/BTest,做A/BTest证明PM没有产品 sense。首先，很长时期以来互联网行业的极速膨胀导致了各种职位招聘门槛降低，PM、RD都不例外。 有一些PM会产出各种粗制滥造的产品需求，而RD的技术方案不完善，性能体验不符合要求的情况也很常见。即便那些超级有产品sense的神级PM，也没有人敢说他的产品决策是100%正确的。
咱们的总设计师同志都说，对他的评价，“五五开”就很不错了。所以，再有sense的PM，也应该承认自己的决策会有出错的时候，而A/BTest是有可能帮助我们避免错误的。
2.另外一个反对意见是：
我不需要用A/BTest,我可以用数据的变化趋势来判断。
那么,我们来看看,在没有任何操作的情况下,某产品某个展位某个指标的变化趋势。我在互联网公司工作多年,深知很多产品的指标会走出各种奇怪的走势。
例如上图的红线部分,是 Airbnb公司某个产品功能上线和下线期间的产品指标的走势。从趋势上来看,我们很难看出这个产品功能的上线和下线,对产品指标产生了什么样的影响。
当然,NB的产品经理还是能够想办法“拟合”出他们想看到的数据,在老板那里邀功请赏,而老板可能根本没有时间来和这些产品经理周旋……
当然,也不是说,什么时候都必须 A/BTest。
- 有些产品还在早期,用户量太小,是没法通过 A/BTest得出靠谱结论的;
- 有些产品体验的改进是可以通过线下用户调研得到答案的;
- 有些改变,有决策者的特殊意图在里面(或者某些不可抗力的影响),并不以某个指标的提升作为出发点,那也应该另当别论。
A/BTest的关键技术
在大量运行 A/BTest实验的公司,为了让各个团队,各个模块的A/BTest有序进行,需要设计良好的A/BTest实验架构。下面以有一定代表性的一种简化的场景介绍一个A/BTest框架。
下图所示是一个客户端列表页从前端到后端的极其简化版的流程图。括号中表示进行A/BTest时候,每个层次主要关注的点。
在谷歌的那篇文章《 Overlapping Experiment Infrastructure:More,Better, Faster Experimentation》中,介绍了一个很复杂的A/BTest框架。
以下我们描述一个简化的版本。看这个图的时候,可以想象流量从上往下流动,左侧的流量不分层,它可以同时测试产品展示交互设计,产品功能点,策略算法等层次的参数组合。而右侧的流量会经过不同层次的实验。上方的是展示交互层实验,中间是排序层实验,下方是召回层实验。层与层之间,可以有几种不同的关系。多数实验会使用右侧的多层实验框架,跨层次的实验发生得比较交少。
A/BTest的常见误区
1.在不同的应用市场发布不同版本的app,在不同渠道发布不同版本的页面,并进行数据效果对比。
“
A/BTest强调对照组、实验组2个版本的用户的分布必须是一致的,不同的应用市场、不同的渠道,其用户的分布会有很明显的区别,因此通过这种方式做出来的试验数据,不具有可信性。
”
2.盲目分层,所有的试验都放在不同的分层去做,都用正交试验的方式去做，现在市场上开始出现了一些好用的A/BTest工具（吆喝科技）,可以很方便进行试验分层,于是有很多同学做试验的时候,不假思索就进行分层试验。
“
2个试验正交,需要保证2个试验所改动的变量相互不影响,这样2个试验的数据结果才都是可信的,否则有可能给出错误的数据,作出错误的决策。
”
3.不了解p值,不知道试验数据是否有效。
“
没有进行科学的p值计算,很可能会使用错误的数据,得出错误的结论。
”
p值定义为：在零假设(实验组和对照组效果一样)成立的条件下,获得和观察到的数据一致,或者更加极端(地背离零假设)的情况的概率。p值越小,说明零假设越有问题(实验组和对照组效果有差异),因为观察到太小概率的事件发生了。
目前，吆喝科技的A/BTest服务内置了成熟的p值计算方案。
Q＆A
目前，国内的BAT、美团、今日头条等超级独角兽公司，内部都开发了自己的A/BTesting系统，那对于很多其他中小型公司来说,是否有必要开发自己的 A/BTest系统?
首先，A/Btesting足够重要,但假设投入5个RD花费一年的时间来开发这个服务,后续还至少需要每年投入2个RD去维护，按照RD人均成本30W/年计算，成本很高。目前的话，企业可以直接购买吆喝科技的A/BTest服务，比开发成本低,而且我们的产品和客户服务体验在不断迭代和提升，完全可以帮助用户去做。
老师，对于这一领域，我是小白，想问这些对数学要求高吗？
后端有些部分对数学要求很高，但是也有些部分要求不高的。
老师，数学不好的人如何学习机器学习？
可以加强业务理解，把业务问题转化为机器学习问题。这部分对数学要求不高。
请问推荐系统的排序模型选定是基于什么原理情况啊？
排序模型的选择，其实目前比较流行的是XGBoost以及FFM，主要原因是：
1. 它们的拟合效果很好
2. 使用方便，不需要做很多复杂的特征处理
3. 它们在各个主流公司的使用效果都非常不错
请问实时分析框架哪个好？
实时分析框架还是要看自己的需求吧。Spark Streaming是美团用的比较多的。
老师 你们公司招人吗？
招人，主要是前端、测试以及懂技术的产品，因为我们是一个技术型公司，所以产品也必须非常懂技术。
