注:下面所述文字均仅包含个人的一些实践经验总结,出于隐私保护需要隐去相关具体信息。
背景
对某社区内容进行智能推荐,平台包括app内嵌端,web端,移动端,作品类型包括文字,图片,视频,涵盖不同细分场景。如果按照传统离线推荐方式在每种场景下给出推荐列表,开发量和存储量将比较大,在人力和时间有限的情况下考虑实时推荐处理,即采用“实时条件过滤+排序”的方式给出最终推荐结果。
要解决的问题
- 头部内容过度曝光,长尾优质内容曝光不足
- 未能适应玩家的个性化需求
推荐的考量因素
- 作品曝光引入时间衰减权重,避免头部作品持续霸榜
- 长尾优质作品,新作品提升曝光机会(总热度,实时计算热度上升速度)
- 用户兴趣匹配(兴趣标签,协同过滤)
- 风险内容的识别和剔除(关键词,运营,算法识别)
- 关注作者、好友、同家族成员发表作品增加曝光
- 优质作者和原创作品的曝光支持
- 作品冷启动机制
评价指标
- 内容侧:分发覆盖率、头部内容的集中度
- 用户侧:点击、点赞、评论、分享、收藏、关注、发帖、浏览时长
方案简介
1.ES内容库维护:用户发布/删除/修改内容记录实时更新到ES库,用于检索。
2.Redis用户兴趣标签,历史访问记录,热门内容,关注人列表维护:根据用户内容交互日志计算出对内容形式,标签的偏好,关注人列表,每日更新存储到Redis。
3.Hive协同过滤内容召回:利用分布式计算利用用户内容交互记录生成相似度列表并且存储到Redis。
4.实时推荐结果生成(召回和排序):当服务端发起请求,根据用户id去Redis获取相应数据进行召回和排序,召回即根据用户所在入口或玩家标签的不同进行多路召回(兴趣标签,关注者,协同过滤,热门作品,冷启动作品等),圈出一批候选内容;排序即对召回的内容,根据玩家特征,内容特征,交叉特征训练点击率模型排序,最后返回推荐结果。
作品实时召回框架
推荐内容合法性校验
服务端接收到推送后,需要对推送的类容进行合法性验证,保证下述情况发生时网页端有兜底逻辑:
- 返回数据不合规:包括格式异常,推荐结果数量超过设定值,返回结果为空,返回内容Id非法等
- 访问接口失败:包括服务器内部异常,计算超时,访问超时等
QA
- 常规测试:参数正确时有返回/返回结果格式正确/边界值测试/空值测试/异常参数报警/真实玩家id/缺少部分离线特征/虚拟玩家id/兜底措施确认
- 功能测试:只有协同/只有关注/只有热门/只有标签/没有标签召回有其他召回的id/没有关注召回有其他召回的id/没有协同过滤召回有其他召回的id/只有关注和标签/只有关注和协同/只有协同和标签
- 压测:响应延迟和结果正确性校验
后续迭代的方向
- 多目标优化,后面会参考[1,2]对算法进行迭代
- 信息含量较少的作品下沉,比如自拍,无意义的文字较多的作品
- 文本分类给作品打标记等
一些实践经验复盘
- 前期明确需求,设计好各类数据格式,方案设计时尽量考虑迁移性和扩展性,便于后面迁移到不同场景
- QPS较大时,访问接口超时可能会出现服务端请求积压的情况,更为保险的措施是异步拉取,同时服务端也可以做一些削峰策略;同时也可以考虑将多次请求打包,将推荐结果按批次返回,减少线程的创建
[1] 多目标学习在推荐系统中的应用 多目标学习在推荐系统中的应用 - 知乎
[2] 微信「看一看」 推荐排序技术揭秘 微信「看一看」 推荐排序技术揭秘 | 机器之心