学习总结

（1）在sparrow RecSys中使用 Embedding 方法准备好了食材，使用 Redis 把食材下锅，做菜的步骤稍微复杂一点，分为建立候选集、实现召回层、实现排序层这 3 个步骤。最后我们用 HTML+Ajax 的方式把相似电影推荐这盘菜呈现出来。
（2）品菜：针对相似物品推荐这一常见的功能，可以使用人工测试、Ground truth 和商业指标评估这三种方法对得到的结果进行评估。用评估结果指导模型的下一步改进。
（3）参考最后部分的思维导图。

一、清点技能库

1.1 准备食材

即特征工程篇（常用特征：用户行为数据、用户关系数据、属性标签类数据、内容类数据和场景context上下文信息等）的内容，这里用分布式计算平台Spark进行特征处理（Spark的计算过程：Stage内部数据高效并行计算，Stage边界处进行消耗资源的shuffle或者reduce操作），处理的结果是生成embedding（针对序列数据或者图结构数据）

——具体而言：利用物品序列数据，通过 Item2vec 方法训练出 Embedding，也能够使用 Deep Walk 和 Node2vec 把图结构数据生成 Graph Embedding。

1.2 食材下锅

过程有两个：一是把线上推荐所用的特征存储到数据库中，我们用 Redis 作为特征数据库的方法，另一个是把模型部署到模型服务模块（后面用tensorflow serving）。

1.3 做菜技术

推荐服务器线上推荐的整个流程是否合理。那回到推荐系统中就是指，召回层要快速准确，模型排序部分要精确。主要学习了召回层（快速准确地过滤出相关物品，缩小候选集）的三种召回策略，我们后面采用embedding的召回方法——计算物品embedding和用户embedding的相似度进行推荐。

这个相似度的计算单纯用聚类或者kd-tree的索引方法都不太好，所以大佬们提出用局部敏感哈希LSH，即使用分桶策略使得最近邻查找embedding的时间复杂度为常数级别。

1.4 上菜过程

这部分还没学：在 Sparrow Recsys 中，会先利用 JavaScript 异步请求推荐服务 API 获取推荐结果，再利用 JavaScript+HTML 把结果展现给用户”。因为，这一部分内容不是推荐系统的重点，所以我们这里只要做到界面清爽、逻辑清晰就可以了。

二、相似电影推荐功能

图1 Sparrow Recsys 相似电影推荐功能的技术架构图

2.1 数据和模型

（1）考虑到大数据的数据处理与训练的一致性——用spark进行数据处理；用sparkMLlib进行embedding的训练（如deepwalk、item2vec等）。
代码参考：项目中的_com.wzhe.sparrowrecsys.offline.spark.embedding.__Embedding_对象，它定义了所有项目中用到的 Embedding 方法。

【注意】
对于一些比较复杂的 Embedding 方案，比如特征种类很多，网络结构也更多样化的 Embedding 模型，业界也多采用 Spark 进行原始数据处理，生成训练样本后交由 TensorFlow、PyTorch 训练的方案。

（2）需要将生成的embedding存入一个高可用的数据库（我们选用主流的redis），这里的redis是连接线上和线下的关键节点。
代码参考：com.wzhe.sparrowrecsys.offline.spark.embedding.Embedding对象中 trainItem2vec 函数的 Redis 存储操作。

业界也会使用 Cassandra+ 缓存，RocksDB 等不同的存储方案来实现 Embedding 向量的高效读取，但我们现阶段只要学会 Redis 存储和读取操作就够用了。
（3）

2.2 线上服务

经过以下三个主要的线上服务步骤，Sparrow Recsys 就可以向用户返回推荐列表。

（1）候选物品库的建立

Sparrow Recsys 中候选物品库的建立采用了较为简单的方式：直接把 MovieLens 数据集中的物品数据载入到内存中。

但对于业界比较复杂的推荐业务来说，候选集的选取往往是有很多条件的， 比如物品可不可用，有没有过期，有没有其他过滤条件等等，所以，工业级推荐系统往往会通过比较复杂的 SQL 查询，或者 API 查询来获取候选集。

（2）召回层的实现

因为物品的 Embedding 向量已经在离线生成，所以我们可以自然而然的使用 Embedding 召回的方法来完成召回层的实现。同时，Sparrow Recsys 也实现了基于物品 metadata（元信息）的多路召回方法。
代码参照：com.wzhe.sparrowrecsys.online.recprocess.SimilarMovieProcess类中的 multipleRetrievalCandidates 函数和 retrievalCandidatesByEmbedding 函数。

（3）排序层的实现

根据 Embedding 相似度来进行“相似物品推荐”，是深度学习推荐系统最主流的解决方案。可以是余弦相似度，也可以是内积相似度，还可以根据你训练 Embedding 时定义的不同相似度指标来确定。
因为在 Word2vec 中，相似度的定义是内积相似度，所以, 这里我们也采用内积作为相似度的计算方法。

代码参照： com.wzhe.sparrowrecsys.online.recprocess.SimilarMovieProcess类中的 ranker 函数。

2.3 前端

Sparrow Recsys 的前端部分采用了最简单的 HTML+AJAX 请求的方式。

AJAX 的全称是 Asynchronous JavaScript and XML，异步 JavaScript 和 XML 请求。它指的是不刷新整体页面，用 JavaScript 异步请求服务器端，更新页面中部分元素的技术。当前流行的 JavaScript 前端框架 React、Vue 等等也大多是基于 AJAX 来进行数据交互的。

如果已经在本地的 6010 端口运行起了 Sparrow Recsys，那直接点击这个链接：http://localhost:6010/movie.html?movieId=589 ， 就可以看到电影《终结者 2》的详情页面和相似电影推荐结果了。

三、相似电影推荐的结果和初步分析

【注意】
（1）Sparrow Recsys 开源项目中自带的 MovieLens 数据集是经过王喆大佬采样后的缩小集，所以基于这个数据集训练出的模型的准确性和稳定性是比较低的。可以去MovieLens 官网选择 MovieLens 20M Dataset 下载并重新训练，会得到更准确的推荐结果。

3.1 人工测试

主页点击电影看出来的相似推荐效果是否合理。

仅利用基于用户行为序列的 Embedding 方法是很难解决推荐效果不佳的问题。这需要我们引入更多内容型特征进行有针对性的改进，比如电影类型、海报风格，或者在训练中有意减少热门电影的样本权重，增大冷门电影的样本权重等等。总的来说，遇到推荐结果不合理的情况，我们需要做更多的调查研究，发掘这些结果出现的真实原因，才能找到改进方向。

3.2 指定Ground truth

可以指定一些比较权威的验证集。比如，对于相似影片来说，可以利用 IMDB 的 more like this 的结果去做验证我们的相似电影结果。要注意有些 Ground truth 数据集的可用范围，不能随意在商业用途中使用未经许可的数据集。

3.3 利用商业指标进行评估

对于一个商业网站来说，无非是提高点击率，播放量等等。因此，我们完全可以跃过评估相似度这样一个过程，直接去评估它的终极商业指标。举个例子，我们可以通过上线一个新的相似电影模型，让相似电影这个功能模块的点击率提高，假设提高了 5%，那这就是一个成功的模型改进。

四、思维导图

回顾前三章：

4.1 基础架构篇

4.2 特征工程篇

4.3 线上服务篇：

首先是这部分的线上服务基础（高并发三架构机制）、存储模块和召回层的细节。

最后的是线上服务篇的模型服务，后面主要用tensorflow serving：

五、作业

搜《玩具总动员》出现《阿甘正传》等非儿童动画类电影的相似电影推荐，可能是热门电影的头部效应（热门电影其实很容易跟其他大部分电影产生相似性），还有其他可能吗？

【答】
热门特性，可以大概的猜测几点：经典、新颖、价值高、文化核心、受众用户群、时间效应等等。所以召回层的多路召回策略又会衍生出几个问题：
1、如何调整热门推荐与个性化推荐权重。
2、随着时间效应消失，热门度对个体对用户群又是怎么影响的，又如何实现精准的推荐呢？
3、推荐系统针对个人与用户群场景如何切换？

【其他可能】
（1）比如有些人的兴趣就是看热门影片。 只要在最后在排序的时候，过滤掉用户已经看过，和推荐过n次依然没有看的（说明不感兴趣），这样的推荐应该很make sense。评价系统好不好的终极标准是观看时间和点击率，而且一般人的直觉感觉推荐热门电影的点击率就会比其他的高。
（2）有的时候潜在的数据pattern我们不一定都能解释的了，但是模型能够学到这些pattern。如《玩具总动员》有些成年人也喜欢看hhh。

【Embedding 方法上的改进建议】
1、Attention机制的Embedding算法
2、类别标签TF-CR权重计算等 。
3、也可以通过改变node2vec的随机游走概率调整【结构性】和【同质性】。
4、最后，具体问题具体分析，请结合业务改进推荐系统，又如短视频推荐：停留时间、点击率、点赞数、点击转化率等作为热门评估指标。
【其他改进】
1、重排层的策略性方法：在推荐最终展示前在加一层简单的规则过滤，例如利用电影类别把非儿童的电影剔除掉。

六、课后答疑

（1）在小视频行业，基于CTR或播放量的商业逻辑进行推荐策略的调整，在实际过程中往往会变成大量推荐低俗、擦边内容，短期各个指标会上涨，但从长远来看，其实是损害了整个商业收益。所以在短视频一般会以播放时长ts做为商业指标。

【答】CTR对一些标题党、低俗预览图之类的确实有偏好。也可以在正样本的定义上下功夫，把真正播放超过一定时长的作为正样本，算是可以在CTR模型的框架上继续做改进。

（2）线上服务建立候选集的时候，文章里面提到利用sql等方式进行查询，这样的话对于大量物品会不会有耗时问题，真实环境一般是怎么处理的？

【答】基于传统数据库的sql方式当然是比较老式的方式。一般来说会建立一个candidate retrieval api来处理这个事情，这个api内部可以通过预处理，内存数据库，提前load等不同的方式来把candidate提前处理好。

Reference

（1）https://github.com/wzhe06/Reco-papers
（2）《深度学习推荐系统实战》，王喆