转转推荐系统架构演进之路

推荐在今天互联网产品,特别是电商产品中被广泛使用。在转转这样一个二手交易平台下,一个好的推荐系统能够帮助买家发现对自己有价值的商品,也能让商品尽可能多的展现在对它感兴趣的用户面前,达到买家与卖家的双赢。

转转APP上线于2016年11月12日,在这1年多的时间里,推荐系统也日渐完善,本文着重讲述转转推荐系统的架构演进之路。

1. 诞生

推荐功能是随着APP第一版就存在的功能,当时的首要工作是快速实现首页展示商品列表的功能,并且能够方便的人工干预排序,为此选择了如图所示的方案实现:

这一阶段推荐系统特点:

1. 推荐功能简单,全局推荐,没有个性化。

2. 召回 & 排序逻辑都集中在ElasticSearch,推荐服务逻辑较轻,只负责一些数据去重和数据渲染等功能。

3. 推荐召回 & 排序策略主要由人工来定。

诞生之初的推荐系统虽然非常简陋,但是在设计之初,就预留好人工调整商品特征权重的功能,产品同学可以快速的调整推荐排序策略来达到“人工智能”的效果,前期也能较好的满足业务需求。

2. 成长

随着转转平台中商品不断增多,用户面临的信息过载也越来越严重,这时人工干预的召回 & 排序策略已经不能满足业务需求,此时的推荐系统架构如下:

优化后推荐系统特点:

1. 尝试加入了个性化因素,上线了用户——商品分类的ALS协同过滤算法

2. 加入abtest分流实验模块,评估线上指标,方便模型调优。

3. 梳理用户行为日志收集流程,能够完整的收集曝光——点击——下单一整条行为链路,也为以后上更复杂的模型做准备。

通过这阶段的努力,协同过滤单策略下CTR提升明显,并且完善了推荐系统的基础设施(abtest、日志收集),同时团队内也有了更多的技术积淀,为下一阶段的爆发做好准备。

3. 爆发

经过类别维度协同过滤应用之后CTR的显著提升,让我们看到了模型相较于人工规则的威力,为了进一步提升推荐效果,我们重构了推荐系统:

在设计这版推荐系统架构时,充分考虑了系统的稳定性、扩展性和易用性,主要体现在:

1. 线上推荐策略插件模块化,拉取配置中心配置之后,通过Java反射生成整套推荐策略pipeline,并且支持策略热更新。

2. 实现服务降级功能,推荐召回策略不可用时,回退到默认托底策略,保证APP端展示正常。

3. 抽象出推荐核心逻辑,作为单独的服务,供不同推荐位使用。

这一版推荐系统功能特点:

1. 接入实时数据,目前主要是实时用户行为。

2. 提升推荐策略覆盖度,由原来的基于用户ID推荐,转为基于设备token的推荐,并增加Token Mapping。

3. 粒度更细的个性化,由原来商品分类粒度变为商品粒度。

4. 多种召回策略融合:用户行为相似度召回,用户性别、兴趣率、LDA主题模型召回。

5. 记录完整的商品血统,便于追踪推荐结果,给出推荐解释。

新版推荐系统上线以后,模块化的设计很好的支持了策略优化迭代,经过多个版本的策略优化,转转APP首页推荐CTR以及CVR较上一阶段提升非常明显,并且快速地上线了单品页看了又看推荐和个性化push。

4. 总结&展望

推荐系统未来改进方向大致如下:

1. 加入机器学习排序。目前部分召回策略融合策略还是人为设定的规则,存在较大局限性。

2. 利用知识图谱等结构化数据,增加基于商品知识图谱的召回策略。

3. 进一步完善实时化数据,商品相似度实时化,用户兴趣实时化等。

通过这一年来的工作,个人也总结出一些经验教训:

1. 整个推荐系统中数据是重中之重,要做好多维度的数据监控,由于推荐数据出问题,可能会导致数据指标缓慢下降,到时候很难排查。

2. 推荐结果要尽可能多的记录血统,保证线上结果的可解释性。面对用户报过来badcase,通过血统分析,可以快速定位推荐策略的来源,便于定位。

原文发布于微信公众号 - 架构之美(beautyArch)

原文发表时间:2017-01-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区