从最初接触个性化推荐系统已过去六天。今天是第七天，完全可以对前六日的学习做出复盘。推荐系统并没有如同网络上那般盛传的玄秘深晦，而是直白到令人一眼看穿，当然如果你看完本文的话，你也会有与我一样的想法。
个性化推荐系统的出现，是为了解决信息超载这颗毒瘤。已经算不清从什么时候开始，互联网资源开始指数性地爆发，我们每个人穷尽一生，都无法窥到其冰山一角，更遑论坐拥十万大山的互联网全貌。这个时候开始有人提出要建立一个个性化推荐系统，根据用户概貌自动推荐用户最感兴趣的内容。
本文整体分为六个部分：
01 用户对象建模 构建个性化推荐系统的目的是为了解决 信息超载 的信息难题，实际上有前辈们做的搜索引擎也可以算作是一种推荐系统，它会将用户输入的信息与数据库进行配对，然后做出一个排序显示，对现今的搜索引擎，我是更倾向于按照用户的兴趣偏好对用户的搜索结果进行值的排序。那么首当其冲的就是针对用户对象进行建模。
用户对象建模前的思考
对用户建模之前，我们需要做好充足地考虑，一般来说有六点是较为重要的。
模型的输入数据有哪些？
怎么样获取用户输入数据？
怎么考虑用户的兴趣偏好变化？
建模对象是谁？
怎么建模？
模型输出的样子是什么？
1.1 模型输入数据有哪些？
一般来说，模型的输入数据包括用户属性、用户主动输入的信息、用户产生的浏览行为和浏览内容、推荐对象的属性特征。但是我现在还不想把最后一类放进去，因为当前还没讲到推荐对象的建模。
从用户属性来说，就有社会属性，比如说从事什么职业；学历是什么；有哪些社会关系等等。还有一类是自然属性，比如说身高、体重等等。就人而言，所谓自然属性指的是人的肉体以及其衍生出来的相关特征，而社会属性则是表示在人在社会中的关系，人之所以为人，不是因为他的自然属性决定的，而是他的社会属性决定了他是人。因此在推荐系统中权重占比会更倾向于社会属性，尤其是在协同过滤中，这点被放至极大。
从用户主动输入的信息来说，就有搜索栏中主动键入的信息等等。
当用户在浏览项目时，可能会产生评论、点赞、转发等等浏览行为；以及浏览项目的内容特征是什么，诸如此类的相关属性，当推荐系统将一些极为契合当前用户的推荐对象推介给用户时，它的属性特征也可以视作一类输入数据。
1.2 如何获取用户输入数据
如何获取用户输入数据，当前业内的主流方案不吝是以下三种：
现在对这三种方案进行描述。
显式获取：在用户刚开始使用推荐系统的时候，让用户主动地输入自己感兴趣的领域或方向，这种方法的代表是 Quora，当初我刚开始用它的时候，就要我选择很多兴趣方向，点的我头都大了。从我的体验种能够表明显式获取数据这种方案，其优点是简单直接、相对准确、具体全面、客观可靠；但是缺点是侵袭性很大、实时性与可操作性低，灵活性较差。如果使用这种方式，就要好好考虑一下如何解决侵袭性问题；同时用户能够接受多少次这样的操作；并且如果出现五级积分制的评分，用户有多少耐心能够去进行评价；用户所能够接受的评价方式是什么等等。
隐式获取：使用这种方案会极大地减少对用户的侵袭性，通过 Web 日志挖掘或者是跟踪用户浏览行为等相关办法，可以在不打扰用户正常生活的情况下，获取用户概貌。虽然这种办法在一定程度上减少了用户不必要的负担，但是也可能会存在信息走样，并且用户也很难意识到自己的兴趣偏好是什么，甚至当系统长期过度地挖掘用户的 Web 日志，会引起用户的极大反感，致使用户弃用该系统。
启发式获取：当系统使用这种方案时，是希望尽可能地利用专家意见或者是领域术语抽取出用户的兴趣偏好以得到用户个人信息概貌。这样子做的好处是，能够尽系统所能为用户提供建议，实现领域知识的复用，提高用户兴趣的获取质量。
1.3 怎么考虑用户的兴趣偏好变化
上小节的三种获取用户输入数据的方案，有一个不好的地方在于，很难跟踪用户的长短期兴趣变化，比如说我作为一个用户，我很喜欢游泳，可能会在长时间内喜欢这项运动，但与此同时，我爱上了甜品，可这只是一个短期的兴趣偏好，那应该如何来跟踪用户的长短期？目前业界有两种策略，时间窗方法与遗忘机制，这两种方法都可以反应用户的长短期兴趣变化。
1.4 建模对象与建模方法
一般来说，建模的对象有两大类，一个是针对单用户建模，一般采用基于内容的推荐策略；另一个是对群组建模，一般采用基于协同过滤的推荐策略。对于这两种类型的推荐策略，本文会在第三章中详细讲到，此处做个大致的介绍，这俩都挺重要的。对于建模方法，可以分成两种分支，使用进化算法中的遗传算法，通过不断地子孙迭代得到用户的最新概貌情况，我认为是一种蛮好的策略；当然也可以使用机器学习中的一些方法，比如 TF-IDF 词向量分析、贝叶斯分类器、决策树分析、决策树归纳、神经网络与聚类分析。这些就留到专栏再展开讲具体好啦。
1.5 模型输出数据的表示
在用户模型的输出表示上，很多时候系统会使用主题表示法；在进行协同推荐的时候，更多的是采用用户-项目评价矩阵来表示模型的输出形式，下表就是一个用户-项目评价矩阵的范例。
当然也有一些推荐系统使用案例表示法或者本体论表示法。就目前来说，研究较多的是细粒度模型表示法。
02
推荐对象建模
准备完对用户对象的模型之后，接着是推荐对象建模。所谓推荐对象建模，就是将某一内容的多媒体文件通过某些计算方法得到一个配对值，然后看看这个值和哪些用户之间是有较高关联性的，这样就可以把这个多媒体文件推送给目标用户。
2.1 推荐对象建模前的思考
在进行推荐对象建模之前，我们首先要思考一些问题，比如说这个模型是用来提取推荐对象的什么特征，怎么提取这些特征，提取完特征之后用于何种目的？再比说推荐对象的特征描述与用户的概貌描述之间存在何种关联？一个推荐对象可能会有多维特征，那么每一维的特征对推荐结果有什么影响？能不能让推荐对象的特征描述文件自动更新，如果能，那应该怎么做？
2.2 推荐对象的描述方法
当我们进行对推荐对象的描述时，一般用两种办法，基于内容和基于分类，现在对这两个方向展开来说。
基于内容的描述方法，不吝乎就是计算加权关键词矢量了。业界有蛮多的办法来计算这种加权关键词，但就特征计算来说，可以计算每个特征的熵值，然后选择具有最大熵值的若干特征；也可以计算每个特征的信息增量或者是互信息，也就是特征-文档之间的关系；在统计上，还经常使用
统计方法。除了特征计算之后外，还有一个方向是权值计算，就是要计算每个特征的权重，权重越大，影响越大。
基于分类的描述方法，其实也就是机器学习那套把式，使用朴素贝叶斯或者是 KNN、SVM 等方法提取出对象的分类信息之后，再展开描述。但是当对象数据比较少的情况下，手动分类是蛮可行的办法；如果数据较多，推荐使用聚类自动化的进行分类描述。
一开始我有提到“某一内容的多媒体文件”。我们都知道如果这个多媒体文件单纯只是文档类型的，比如说小说、新闻等等文字型对象，那提取特征的方法挺简单的，但是，实际生活中不单纯只有文档类型，还有千千万万的音频、视频等等多媒体类型，那么提取特征就不是那么容易的了。这是推荐系统要解决的第一大难点，如何提取多媒体对象的特征。
其次我们也希望系统推荐给用户的内容不要与以前看过的内容重复，甚至是完全不搭边，这是要解决推荐系统的过拟合问题，其本质是数据不完备，就举个例子来说，国家图书馆里有数不清的书籍文献，但是真被读者看过的也就那 1%~2%，还有很多的书没被读过，那么这些东西的数据就是不完备的。针对这一问题，目前是已经有解决方案了，就是引入随机性，可以是全局随机也可以是局部随机，比如说使用遗传算法或者是模拟退火使得其收敛至最优或者近似最优。
最后就是冷启动问题，当一个新的对象进入推荐系统时，它本身还没有被用户查看过，那系统如何把它推荐给用户呢？这个问题截止目前，方法有很多种，我们在 6.2 稀疏性与冷启动研究
这一章可以说是推荐系统的精髓所在，几乎全文的公式都是集中在此处，可能有些读者看着会比较吃力一些，但不要紧，解释一下会懂的。本章节会提到五种主流推荐模式——基于内容的、基于协同过滤的、基于网络结构的、组合推荐、其他混合推荐。
使用基于内容的推荐策略，首先需要计算当前用户喜爱的内容的特征，然后依据这个特征在系统中寻找与之相近的内容，再按照相似度高低推荐给当前用户。
可以很简单很有效地就将接近用户概貌的内容推送给目标用户，推荐结果直观，容易理解，也不需要有什么领域知识。
有很多种业界成熟的分类学习方法为此推荐方案提供支持，例如自动聚类分析、数据挖掘。
但是有好的就有坏的地方。正是因为这种策略基于内容推荐，因此它受限程度非常大，例如所需推荐的对象是多媒体文件，音频或者视频，那么这类多媒体的特征提取就非常不便。
而且又由于用户喜欢的兴趣点不断地被推荐系统所匹配推荐，这就导致了用户只能一直在这个兴趣点内不断被深挖，很难出现新的推荐结果。
之前在优点方面我们提到推荐对象不会出现冷启动的问题，是因为这颗丑恶的毒瘤被踢到用户这边过来了。当出现一个新用户时，除非使用显示获取，否则很难获得用户的兴趣偏好，这是因为不知道要推荐什么给新用户。
目前较为普遍的计算用户描述文件与推荐内容相似度的方法是使用下面这个公式：
其中
可以使用向量夹角余弦代替，这是最简单的代入模式：
3.2 协同过滤
所谓协同过滤，它假设你朋友喜欢的东西，你也会喜欢，于是乎推广到推荐系统时，就是把和当前用户最近邻的若干用户的喜欢内容通过一些计算方法得出相似度之后推送给当前用户。目前的协同过滤策略主要有基于用户的协同过滤、基于项目的协同过滤、基于模型的协同过滤，接下来就开始讲述这三种不同策略的相关思路。
所谓基于用户的协同过滤（UBCF），它的思路蛮清晰的，大体上分为两步走，第一步计算用户之间的相似性得到用户的最近邻；第二步把符合当前用户概貌的内容推送给当前用户。
在第一步的相似性计算中，最简单的方法是计算两者的余弦相似性，形如下式：
也可以计算两者之间的相关相似性，会比较提高些，形如下式：
或者是两者之间的修正余弦函数弦相似性，更改善一些关系内容，形如下式：
当得到当前用户的最近邻时，就可以开始进行第二步，使用下式：
基于项目的协同过滤策略（IBCF），是假设大部分用户对于一些推荐对象的评分很接近，那么就认为当前用户对这些项目的评分也会很接近。比如说有很多用户对某个品牌非常认可，由于从众心理，其他用户也会对这个品牌产生认可，从而选择这个品牌的相关产品。
其基本思路与基于用户的协同过滤模型有些类似，同样是先找到目标用户的最近邻，然后使用当前用户对最近邻的评分，预测到当前用户对目标推荐对象的评分，最后再选择若干得分最高的推荐对象作为结果推送给当前用户。
在这个策略中，第一步查询最近邻的相似性计算函数可以使用在 3.2.1 基于用户的协同过滤策略
3.2.3 基于模型的协同过滤策略
最后是基于模型的协同过滤策略（MBCF）。这种方案相对于前两种的不同之处在于本策略针对用户已有数据应用了统计学与机器学习的方法，计算出一个用户模型，随后对已有数据之外的对象进行预测打分，把得分高的对象推荐给用户。
很显然，建立一个用户模型是这个策略的核心所在。在业界，我们通常是使用机器学习方法或者是统计学上的一些模型方案，去不断地调整处理，最终得到一个较为不错的用户模型。当然除了上述两种方案之外，我们还能够使用基于马尔科夫链模型法、潜层语义分析、语义生成或者是输入选择技术来对用户模型进行创建。
基于网络结构的推荐策略是认为用户和对象可以形成二部分图，当用户选择某一对象时，则两者直接产生一条边，并对任一用户他当前没有选择的对象按照其兴趣偏好进行排序，把排序结果靠前的若干对象推荐给该用户。有研究者就此策略提出一种基于资源分配的推荐算法，该算法认为推荐系统中的所有对象都具备某种可以分配的资源，并且会把这类资源分配自己喜欢的对象。
如果使用
来表示对象
愿意给 对象
一定的资源量，那么
可以使用下式计算：
其中
表示用户
的度，
表示用户
和 对象
之间是否存在一条边，如果存在，则
，反之为零。
假设此前已经存在一个具备了
n 个对象的系统，如果用户
i 选择了对象
j ，则对象
j 的初始资源为
1 ，否则为
0 ，据此可以得到用户
i 的
n 维向量，把它标记为当前用户初始资源分配构型，记作
，然后通过下式计算新的资源分配构型
：
对于用户没看过的对象，就要按照
中的值从大到小进行排序，把排在靠前的若干对象推荐给用户。
无论是基于内容还是基于协同过滤或者是基于网络结构，它们都存在着各自的优劣性，当我们使用组合推荐时，就可以在实际问题种针对具体问题采用合理的推荐策略组合进行推荐。最后通过不同的组合方式，能够尽可能地扬长避短，从而产生更符合用户需求的推荐。目前的组合思路主要是推荐结果混合和推荐算法混合。
如果是推荐结果混合的话，开发者可以采用投票机制来组合推荐结果，投票高者优先；也可以采用一定的标准对推荐结果进行判断，最后选择其中之一；当然也有利用线性组合进行推荐结果混合；也有计算推荐结果队列的逐一可信度，然后选择其中之一。
要是推荐算法混合的话，那可就多多了，你总能够以某种推荐策略作为框架，混合其他的推荐策略，比如把协同过滤做底子，衬上内容推荐或是社交网络的皮囊。
这章要讲推荐系统的体系结构。纵观推荐系统的体系结构，其中最为重要的问题是——用户个人信息概貌与整体描述文件应该放在哪里？
就存放地点来说，用户概貌文件可以存放在服务器、客户端、代理服务器【介于服务器与客户端两者之间的中转站】、分布式集群【一般小系统不考虑】。
如果一个推荐系统将用户概貌文件存放在服务器端，那么会导致整个 Web 服务器系统开销变得非常大，因为要不断地在计算用户描述；而且对于用户信息的采集也会受到来自 Web 服务器的限制；最为重要的是，Web 服务器很容易遭受外部攻击，这对存放在其内的用户隐私有极大的威胁性。
要是推荐系统把用户概貌文件存放在客户端，则喜忧参半，喜在于用户的个人隐私基本上不会受到外部攻击而泄露，并且就在本地收集和处理的用户信息，因而能准确地获得用户的个人信息，从而创建高质量的用户模型；忧的部分在于，每个用户的个人概貌都存放在自己的本地客户端，对于使用协同过滤策略的系统不友好，需要重新设计系统的推荐算法，并且可能会有小部分的数据需要同服务器交互，在数据传输的过程中，也许有会被截获的风险。
假如把推荐系统的用户数据存放在代理服务器端，也会面临着被攻击的风险，甚至较之服务器端只多不少，因为数据的传输从客户端到代理端，代理端到服务端，两次的数据传输过程中，被截获的风险太大。
那使用分布式集群来存放总归是好的吧？说好是好，可以极大地提高数据安全性；但是说贵是真的贵，分布式集群本身的搭建成本过高，不适合小微型企业使用。
本章主要是简单讲下推荐系统的性能评价。当一个推荐系统被开发出来之后，慢慢地有用户开始使用这个系统，那么用户的个人概貌就会开始改变系统对此用户的一个整体构型，有点儿像养成游戏，不断地调教系统，直到系统推荐符合我们想要它推荐的内容。那么就可以引出两个推荐标准——准确度和效果值。
开发者总是希望系统推荐的准确度能够不断地上升，使用最多的指标是平均绝对误差、平均平方误差和标准平均误差。
其次还有效果值，一个推荐系统所推介给用户的内容能够让用户认为是自己喜欢的内容，那么这个效果就很棒，按照指标上来看，召回率是一个不错的评判指标。
当然还有其他的评价标准，比如说系统推荐多样性内容的能力以及推荐新产生内容的能力和冷门内容的能力，这些都应该成为一个好的推荐系统的评价标准。
最后是关于推荐系统今后研究方向的一些总结。实际上现今的推荐系统还在不断地成长当中，它还有不少的问题需要我们不断地去研究和发现并且解决掉。本章大致讲一下推荐系统的安全性研究和稀疏性与冷启动的问题研究。
前面我们讲推荐系统的用户个人信息的时候，经常用到一个词用户概貌，它所指的是用户在推荐系统中存放的个人信息，包括了兴趣偏好等等相关数据。我们也提到了养成这一说法，就是把系统当作是一个小白助理，我们不断地对它进行个人信息投喂，直到这个助理把我们想要的内容提供给我们，这个过程我把它叫做养成。有一些恶意用户会通过向推荐系统注入他们恶意编造的用户概貌来改变推荐结果，这种模式，被称为托攻击。
在进行一次托攻击之前，恶意用户需要了解所要攻击的项目信息、用户信息、此推荐系统使用了哪种推荐算法策略以及此推荐系统的评分信息，包括评分的分布与稀疏情况。
当完成好上述准备时，恶意用户开始针对推荐系统进行托攻击。如果是希望提高目标项目的推荐频率，则此次托攻击称为推攻击，可以理解为推广的意思；如果是希望降低目标项目的推荐频率，则成为核攻击。无论是托攻击中的何种，它们的攻击模式无外乎随机攻击、均值攻击、流行攻击与细分攻击。
无论是进行推攻击还是核攻击，恶意用户们组织一场战斗总是需要成本的，而他们的成本就是我们先前提到的所需了解的相关信息。我们把这些成本统称为攻击成本，其内细分为知识成本，即推荐系统与推荐用户的相关信息；执行成本，即展开攻击时所要提交的恶意概貌和提交恶意概貌时同系统的交互情况。倘若所需信息越多，则知识成本越高；若恶意概貌维度越多，则执行成本越高。
最后，我们使用预测值变化和推荐列表变化这两个指标来度量一次托攻击对受攻击推荐系统的攻击情况。
到这里，相信读者们对攻击推荐系统有了一个大致的了解。接下来我们讲下稀疏性和冷启动。
稀疏性问题的本质数据的不完备。我们研究稀疏性问题的意义就是使得整个推荐系统中的内容不再沉淀在冗余的空间里，而不被利用。目前推荐系统稀疏性问题的方法主要是使用多级关联规则挖掘方法、ICHM 算法、或者是矩阵聚类、信任度传播策略。其中 ICHM 算法是针对项目采用了传递关联来解决稀疏性，与之类似的还有 UCHM 算法，这个是对用户概貌进行聚类。对于其中所使用到的算法详情，我会再另外开一篇文章进行详解，此处便不再赘述。
而冷启动问题则是由于新进用户或者内容尚未建立起内容关联而导致推荐效果差的情况。目前有两种解决方向，一个是不考虑内容的解决方案，比如说利用随机推荐，当一个新进用户开始使用系统时，给他随机地推荐一些内容，这样子不断地积累此用户概貌，然后慢慢养成，慢慢调教，直到推荐出用户喜欢的内容。除了随机推荐法之外，还有平均值法、众数法、信息熵法等相关解决办法。另一种方案是考虑内容的解决方案，比如说结合机器学习的相关方法或者是统计学上的一些策略模型进行解决。
最后，一个真正优秀的推荐系统，是始终将用户的个人隐私视为系统生命的至高存在，保护用户隐私，就是在保护系统自己。
更多优质干货文章，加入 GitChat 会员全年免费看！每月还送一张专栏 3 折券哦~