推荐算法-基础

Posted 2021-04-29 北邮郭大宝

1：基于人口统计学的推荐

基于人口统计学的推荐机制（Demographic-based Recommendation）是一种最易于实现的推荐方法，它只是简单的根据系统用户的基本信息发现用户的相关程度，然后将相似用户喜爱的其他物品推荐给当前用户，如下图这种推荐的工作原理：

从图中可以很清楚的看到，首先，系统对每个用户都有一个用户 Profile 的建模，其中包括用户的基本信息，例如用户的年龄，性别等等；然后，系统会根据用户的 Profile 计算用户的相似度，可以看到用户 A 的 Profile 和用户 C 一样，那么系统会认为用户 A 和 C 是相似用户，在推荐引擎中，可以称他们是“邻居”；最后，基于“邻居”用户群的喜好推荐给当前用户一些物品，图中将用户 A 喜欢的物品 A 推荐给用户 C。

这种基于人口统计学的推荐机制的好处在于：

1. 因为不使用当前用户对物品的喜好历史数据，所以对于新用户讲没有“冷启动（Cold Start）”的问题。

2. 这个方法不依赖于物品本身的数据，所以这个方法在不同物品的领域都可以使用，它是领域独立的（domain-independent）。

那么这个方法的缺点和问题是什么呢？这种基于用户的基本信息对用户进行分类的方法过于粗糙，尤其是对品味要求较高的领域，比如图书，电影和音乐等领域，无法得到很好的推荐效果。可能在一些电子商务的网站中，这个方法可以给出一些简单的推荐。另外一个局限是，这个方法可能涉及到一些与信息发现问题本身无关却比较敏感的信息，比如用户的年龄等，这些用户信息不是很好获取。

2：基于内容的推荐

基于内容的推荐是在推荐引擎出现之初应用最为广泛的推荐机制，它的核心思想是根据推荐物品或内容的元数据，发现物品或者内容的相关性，然后基于用户以往的喜好记录，推荐给用户相似的物品。如下图给出了基于内容推荐的基本原理。

图 3 中给出了基于内容推荐的一个典型的例子，电影推荐系统，首先我们需要对电影的元数据有一个建模，这里只简单的描述了一下电影的类型；然后通过电影的元数据发现电影间的相似度，因为类型都是“爱情，浪漫”电影 A 和 C 被认为是相似的电影（当然，只根据类型是不够的，要得到更好的推荐，我们还可以考虑电影的导演，演员等等）；最后实现推荐，对于用户 A，他喜欢看电影 A，那么系统就可以给他推荐类似的电影 C。

这种基于内容的推荐机制的好处在于它能很好的建模用户的口味，能提供更加精确的推荐。但它也存在以下几个问题：

1. 需要对物品进行分析和建模，推荐的质量依赖于对物品模型的完整和全面程度。在现在的应用中我们可以观察到关键词和标签（Tag）被认为是描述物品元数据的一种简单有效的方法。

2. 物品相似度的分析仅仅依赖于物品本身的特征，这里没有考虑人对物品的态度。

3. 因为需要基于用户以往的喜好历史做出推荐，所以对于新用户有“冷启动”的问题。

虽然这个方法有很多不足和问题，但他还是成功的应用在一些电影，音乐，图书的社交站点，有些站点还请专业的人员对物品进行基因编码，比如潘多拉，在一份报告中说道，在潘多拉的推荐引擎中，每首歌有超过 100 个元数据特征，包括歌曲的风格，年份，演唱者等等。

3：协同过滤（User_CF,Item_CF）

基于用户的协同过滤推荐的基本原理是，根据所有用户对物品或者信息的偏好，发现与当前用户口味和偏好相似的“邻居”用户群，在一般的应用中是采用计算“K- 邻居”的算法；然后，基于这 K 个邻居的历史偏好信息，为当前用户进行推荐。如下图所示：

上图示意出基于用户的协同过滤推荐机制的基本原理，假设用户 A 喜欢物品 A，物品 C，用户 B 喜欢物品 B，用户 C 喜欢物品 A ，物品 C 和物品 D；从这些用户的历史喜好信息中，我们可以发现用户 A 和用户 C 的口味和偏好是比较类似的，同时用户 C 还喜欢物品 D，那么我们可以推断用户 A 可能也喜欢物品 D，因此可以将物品 D 推荐给用户 A

基于用户的协同过滤推荐机制和基于人口统计学的推荐机制都是计算用户的相似度，并基于“邻居”用户群计算推荐，但它们所不同的是如何计算用户的相似度，基于人口统计学的机制只考虑用户本身的特征，而基于用户的协同过滤机制可是在用户的历史偏好的数据上计算用户的相似度，它的基本假设是，喜欢类似物品的用户可能有相同或者相似的口味和偏好。

基于项目的协同过滤推荐的基本原理也是类似的，只是说它使用所有用户对物品或者信息的偏好，发现物品和物品之间的相似度，然后根据用户的历史偏好信息，将类似的物品推荐给用户，图 5 很好的诠释了它的基本原理。

假设用户 A 喜欢物品 A 和物品 C，用户 B 喜欢物品 A，物品 B 和物品 C，用户 C 喜欢物品 A，从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的，喜欢物品 A 的人都喜欢物品 C，基于这个数据可以推断用户 C 很有可能也喜欢物品 C，所以系统会将物品 C 推荐给用户 C。

与上面讲的类似，基于项目的协同过滤推荐和基于内容的推荐其实都是基于物品相似度预测推荐，只是相似度计算的方法不一样，前者是从用户历史的偏好推断，而后者是基于物品本身的属性特征信息。

同时协同过滤，在基于用户和基于物品两个策略中应该如何选择呢？其实基于物品的协同过滤推荐机制是 Amazon 在基于用户的机制上改良的一种策略，因为在大部分的 Web 站点中，物品的个数是远远小于用户的数量的，而且物品的个数和相似度相对比较稳定，同时基于项目的机制比基于用户的实时性更好一些。但也不是所有的场景都是这样的情况，可以设想一下在一些新闻推荐系统中，也许物品，也就是新闻的个数可能大于用户的个数，而且新闻的更新程度也有很快，所以它的形似度依然不稳定。所以，其实可以看出，推荐策略的选择其实和具体的应用场景有很大的关系

相似度计算

1.欧几里德距离（Euclidean Distance）

2.皮尔逊相关系数（Person Correlation Coefficient）

3.Cosine相似度（Cosine Similarity）

4：LFM(隐语义模型，latent factor model)

LFM是一种基于机器学习的方法，具有比较好的理论基础。这个方法和基于邻域的方法（比如UserCF、ItemCF）相比，各有优缺点。下面将从不同的方面对比LFM和基于邻域的方法。

理论基础

LFM具有比较好的理论基础，他是一种学习方法，通过优化一个设定的指标建立最优的模型。基于邻域的方法更多是一种基于统计的方法，并没有学习过程。

离线计算的空间复杂度

基于邻域的方法需要维护一张离线的相关表。在离线计算相关表的过程中，如果用户/物品数很多，将会占用很大的内存。假如有M个用户和N个物品，在计算相关表的过程中，我们可能会获得一张比较稠密的临时相关表（尽管最终我们队每个物品只保留K个最相关的物品，但在计算过程中稠密的相关表是不可避免的），LFM则节省了大量的内存。

离线计算的时间复杂度     

一般情况下，LFM的时间复杂度要稍微高于UserCF和ItemCF，这主要是因为该算法需要多次迭代。但总体上，这两种算法在时间复杂度上面没有本质的差别。

在线实时推荐

UserCF和ItemCF在线服务算法需要将相关表缓存在内存中，然后可以在线进行实时的预测。以ItemCF算法为例，一旦用户喜欢了新的物品，就可以通过查询内存中的相关表将和该物品相似的其他物品推荐给用户。因此，一旦用户有了新的行为，而且该行为被实时地记录到后台的数据库系统中，他的推荐列表就会发生变化。而从LFM的预测公式可以看到，LFM在给用户生成推荐列表时，需要计算用户对所有物品的兴趣权重，然后排名，返回全中最大的N个物品。那么，在物品数很多时，这一过程的时间复杂度非常高，因此，LFM不太适合用户物品数非常庞大的系统。另一方面，LFM在生成一个用户推荐列表时速度太慢，因此不鞥呢在线实时计算，而需要离线将所有用户的推荐结果事先计算好存储在数据库中。因此，LFM不鞥呢进行在线试试推荐，也就是说，当用户有了新的行为后，他的推荐列表不会发生变化。

推荐解释 

ItemCF算法支持很好的推荐解释，它可以利用用户的历史行为解释推荐结果。但LFM无法提供这样的解释，它计算出的隐类虽然在语义上却是代表了一类兴趣和物品，却很难用自然语言描述并生成解释展示给用户。

LFM核心思想：通过隐含特征（laten factor）联系用户和物品

假设隐因子个数为F个，则可以重写为：

其中是正则化项。要最小化上面的损失函数，可以利用随机梯度下降法。上面的目标函数对pufpuf和qifqif分别偏导数，得到:

然后根据梯度下降法，迭代公式为：

其中， α α 是学习速率(learning rate)。 
对于导数，也可以直接使用向量表示：

其中Pu和Qi分别为大小为F的列向量，表示用户和物品的隐因子向量。

5：ALS

ALS的意思是交替最小二乘法（Alternating Least Squares）,它只是一种优化算法的名字，被用在求解spark中所提供的推荐系统模型的最优解。spark中协同过滤的文档中一开始就说了，这是一个基于模型的协同过滤（model-based CF），其实它是一种近几年推荐系统界大火的隐语义模型中的一种。

隐语义模型又叫潜在因素模型，它试图通过数量相对少的未被观察到的底层原因，来解释大量用户和产品之间可观察到的交互。操作起来就是通过降维的方法来补全用户-物品矩阵，对矩阵中没有出现的值进行估计。基于这种思想的早期推荐系统常用的一种方法是SVD（奇异值分解）。该方法在矩阵分解之前需要先把评分矩阵R缺失值补全，补全之后稀疏矩阵R表示成稠密矩阵R'，然后将R’分解成如下形式：

然后再选取U中的K列和V中的S行作为隐特征的个数，达到降维的目的。K的选取通常用启发式策略。这种方法有两个缺点，第一是补全成稠密矩阵之后需要耗费巨大的存储空间，在实际中，用户对物品的行为信息何止千万，对这样的稠密矩阵的存储是不现实的；第二，SVD的计算复杂度很高，更不用说这样的大规模稠密矩阵了。所以关于SVD的研究很多都是在小数据集上进行的。

隐语义模型也是基于矩阵分解的，但是和SVD不同，它是把原始矩阵分解成两个矩阵相乘而不是三个。

现在的问题就变成了确定X和Y ，我们把X叫做用户因子矩阵，Y叫做物品因子矩阵。通常上式不能达到精确相等的程度，我们要做的就是要最小化他们之间的差距，从而又变成了一个最优化问题。求解最优化问题我们很容易就想到了随机梯度下降，其中有一种方法就是这样，通过优化如下损失函数来找到X和Y中合适的参数：

其中Puk就是X矩阵中u行k列的参数，度量了用户u和第k个隐类的关系；Qik是Y矩阵中i行k列的参数，度量了物品i和第k个隐类的关系。这种方式也是一种很流行的方法，有很多对它的相关扩展，比如加上偏置项的LFM。

然而ALS用的是另一种求解方法，它先用随机初始化的方式固定一个矩阵，例如Y：

然后通过最小化等式两边差的平方来更新另一个矩阵X，这就是“最小二乘”的由来。得到X之后，又可以固定X用相同的方法求Y，如此交替进行，直到最后收敛或者达到用户指定的迭代次数为止，是为“交替”是也。 从上式可以看出，X的第i行是A的第i行和Y的函数，因此可以很容易地分开计算X的每一行，这就为并行就算提供了很大的便捷，也正是如此，Spark这种面向大规模计算的平台选择了这个算法。在3这篇文章中，作者用了embarrassingly parallel来形容这个算法，意思是高度易并行化的——它的每个子任务之间没有什么依赖关系。

在现实中，不可能每个用户都和所有的物品都有行为关系，事实上，有交互关系的用户-物品对只占很小的一部分，换句话说，用户-物品关系列表是非常稀疏的。和SVD这种矩阵分解不同，ALS所用的矩阵分解技术在分解之前不用把系数矩阵填充成稠密矩阵之后再分解，这不但大大减少了存储空间，而且spark可以利用这种稀疏性用简单的线性代数计算求解。这几点使得本算法在大规模数据上计算非常快，解释了为什么spark mllib目前只有ALS一种推荐算法。

ALS显性反馈和隐性反馈

我们知道，在推荐系统中用户和物品的交互数据分为显性反馈和隐性反馈数据的。在ALS中这两种情况也是被考虑了进来的，分别可以训练如下两种模型。

参数：

rating：由用户-物品矩阵构成的训练集

rank：隐藏因子的个数

numIterations: 迭代次数

lambda：正则项的惩罚系数

alpha： 置信参数

从上面可以看到，隐式模型多了一个置信参数，这就涉及到ALS中对于隐式反馈模型的处理方式了——有的文章称为“加权的正则化矩阵分解”，它的损失函数如下：

我们知道，在隐反馈模型中是没有评分的，所以在式子中rui被pui所取代，pui是偏好的表示，仅仅表示用户和物品之间有没有交互，而不表示评分高低或者喜好程度。比如用户和物品之间有交互就让pui等于1，没有就等于0。函数中还有一个cui的项，它用来表示用户偏爱某个商品的置信程度，比如交互次数多的权重就会增加。如果我们用dui来表示交互次数的话，那么就可以把置信程度表示成如下公式：

这里的alpha就是上面提到的置信参数，也是这个模型的超参数之一，需要用交叉验证来得到。