召回 & 排序
目前业界推荐系统普遍采用召回+排序的两阶段模型，如下图所示。所谓召回（matching），指的是从全量信息集合中触发尽可能多正确的结果，并将结果返回给排序作为输入。相比搜索系统，推荐系统最大的不同在于用户没有明确的Query输入，即用户自身的需求是不明确的，推荐系统需要做的就是根据用户画像、内容画像等各种信息为用户推荐他可能感兴趣的内容，达到延长用户停留时间的作用。由于没有明确的Query，推荐系统中的召回面对的是全量信息池，需要从整个信息集合中挑选出尽可能多的相关结果，剔除相关性较弱的结果，降低排序阶段的工作量。
排序（ranking）则是指对多路召回渠道的内容进行统一打分排序，选出少量的最优结果。召回阶段的主要职责是从千万量级的候选物品中，采取简单模型将推荐物品候选集合快速筛减到千级别甚至百级别，这样将候选集合数量降下来，之后的排序阶段就可以上一些复杂模型，细致地对候选集进行个性化排序。我觉得英文matching的描述更相对贴切，易于理解。
多路召回策略
基于内容匹配的召回
内容匹配即将用户画像和内容画像进行匹配，基于内容的匹配召回率较高，但准确率较低，比较适合冷启动的语义环境。以微博feed流为例，有基于兴趣标签、兴趣Topic、兴趣实体的召回策略。
基于协同过滤的召回
基于领域的协同过滤
-
UserCF - 基于用户的协同过滤
UserCF即发现与用户相似的其他用户，然后基于用户的浏览记录做相互推荐。 -
ItemCF - 基于项目的协同过滤
ItemCF中的项目依业务场景而定，可以是信息流产品中的“内容”或者电商场景中的商品，通过计算项目之间的相似性，再根据用户的历史偏好进行类似物品推荐。
基于模型的协同过滤
Model-based的协同过滤是基于样本的用户喜好信息，训练一个推荐模型，然后根据实时的用户喜好信息进行预测推荐。常用的比如隐语义模型中的矩阵分解（matrix factorization，MF）和LDA等。其他还有基于贝叶斯网络以及基于SVM的协同过滤。
基于流行度/热度的召回
内容的流行程度，也称之为热度，最常见的就是将榜单中热度最高的内容推荐给用户，比如微博热搜，电商中的Top N商品等。
基于场景上下文的召回
所谓上下文（Context）即用户行为发生的时间、地点以及使用的设备，有些行为是近乎实时的，比如刷新微博的时间，以及美团/滴滴对地理位置极其敏感的应用，这种变化需要在召回阶段就体现出来，上下文特征具有非常强的动态性。
Reference
