介绍
推荐系统并不总是需要用到复杂的机器学习技术.只要手头上有足够的数据,你就可以花很少的功夫开发一个推荐系统.一个最简单的推荐系统可以只是从用户感兴趣的表中查找所需要的推荐信息.当你已经有很多用户和其行为的数据时,使用协同过滤就是一个简单的推荐方案.例如,对于一个运用了协同过滤推荐算法的电子商务网站,你就可以知道哪些购买过睡袋的用户也购买了手电筒,灯笼和驱虫剂.而基于内容的推荐系统则进一步,它具有强大的预测功能,如基于用户的交互就能预测一个用户想要什么.本文将演示如何使用Redis基于用户的兴趣和协同过滤算法开发一个简单的推荐系统.
什么是Redis?
Redis是一个被经常当作数据库,缓存和消息代理来使用的内存型NoSQL数据存储.不像其它的内存型数据存储,它还能够将你的数据保存到磁盘上,同时也提供了大量的数据结构类型(Sets, Sorted Sets, Hashes, Lists, Strings, Bit Arrays, HyperLogLogs, and Geospatial Indexes). Redis命令可以帮助开发者以极低的复杂度在其数据结构上执行高性能操作.也就是说,Redis 的构建是基于性能和简单性的考量而出发的.
Redis的数据结构
Redis数据结构就像乐高的积木,可以帮助开发者实现低复杂度,低网络开销和低延时的具体功能,因为这些操作都是在仅临数据存储的内存中高效执行.多样而灵活的数据结构使得Redis与其它的K/V存储和NoSQL数据库相区分开来.Redis数据结构包括:
什么是推荐引擎?
推荐引擎就是一个最可能为用户做出下一个选择的应用或微服务.推荐内容包括如用户最想听的下一首歌,他们最想看的下一场电影或者他们预定某服务后下一步可能做出的选择行为.
在系统层面,推荐引擎会匹配用户最可能感兴趣的物品.通过推送相关的个性化推荐给用户,应用会引导用户购买相关物品,提升他们在网站或APP上的停留时间或者点击想看的广告-最终帮助对收入,使用率的最大化.
一个有效的推荐引擎需要具备以下条件:
常见的推荐引擎
最常用的推荐引擎有基于用户选择的画像设置,协同过滤和基于内容的推荐.
基于用户选择的画像设置是最易实现的一种,但它是静态的,即它不会考虑用户的行为或尝试理解什么需要被推荐.
当你有许多用户并收集了足够的信息,那么就很适合用协同过虑基于用户的行为去给用户进行分类.协同过滤非常的高效并能取得到非常好的效果.不足之处就是它是重量级的计算.
基于内容的推荐则依赖于机器学习技术并需要理解被推荐用户和物品的属性维度.为它准备正确的数据模型通常是个严格而漫长的过程.然而,一旦有了正确的数据模型,那么基于内容的推荐只需要少量的历史数据或系统用户就可以产生很好的推荐结果.
Redis中适合推荐引擎的数据结构和命令
Redis的数据结构在大规模的高性能应用中可极大的降低应用的复杂度.推荐引擎方案通常需要Set的一些可快速执行的操作诸如 intersection, union和setdifference.我们可以很方便地使用Redis的Strings, Sets和 Sorted Sets等数据结构来实现推荐引擎或一个内存数据库平台.Redis只需极少计算资源就可以达到亚毫秒级的高性能.
在我们开发推荐系统之前,让我们先来熟悉下Redis的一些数据结构和命令:
基于用户兴趣的推荐
这是一个简单的基于用户兴趣的推荐系统.在这个方法中,我们让用户选择他们所感兴趣的类别.我们也会根据他们选择的类别对物品进行分类.然后我们会基于这样的分类将用户的兴趣和物品相关联起来.
算法:
找出用户U所感兴趣的所有类别,我们将这个类别集合叫做userU.然后得到userU所关联的所有物品.
步骤1
设置每个用户所感兴趣的类别.
SADD user:
步骤 2
为每个类别维护一个集合,此集合存放该类别的所有物品。
SADD category:
步骤 3
获取一个用户所感兴趣的所有类别(假设这个集合很小,对于大数据集则使用SSCAN).
SMEMBERS user:
步骤 4
获取属于用户所感兴趣类别的所有物品.
SUNION category:
对于大数据集,最好使用SUNIONSTORE.
示例场景: 一个当地杂货铺的移动应用
杂货铺刚发布了一款新的手机应用以供客户选择他们感兴趣的商品. 应用的背后会追踪每个类别促销的所有商品. 当一个客户走进此店并打开这个应用,那么客户将会收到个性化的目标优惠劵。该例子的数据结构:
categories = {organic, dairy,… }
category:organic:items = {milk, carrots, tomatoes, …}
category:dairy:items = {milk, butter, cheese, …}
user:U1:categories = {organic, dairy}
user:U2:categories = {dairy}
当客户U1打开她的应用,她将会收到关于以下商品的促销信息:
SUNION category:organic:items category:dairy:items
= {milk, carrots, tomatoes, butter, cheese, …}
基于用户-物品关系的协同过滤
在这个方法中,我们将深入了解用户的行为并基于其它用户类似的行为做出相关的推荐.
算法:
步骤 1
维护一个与指定用户相关联的所有物品集合,例如:所有通过电子商务应用所购买的物品.
SADD user:
步骤 2
对每个用户-物品关系,维护一个反向映射即物品-用户关系.
SADD item:
步骤 3
获取同用户相关联的所有物品 (假设这是一个小集合,对于大数据集则使用SSCAN).
SMEMBERS user:
步骤 4
获取属于用户所感兴趣类别的所有用户.
SUNION item:
步骤 5
获取属于用户所感兴趣类别的所有物品.
SUNIONSTORE user:
上面这个计算出来的集合将包含其它用户所具有相同物品关系的所有关联物品.
步骤 6
获取还未与用户相关联但与其它具有类似行为用户相关联的物品列表.
SDIFF user:
示例场景: 本地杂货铺移动应用的推荐信息
本地杂货铺的个性化促销灵感取得了很大的成功,杂货铺决定继续升级,即通过用户的行为来促销物品。杂货铺想告诉顾客,“购买了物品X的顾客也购买了Y”,此例的数据结构如下:
userid:U1:items = {milk, bananas}
userid:U2:items = {milk, carrots, bananas}
userid:U3:items = {milk}
item:milk:users = {U1, U2, U3}
item:bananas:users = {U1, U2}
item:carrots:users = {U2}
那么,什么物品将会被推荐给用户U1?
SMEMBERS user:U1:items
= {milk, banana}
SUNION item:milk:users items:banana:users
= {U1, U2, U3}
SUNIONSTORE user:U1:all_recommended user:U1:items user:U2:items user:U3:items
= {milk, bananas, carrots}
SDIFF user:U1:all_recommended user:U1:items
= {milk, bananas, carrots} - {milk, bananas}
= {carrots}
杂货铺会推荐carrots给U1
基于用户-物品关系及其打分的协同过滤
此方法不仅要计算具有相同物品集合的不同用户的共同行为,还要决定每个用户如何给物品打分。对于一个给定用户U,此技术要找出给同用户U类似的物品打过分的所有用户,然后系统将根据打分情况推荐具有类似行为用户打过分的物品.
算法:
给定一个用户,根据以下条件找出最相似的用户:
找出将要排在最前的物品:
步骤 1 插入打分事件
为每个用户维护一个Sorted Set用于存储该用户打过分的所有物品.
ZADD user:
为每个物品维护一个Sorted Set来追踪所有给该物品打过分的用户.
ZADD item:
步骤 2 获取具有相同物品积分的候选者
这里需要分两步,第一步,获取给相同物品打过分的所有用户. 第二,找出第一步中已经计算过的每个与用户U相似的用户,这个用户就是需要推荐的.
找出
ZRANGE user:
找出给相同物品打过分的用户
ZUNIONSTORE user:
步骤 3 计算每个候选者的相似性
找出
ZRANGE user:
ZINTERSTORE rms:
将两个用户的差开平方根再取绝对值。然后根据这值去实现自己的逻辑来判断谁与给定用户最为接近.
步骤 4 获取候选物品
既然我们有一个与用户U1类似的Sorted用户Set,那么我们可以将与那些用户和他们打过分相关联的物品抽取出来. 我们将会用ZUNIONSTORE 和U1的相似用户来做这个, 但我们需要保证已经排除了用户U1已经打过分的所有物品.
这里又要用到权重,这次使用AGGREGATE选项和ZRANGEBYSCORE命令. 将U1的物品乘以-1,其它的物品乘以1,指定AGGREGATE MIN选项可以得到一个比较容易截取的Sorted Set: 所有U1物品的分数将是负数,而其它用户的物品分数将是正数. 借助ZRANGEBYSCORE, 我们可以获取到分数大于0的所有物品,并返回用户U1未打过分的那些物品.
假设
ZUNIONSTORE recommendations:
示例场景: 本地杂货铺移动应用的推荐信息
杂货连锁店决定在应用内增加另一个特性. 允许顾客给物品打分,分数范围从1到5. 那些购买过类似物品并给物品打过类似分的顾客将更具有相关性,因为商铺现在开始促销的物品不仅仅是基于顾客购买的行为来推荐的,而且还基于他们如何给物品打分来做推荐.
数据结构如下:
userid:U1:items = {(milk, 4), (bananas, 5)}
userid:U2:items = {(milk, 3), (carrots, 4), (bananas, 5)}
userid:U3:items = {(milk, 5)}
item:milk:scores = {(U1, 4), (U2, 3), (U3, 5)}
item:bananas:scores = {(U1, 5), (U2, 5)}
item:carrots:scores = {(U2, 4)}
ZRANGE user:U1:items 0 -1
= {(milk, 4), (bananas, 5)}
ZUNIONSTORE user:U1:same_items 2 item:milk:scores item:bananas:scores
user:U1:same_items = {(U1, 9), (U2, 8), (U3, 5)}
ZINTERSTORE rms:U1:U2 2 user:U1:items user:U2:items WEIGHTS 1 -1
ZINTERSTORE rms:U1:U3 2 user:U1:items user:U3:items WEIGHTS 1 -1
rms:U1:U2 = {(bananas, 0), (milk, 1)};
rms:U1:U3 = {(milk, -1)};
RMS of rms:U1:U2 = 0.7
RMS of rms:U1:U3 = 1
根据以上的计算,我们可以得出结论U2与U1的相似性要高于U3与U1的相似性.然而,对我们的计算,我们会选择开平方根的值<=1的,因此,我们会同时考虑 U2和U3的打分.
ZUNIONSTORE recommendations:U1 3 user:U1:items user:U2:items user:U3:items WEIGHTS -1 1 1 AGGREGATE MIN
recommendations:U1 = {(bananas, -5), (milk, -4), (carrots, 4)}
具有最高分的物品推荐给了U1. 在我们例子中,商铺推荐了carrots给U1.
高级推荐
如果有大量的用户行为数据,那么使用协同过滤是一个很好的技术方案。协调过滤相对比较泛化,不需要深入理解被推荐物品的内容. 这个技术对于许多用户具有相同兴趣的情况下会工作的很好。反观基于内容的推荐却很乏味. 但他们如果结合了预测分析和机器学习技术后会最有效. Redis-ML提供了一个使用树族如随机树的分类技术.
下面的伪代码阐述了我们如何使用Redis-ML模块做推荐. 代码中假设你已经生成了在Apache Spark上的模型并将其导入到了Redis. Apache Spark提供了一些必要的工具用于创建和训练一个机器学习(ML)模块. 当你将Apache Spark的ML模型导入到Redis, Redis-ML会自动将Spark ML模块转成Redis的数据结构并使用得它可以立即工作.
代码的主要思路是:
关于Redis-ML更多的信息,请访问 http://redismodules.com/modules/redis-ml/.
优化生产环境中的实时推荐服务
Set和Sorted Set操作比较耗时耗资源,特别是对大数据集而言. 对于实时推荐,我们所需要的最终产品就是:推荐给每个用户的物品Set或Sorted Set. 作为一个高性能,低延时,内存型的数据存储,Redis通常能完成好推荐所需要的计算量. 然而,我们推荐你应该提前为每个用户准备最终推荐产品,主要是为了(1) 以亚毫秒的延时推送推荐信息且(2) 让方案更资源有效. 所有临时的用于计算的Sets和Sorted Sets可在生成用户的最终推荐集合后被丢弃.
推荐引擎是否要以一个batch job来创建还是当用户更新他们的画像或活动时做为一个正在运行的进程?这其实取决于许多因素, 如用户访问应用频率有多高,他们的行为改变有多频繁, 事务的量有多大以及业务目标等. 例如,如果方案的设计者正在一个退休计划应用(一个不被用户经常使用的应用)中创建推荐 ,那么没有实时的推荐信息并不重要. 反之,如果方案设计者正在给白天的交易员创建推荐,那么推荐需要及时的反应市场最佳情况才是有价值的. 方案设计者必须研究他们的数据,用户的行为,推荐的目标等来选择正确的响应级别.
本文分享自微信公众号 - IT技术精选文摘(ITHK01) ,作者:Bill Tu
原文出处及转载信息见文内详细说明,如有侵权,请联系 [email protected] 删除。
原始发表时间: 2017-08-04
本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。