[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是美团用的比较多的。
老师 你们公司招人吗?
招人,主要是前端、测试以及懂技术的产品,因为我们是一个技术型公司,所以产品也必须非常懂技术。
既然都看到这里了
场主做个小调查
你究竟看懂了多少?
有没有建立起逻辑框架?
没有?
记得要复习啊~
注: 本文图片来源于网络
更多技术干货分享
尽在“养码场”微信公众号
欢迎联系豆豆
进入“养码场”技术交流社群!
与各位技术大咖沟通学习
共同成长!