如何从零构建实时的个性化推荐系统?

作者介绍

刈刀(程君杰),曾就职于阿里巴巴移动事业部,数据技术专家。主要负责业务数据分析挖掘系统架构和设计,包括大规模数据采集、分析处理、数据挖掘、数据可视化、高性能数据服务等。

 

前言
 

在移动互联网迅速发展的今天,信息量爆发性增长,人们获取信息的途径越来越多,如何从大量的信息中获取我们想要的内容,成为了推荐系统研究的重点。 随着大数据产业的不断壮大,推荐系统在企业也越来越重要,从亚马逊的“猜您喜欢”,到阿里双十一手机淘宝的“千人千面”,无一不彰显着推荐系统至关重要的作用。

 

相比之下, 消息推送作为传递信息的一种重要的手段,能够有效地提高活跃度,被各大App厂商广泛使用,本应有很大的发展。 但是由于终端上应用越来越多,每天各大App推送的信息也越来越庞大,加上信息都是千篇一律,没有新意, 不但不能起到响应的作用, 反而会引起用户强烈的反感,用户收到的推送信息,基本都会忽略, 删除,甚至完全限制推送。

 

随着推荐系统的成熟,将其应用于推送变成了可能, 通过推荐系统寻找用户关注的焦点,精准定位用户兴趣,从而推送用户感兴趣的内容,达到提升推送的效果。

 

个性化推送整体架构
 

 

个性化推送的核心思想,是将推荐系统与推送系统结合,用推荐系统提取用户感兴趣的内容给用户推送,提高用户对推送消息的点击率,提升推送效果。

 

从个性化推送架构图上可以看出,个性化推送系统,核心组件有三层:数据层、计算逻辑层和推送服务层。
 

  • 基础数据层 是个性化推送的基础, 通过数据,将用户与信息相关联,通过特征,将用户与用户相区分,从而达到千人千面的效果。
  • 计算逻辑层 是个性化推送的核心,通过特征匹配等相关的逻辑运算,将用户和信息做关联,筛选更适合的数据,计算逻辑直接影响到个性化推送的准确度。
  • 推送服务层 是个性化推送与用户交互的通道。推送服务,间接地影响到个性化推送的到达率,影响着推送的效果。

 

数据层
 

推荐系统的基本任务是联系用户和内容,解决信息过载的问题。 想要做到用户和内容更大程度的匹配, 就必须去深入了解用户和信息。 在这里,我们将数据分为三个维度, 方便对用于,信息的把握。

 

  • 用户维度数据
  • 信息维度数据
  • 时间维度数据

 

1用户维度数据
 

用户维度数据,是用来描述用户的特征数据。 了解用户,一般从用户标签属性和用户行为属性两个层面入手。

 

  • 用户标签属性是用来描述用户的静态特征属性,如用户的性别,年龄,喜好,出行偏好,住址等。
  • 用户行为数据,简单来说就是用户的行为日志,用户在互联网上的任何行为,都会产生日志, 比如用户浏览了哪个网站,用户搜索了哪个名词,用户点击了哪个广告,用户播放了哪个视频等等,都属于用户行为数据。 用户行为常被分为两类,显性反馈行为和隐性反馈行为。显性反馈行为是指用户明确表示物品喜好的行为, 如常见的评分,点赞等。 隐性反馈行为是指那些不能明确反映用户喜好的行为。常见的有页面浏览的行为。 用户浏览一个页面,不代表用户一定喜欢这个页面展现的物品,很有可能只是因为这个页面在首页,用户更容易点击而已。

 

对收集的用户特征做融合,根据不同的方向,对用户特征库做划分, 方便之后的使用。

 

我们整理了用户常见的一些特征指标,如下:

 

 

所属的行业不同,所关注的用户特征也不同,不同的行业,会对用户在某一方面有更细致的特征描述。

 

从原始的用户行为数据,用户标签数据,以及其它第三方的数据中,提取我们所要关注的特征值,形成特征向量,为后续信息筛选做准备。

 

2信息维度数据
 

信息维度数据,用于描述信息的特征属性。 不同种类的消息内容,用不同的特征指标来标识。

 

上述的三个类似,列举了舞蹈,视频,音乐三个类型内容所关注的特征。 更细、更准确的特征描述,有利于我们更加准确地去匹配内容。

 

3时间维度数据
 

时间维度数据,就是与时间相关的用户特征和信息特征。 如用户当前在中关村, 中关村某店未来三小时有抢购活动等。 在使用这些特征的时候,一定要注意其时效性。

 

计算逻辑层
 

我们准备好了用户和内容之后,接下来要做的就是连接用户和内容。 推荐系统连接用户和内容的方式有三种:

 

 

  • 用户信息匹配:用户喜欢某些特征的内容,如果信息里包含了这些特征,则认为该内容是用户最有可能感兴趣的内容;
  • 信息匹配:利用用户之前喜欢的内容,寻找与这些内容相似的内容,视为用户最有可能感兴趣的内容;
  • 用户匹配:根据用户特征寻找相似的用户,将相似用户所感兴趣的内容视为该用户最有可能感兴趣的内容;

 

用户信息匹配,是直接通过用户特征和信息特征做匹配,筛选出用户感兴趣的内容,这种方式计算方式简单,直接了当,但是覆盖面比较窄,能够完全匹配上的内容占很少一部分,为了扩大召回, 将大部分特征相匹配的信息也筛选出来,视为用户最感兴趣的内容。 信息匹配和用户匹配,则是典型的协同过滤,更多是计算相似度,信息匹配计算内容的相似度,用户匹配则是计算用户的相似度, 于是用户和信息的连接问题转化为了计算相似度的问题。

 

常用的计算相似度的算法有以下几种:

 

  • 殴氏距离或者曼哈顿距离
  • 余弦相似度
  • 皮尔逊相关系数

 

两个n维向量的殴氏距离计算公式如下:

 

 

两个n维向量的曼哈顿距离计算公式如下:

 

 

两个n维向量的余弦系数如下:

 

 

两个n维向量的皮尔逊系数如下:

 

 

这里不再赘述各个公式的由来以及推倒,有兴趣大家可以自行查找相关文章。 一般的,如果数据比较稠密,而且属性值大小都比较重要,则采用殴氏距离或者曼哈顿距离,如果数据稀疏,考虑使用余弦距离,如数据受到分数贬值的影响(及不同的类型采用不同的评分),则使用皮尔逊相关系数。

 

经过特征匹配和若干轮的相似度计算后,我们拿到了一个初步的用户信息匹配结果集, 接下来我们会对结果集做进一步的处理。

 

  • 过滤:主要是根据推送的历史,将之前推送过的信息过滤掉,同时,我们会根据实际情况,将不满足要求,或者质量比较差的信息过滤掉
  • 排名:主要是拟定推送信息的优先级, 一般按照新颖性,多样性和用户反馈等规则来做排序,新颖性保证了尽量给用户推送他们不知道的,长尾的信息,多样性保证用户可以获取更广的内容,而用户反馈则通过收集用户真实的意愿(如通过用户对推送内容的打开,关闭操作反应用户的喜好)实现更优的排序。
  • 信息整理:选择最优内容,形成消息,进行推送

 

这只是简单介绍了一下数据处理和匹配的逻辑,在具体的实现过程中,需要考虑特征权重的问题, 特征权重对特征匹配,结果排序等影响较大。

 

推送服务
 

推送服务,作为个性化消息的出口, 根据客户端的种类,也被分为了Apple和Android两大体系。 Apple系推送服务统一将推送信息送入apns,由apns负责后续推送工作。 Android则通过后台守护进程,和推送服务建立联系后获取推送内容。 目前行业内有很多开放的推送服务,如umeng推送,信鸽推送,个推等,基本上都是对上述功能的封装。 一些开源推送服务,如umeng, 由于背靠阿里,和所有阿里系应用共享推送数据通道(也就是后台的守护进程), 大大提高了消息的到达率。

 

个性化推送,在推送的内容和时机上都是离散的,所以很难做到批量推送,这就对推送服务的设计和性能提出了比较高的要求。 我们推送服务做了如下改进:

 

  • 数据局部聚合:将相同消息内容的推送放在一起, 这样就可以做局部的批量推送,增加服务吞吐
  • 数据分片:将不同消息内容的推送分割为不同的数据片, 不同的数据片可以并行推送, 提高推送效率
  • 守护线程:每台服务实例都保留一个守护线程,用于监控推送过程,确保推送有且仅有一次送达

 

基于用户位置的个性化推送
 

在个性化推送的基础上,借助于LBS,我们完成一个新的推送场景的尝试,这就是基于用户位置的实效性个性化推送推送。 当你步入中关村商圈,那里的新中关购物中心正在搞活动,其中耐克正在打折,从你的用户特征可以看出,你是个运动达人,最近在某电商网站上浏览了多次运动鞋, 这个时候,我们为你推送了耐克打折的这个消息, 这就是一个典型的基于位置的个性化推送场景。

 

通过定位服务获取用户的实时位置数据,通过计算,获取与参照物的位置关系,结合上述的个性化推送,为用户推送该参照物范围内用户感兴趣的内容。 一般的,通过空间索引,来提高计算地理位置关系的性能,空间索引分为两类:

 

  • 网状索引, 如geohash等
  • 树状索引, 如R树,四差树等

 

可以根据时间的场景来选择不同的空间索引。


时间: 2024-10-29 05:48:03

如何从零构建实时的个性化推荐系统?的相关文章

如何从零构建实时的个性化推荐系统?

这些知名公司使用推荐提供情境化的.有相关性的用户体验,以提高转化率和用户满意度.这些建议原来一般由每天晚上.每周或每月生成新推荐的批处理作业计算提供. 然而对于某些类型的推荐,响应时间有必要比批量处理作业所需的时间更短,比如为消费者提供基于地理位置的推荐.比如电影推荐系统,若用户先前看过动 作片,但现在要找一部喜剧片,批量推荐很可能会给出更多动作片,而不是最相关的喜剧片.本文将会介绍如何使用Kiji框架,它是一个用来构建大数据应用和 实时推荐系统的开源框架. Kiji,以实体为中心数据和360度

如何用Kiji构建实时和个性化的推荐系统

现在网上到处都有推荐.亚马逊等主流电子商务网站根据它们的页面属性以各种形式向用户推荐产品.Mint.com之类的财务规划网站为用户提供很多建议,比如向用户推荐他们可能想要办理的信用卡,可以提供更好利率的银行.谷歌根据用户搜索历史记录的信息优化搜索结果,找到相关性更高的结果. 这些知名公司使用推荐提供情境化的.有相关性的用户体验,以提高转化率和用户满意度.这些建议原来一般由每天晚上.每周或每月生成新推荐的批处理作业计算提供. 然而对于某些类型的推荐,响应时间有必要比批量处理作业所需的时间更短,比如

下一代个性化推荐系统

下一代个性化推荐系统 文/王守崑 本文结合技术及社会需求发展的大背景,讲述了当前推荐系统的价值及所面临的挑战,并指出了下一代个性化推荐系统的设计思路及需要注意的问题. 作为个性化推荐系统核心的协同过滤(Collabora-tive Filtering)算法,是Goldberg等人在1992年的一篇学术论文中最早提出的.他们在这篇文章中提出一种方法,在一个新闻组中,根据 用户下载的新闻计算他们之间在口味上的相似程度,并利用这种相似程度为他们进一步推荐相关的新闻.这也是最早期的个性化推荐系统的雏形.

个性化推荐系统的六个问题

大数据的声音,从没如此聒噪的充斥着我们周遭,而基于大数据的个性化推荐亦如是的包围着我们.以下是个性化推荐系统的一丝陋见,不破不立,止增笑耳: 1.好体验与烂体验只有一线之隔: 完全陌生的人为你推荐.筛选的资讯体验如何?微博的广场让少数人毫无兴趣,让多数人忘记它的存在:然而,传统编辑筛选新闻的模式,早已让用户接受.如此被事实做证明的模式,不可谓体验不好.由此可见,完全陌生的推荐.筛选机制,好体验与差体验只有一线之隔.如何选择KPI去评估其效果,必然与之前方法有所不同,值得PM去仔细思考. 2.是否

Netflix每年靠它节省10亿美元,这套个性化推荐系统是怎么回事?

2009年由Netflix发起的Netflix Prize百万美金竞赛,绝对是推荐系统领域最标致性的事件,这次比赛不但吸引了众多专业人士开始投身于推荐系统领域的研究工作,也让这项技术从学术圈真正地进入到了商业界,引发了热烈的讨论并逐渐深入到了商业的核心腹地. 当然,最受益的肯定还是Netflix公司自己,不仅大有取代Amazon成为新一代推荐引擎之王的架势,而且从商业回报本身上看也无疑取得了非常巨大的回报. 7年过去了,Netflix推荐系统的现状如何呢?ResysChina将带来最新的深度解读

如何基于Spark Streaming构建实时计算平台

1.前言 随着互联网技术的迅速发展,用户对于数据处理的时效性.准确性与稳定性要求越来越高,如何构建一个稳定易用并提供齐备的监控与预警功能的实时计算平台也成了很多公司一个很大的挑战. 自2015年携程实时计算平台搭建以来,经过两年多不断的技术演进,目前实时集群规模已达上百台,平台涵盖各个SBU与公共部门数百个实时应用,全年JStorm集群稳定性达到100%.目前实时平台主要基于JStorm与Spark Streaming构建而成,相信关注携程实时平台的朋友在去年已经看到一篇关于携程实时平台的分享:

用户研究:互联网产品的个性化推荐系统

文章描述:个性化推荐系统的研究进展. 上个月写过一篇产品推荐的文章,详情请见<我所了解的产品推荐>,内容很泛,多为工作心得.本周读了几篇相关的论文,收获颇多,分享点干货.以下内容摘自<个性化推荐系统的研究进展>,该文发表于2009年1月的<自然科学进展>专题评述,作者是刘建国.周涛.汪秉宏.我略去了具体的算法和许多公式,重点看原理.思路和比较.互联网技术的迅速发展使得大量的信息同时呈现在我们面前,传统的搜索算法只能呈现给所有的用户一样的排序结果,无法针对不同用户的兴趣爱

探析数字音乐个性化推荐系统

互联网已逐渐成为数字多媒体资产(数字音乐,数字电影--)的存储和分发中心.虽然互联网的结构能使用户方便的获得内容,但这些内容资源需要有强有力的管理.检索和呈现工具的支持,数字音乐内容当然也不例外.基于用户音乐口味的个性化音乐内容推荐是当前最热门的应用方法.而同时音乐作为与朋友交流关于个性.历史.文化等重要的媒介,所以很多音乐服务中往往会融入SNS的应用. 用户特征描述 音乐内容本身有一定的文字信息(专辑的简介.音乐人的生平--等),但这些信息很难直接与音乐文件相关联.一般的音乐社区会要求用户建立

基于Google Reader发展起来的个性化推荐系统之三大问题

郑昀@玩聚SR 20091003     中科院的xlvector(即项亮,他所在的团队The Ensemble在7月份获得Netflix大奖赛公开测试排名第一,但在9月22日Netflix宣布BPC获胜,原因据说只是因为项亮他们提交结果晚了20分钟)最近发布了一个小工具GRSuggest,有点像之前Kuber在FeedzShare所做过的"个性化阅读",都属于"基于某个Google Reader用户的Shared Items中的文章,为该用户推荐他可能感兴趣的其他文章&qu