推荐系统的自我见解

对于推荐系统介绍的文章论文已经有不少，然后大家的关注点基本都是在具体一个点，较少看到有文章对推荐系统做比较全面且粒度比较细的描述文章。其实出现这样的情况也不难理解，推荐系统称之为系统也就可以看到它是由多部分共同构成，要全面且较细粒度的去描述清楚这样一个东西一定是需要足够的篇幅的，并且对于一个系统每家公司的实现还是千差万别的所以也不具参考性。然而差异性中总是有些共性的东西在的，比如推荐系统的流程、组成部件，以及思考怎么去构建怎么样把各种新创新点组装到已有推荐系统升级系统打怪能力的思路应该是有共性的。

下面笔者试着用一个案例来描述推荐系统的构建过程，以及在设计这个系统时要考虑哪些东西，以及我的一些思考和解决方法。更多是从思路上去架构一个推荐系统，这样当读者碰到实际问题时候也可以结合自己情况做思路上的参考。

数据：

1、用户的点击数据：点击跳转列表、点击类别统计数、点击数据关键词、点击信息摘要、点击距离现在时间、n天内点击统计

2、用户的浏览数据：浏览轨迹序列、浏览主题统计数、浏览时长、浏览文章主题、关键词、tag、n天内浏览统计

3、用户的搜索数据：搜索词、搜索词距离现在时间、一个session搜索词序列

4、用户的收藏数据：收藏标题摘要、收藏信息类目统计、收藏后点击阅读数、收藏主题统计分布

5、用户的付费数据：付费内容主题、付费内容关键词tag、付费金额、频度

6、用户的订阅数据：订阅的主题、主题的的描述文本、主题画像、点阅信息阅读情况统计

7、用户的行为跳转数据：一个seesion中用户行为跳转轨迹序列

8、用户画像数据：app安装列表、人口属性（居住地址、年龄、性别、收入）、是否商旅人员

9、商品的描述数据：所属类目（一级、二级、三级）、描述的文本摘要、描述tag关键词、导演、主人公、文字长度、主题

10、商品统计数据：历史曝光数、点击数、转化数

11、商品投放商数据：投放主背景描述、关键词

12、商品评论数据：点赞数、评论条数、评论摘要、评论打分、评论关键词

13、社交数据：好友、相同兴趣人群、活动关系

14、上下文数据：场景（商场、工作地点、家）、时间（是否节假日、白天晚上）、是否有好友在身边

15、app使用频度：使用时长、日使用频次

对于如此多的数据类别要怎么处理成特征放入到模型中使用呢？通过上面的观察其实以上的数据主要分为四大类：数值类、文本类、类别类、序列类、图关系类

数值类：点击内容所属类统计数、浏览主题统计数、收藏主题统计数、付费、订阅统计数、年龄、收入、付费金额、点赞数、打分、商品曝光数、点击数、转化数、点击率、转化率......

类别类：性别、是否有车、是否结婚、是否有房、是否商旅、是否节假日、白天晚上、是否好友在身边、居住省市、内容主题类

文本类：用户搜索词、点击内容摘要、关键词、tag、商品描述摘要、关键词、主人公描述、主题、评论数据、app描述文本、收藏、订阅主题描述文本

序列类：用户点击跳转序列、浏览轨迹序列、seesion中用户行为跳转轨迹序列

图关系：社交关系、活动关系

有如此多种特征该怎么把这些数据给组织起来、用好呢？我的思路是：

1.个数、类目比较固定规则的信息含量高的放浅层

2.数据长度变化的、不规则或信息含量不高的考虑embedding

3.序列数据、图关系可以考虑单独一个模型或embedding

4.数据可以考虑分层并行融合（召回时候用社交关系+主题搜索，排序时候融合行为特征，在线训练模型用用户行为跳转序列、最后排序考虑离线、在线数据融合在一起）

以上数值类、类别类数据基本都可以放到模型浅层部分，因为这部分数据是比较规整，且长度基本是固定的。对于文本类、序列类特征基本是需要embedding处理的，比如：每个人订阅主题个数不一样，描述关键词个数也不一样，也就是这部分数据是变长的直接放到模型里面比较不好处理，我们可以通过订阅主题embedding办法把这部分数据embedding成固定长度特征放到模型就好处理了。序列类数据也是变长的并且对于用户在当前session行为跳转是包含他此刻最真实想法，如果可以通过序列预测出他下一刻想看什么，马上展示出来推给他那用户的体验感会是很好的，即使不能精确猜出他喜欢什么他前一刻看过如果可以把他犹豫不决的商品在最后时候在给他一次曝光远胜于曝光其他商品的转化率；或者也可以把和他当前浏览点击相类似商品推给他，他应该也是不会排斥的。对于社交数据可以自成一个体系做推荐或召回，最好把召回数据融合结合更细粒度用户数据做排序。

召回：

召回已经从单一维度召回——多维度召回——模型召回——线上线下召回——混合召回。

单一维度召回：

基于主题词匹配——用户搜索过的关键词、浏览过信息、电影主人公、导演和用户画像提取主题词，通过主题词搜索商品相关词作召回

基于item base

基于use base

基于社区发现召回——基于社区关系做社区发现，把好友看过内容推荐给自己

基于分fp-growthTree——根据用户看过的内容构建商品篮，推看过还会看的商品

多维度召回：同时考虑以上多种召回，对每种召回策略考虑不同召回权重

模型召回：通过用户画像数据、浏览、点击、收藏......和商品特征数据建模，判断用户会不对喜欢这件商品做召回，融合多种特征且要考虑用户和每种商品相关性计算量大，可以考虑用局部hash算法提升效率

线上线下召回：除了以上用线下特征召回的数据，同时结合用户当先session内生成数据（搜索过的关键词、浏览过内容的关键词、行为跳转序列）即时召回，然后通过排序算法做排序

混合召回：同时考虑多维度召回、模型召回、线上线下召回

召回最难的部分在于怎么去设置每个召回策略该召回多少条数据。

排序：

排序类算法已经有很多论文、博客做介绍。本文不做过多介绍。主要有分为三大类：基于LR为代表的传统机器学习算法及其衍生算法、基于wide&deep的深度学习算法及其衍生算法、在线学习算法。

这边要重点讲下在排序时候要注意的一些事情，怎么样把各种各种文本特征融合、图片特征融合到模型当中。我个人观点是需要做分片，比如浏览数据、收藏数据、搜索数据、订阅数据、付费数据他们之间在模型低层部分应该是要分开，在高维特征上在做融合。序列特征可以尝试用transform模型抽取低纬+高维特征做embedding。

线上模型可以考虑：文本关键词+session跳转transform预测模型效果会比单纯用序列模型做预测更好。

工程：

这部分内容对于推荐系统也是很关键的一部分，因为它直接面对用户。模型在牛逼如果不能在用户可以忍耐的时间窗口内把东西算出来让用户看到，你就失去了和用户交互的一次机会。同时往往越准确意味需要越多的计算，如何在准确和计算量之间做取舍是工程上很重要原则。

1.一般做法是把能先算好的东西先算法用空间换时间，比如先把离线模型的每个用户的召回列表、排序列表算法存在redis里面（只记用户Id，商品id）。

2.尽量把问题解耦可并行化计算，比如在线算法部分关键词抽取、序列预测分模块处理。

3.尽可能把一次请求变成按批请求，比如在线计算更新参数时候，可以按小时来计算；多个用户请求时候，可以分批做在线召回（减少es通讯、降低资源拥塞）

4.提前做数据过滤和剪枝

指标：

指标是个比较抽象和难搞的问题，这边结合我做的一个例子来讲。怎么去抽象一个业务指标，怎么结合指标构成合适数据集。

背景：业务希望我们推出的小说app收入提升

问题分解：

收入=用户数*付费金额

按概率事件来讲，用户越多会付费用户的基数也就越大，也就是我们要尽可能多的给用户推他们喜欢的东西，让存量用户越来越多，同时也会拉来越来越多好友推荐用户

付费金额，用户看的越多，推给他们的东西越喜欢，他们付费可能才会越大

所以以上一个抽象问题就转为一个多问题优化的问题：点击率+用户阅读时长