推荐系统（1）--splitting approaches for context-aware recommendation

开篇语：

大一的时候。在实验室老师和师兄的带领下。我開始接触推荐系统。时光匆匆，转眼已是大三，因为大三课甚是少。于是便有了时间将自己所学的东西做下总结。

第一篇博客。献给过去三年里带我飞的老师和师兄们，感谢你们的无私帮助与教导！

协同过滤算法：

在传统的协同过滤算法中，算法是基于如图一的用户评分矩阵对用户进行推荐的。其核心思想大致是利用相似用户或者相似商品的信息对用户进行推荐，拿图一举例。在这里我们要预測小红对《了不起的盖茨比》这部电影的评分是多少（1-5），一个最简单的想法就是从全部用户中找到跟小红的品味相似的人。一眼望过去，小明跟小红的品味最相近（都是小李子的粉丝？都比較喜欢看煽情一点的电影？）。所以我们能够预測小红对《了不起的盖兹比》这部电影的评分应该是比較高的，所以在做电影推荐的时候，我们能够把《了不起的盖茨比》这部电影推荐给小红。这样的利用相似用户的信息进行推荐的算法叫做user-based（基于用户的）协同过滤算法，这样的而相相应的。就有item-based（基于商品的）协同过滤算法，基于商品协同过滤算法思想大致是。那些跟用户喜欢的商品相似的商品，在某种程度上说用户也应该喜欢，放在这里的话。小红喜欢《泰坦尼克号》这部电影，因为《泰坦尼克号》跟《了不起的盖茨比》比較相似，那么小红也理所当然地喜欢《了不起的盖茨比》这部电影。有关协同过滤算法，这篇博客进行了具体的介绍。

（图一）

为了引出下文，这里插个没啥剧情没啥品味的小故事：

A公司利用协同过滤算法，为其下的每一个用户生成个性化的推荐之后，公司的营业额一天比一天高，而随着数据越来越丰富，A公司除了拥实用户对商品的评分这些数据外。还拥有各种上下文信息（如小红是在什么时候看的这场电影，是跟什么人一起看的，看完之后心情怎样等等），老板希望把这些上下文的信息都给利用上。但上面已经讲到。传统的协同过滤算法不过基于用户对商品的评分对用户进行推荐的，那么。有没有什么办法让A公司在不换掉这套算法的前提下。把这些上下文信息给利用上呢？

Splitting：

splitting的分类：
splitting方法分为item-splitting。user-splitting，UI-splitting三种。

splitting的基本思想：
对于某个事物X。假设它随着环境（上下文）的改变。X也发生非常大的变化，则应该觉得X在不同的环境（上下文）中是属于不同的事物，因此我们应该把它们切割开来。当成不同的事物对待。

splitting的做法：
这里以item-splitting来举例说明，item-splitting嘛，翻译成中文就是“项目-切割”。字面意思就是对一个项目（商品）进行切割，将其切割成几份，既然要切割。我们要拿什么来切割？怎么切割？切割成几份？

切割？？？~~~

言归正传，先来看第一个和第二个问题。拿什么来切割，怎么切割？看回前面的小故事，我们会非常自然而然地想到。这时候我们会用到上下文的信息来对item进行切割。在这里，我们看图二和图三中的两个矩阵：
（图二）


（图三）

图三是用户对泰坦尼克号的评分，而图二是用户在看这部电影时的一些上下文信息，item-splitting方法的思想是利用某个上下文条件对项目尝试进行切割，尝试切割成两个向量后，如果这两个向量有显著地不同。则应该把原来这个项目进行切割，如果上面的上下文条件中。“是否跟恋人”这个上下文条件能够让泰坦尼克号这个列向量在切割之后有显著地不同，则应该将其划分为两个向量，如图四：

（图四）


在图四中，根据“是否跟恋人”这个上下文条件对《泰坦尼克号》这个列向量进行切割后，形成了两个不同的向量（跟恋人，不跟恋人），在item-splitting方法中。相应的事实上是两个不同的电影。

在这里，引入一个新的问题，怎样推断一个向量在切割成两个向量之后。这两个向量有显著的不同，即怎样评判泰坦尼克号（跟恋人）和泰坦尼克号（不跟恋人）这两个列向量有显著的不同？

论文[1]中具体地解说了splitting的整个过程。在这里摘取当中一个评判两个向量是否有显著不同的公式：

（图五）


该公式是两个样本的t检验。在p值满足阈值（一般是p<=0.05满足）的情况下，t值越大，这两个向量越不同，当中，Ui是该电影的平均分，Si为该电影的评分方差。ni为该电影有多少个非零值，下标C和非C表示不同的上下文（跟恋人和不跟恋人）。

item-splitting的算法伪代码（摘自论文[1]）如图六所看到的：
（图六）


将图一的矩阵在运行item-splitting后。如果除了《了不起的盖茨比》外，其它两部电影都被splitting了，则将会变成如图七的矩阵：
（图七）

利用上下文信息得到如图七的矩阵后。能够在该矩阵上套用传统的协同过滤算法。

最后看一下上面说到的切割成几份的问题，在上述过程中，对于每一个item，我们都是划分成2份，即是这个上下文的和不是这个上下文的，那么。我们能够将其划分成很多其它份吗？比方对于图二中的天气这一个上下文维度，对每一个项目划分成4份，即晴，下雨，阴天。下雪这四个。能够是能够，但论文[1]有提到这样划分不仅会带来时间成本的添加。也会导致评分矩阵过度稀疏，也会造成过拟合的问题。

splitting方法的优缺点及思考：

首先说下长处，splitting方法能够把有价值的上下文信息融入到传统的协同过滤算法中。从而提升推荐的效果。
再来说下缺点，从上面的伪代码来分析。我们能够知道，在上下文的维度非常高。且每一个维度有非常多值的情况下，整个splitting过程是十分耗时的，并且splitting耗费的这些时间不一定能非常大幅度的提升推荐的效果，注意我上面说splitting的长处的时候， 有特别地说明“有价值的上下文信息”，可是。什么上下文信息是有价值的呢？这又与业务背景有关，有人专门对上下文的选取做过研究。发现并非全部的上下文信息都能提升推荐的效果的。有时候引入不恰当的上下文，反而会减少推荐的效果，因此，对于splitting过程中要用什么上下文才干提升推荐效果。这也须要我们对业务背景有一定的了解。

在这里推荐一个github上的有关上下文推荐系统相当不错的项目：

https://github.com/irecsys/CARSKit

參考学习资料：

[1]L. Baltrunas and F. Ricci. Experimental evaluation of context-dependent collaborative filtering using item splitting.2013.
[2]Yong Zheng,Robin Burke,Bamshad Mobasher.Splitting Approaches for Context-Aware Recommendation: An Empirical Study.2014