社区内容智能推荐项目实践复盘

注：下面所述文字均仅包含个人的一些实践经验总结，出于隐私保护需要隐去相关具体信息。

 

背景

最近对某社区进行内容智能分发算法的开发，平台包括app内嵌端，web端，移动端，社区内容包括文字，图片，视频，下面还有很多细分场景。如果按照传统离线推荐方式在每种场景下给出推荐列表，开发量和存储量将比较大，在人力和时间有限的情况下考虑实时推荐处理，即采用“实时条件过滤+排序”的方式给出最终推荐结果。

 

方案简介

1.ES内容库维护：用户发布/删除/修改内容记录实时更新到ES库，用于检索。

2.Redis用户兴趣标签，历史访问记录，热门内容，关注人列表维护：根据用户内容交互日志计算出对内容形式，标签的偏好，关注人列表，每日更新存储到Redis。

3.Hive协同过滤内容召回：利用分布式计算利用用户内容交互记录生成相似度列表并且存储到Redis。

4.实时推荐结果生成（召回和排序）：当服务端发起请求，根据用户id去Redis获取相应数据进行召回和排序，召回即根据用户所在入口或玩家标签的不同进行多路召回（兴趣标签，关注者，协同过滤，热门作品，冷启动作品保护机制），圈出一批候选内容；排序即对召回的内容，根据玩家特征，内容特征，交叉特征训练点击率模型排序，最后返回推荐结果。

 

 

推荐内容合法性校验

服务端接收到推送后，需要对推送的类容进行合法性验证，保证下述情况发生时网页端有兜底逻辑：
返回数据不合规（包括格式异常，推荐结果数量超过设定值，返回结果为空，返回内容Id非法等），访问接口失败（包括推荐服务器内部异常，推荐服务计算超时，服务器访问推荐服务超时等）

 

QA

1.常规测试：参数正确时有返回/返回结果格式正确/边界值测试/空值测试/异常参数报警/真实玩家id/缺少部分离线特征/虚拟玩家id/兜底措施确认

2.功能测试：只有协同/只有关注/只有热门/只有标签/没有标签召回有其他召回的id/没有关注召回有其他召回的id/没有协同过滤召回有其他召回的id/只有关注和标签/只有关注和协同/只有协同和标签

3.压测：响应延迟和结果正确性校验

 

后续迭代的方向

社区运营的最终目的是提升社区的繁荣度，繁荣度从内容消费者角度来说包括点击，点赞，评论，分享，收藏内容，从内容生产者角度来说是发布，修改内容，因此算法理想效果是提升上面所有的指标而不是单一指标，目前业界比较常见的做法有多目标优化，多模型分数融合，多任务学习等，后面会参考[1,2]对算法进行迭代。

 

[1] 多目标学习在推荐系统中的应用 https://zhuanlan.zhihu.com/p/268359893

[2] 微信「看一看」 推荐排序技术揭秘 https://www.jiqizhixin.com/articles/2020-07-21-16