简单了解“推荐系统”原理和架构的读者提供学习实践参考。为什么需要推荐系统对于信息消费者来说，他们需要从大量的信息中找到自己感兴趣的信息，但是在信息过载的时代，用户很难获得自己感兴趣或者有价值的信息自己从大量的信息中。对于信息生产者来说，需要让自己生产的信息脱颖而出，吸引广大用户的眼球。从物品的角度来看，推荐系统可以更好地发现物品的长尾。长尾效应是美国《连线》杂志主编ChrisAnderson在2006年出版的《长尾理论》一书中指出，传统的80/20原则（80%的销售额来自20%的流行品牌）将随着互联网的加入而得到极大改善。将受到挑战。在互联网条件下，由于极低的货架成本，电子商务网站往往能卖出比传统零售店更多的商品。由于这些产品或服务体量大，销量小，但种类多，以前不被看重，出现累计总收入超过主流产品的现象。主流产品往往代表了绝大多数用户的需求，而长尾产品往往代表了一小部分用户的个性化需求。推荐系统通过挖掘用户的行为发现用户的个性化需求，从而将长尾产品精准推荐给有需要的用户，帮助用户找到那些感兴趣但又难找到的产品。推荐系统的任务是：一方面帮助用户找到对自己有价值的信息。另一方面，可以将信息展示在感兴趣的用户面前，实现信息消费者和信息生产者的双赢。推荐系统的本质是以一定的方式连接用户和物品，不同的推荐系统采用不同的方式。推荐系统是一种自动连接用户和项目的工具。它可以帮助用户在信息过载的环境中找到自己感兴趣的信息，也可以将信息推送给对自己感兴趣的用户。评价指标从产品的角度来看，可以从以下几个维度对推荐系统进行评价：用户满意度：作为推荐系统的重要参与者，用户满意度是评价推荐系统最重要的指标。但是线下用户满意度是没有办法计算出来的，只能通过用户调查或者线上实验来获得。预测准确性：预测准确性衡量推荐系统或推荐算法预测用户行为的能力。该指标是推荐系统最重要的离线评价指标。自推荐系统诞生之日起，几乎99%的推荐相关论文都在讨论这个指标。在计算这个指标的时候，需要一个离线数据集，里面包含了用户的历史行为记录。然后，这个数据集随着时间的推移被分成训练集和测试集。最后，通过在训练集上建立用户行为和兴趣模型，预测用户在测试集上的行为，计算预测行为与测试集上实际行为的重合度作为预测准确率。覆盖率：覆盖率描述了推荐系统发现项目长尾的能力。定义覆盖率的方法有多种。最简单的定义是推荐系统推荐的项目占总项目集的比例。多样性：用户有广泛的兴趣。为了满足用户广泛的兴趣，推荐列表需要能够涵盖用户不同的兴趣领域，即推荐结果需要多样化。新颖性：新颖性推荐是指向用户推荐他们以前没有听说过的项目。在网站中实现新颖性的最简单方法是从推荐列表中过滤掉用户之前在网站上操作过的那些项目。惊喜度：与新颖性不同，如果推荐结果与用户的历史兴趣不相近，但让用户感到满意，则可以说推荐结果具有较高的惊喜度，而推荐的新颖性仅取决于用户是否听说过它。通过了这个建议。信任：对于基于机器学习的自动推荐系统，同样存在信任（trust）的问题。如果用户信任推荐系统，就会增加用户与推荐系统的交互。同样的推荐结果，以让用户信任的方式推荐给用户，可以让用户更愿意购买，而以类似的广告形式推荐给用户，则可能很难让用户产生购买的欲望。衡量推荐系统信任度的唯一方法是通过问卷调查的方式询问用户是否信任推荐系统的推荐结果。实时性：推荐系统需要实时更新推荐列表，以满足用户新的行为变化。推荐系统需要能够向用户推荐添加到系统中的新项目。这主要是测试推荐系统处理物品冷启动的能力。鲁棒性：任何能够带来收益的算法系统都会受到人们的攻击。这方面最典型的例子就是搜索引擎。搜索引擎的作弊与反作弊斗争异常激烈，鲁棒性（即鲁棒性）指标衡量的是推荐系统抵抗作弊的能力。基于用户行为的用户行为推荐用户行为可以分为显式反馈行为（explicitfeedback）和隐式反馈行为（implicitfeedback）。ExplicitFeedbackBehavior：指用户表达对物品的偏好的行为，主要通过评分和喜欢/不喜欢来表达。常见的显式反馈行为可以参考下表：隐式反馈行为（implicitfeedback）：指那些不能明确反映用户偏好的行为。最具代表性的隐式反馈行为是页面浏览行为。仅仅因为用户浏览了一个项目的页面并不一定意味着用户喜欢这个页面上显示的项目。例如，由于页面链接显示在主页上，用户可能更容易点击它。与显式反馈相比，隐式反馈虽然不明确，但数据量更大。在很多网站中，很多用户甚至只有隐式反馈数据，而没有显式反馈数据。基于用户行为数据设计的推荐算法一般称为协同过滤算法。学术界对协同过滤算法进行了深入的研究，提出了很多方法。例如，基于邻域的算法、隐因子模型、图上随机游走算法等。下面主要介绍基于领域的算法和隐藏语义模型算法。基于领域的算法基于邻域的方法是业界最著名和应用最广泛的推荐算法，主要包括以下两种算法：基于用户的协同过滤算法（UserCF）。基于项目的协同过滤算法（ItemCF）。算法涉及的基本步骤如下：收集用户偏好，将用户对物品的偏好转化为可量化的综合评分。查找相似的用户或项目。计算转介。相似度计算计算相似度主要有三种计算方法：①欧氏距离（EuclideanDistance）向量欧氏距离：相似度：②皮尔逊相关系数（PearsonCorrelationCoefficient）协方差，用来衡量两个向量的变化趋势是否一致：standarddeviation:Pearsoncorrelationcoefficient:皮尔逊相关系数是协方差除以2个向量的标准差得到的，取值范围是[-1,1]。③余弦相似度（CosineSimilarity，余弦距离）余弦相似度其实就是求两个向量的夹角。在计算相关系数的3种算法中，Pearson相关系数是生产中最常用的。邻居的选择通过相似度计算出几个最相似的邻居后，如何选择邻居呢？主要有以下几种方法：基于固定数量的邻居：这种方法直接选择固定数量的邻居，可以选择引入相似度较小的对象。基于相似度阈值的邻居：该方法首先筛选出一组具有相似度阈值的邻居，然后从该集合中选择相似度较大的邻居。可以避免引入相似度较低的对象，效果更好。简单来说，基于用户的协同过滤算法（UserCF）就是将其他用户喜欢的、兴趣相近的项目推荐给该用户。在在线个性化推荐系统中，当用户A需要个性化推荐时，他可以先找到其他兴趣相似的用户，然后将那些用户喜欢但用户A没有听说过的项目推荐给A。这种方法称为基于用户的协同过滤算法。用户A和用户C兴趣相似，用户C喜欢item4，所以将item4推荐给用户A。数学实现如下图所示：给定用户评分矩阵R（一般很稀疏），推断矩阵中问号处的评分值。UserCF模型存在一个问题：对于一个新用户，很难找到相邻用户。对于一个新项目，所有最近的邻居都没有太多分数。基本解决方案：相似度计算最好使用Pearson相似度。计算用户相似度会考虑共同评分的项目数量。例如相乘，n为一起评分的item个数，N为指定的阈值，这样两个用户评分的item个数越少，相似度越小。对score进行归一化，比如原来的score取值范围是[0,10]，归一化后就变成了[0,1]。设置相似度阈值。基于用户的协同过滤不流行的原因：数据稀疏和数据访问困难。计算百万用户，成对计算用户之间的相似度，计算量太大。人是善变的。基于项目的协同过滤算法（ItemCF）基于项目的协同过滤算法（简称ItemCF）是向用户推荐与用户之前喜欢的项目相似的项目。例如，算法会向你推荐《机器学习》，因为你购买了?。但是ItemCF算法并没有利用物品的内容属性来计算物品之间的相似度，它主要是通过分析用户行为记录来计算物品之间的相似度。算法认为itemA和itemB有很高的相似度，因为大多数喜欢itemA的用户也喜欢itemB。item1和item3都被用户A和用户B喜欢，所以认为它们是相似的item，所以当用户C喜欢物品1时，物品3被推荐给用户C。算法的主要步骤如下：计算物品之间的相似度。根据物品的相似度和用户的历史行为，为用户生成推荐列表。数学实现的思路如下图所示：用户5需要在item1上打分r_15，由于item3和item6是与item1最相似的两个item，所以以相似度作为权重，所以r_15可以预测如下：模型优势：计算性能高，通常用户数远大于物品数。真正计算物品之间的相似度，可以只选择同一类别下的相似物品进行计算，从而减少计算量。结果可提前预约，物品不善变。UserCF和ItemCF的综合比较UserCF向用户推荐那些与他有相同兴趣的用户喜欢的项目，而ItemCF向用户推荐那些与他以前喜欢的项目相似的项目。从该算法的原理可以看出，UserCF的推荐结果侧重于反映与用户兴趣相似的小群体的热点。ItemCF的推荐结果侧重于维护用户的历史兴趣。换句话说：UserCF的推荐更具社会性，反映了项目在用户的小兴趣群体中的受欢迎程度。ItemCF的推荐更加个性化，体现了用户自身的兴趣传承。基于用户标签的推荐推荐系统的目的是连接用户的兴趣和物品，而这种连接需要依赖不同的媒体。目前流行的推荐系统基本上是通过三种方式连接用户兴趣和物品的：基于用户的推荐UserCF：利用与用户有相似兴趣的其他用户，推荐与自己爱好相似的其他用户喜欢的物品。Item-basedrecommendationItemCF：向用户推荐与他喜欢的物品相似的物品。Feature-based：这里的特征可以有不同的表达方式，比如可以表达为物品的属性集（比如对于图书，属性集包括作者、出版商、主题和关键词等），或者可以表示为潜在语义向量（latentfactorvector）。标签相关问题标签的定义根据维基百科的定义，标签是用于描述信息的非层次关键词，可以用来描述一个条目的语义。根据给物品打标签的人不同，标签应用一般分为两种：一种是作者或专家给物品打标签。另一种是允许普通用户对物品进行标记，即UGC（UserGeneratedContent，用户生成内容）标记应用。UGC标签系统是表达用户兴趣和物品语义的重要方式。当用户给物品打上标签时，标签一方面描述了用户的兴趣，另一方面表达了物品的语义，从而将用户和物品联系起来。因此，下面主要讨论UGC标签的应用，研究用户给物品打标签的行为，并通过分析这种行为来讨论如何向用户进行个性化推荐。用户为什么要打标签？从产品的角度，我们需要了解用户的打标签行为，以及他们为什么打标签。只有深刻理解用户行为，才能设计出满足他们的个性化推荐系统。用户这种行为背后的原因可以从两个维度来讨论：社会维度，一些用户注释是针对内容上传者的（方便上传者整理自己的信息），而一些用户注释是针对一般用户的（便于帮助其他用户找到信息）。在功能维度上，一些注释用于更好地组织内容，方便用户日后搜索，而另一些则用于传达某些信息，例如照片拍摄的时间和地点。用户标记什么样的标签？用户经常标记的标签如下：表明物品是什么。指示项目的类型。指示谁拥有该项目。比如很多博客的标签都会包含博客作者等信息。表达用户的观点。例如，如果用户觉得这个网页很有趣，他们就会给它贴上funny（有趣）的标签，如果他们认为它很无聊，就会给它贴上boring（无聊）的标签。用户相关的标签，比如我的最爱（myfavorite）、我的评论（mycomment）等用户任务，比如toread（即将阅读）、jobsearch（找工作）等为什么要向用户推荐标签当用户浏览一个物品时，标签系统非常希望用户能够为该物品打上高质量的标签，从而促进标签系统的良性循环。因此，很多标注系统都设计了标签推荐模块，向用户推荐标签。一般认为，向用户推荐标签有以下优点：方便用户输入标签，让用户通过键盘输入标签无疑会增加给用户打标签的难度，所以很多用户不愿意给物品打标签，所以我们需要一个辅助工具来降低用户标注的难度，从而增加用户标注的参与度。为了提高标签质量，具有不同语义的同一用户可能由不同的词表示。这些同义词会使标签的词汇量非常大，使得相似度的计算不太准确。在使用推荐标签的时候，我们可以选择词库，首先要保证词库中的同义词不要太多，同时要保证出现的词是一些流行的、有代表性的词。如何给用户推荐标签当用户u给itemi打标签的时候，我们有很多方法可以向用户推荐itemi相关的标签。比较简单的方法有四种：把整个系统中最流行的标签推荐给用户u（这个算法这里叫做PopularTags）。这个算法太简单了，甚至不能称为标签推荐算法。将物品i上最受欢迎的标签推荐给用户u（此算法在此称为ItemPopularTags）。用户u推荐自己的常用标签（我们这里称这个算法为UserPopularTags）。前两者的融合（这里简称HybridPopularTags），这种方法通过一个系数对上述推荐结果进行线性加权，然后生成最终的推荐结果。一个最简单的算法的基本步骤如下：统计每个用户最常使用的标签。对于每个标签，计算被标记次数最多的项目。对于一个用户来说，首先找到他经常使用的标签，然后找到带有这些标签的最受欢迎的商品推荐给这个用户。对于上述算法，用户u对物品i的兴趣公式如下：是用户u键入的标签集。是标记项目i的集合。是用户u标记b的次数。是项目i被标记为b的次数。用户使用“幽默”标签10次，“搞笑”标签3次，“讽刺”标签6次。这3个标签分别被项目A使用了4、7和2次。由此计算出用户对物品的兴趣度：上述计算公式往往会给热门标签对应的热门物品赋予较大的权重，因此会引起该热门物品向用户的推荐，从而降低推荐结果的新颖性，以及数据稀疏性的问题可以通过将计算结果除以惩罚项来修正。系统冷启动问题介绍系统冷启动（coldstart）问题主要在于如何在一个新开发的网站（没有用户，没有用户行为，只有一些item信息）上设计一个个性化的推荐系统，让网站刚好让个性化推荐服务上线时用户体验问题。主要可以分为三类：用户冷启动：用户冷启动的问题主要在于如何对新用户进行个性化推荐。当一个新用户到来时，我们没有他的行为数据，所以我们无法根据他的历史行为来预测他的兴趣，也就无法为他做出个性化的推荐。物品冷启动：物品冷启动问题主要在于如何解决向可能感兴趣的用户推荐新物品的问题。系统冷启动：系统刚上线，用户和物品数据很少。解决方案针对以上三类冷启动问题，一般来说，可以参考以下解决方案：提供非个性化推荐：非个性化推荐最简单的例子就是热门榜单。我们可以把热门榜单推荐给用户，然后等到收集到一定的用户数据，再转为个性化推荐。这也是最常见的解决方案。利用用户在注册时提供的年龄、性别等数据，进行粗粒度的个性化。要求用户在首次登录时提供反馈，例如输入感兴趣的标签或感兴趣的项目。收集用户对物品的兴趣信息，然后向用户推荐与这些物品相似的物品。对于新添加的商品，可以利用内容信息将其推荐给喜欢过与其相似商品的用户。在系统冷启动时，可以引入专家知识，以一定高效的方式快速建立项目关联表。评价指标顺序是根据用户在训练集上的行为对用户做出的推荐列表，是用户在测试集上的行为列表。准确性用于衡量模型的预测值与真实值之间的误差。召回率用来衡量有多少正例被分类为正例，这里是正确推荐的数量与测试集上用户动作列表的比值。覆盖率：用户衡量推荐商品占所有商品的比例。一般来说，我们推荐的项目希望涵盖尽可能多的类别。常见的计算方式有两种：推荐商品占总商品的比例；或者通过推荐item的熵值得到的覆盖率。熵值越大，覆盖率越大：diversity用于衡量每次推荐中pushitems与所有可能性的比值，diversity越大，表示每次推荐的items越丰富。事实上，不同的平台有不同的衡量标准，比如用户满意度、广告收入等，需要根据实际业务情况进行策略调整。系统架构基于特征的推荐系统重新审视上面提到的推荐系统连接用户和项目的3种方式。通过对这三种方法进行抽象，可以发现，如果用户喜欢的物品也是用户特征，或者与用户有相似兴趣的其他用户也是用户特征，那么用户和物品是通过特征连接起来的.用户特征的种类很多，主要包括以下几类：用户注册属性：年龄、性别、国籍等用户行为特征：浏览、点赞、评论、购买等系统整体架构由于复杂push策略本身，如果把上面提到的各种特性和任务都考虑在一个系统中，系统会很复杂，很难通过配置文件方便地配置不同的特性和任务。任务的重量。因此，推荐系统需要由多个推荐引擎组成，每个推荐引擎负责一类特征和一个任务，推荐系统的任务就是将推荐引擎的结果根据一定的权重或优先级。这样做有两个好处：可以方便地添加/删除引擎，控制不同引擎对推荐结果的影响。对于绝大多数的需求，只需要通过不同的引擎组合就可以实现。可以实现推荐引擎级别的用户反馈。每个推荐引擎实际上代表一种推荐策略，不同的用户可能喜欢不同的推荐策略：有些用户可能喜欢根据年龄和性别进行推荐。一些用户可能更喜欢看到新添加的与他们的兴趣相关的视频。一些用户更喜欢新颖的推荐。一些用户更喜欢专注于一个社区的推荐。一些用户喜欢各种推荐。我们可以将每一种策略设计成一个推荐引擎，然后分析用户对推荐结果的反馈，了解用户更喜欢推荐哪些引擎，从而为不同的用户赋予不同的引擎组合权重。推荐引擎架构推荐引擎利用一个或多个用户特征，根据推荐策略为一类商品生成推荐列表。基本架构如下图所示：如上图所示，推荐引擎架构主要包括3个部分：用户行为数据模块：如图A部分，该部分负责从数据库中获取用户行为数据或缓存，通过分析不同的行为生成当前用户的特征向量。但是，如果使用非行为特征，则不需要使用行为提取和分析模块。该模块的输出是用户特征向量。物品数据模块：图中B部分，负责将用户的特征向量通过特征-物品相关矩阵转化为初始推荐物品列表。最终结果生成模块：图中C部分，负责对初始推荐列表进行过滤排序，从而生成最终推荐结果。其中，有几个模块需要特别介绍：候选项集：特征项相关的推荐模块也可以接受一个候选项集。候选项集的目的是保证推荐结果只包含候选项集中的项。它的应用一般是产品需要向用户推荐某类电视剧。例如，有些商品需要向用户推荐上周新增的商品，那么候选商品集合中就包含了上周新增的商品。过滤模块：获取初步推荐列表后，不能向用户展示该列表。首先，需要根据产品要求对结果进行过滤，过滤掉那些不符合要求的项目。一般来说，过滤模块会过滤掉以下项目：用户已经产生了行为项目，因为推荐系统的目的是帮助用户发现项目，所以没有必要向用户推荐他已经知道的项目，从而保证推荐结果的新颖性。对于候选项以外的项，候选项的集合一般有两个来源，一个是产品需求。比如在首页，可能需要向用户推荐新添加的商品，那么需要在过滤模块中过滤掉不符合这个条件的商品。另一个来源是用户自己的选择。例如，用户选择了某个价格区间，只想看到这个价格区间内的商品，那么过滤模块就需要过滤掉不符合用户需求的商品。对于一些质量较差的物品，为了提升用户体验，推荐系统需要向用户推荐质量好的物品，而对于一些大多数用户评价较差的物品，推荐系统需要将其过滤掉。这个过滤一般是根据用户的历史评分，比如过滤掉平均分在2以下的item。可以更好地提高用户满意度。在实际排名中，可以根据新颖性、多样性和用户反馈来优化排名。总结除了本文介绍的模型算法外，还有基于用户行为推荐的隐藏语义模型，比较常见的是基于图的模型，以及基于上下文和社交网络的推荐。其实有一些常用的算法库可以实现推荐系统的操作，包括LibRec、Crab等。参考资料：《推荐系统实践》看一篇文章了解推荐系统的知识体系https://cloud.tencent.com/developer/article/1070529个性化推荐系统总结https://www.jianshu.com/p/319e4933c5ba推荐系统介绍https://cloud.tencent.com/developer/article/1070529://www.cnblogs.com/redbear/p/8594939.html陈才华（caison），从事服务器端开发，擅长系统设计、优化重构、在线问题排查，主要开发语言为Java，微信号：hua1881375。【原创稿件，合作网站转载请注明原作者和出处为.com】
