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

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

转转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，通过血统分析，可以快速定位推荐策略的来源，便于定位。