推荐系统实时推荐架构演进

推荐系统实时召回引擎升级

问题背景 

1. 用户体验问题，由于离线推荐性能问题，离线推荐大部分引擎只计算昨天活跃用户，当用户较前几天活跃时候，当用户打开app,触发拿到的推荐数据其实是比较老旧的；

2. 离线推荐存量问题，在feed架构存储的数据也有比较多，原有设计都是为了避免离线推荐数据消费完无数据可推荐，但这个对于业务的调整都没感知，比如内容敏感下架，用户兴趣变化；

3. 推荐数据不足，离线推荐的数据会很快受到用户的刷新过量快速消费完，导致召回源数据不足，多样性不够，需要补充引擎；目前解决方式是基于sparkstreaming实现的准实时推荐，这个设计也是为了能快速响应用户的消费推荐，以免离线推荐快速消费完。但这个如果能即时推荐，可以两块更完美解决，将异步计算更多压在串行计算，需要解决性能问题；业务逻辑实现也可以统一，方便维护与迭代；

4. 推荐池流动，后续需要快速让推荐池内容流动起来，现在拿到的推荐数据不在推荐池了；

5. 由于没有高度抽象召回方式 ，策略平台上需要开发比较多的组件才能满足个性化召回；

6. 当天用户没上来，则没有浪费计算，这是离线推荐弊端

挑战

1. 性能，逻辑会全压在召回服务上；

2. 如何做到通用化；

3. 个性化过滤的问题处理，如用户已播放，已下发，已曝光；

目标

1. 减少接口开发工作，提高算法与后端工程师对接效率

2. 支持实时推荐架构

需求拆解问题：

1. 不同业务场景，各自实现召回引擎模型，对应模型存储、文件格式有很多种

2. 重复开发，对接效率较慢，管理麻烦，不同开发风格性能也有风险问题

3. 实时推荐诉求

解决方案--统一召回框架

1. 定义标准，主要的几种算法生成模型格式，线上服务引擎使用格式，接口标准；

2. 召回底层引擎解决方案，支持多种通用召回模型类型，提供在线计算能力

3. 模型发布，模型管理服务化，打通模型平台

4. 打通机器学习平台、推荐策略平台，组件模块通用化

召回引擎，高度抽象后变为下面几种：i2i,k2i,向量检索

• K2I:需要全文检索，可以把数据索引到搜索引擎：solrcloud/es/lucene（目前方案问题不大）

        输入：user—》user画像—》取出长期，短期，实时等偏 好 key—>key全文检索召回—》合并所有id集合—》过滤—》粗     排序 如：通过实体召回物品；通过类别召回物品；通过关键词召回物品；通过时间场景召回物品

• I2I ：通过物品与物品的关系 ，输入物品，得到相似的物品，物品间的关系 链可以类似itemcf提前离线计算好，也可以基于关系链计算好，建成边，构成整个图；当输入物品的时候，召回相关物品；这种对于千万级别物品模型，可以考虑使用   kv存储架构，提前将物品对应相似结果串起来，存储到value;  可以使用 redis,hbase，不同模型间，同一模型间的更新需要管理隔离；

       输入：user—》user画像—》取出长期，短期，实时等偏 好idlist—>id召回—》合并所有id集合—》过滤—》粗排序

• 向量召回——可以借助向量检索架构实现，有类似fasis,hndw,milvus专门解决高性能的向量检索方案

        需要实时将用户画像输入到模型生成向量，可以考虑异步准实时方式生成，线上服务时只关注取生成的向量

        输入：user—》user画像—>vector-->向量召回检索—》过滤—》粗排序

 

旧信息流推荐架构大致图如下：主要学习了pinterest的feed流架构

 

 

调整后实时推荐架构图

召回引擎底层框架粗设计图分别如下：（i2i,v2i,k2i)

 

模型服务&过滤服务