荔枝推荐系统实时推荐架构演进
荔枝推荐系统实时召回引擎升级
问题背景
-
用户体验问题，由于离线推荐性能问题，离线推荐大部分引擎只计算昨天活跃用户，当用户较前几天活跃时候，当用户打开app,触发拿到的推荐数据其实是比较老旧的；
-
离线推荐存量问题，在feed架构存储的数据也有比较多，原有设计都是为了避免离线推荐数据消费完无数据可推荐，但这个对于业务的调整都没感知，比如内容敏感下架，用户兴趣变化；
-
推荐数据不足，离线推荐的数据会很快受到用户的刷新过量快速消费完，导致召回源数据不足，多样性不够，需要补充引擎；
-
推荐池流动，后续需要快速让推荐池内容流动起来，现在拿到的推荐数据不在推荐池了；
-
除了离线推荐还有准实时推荐，这个设计 也是为了能快速响应用户的消费推荐，以免离线推荐快速消费完。但这个如果能即时推荐，可以两块更完美解决，将异步计算更多压在串行计算，需要解决性能问题；
-
由于没有高度抽象召回方式 ，策略平台上需要开发比较多的组件才能满足个性化召回；
-
当天用户没上来，则没有浪费计算，这是离线推荐弊端
挑战
-
性能，逻辑会全压在召回服务上；
-
如何做到通用化；
-
个性化过滤的问题处理，如用户已播放，已下发，已曝光；
目标
-
减少接口开发工作，提高算法与后端工程师对接效率
-
支持实时推荐架构
需求拆解问题：
-
不同业务场景，各自实现召回引擎模型，对应模型存储、文件格式有很多种
-
重复开发，对接效率较慢，管理麻烦，不同开发风格性能也有风险问题
-
实时推荐诉求
解决方案--统一召回框架
-
定义标准，主要的几种算法生成模型格式，线上服务引擎使用格式，接口标准；
-
召回底层引擎解决方案，支持多种通用召回模型类型，提供在线计算能力
-
模型发布，模型管理服务化，打通模型平台
-
打通机器学习平台、推荐策略平台，组件模块通用化
召回引擎，高度抽象后变为下面几种：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-->向量召回检索—》过滤—》粗排序
旧信息流推荐架构大致图如下：
调整后实时推荐架构图
本文地址：https://blog.csdn.net/duck_genuine/article/details/108781011