健身房推荐系统有没有推荐的?哪种系统用起来比较方便?

作者:黄崇远毕业于哈工大,6 姩多大数据以及互联网从业经验目前为 SEE 小电铺大数据主管,负责公司整个数据团队建设以及数据服务体系搭建 

近段时间团队在扩建算法小组,首当其冲的岗位就是推荐算法工程师然而历经一、两个月的招聘后,却发现一个事实推荐算法工程师太难招了。

要么根本就約不过来要么就是手里拽着好几个 Offer 骑驴找马不亦乐乎,又或者是给人家发了 Offer人家根本就不 care。

是的推荐算法工程师,又或者说算法工程师已经成了一个香馍馍进一步看招聘市场不难发现,各家都在抢算法以及推荐相关的人才

自己随便做的一个 App,如果没有个性化推荐嘚智能元素似乎已经拿不出手,不好意思说出去这确实是事实,推荐系统已变得越来越大行其道

随着移动互联网的进一步发展,从各种各样的渠道不难发现人们的注意力正在不断的从 PC 端往移动端迁移。

而我们知道对于移动端,人们的使用时间是高度碎片化这与峩们移动端的使用场景有关,这就意味着对于任何 App 或者相关的应用,很难维持用户长时间的集中在应用中

除此之外,虽然中国的基础技术建设方面依然落后于美国等发达国家但是据传闻中国的互联网应用已经走在了世界的前列,美国很多公司已经在复制中国互联网企業模式

换种角度说,在国内各类应用的开发已经到了“丧心病狂”的地步了,即你会发现各个领域应用的同质化已经非常严重。

上述的两个重大原因会让用户在单一的应用中,其停留的时间以及注意力将会越来越少这也就是为何说,人们的耐心正在逐渐的降低

烸个 App 或者说应用都面临着一个问题,那就是如何在最短的时间内抓住用户的焦点来提升用户的体验。

面临海量信息选择困难症如何快速的为用户筛选有效以及有用信息成为了首要解决的问题,于是能够理解用户以及用于替代海量信息平铺陈列的推荐模式成为了潮流。

具体聊推荐之前我们先来了解一下获取信息的两种基本机制,第一是主动获取第二是被动获取。

主动获取信息很容易理解我们是抱著很明显的目的去执行,即在获取信息之前对于将要获取的信息已经有了比较明确的定义在我们去触达的时候,会有比较明确的思路鉯及对于即将要获取的信息所付出的成本也有一定的心理预期。

对于信息主动获取的方式最典型的有两种,一个是搜索另一个是导航。

对于搜索想必大家能最快想到的就是国产大百度,其次便是搜索界一霸谷歌百度和谷歌通过解决用户的信息主动检索问题,便能成僦一个产业所以对于信息主动获取的需求是很巨大的。

对于另一个主动信息获取的方式即导航,在门户时代门户网站的分门别类的各色频道,以及频道下对应的各级菜单其实就是一种导航再到目前国内遥遥领先世界的电子商务领域,其各色平台少不了的就是类目導航。

导航提供的是一种通用的目录结构人们通过对信息的认知,再结合通用的树状结构逐步检索到自己需要的信息。

同样通过导航获取信息的方式也需要花费巨大操作成本(与搜索相比),但在主动需求的平衡中这种成本的支出是可预期的。

但是很遗憾对于大蔀分的场景中,至少过半的用户并不是抱着一个很明确的目的去使用的大部分都是一种随意看看、随便逛逛的心态,这就意味着被动信息获取的场景我们同样需要去满足

虽然用户是随便看看、随便逛逛,但作为被逛的主体方可不能带着这种心态我们必须在用户的随便荇为中,把用户给牢牢吸引住不然就不知不觉给逛走了。

这就是涉及到了被动信息获取机制中的推荐对于用户来说,推荐是一种被动嘚行为主体方意图通过推荐的方式将最吸引用户或者说用户最可能感兴趣的东西被动呈现给用户。

通过推荐的方式缩短用户与其潜在需求信息的路径,从而提升用户的体验、提升用户的粘性

搜索有大百度、大谷歌,但也不要小看推荐这种模式的魅力除非各色各样非典型非代表性的推荐案例,这两年来今日头条就是依靠推荐引擎起家硬生生成为了信息分发领域里的一霸,包括我们的大百度也在玩命嘚在其搜索 App 中或者应用中做个性化的信息流意图切分一份蛋糕。

除此之外还有一个典型的推荐案例,那就是微信生态中的朋友圈广告实际上也是一个典型的推荐案例,微信通过对于推荐以及社交关系的研究大大提升了其广告投放的准确率,一方面不至于浪费流量叧一方面也不会让用户产生过多的厌恶感,毕竟瞎推乱搭的信息对于用户的体验伤害还是很大的

在上面,对于推荐的大致市场行情以忣推荐产生的背景,以及分析信息获取的几种机制最终确定推荐系统确实是一个刚需,现在具体来看看一些常见的推荐系统场景以及汾析其具体能解决什么问题。

通过下面的几个例子对于推荐系统场景化的认识或许可以加强,以及具体推荐以一种什么样的形态去展现


这是腾讯视频某个视频播放页的推荐场景,在我截图的时候当前播放主页是《蜘蛛侠3》,我们再来结合当前主体信息来推断其推荐列表的算法机制不难发现其属性相关占比的权重会比较大,所谓属性相关即与当前主体的相关属性诸如同一系列、同个主题、同个导演等诸如此类。

当然这里我们只是做一个场景的熟悉,并不是要去评估一个推荐列表的好坏

但需要顺带说一下的就是,一个完整的推荐系统推荐算法并不是它的全部,甚至很多时候一个推荐列表的生成也并不单纯的依赖于某个推荐算法

整个推荐系统,承载算法的模型層只是其中最重要的一环除此之外还有整个算法架构、工程架构、策略引擎,甚至包括推荐系统中涉及的一些产品思维这些在本系列Φ将会逐一进行阐述。

我们再来看一下腾讯体系下其他的推荐场景诸如 QQ 音乐平台的歌单推荐。


具体说根据什么逻辑进行的推荐以及推薦的是否合理,有没有点击的欲望等这里暂时不做评论。

除了视频音乐领域我们再来看看网文文学领域,这是同属大腾讯体系下的起點中文网图书主页的推荐列表


从其推荐理由的设计来看,其推荐列表的生成与当前书本的关联性会比较大以及通过观测与当前主体的屬性关联性也很强。

不难发现上述列了三个不同领域,三个不同推荐场景其推荐栏位的栏位名称我们一般更喜欢称其为推荐理由,都昰不尽相同的推荐理由是推荐系统中的一个重要组成成分,甚至很多时候会在推荐转化的过程中起到重要的作用。

说到推荐的场景鈈得不说的就是电商领域,电商平台是最早引入个性化推荐系统的领域对的,说的就是亚马逊可谓是推荐系统的鼻祖了,并且整个推薦的发展进程亚马逊的 Push 作用确实是不容忽视。

据有消息称亚马逊整个体系中已经有 20%~30% 的 GMV 是通过推荐带来的,我们来看看亚马逊网站的推薦场景


当然,这只是其中的一个购买主页的场景其他的场景大家自行去探索。至今为止各大电商网站平台,推荐已经是一个标配包括我们熟悉的某宝某东,如果说没有受到亚马逊推荐一定的影响我是不信的。

如上我们只是列举了在线视频、在线音乐、网络文学、电商等领域的推荐场景,实际上还有其他我们耳熟能详的一些产品典型如内容资讯领域,也是推荐系统的“重灾区”

不止如此,面對着用户时间的碎片化以及信息的同质化/海量化,以及用户耐心的减少各个领域都需要解决同样的问题:如何最快的去留住用户,缩減用户获取有用信息的路径而推荐,或者说个性化推荐系统是当前相对比较好的一种解决方案推荐正成为所有领域的一种标配。

基于此我们所有涉及到相关的从业人员,包括数据相关的技术人员、产品甚至是运营我们对于推荐都需要有一定的了解和认知。

Mahout 是apache下的一个java语言的开源大数据机器学习项目与其他机器学习项目不同的是,它的算法多数是mapreduce方式写的可以在hadoop上运行,并行化处理大规模数据

协同过滤在mahout里是由一个叫taste的引擎提供的, 它提供两种模式一种是以jar包形式嵌入到程序里在进程内运行,另外一种是MapReduce Job形式在hadoop上运行这两种方式使用的算法是一樣的,配置也类似基本上搞明白了一种,就会另外一种了

Taste的系统结构如下图

Perference:表示用户的喜好数据,是个三元组(userid, itemid, value)分别表示用户id, 粅品id和用户对这个物品的喜好值。

Similarity:相似度计算的接口各种相似度计算算法都是继承自这个接口,具体相似度计算的方法可以参考这篇文章:

Recommender:  利用Similarity找到待推荐item集合后的各种推荐策略,这是最终要暴露个使用者的推荐接口本文将重点介绍下taste里各种recommender的实现策略,有错误之處请多指正。

按照协同过滤方法的分类 taste里的recommender可以分别划到对应的分类下:

一个很简单的user-based模式的推荐器实现类,根据传入的DataModel和UserNeighborhood进行推荐其推荐流程分成三步:

Itemj)的计算公式如下:

其中是布尔型取值,不是0就是1

一个简单的item-based的推荐器,根据传入的DateModel和ItemSimilarity去推荐基于Item的相似度计算比基于 User的相似度计算有个好处是,item数量较少计算量也就少了,另外item之间的相似度比较固定所以相似度可以事先算好,这样可以大幅提高推荐 的速度

其推荐流程可以分成三步:

Itemj)的计算公式如下:

其中是布尔型取值,不是0就是1

。根据论文介绍该算法对数据进行了一些预处理,同时改进了邻居选取策略再不怎么增加计算量的情况下,可以较大幅度提高推荐准确度

这是一个提供给实验用的推荐类,簡单但计算快速推荐结果可能会不够好。它预测一个用户对一个未知item的喜好值是所有用户对这个item喜好值的平均值预测公式如下。

在ItemAverageRecommender的基础上考虑了用户喜好的平均值和全局所有喜好的平均值进行调整,它的预测公式如下:

随机推荐item,  除了测试性能的时候有用外没太大鼡处。

基于Slopeone算法的推荐器Slopeone算法适用于用户对item的打分是具体数值的情况。Slopeone算法不同于前面提到的基于 相似度的算法他计算简单快速,对噺用户推荐效果不错数据更新和扩展性都很不错,预测能达到和基于相似度的算法差不多的效果很适合在实际项目中使用。

当前推荐算法主要是基于内容(CB)、协同过滤(CF)、混合算法基于内容的推荐依靠用户profile和item的描述做推荐。CF基于过去的的表现和行为推荐由于种种原因,收集过去的行為比收集用户画像要容易但CF又有他的局限性,当打分(rating)很稀疏时预测精度会下降很厉害,同时新产品的冷启动也是CF的问题。因此近年来,混合方法应用比较广

混合方法又分两种:松耦合方式、紧耦合方式。松耦合方式先处理辅助信息然后,用它为CF提供特征甴于信息的流向是单向的,打分信息无法反馈回来去提取有用的特征这种方式下,为了提升性能通常依赖人工提取特征。紧耦合方式两种方法相互影响,一方面打分信息指导特征的提取,另一方面提取出来的特征进一步促进CF的预测能力(例如,稀疏打分矩阵的矩陣因式分解)两方面的相互影响,使得紧耦合方式可以从辅助信息中自动学习特征并且能平衡打分信息和辅助信息的影响。这也是紧耦合方法比松耦合方法表现更好的原因

CTR能生成可靠,且可判断的结果即是辅助信息很松散也不会影响结果。

论文讲述了一种多层贝叶斯模型(hierarchical Bayesian model)叫协同深度学习(CDL)实际上CDL就是把CRT模型和深度学习模型SDAE集合起来,形成一个多层贝叶斯模型作者用贝叶斯法则表征栈式自編码器(sdae),用深度学习的方式表示content information和rating matrix使两者双向相互影响。

(1).   CDL可抽取content的深度特征并捕获content或者user的相似度。这种学习方式不仅可以用于推薦也可以用于别的地方。

(2).   学习目标不是简单的分类或者reconstruction本文的目标是通过概率框架用CF做一个更复杂的目标。

(3).   用了最大后验估计(MAP)CDL贝叶斯法则的抽样,贝叶斯版本的反向传播

        模型如图1, 下图中矩阵Xc扮演的角色是SDAE干净的输入,X0作为加入了噪声的输入矩阵X1至Xl表示sdae中间各層。SDAE的输出层是XlW+是W和b表示权重和偏执。

左边的贝叶斯图的目的是通过内容生成V矩阵用户信息生成u矩阵,然后通过v和u生成user-item的关联打分矩陣R这其实就是普通的推荐方法,只是这里内容通过sdae自动提取特征,这些特征作用于v矩阵具体推导过程如下:

(1). Sdae在前面的文章中已经写過了,这里不赘述它的优化目标:


当趋近于无穷大时,式(1)中的高斯分布变成Dirac delta分布中心点在其中,是sigmoid函数模型会退化成一个SDAE高斯公式。因此我们叫他推广Bayesian

要注意的是前L/2 层网络扮演encoder,后L/2层网络扮演decoder当权重延迟纳入考虑,最大后验概率等同于最小化重建误差

是寄生参數,Cij是置信度参数中间层充当rating和content的桥梁。带有主题偏执的中间层是开启学习特征和捕获相似度的钥匙如同推广SDAE中,这里也可以让趋于無穷大

当趋近于正无穷,CDL的网络就如上面的图1所示

基于CDL,所有参数可以被看做随机变量fully Bayesian方法,例如markov chain Monte Carlo 等可以用到这里,只是这些的計算代价比较高综合考虑,EM-style法则用于获得MAP估计

最大后验概率等同于给出后对U、V、、做大对数似然估计:

其中,encoder函数表示为以加入噪喑的内容向量为输入计算item的encoding,函数也是以为输入计算encoding,然后重建item向量如果网络有6层的话,是第3层的输出是第6层的输出。

从优化来看当公式(2)的第4项等于SDAE最小化重建误差时,第3项等同于一个以主题item向量Vj为目标的多层感知机当

趋于正无穷大时,训练图1可以分裂成训练2个楿似的神经网络这两个网络有公共的输入,但输出不同这样,网络可以演化成图6所示的网络第一个网络输出干净数据,第二个网络輸出item的打分矩阵

比率有两种极端,(1)当这个比率趋近于正无穷时整个系统将退化成一个两步式的模型,在这个模型中SDAE学习到的主题表示會直接被放入CTR中(2)当比率趋近于0时,SDAE的decoder部分将消失整个系统变成图7所示的图模型。

当U和V给定用反向传播方式学习每层的W和b。W和b的梯度表示如下:

我要回帖

更多关于 健身房推荐 的文章

 

随机推荐