《Statistical Methods for Recommender Systems》--第五章（1）推荐问题设定和系统架构

可以将网站分为以下四类，对应每类，再选择推荐模型的时候会有各自的考虑：

1. general portals；也就是综合的门户网站，比如雅虎，新浪等；

2. Personal portals；个性化网站；应该指的是类似个人博客一类的网站

3. Domain-specific sites；领域特定的网站。比如新浪体育等

4. Social network sites；facebook；人人网等。

为了给一个应用选择一个推荐方法，我们需要考虑应用的特性。常用的描述一个推荐应用的特性的问题有：

● 用户相关的；

能获得用户标识吗？比如，Personal portals 和Social network sites通常都是需要用户登陆的。所以用户标识能获取。而另外两种网站不行。

有哪些用户特征（属性，位置等）？ 用户和应用的交互频繁吗？如果能获取丰富的用户特征，我们可以利用这些特征来给用户推荐。当然，如果不能获取，我们可以利用协同过滤算法。前提是有活跃的用户行为。此外，并不是所有的推荐模块都需要是个性化的嘛。比如像综合门户，或者领域特定领域，不需要很深入的个性化。

● 物品相关的；

物品候选集的尺寸和质量怎么样？（对少部分高质量的物品排序和对包含大量低质量物品排序要考虑的是不一样的：前者的挑战是如何快速的准确估计CTR,而后者的首先需要考虑怎能移除低质量物品）；

有哪些物品的特征（比如，类别，关键字等）？ 当物品集较小，而用户行为足够时，预测CTR的时候，物品的特征也就显得不那么重要了。我们用丰富的用户行为就可以预测。

物品是时间敏感的吗？

● 上下文信息；

能获得上下文信息吗？如果能，能获得哪些上下文信息？比较明显的上下文是：你当前所在页面看到的文章；不明显但也非常有用的包括：当前的时间，当天是周末还是工作日，用户用的是手机还是电脑等。当包含上下文信息时，推荐问题就由一个在用户-物品的二维矩阵上建模扩展到了在用户-物品-上下文信息的三维张量上建模。纤细可以参考第10章。

● 反馈；

能获得用户的反馈（比如，点击，评分等）吗？ 我们能够多快使用当前的反馈来更新模型？反馈问题主要还包括：当用户提供多种反馈（点击，分享等）时，我们如何解析。

针对这些网站的推荐模块，又可以分为以下三类：

● Featured modules (FMs) –特征类模型。实现的是基于特征的方法。

● Network-update modules (NMs)–基于网络更新的模块。也就是基于社交网络的推荐

● Related-content modules (RMs)–内容相关的模块。也就是基于内容的一些推荐方法