混合推荐系统介绍

当前推荐系统的问题

1. 冷启动问题
2. 数据稀疏性问题
3. 头部效应
   头部”标的物“被越来越多的用户”消费“，而质量好的长尾”标的物“由于用户行为较少，自身描述信息不足而得不到足够的关注
4. 佛系人群问题
   是指某些用户的倾向性和偏好不太明显，比较散乱，没有表现出对具备某些特征的标的物强烈的偏好。因此在协同过滤推荐算法中(拿基于用户的协同过滤来说)，这种偏好性不强的用户跟其他用户的相似度都差不多，选择不同的相似用户没啥差别，因此推荐效果不是特别好。这种问题，在多用户使用同一个设备时是非常明显的(比如家庭中的智能电视，一家人都用同一个电视在不同时段看自己喜欢的内容，导致该电视上的行为比较宽泛，无任何特性)。
5. 重复推荐
   推荐系统可能会推荐非常相关的标的物给用户，但对用户来说，这些相关的标的物是重复的、无价值的。在新闻资讯、短视频类APP的推荐中这种情况是经常发生的。
6. 不能察觉兴趣变化了
   该问题指的是当用户的兴趣稳定下来后，(推荐)系统很难改变对用户的认知，即使用户兴趣最近变化了，推荐系统还是保留了用户过往的兴趣，除非当用户新兴趣积累到足够多，所起的作用完全盖过了老的兴趣。一般解决该问题的思路可以对用户兴趣进行时间衰减操作，最近行为权重更大，越久远的行为权重越小。

工程实践

每一种召回策略可以看成是一个推荐算法，不同召回算法的结果进行合并，混合后的推荐结果作为数据输入给后续的排序推荐算法阶段进行进一步精细化处理。
在排序阶段，对召回阶段多种召回算法混合后的推荐结果进行精细排序，因此从召回到排序这两个阶段的pipeline就是前面提到的级联混合推荐(也就是前面提到的第六种混合推荐算法)策略。

在业务调控阶段，会根据业务规则及运营需求，对排序阶段的推荐结果进行调整，可能会调整顺序，插入需要强运营的标的物，插入广告等。这一阶段的处理是比较偏业务的，不同行业和运营策略所做的处理会很不一样，这一块可能会更多偏规则。从排序到业务调控这两个阶段的pipeline没有被前面提到的7种混合推荐算法覆盖，算是在真实业务场景下对上述混合推荐算法的一种补充和完善。

实时推荐系统与混合推荐

实时个性化推荐基于用户最近的行为近实时更新用户的推荐列表，对计算能力、算法、服务响应等都有极高的要求。从用户最近的行为获得用户短期偏好，这算是一种推荐算法，将短期偏好获得的推荐结果与原来T+1推荐结果融合推荐给用户也是一种算法的混合，一般可以采用加权的混合方式，最粗暴的方式是将短期偏好推荐结果置于最高的权重，直接放在推荐列表最前面

深度学习等复杂推荐模型整合多数据源

深度学习可以将多种数据整合到一个模型/框架中，获得非常好的推荐效果(如2016年YouTube的深度学习推荐系统，可以非常容易整合多种信息进行统一学习，见参考文献7)。深度学习模型这种具备整合用户行为数据、标的物metadata数据、用户画像数据等数据的能力，是非常有优势的，相当于将协同过滤、基于内容的推荐等多种算法的能力融合到一个模型中，虽然不是直接将多个模型融合，不在第三部分7大混合推荐方式之列，但这也算是一种多数据源能力的融合，通过整个多数据源获得比古典的单个推荐模型更好的效果。

特殊情况下的处理策略

推荐系统属于互联网软件服务，任何软件服务都存在不确定性，因而会存在一定概率出现问题，对推荐系统也不例外。当由于网络故障或者服务故障导致推荐服务不可用时，如果在客户端(即APP上)不做异常保护和处理，用户访问推荐服务时，会超时，导致无任何推荐结果返回，整个UI展示都将出问题，出现开天窗的现象，这时就需要前端做保护，在极端情况出现时，给出一组备选方案展示出来，这样虽然推荐的结果不会那么精准，但不至于什么结果都没有，明显可以提升用户体验。

推荐数量不足的增补

在真实工业级推荐场景中，最终的推荐算法一般会给出固定数量的推荐结果(比如50个，但是在前端可能只展现30个)，由于标的物会出现下线、不可用(视频下线、商品下架等)等情况，当用户在客户端请求推荐服务时，推荐接口先获取推荐列表(一般是一组标的物的id)，再根据列表的id获得标的物的metadata信息，填充完整后返回前端并展示给用户，这个过程中会对标的物id进行过滤和检查，如果下线了或者不可用了会剔除掉。如果某个用户的推荐列表下线的标的物比较多(这种情况出现的概率一般不大)，导致最终数量不够前端展现时，一般会采用补足的策略，比如利用热门推荐的结果填补不足的数量，最终获得规定好的数量(如前面提到的50个)，这个利用另外一个推荐算法(如热门推荐)来填补的策略就是掺杂混合策略(第三节的第3个混合推荐策略)

通过混合策略解决用户冷启动