推荐算法集锦(下)——关联规则推荐与KB算法

原创
开发 项目管理 算法
为了读者较为清晰地认识到推荐算法的全貌和各个算法之间的轻重等级,并且能够把握一些小众的推荐算法来为自己设计的推荐系统起到锦上添花的作用,我将会在这一篇文稿中对一些小众的推荐算法进行梳理,正真做到展示出推荐算法的全貌,也对得起这个系列的名字——推荐算法集锦。

[[331263]]

【51CTO.com原创稿件】

1.导读

上几篇文稿中详细的阐述并分析了几种在设计推荐系统中,经常会考虑的或者是经常会接触到的算法。当然,除了这些主要算法以外,仍然会有一些小众的、流行度不是很高的但是存在一定价值的算法。这些小众的算法虽然运用的场景少,但是它们都是具有各自本身的能力和特性,可以解决一些主要算法的缺陷。因此,为了读者较为清晰地认识到推荐算法的全貌和各个算法之间的轻重等级,并且能够把握一些小众的推荐算法来为自己设计的推荐系统起到锦上添花的作用,我将会在这一篇文稿中对一些小众的推荐算法进行梳理,正真做到展示出推荐算法的全貌,也对得起这个系列的名字——推荐算法集锦。

2.关联规则挖掘推荐算法

2.1 何为关联规则推荐?

首先给读者介绍的第一种相对小众的算法就是关联规则挖掘推荐算法,其实这是一种数据挖掘技术或者方法。关联规则挖掘通常是出现在大规模交易中类似规则或者关系模式的通用技术。这种技术也可以应用到协同过滤算法的推荐系统当中去。关联规则也是数据挖掘中的概念,它是通过分析数据并且找到数据之间的关联,也就是各个数据之间的相关性。

其中的具体含义就是,假设交易S是所有有效产品集合C={c1,c2,c3,......,cN}的子集,用来表示被购买的一组产品集合。那么关联规则X=>Y就表示只要交易S中包含X里面的元素,那么就可以认为Y里面的元素也有可能或者极大可能被S集合包含,也就是X跟包含Y的集合相关联。在这一类算法中最常用的算法就是Apriori算法,关联规则的衡量指标是:支持度(support)和可信度(confidennce)。

2.2 Apriori原理

Apriori原理就是对于某个项集是频繁出现的,那么它的所有子集也是频繁的。例如,如果集合{1,2}是频繁出现的,那么集合{1},{2}也是频繁出现的。有的读者就会疑惑,这不是一个显而易见的道理吗?似乎这个原理在直观上并起不到什么作用或者感觉没什么帮助。但是如果反过来看呢?似乎意义就大了,也就是说如果一个项集是非频繁项集,那么它们的所有超集也就是非频繁项集。因为这个命题其实就是原命题的逆否命题,原命题成立,那么逆否命题也同样成立。例如,计算出集合{5,6}的支持度以后,如果知道这个集合是非频繁项集的,那么就不需要计算包含这个集合元素的其他集合了,如{2,5,6},{5,6,7}等集合的支持度已经不需要计算了,因为我们已经知道这些集合不会满足我们的要求了。使用这个原理就可以避免项集数目的指数增长,从而在合理的时间内计算出频繁项集,为推荐节省了更多的处理时间。

2.3参数详解

将关联规则应用到推荐系统中遇到的主要问题而是将评分转换成交易,通常情况下是把所有正向的评分集合(也就是做过去均值化处理后的评分矩阵)或者用户过一次的购买行为或者记录视为一次交易。

支持度和可信度的公式也很好理解,支持度也就是X和Y同时出现完成的交易量在总的交易量中的占比,而可信度则是X和Y同时出现的交易量在仅只有X出现的交易量总额的占比,如下所示:

最后用户u对物i的预测评分值其实就是物品i和与i相关联的物品j之间的支持度和可信度的乘积之和,公式如下:

2.4 一个有趣的营销案例?

为了更好的理解关联规则挖掘推荐算法,这里讲一个流传广泛的一个经典营销案例。据说是一个开发数据分析产品的团队,为了推销自身的数据分析产品,分析了美国几十家零售店的后台交易数据库里面的数据,并且经过查询发现,其实很多商品之间都有一些特殊的关联性,而其中一种就是每天在固定的时间段里,很多顾客都是一起购买了啤酒和尿布。

这个关联性被挖掘出来,很多超市都将啤酒专区移至儿童尿布专区旁边,使顾客可以更便捷的购买尿布时顺便提上一听啤酒。在线上也可以完成这样的推荐,例如,顾客在网上购买了尿布之后,页面会自动推荐出各种啤酒的页面或者直接将某些热销的啤酒加入到顾客的购物车中。但是效果似乎并没有线下营销那么好。这种关联性都是通过分析数据并整合数据得到的一种规律,然后巧妙地利用这种规律来更好地为顾客服务。至于尿布和啤酒能提升零售额的案例是真是假无从考证,但是这种所谓的经典营销案例一直广为流传。

2.5 一种合理的猜想?

有的读者可能会纳闷,啤酒喝尿布有什么关联呢?直观上似乎这两件商品毫无相同点可言,那么为什么它们都是在一起被顾客购买去呢?至于这个问题,并没有明确的答案。我只能提供一些我见过并且似乎还有点合理的猜想。这个猜想就是一般家庭里需要买尿布,那么这个家庭里很可能是有婴儿需要使用,而这种比较小的婴儿又不太方便带出来以防容易染上风寒,因此需要人在家照顾孩子,而一般能够照顾那么小的婴儿的大多数是妈妈了,那么也只有爸爸出去买尿布了,一个有家室的成年男性多多少少会喜欢喝点啤酒,那么再选取尿布的同时,如果看到旁边有啤酒基本很大概率会被选购。不知道这种猜想,广大读者能不能够理解和接纳。但是这种营销方法就的确切实地考虑到顾客的需求,满足顾客的需要,并且可以让顾客不会忘记买啤酒来提升营业额。其实在生活中有很多不同的东西都是有关联的,例如止咳糖浆和果汁(感冒的人需要补充维生素C增强免疫力)、减肥茶和纸巾(想减肥的大多数会运动出汗)等等。其实只要我们自习思考下,想找到一些物品之间的关联性并不难。有了这些关联性,就可以设计出更加周全的服务方式或者推荐方法了。

3.基于知识的推荐算法(KB)

3.1 何为基于知识的推荐?

协同过滤推荐算法(CF)和基于内容的推荐算法(CB)都是属于传统的推荐算法,而这类传统的推荐算法使用场景都是推荐特性或者口味相似的物品,比如:书籍、电影或者新闻这一类的。但是对于某一些产品进行推荐时,就可能不是特别适合了,比如金融产品、房产、手机、汽车等等。其中主要有两个问题就是:很难再某一个产品上获取到大量用户的评分数值,并且已经获得推荐结果且已经购买过的物品或者信息的用户则不回对这些相对用户来说已经过时的产品再进行一个评价或者反馈了。

而基于知识的推荐技术(Knowledge-based Recommendations,KB)就是专门用来解决这类问题的新的推荐技术。这一推荐技术是高度重视知识来源的,也不会存在之前说过的冷启动问题,它的推荐需求都是被直接引出。但是并不是任何知识源都能够获取到,所以这类推荐方式的缺点就是获取知识比较困难,在获取知识的过程中还需要专业领域工程师整合专业知识,继而形成完成的、规范化的条件表达形式。类似于主动地询问对方用户需求,然后基于回答的需求来推荐给用户所需要的推荐结果。

说到基于知识的推荐技术,其实就是类似于搜索过程,不同的是系统需要静搜索过程中的痕迹或者搜索过程中给定的参数存储到知识库中,然后根据这些输入的痕迹或者参数推荐出相关的产品。

3.2 会话交互过程

上面涉及到了一种方式就是主动询问对方用户需求,这在网页上的专业术语叫做会话。因此基于知识的推荐系统一般采用会话式的交互形式,而其中的交互过程如下所示:

(1)当前用户进入指定网页界面以后,用户会需要进行一个最初的指定,来确定自己的兴趣作为最初的偏好信息,然后基于最初的偏好一次性问完所有与之相关的问题或者是逐步问完所有问题;

(2)系统收集到了用户所有的答复或者说是有关用户需求和偏好的信息后,系统会根据这些偏好信息给给定用户一组匹配产品列表;

(3)当用户在后续体验过程中,依旧可以随时修改自己的需求和偏好信息,系统会随着偏好信息的改变即使调整与之对应的相关产品列表,保障推荐的实时性。

3.3 一个小问题?

在基于知识的推荐系统中,开发人员应该需要注意当用户需要高精度的推荐结果时如何处理?当然,这也不是一件轻而易举的事情,需要专业领域的专家不断迭代更新自己的知识库,并且需要更新形成的条件规则形式。另外,在用户未给出答复,也就无法完全匹配上推荐物品时,该如何处理?这个也是需要开发人员提前想到的,需要提前给定好解决方案,类似之前冷启动问题。需要专业领域人员或者技术人员给出预备的推荐结果来主动提供给用户。

基于知识的推荐系统在一般场景运用中主要依赖的还是物品特征的详细信息,通过分类并整合这些物品特征信息来挑出能够匹配上当前用户需求、偏好的物品集。

3.4 一个类似案例?

这种方式有点类似于顾客在逛淘宝买东西时,一般顾客心里都有个心仪物品的雏形或者印象和要求,而基于知识推荐就是买商品时的筛选条件,里面有顾客想买的物品的品牌、价格等参数信息。通过顾客输入心仪物品的条件后,根据输入的条件匹配出相对应的物品列表展示给顾客。举个例子,现实中我想在网上买一个电脑,在我逛淘宝之前,我已经基本想好了关于购买电脑的一些参数,我已经确定的参数是这些:价格在3000元到6000元以内,CPU是酷睿i5的,屏幕尺寸在15英寸左右的。本来淘宝给我的展示页面商品的具体信息如下表所示:

品牌

ID名称

价格

CPU

类型

内存容量

屏幕尺寸

华为

MateBook D

4099

i5

轻薄本

8GB

14英寸

惠普

光影精灵

5799

i7

轻薄本

8GB

15.6英寸

华硕

VivoBook

2788

i3

家庭版

8GB

15.6英寸

联想

小新

7389

i7

轻薄本

16GB

15.6英寸

联想

GTX1060

1288

i7

台式机

32GB

 24 英寸

戴尔

G3

4999

i5

轻薄本

16GB

15.6英寸

联想

拯救者

6789

i7

普通本

16GB

16英寸

小米

RedmiBook

2339

i5

普通本

16GB

16英寸

当我输入完我的筛选条件后立马就会形成如下的推荐列表:

品牌

ID名称

价格

CPU

类型

内存容量

屏幕尺寸

戴尔

G3

4999

i5

轻薄本

16GB

15.6英寸

华为

MateBook D

4099

i5

轻薄本

8GB

14英寸

淘宝网对于这种根据输入筛选条件来完成推荐过程其实就是基于知识的推荐技术了。

3.5 基于知识推荐的分类

基于知识的推荐范畴比较广,在这主要分为两大类:基于样例的推荐和基于约束的推荐,这两种方法比较相似,都是通过先手机用户需求,然后根据需求找推荐方案,当找不到推荐方案的时候,都是通过自动修复与需求的不一致性,并且作出合理的解释说明。而它们之前的区别就在于该如何计算出推荐方案。基于样例的推荐方法是通过相似度度量标准类从目录中检索物品,而基于约束的推荐方法则是需要利用预先定义好的推荐知识库,也就是用来描述某些用户需求以及与这些用户需求相互关联的物品信息特征属性的知识资源,它是使用约束求解器来解决其中的约束或者通过数据库引擎来执行的查询形式。

4.基于样例的推荐算法

由于基于样例的推荐方法用到的仍旧是相似度度量计算,而在之前也已经讲过有关相似度的计算,如皮尔逊相关系数和改进余弦相似度。并且现在在大部分的企业中,如果用到了基于知识的推荐方式,实质上来讲用的比较多的是基于约束的推荐,而基于样例的推荐基本不怎么用。因此关于这一方面,读者只需要理解这个推荐方式的含义以及如何使用相似度度量相关性即可,下面给出基于样例的推荐技术中物品和需求的相似度常用的计算公式(基于样例的推荐技术主要就是求解用户需求和物品之间的距离):

5.基于约束的推荐技术

5.1 约束参数的含义

基于约束的推荐技术属于基于知识的推荐技术领域一个常用的方式,它的过程类似于之前逛淘宝购买电脑根据筛选条件完成推荐的过程。基于约束的推荐技术可以用一组(V,D,C)三元组来描述。集合中的V则是一组变量集合;而D就是这组变量的作用域,也叫有限域;C是一组约束条件,描述了这组变量能够同时满足的取值所要求的组合条件。因此,在实际场景运用中,基于约束的推荐技术其实就是在(V,D,C)三元组的条件情况下,给定一个需求,然后根据需求给出一个最终的推荐结果。而在(V,D,C)三元组中常见的一些参数如下:

(1) :用户属性,它描述了顾客的潜在需求,也就是将顾客需求的特征属性进行实例化,比如我之前逛淘宝所能接受的最高价格为6000;

(2) :产品属性,是用来描述一个给定的产品的种类特征属性,比如购买电脑时电脑的CPU处理器;

(3) :一致性约束条件,它定义了用户实例对象时所允许的范围,也就是对客户需求可能存在的实例化的约束条件,比如购买电脑必须具备i5CPU处理器时,最低接受价格必须要大于3000;

(4) :过滤条件,也就是过滤不满足需求条件的产品,而定义了在筛选条件下应该选择的几种产品,也就是定义用户属性和产品属性之间的关系,也就是满足内存容量为8G的电脑必须过滤掉屏幕尺寸不是15英寸左右的显示屏的电脑;

(5) :用来定义当前的有效产品分类。

5.2 默认值设置方法

如上面说的逛淘宝输入筛选条件的案例所示,对于一些电脑小白,可能在购买电脑前并不是很清楚自己需要买哪些参数的电脑,心里面也没有想要购买的电脑模型,但是他就是需要买电脑,具体情况他看了推荐结果才知道如何选择。所以像这种电脑小白,可能并不会输入筛选条件,因此就想之前为未输入筛选条件时,淘宝给我推荐一些电脑详细信息列表一样,这就是基于约束的推荐技术一个功能,也就是默认值设置。默认值设置的主要目的就是帮助用户说明需求的一种方式,因为用户不清楚自己需要购买什么参数类型的产品,这就需要推荐系统给予他帮助,可以根据用户给定的比较模糊或者泛化的需求(例如购买电脑),对这种所谓的属性进行解析转换,为用户推荐出更为优质的需求产品列表(综合实力强的电脑)。而给定默认的方式有以下几种:

(1)静态默认设置:也就是给每一个产品属性都设置一个默认值;

(2)条件默认设置:类似于动态默认设置,就是根据用户给定的默认条件(电脑)来设置一个默认值;

(3)派生默认设置:通过利用所有用户之前的交互信息或者日志以及当前用户给定的一些参数来进行分析建模,从而得到每一个属性的默认值。其中最常用的方法就是最近邻和加权多数投票方式。

5.3 另外一种相反情况

上面说的现象是对于给定的筛选条件比较模糊或者空泛的情况下,通过采用设定默认值的方式来进行推荐。但是相反,当用户需求的筛选条件给的过于丰富甚至超过了系统所能匹配的范围,也就是需求给的太多以至于系统中没有任何一个物品是符合给定需求的,这样就会导致一个空推荐结果,这种情况是一直存在的,也是目前所有的推荐系统都不能完全解决的一种问题,能够相对减少这种问题现象的发生的解决方案是:先给定用户需求参数的的优先级别,让用户按优先级别输入筛选条件,然后按照用户输入属性的优先级别删除掉用户原始需求中的筛选条件,并且得到一个新的需求条件列表,重新获得新的推荐结果。

5.4 推荐结果排序问题

根据筛选条件完成相关的推荐结果后,对于推荐的产品列表有一个排序的问题需要在这说明下。因为基于首位效应,用户会把大量的注意力放在推荐产品列表开头的一些产品,因此由用户的关注所形成的推荐结果排序好坏会直接影响到推荐系统的好坏和用户购买的意愿。

对推荐产品列表进行排序的原理基本用的是多属性效用理论,也就是根据每个产品对当前用户的实际效用进行评价。因而每个产品都会根据事先定好的维度来进行评价,比如电脑这一块主要考虑的是CPU处理器和价格,其他一些像化妆品类别主要考虑就是品牌、热销情况等。再结合用户对于各个维度的偏好所占的百分比来计算出最终用户对于产品的偏好程度。产品偏好得分公式如下:

6.基于知识的推荐算法优缺点

基于知识的推荐系统在面临协同过滤推荐或者基于内容的推荐技术有明显缺点时,就显得格外重要并且有用了,并且能够很好地应用到大型的推荐系统中去,但是同样地,任何一个推荐系统都不可能是完美的。基于知识的推荐系统还是存在一些系列的问题的:

(1)像之前提到过的,基于约束的推荐过程中,系统构建约束条件需要比较多的一个领域只会,是十分困难的;

(2)基于样例的推荐技术在计算物品和用户需求之间相似度公式效果不佳时,推荐的结果也非常不好,并且物品结构化特征数量以及构建特征属性和需求之间的相似度计算规则相对而言很难,因此同样需要比较高的知识领域。

尽管基于知识的推荐技术仍然有一些问题,但是这种推荐技术在未来这是一个发展方向,即使在如今的推荐领域中,能够实际应用的情况不多。

7.混合推荐系统设计

聊了这么多推荐算法形成的推荐系统,说白了如果将推荐系统看成一个独立模块,那么完成的一个推荐过程其实就是三块内容,输入——推荐模块——输出。因此我们完全可以将推荐系统看成软件测试当中一个名词“黑盒子”。如下所示:

其中这个黑盒子可以将输入的数据转换成一个有序地物品列表进行输出,而输入的数据主要包含用户记录、上下文信息、产品特征、知识模型等等。但是由于输入的数据参数类型过多,没有任何一个单一的推荐系统能用到这么多的输入数据。所以就引出一种推荐方式,就是将多个推荐系统模型得结果混合在一起完成最终的推荐结果,也就是原来的大黑盒子(总推荐系统模块)里面构成几个小黑盒子(分推荐系统模块)。从而是最终构成的大黑盒子(总推荐系统模块)各取所长,具备里面所有小黑盒子(分推荐系统模块)的功能和优势。这种方式构成的推荐系统叫做混合推荐系统,常用的类型结构如下:

这种混合推荐结构只是从整体上把握,至于每一个推荐模块具体使用什么推荐算法还是需要结构前面的各种推荐算法的优缺点和使用场景来考量,进而选取适合每一种类型数据的最恰当的推荐算法,设计出相应的推荐系统。

8.总结

对于推荐系统算法这块,通过几章文稿已经对这一系列做了一个详尽的阐述。现在读者们应该比较清楚推荐系统领域这块,各个推荐算法的优先级或者说是轻重度了吧。也就是我这几篇文稿中的介绍顺序,首先最为重要的就是协同过滤推荐算法,其次是基于内容的推荐算法,而SVD矩阵因子分解算法算是对协同过滤算法的一个处理,也算是对协同过滤算法的一个补充,然后就是关联规则推荐算法,最后是基于知识的推荐算法,而在基于知识的推荐算法中,基于约束的推荐技术更为重要,也就是说,最不常用的就是基于样例的推荐技术了。希望广大读者通过对于这几篇文稿的阅读,能够从整体上把握住推荐系统以及各种推荐算法,为今后设计推荐系统打下一个坚实的基础。

由于这一系列篇幅较长,其中内容或多或少会有些遗漏,对于这些遗漏掉的或者不完善的内容。我将会对这几篇进行一个梳理,最后通过补充稿的形式将这些遗憾弥补上去,并且在不补充稿中,我会对其中某部分内容进行一个深入或者拔高,来进一步走近推荐算法。希望广大读者也不要停下对推荐系统学习的脚步,因为就像前面所说的那样,没有任何一个推荐系统可以说是完美的,毕竟“人无完人,金无足赤”。这个虽然是一种遗憾,但是也是我们设计推荐系统不断前进发展的动力所在。因为对于任何一个推荐系统开发人员来说,每个人心中都有一个相同的愿景,那就是设计出一个万能的、完美的推荐系统,能够在任何实际运用场景的战役中都能够百战百胜。所以,推荐系统设计仍需很长的路要走。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

 

责任编辑:庞桂玉 来源: 51CTO
相关推荐

2017-03-02 10:49:37

推荐算法原理实现

2020-06-30 07:00:00

推荐算法推荐系统

2020-06-28 07:30:00

推荐算法推荐系统

2020-06-29 07:00:00

推荐算法推荐系统

2016-09-30 15:03:13

推荐系统算法

2021-11-23 10:50:29

关联规则推荐推荐系统开发

2021-04-16 07:32:34

推荐算法机制

2018-05-06 16:26:03

关联规则数据分析关联规则推荐

2017-07-11 09:46:29

2016-11-22 08:50:23

2017-06-29 09:15:36

推荐算法策略

2016-12-09 08:56:54

2024-01-04 17:00:59

2019-04-23 09:00:00

机器学习排序学习人工智能

2018-08-08 13:30:59

推荐系统DeepFM算法

2017-02-08 09:25:16

Spark分解推荐

2023-10-31 16:46:45

2021-08-11 20:17:22

推荐算法系统

2023-04-24 07:37:28

推荐算法项目

2023-07-19 08:55:00

神经网络推荐系统
点赞
收藏

51CTO技术栈公众号