推荐系统从0到1[二]:个性化召回

前文说完数据的基础积累，包括用户画像和内容画像的构建，接下来我们可以正式着手开始推荐了。以新闻推荐举例来说，推荐可以有很多策略，包括基于用户兴趣画像语义的策略（兴趣关键词/分类/主题相关），基于用户行为的策略（itemCF/userCF/clusterCF），基于位置的策略（地域相关），基于社交关系的策略（SNS推荐）等等。

在一次个性化推荐中，我们通常需要同时运用多种策略。如果尝试仅仅通过某种精细化的推荐策略（如关键词/itemCF）进行推荐的话，用户往往会在初期表现得很感兴趣，而随着数量增多，用户会逐渐疲劳。毕竟用户的阅读倾向往往是多元的，特别是在新闻领域，绝大多数用户除了自己的一亩三分地外，也会比较关注当日热点新闻，或者关注一些其他领域的潜在兴趣。因此，我们通常是从多种策略拉取内容，而后依据某种规则统一进行排序。这个过程一般称作召回。

1. 召回策略

1.1. 协同过滤

协同过滤（Collaborative Filtering）可说是推荐系统里资历最老最经典的一种算法了，如 userCF、itemCF。原理是基于用户对内容的行为协同，为某一用户没有看过的某条内容作出点击预测。实现方法有很多种，如传统的 Memory-based 方法、基于矩阵分解的方法（LFM/SVD/SDV++）、基于 DNN 的方法。

Memory-based 方法很简单，是基于统计的一种算法。以 item-based CF 举例：

根据用户点击行为，我们可以统计出 item-item 的共现矩阵（矩阵单元内为 item i 与 item j 共同被用户点击的次数），再依此通过Jaccard相似度/余弦相似度/欧氏距离得出 item 相似度矩阵，最后根据用户的点击记录检索出 topK 相似的内容推荐给用户。在计算过程中需要考虑一些因素，比如热门物品对相似度计算的影响、不同倾向的用户的影响等等。

然而 Memory-based 方法不能解决的问题是，当我们的矩阵很稀疏时，大多数 item 和 item 之间是没有关联的（相似度为0），这也就造成最后我们召回的内容覆盖率很低，也许大多集中在头部内容。于是基于矩阵分解的方法诞生了。

MF（Matrix Factorization）的原理是将一个高维稀疏矩阵分解成两个低秩矩阵，其中 k 被称为隐向量维度。在原始的稀疏矩阵 R 中，大部分二阶特征的关系系数是缺失的。而通过训练模型最小化 R 和预测矩阵 R‘ 的损失（如最小二乘），可以求出任意 Ri,j 的值。

MF 可说是大部分推荐系统里协同过滤的标杆方法了，但仍然存在一些问题。比如过于稀疏的矩阵对于最后评分的预测依然有很大影响，并且当用户特征或者内容特征缺失（即冷启动）时，无法进行合理的预测。此时，基于深度学习的一些尝试开始了。如基于DNN实现，可以很轻易地将内容的一些语义特征，以及用户的固有属性与行为特征拼接在一起作为神经网络输入来训练，可以在之前行为协同的前提下加入对内容特征的学习，从而解决冷启动问题。感兴趣的同学可以阅读相关论文，在此不做展开。

1.2. 基于内容

基于内容的召回主要是以之前 NLP 得到的内容画像为基础，以item 对应分类/主题/关键词的权重建立召回，依据用户画像的相应权重和内容画像的距离排序召回。召回过程如下：

1.3. 基于用户群

其实这种策略也是协同过滤的概念，当用户的粒度扩大时，可以为处于某一群体内的单个用户在兴趣范围内带来更多样的阅读内容，在一定程度上也是一种兴趣探索。

首先我们需要对用户分群，这里我们采用的是用户画像中的 topic 兴趣（2000维），相当于对用户进行了降维。降维的方法有很多，包括 autoencoder 等深度学习方法都可以尝试。不仅仅是用户的文本兴趣，用户的人口属性、阅读记录、社交关系等等都可以拼接进来，最终的目的都是将用户 embedding 成一个向量。

完成了用户的向量化之后，接下来就是聚类了，传统的 K-means 基本可以胜任大部分场景。如果需要多分类或者体现层级关系的话，GMM和层次聚类的算法也可以做一些尝试。

最终我们聚出一批类簇，根据类簇内对不同内容的相对点击率（文章i在类簇a中点击率/文章i在所有类簇中平均点击率）排序，对类簇用户进行推荐。另外，也可以根据类簇中用户的倾向主题，给类簇打上解释性label，作为露出。

2. 倒排链

前文中，我们提到内容数据入库时的结构是 itemID - detail 这种形式。而在召回过程中，我们要用到内容画像中的分类、主题等属性，若要通过遍历 itemID 然后计算相似度无疑是不现实的。于是这里我们用到搜索引擎中一个常用的技术——倒排。相较于 itemID - detail 这种形式（我们称之为正排），我们再以 detailX - itemID 的形式建立倒排链，提高召回检索效率。

比如在关键词召回中，我们按如下格式建立倒排表。（这里以 json 格式实例，实际中会采用效率更高的序列化形式）：

{ 
    'tag_1': 
        [ { itemID: '13', weight: 0.7 }, { itemID: '2', weight: 0.53 } ],
    'tag_2': 
        [ { itemID: '1', weight: 0.37 } ],
    ...
}

上述结构中，索引的key是tag的编号，每一个tagID下则对应与之相关的文章摘要（示例中只包括文章ID和tag在此文章中的权重）按相关度排序的数组。随后将倒排链加载到分布式索引里，在拿到用户画像的兴趣tag后，我们根据tagID检索出倒排链，最后再根据倒排链中的itemID去正排里拉取详情即可。

3. 系统架构

有了上述召回的基础，我们便可以初步搭建起推荐系统的架构。完整的推荐系统很庞大、很复杂，基于不同的业务也会有不同的实践方式，这里只谈一些基础的、公用的部分，以作参考。

接入层：接收前端请求的CGI应用，一般处理内容详情拉取、日志上报、各种人工规则干预、去重等任务，计算逻辑简单，I/O密集型任务。这里我们用 Golang 实现，看重他的goroutines处理高并发的能力。

日志采集：消息队列处理前后端的日志上报（点击/曝光/负反馈），采用Kafka，实时打到 Spark Streaming 处理实时数据，同时定期落地到 hdfs 上用以离线处理。

画像计算：用 Spark/Hadoop 按前文所述的方法批量计算长期用户画像，一天计算一次，结果存入 HDFS。

实时画像：采用 Spark Streaming 直接拉取 Kafka 的流实时进行衰减/合并计算，结果写入到 Redis，供线上使用。因为我们每天还会计算一次长期画像，因此短期画像只用保存一天即可。

召回索引：离线更新召回倒排表，定期刷新至线上召回集群的内存里，以加快检索速度。另外在召回模块中，还需要实现诸如截断、过滤等算子，用以在召回的过程中快速过滤曝光内容，截取topN的文章摘要等。

按照上述架构搭建起来后的系统投入到线上使用，QPS在单机1k左右，在召回和接入上还有一些待优化的地方。最终的信息流中，我们从个性化的多路召回中拿到了一批内容，最后根据文章质量（点击量/点击率/阅读时长）统一排序，输出到用户侧，完成推荐。这样，一个推荐系统的完整流程便完成了。