概述

从18年11月开始，接触推荐系统半年左右时间，对推荐系统有了基本的认识。相比于之前做的nlp任务，推荐系统复杂更多，数据来源更复杂、pipeline更复杂、场景更复杂、业务更复杂、指标更复杂。在NLP部分的时候，绝大多数时间花在了数据-模型以及其match上。而在推荐里由于系统复杂度提升，多了更多的功夫在系统架构、代码重构、快速部署上，工程侧的东西在复杂系统中显得更为重要。秉着精益算法的思想，延续之前的系列，这里我结合自己的经验，给大家分享下如何快速的搭建一个不错baseline的推荐系统。请各位吸取精华、去其糟柏即可。

问题描述

• 今日主角：电商推荐系统
• 问题定义：为用户提供其最有可能产生交互的商品（点击、购买、分享）
• 问题举例：
  • 活动页场景：淘宝、京东各电商首页、各个活动界面的商品推荐
  • 购物中后置链路：购物车商品推荐、订单页商品推荐

技术价值：作为电商主要的业务场景，通过算法实现千人千面，由货找人，最大化商业指标

推荐pipeline

据我说知，电商推荐系统大的框架如下，为了方便说明问题，我画了个图来解释下。

1. trigger:触发阶段，该阶段是推荐的源头，可以是用户历史浏览商品、用户偏好。通常这些数据直接从日志获取，加以简单处理。
2. match:召回阶段，通过触发器，我们拿到一些商品或者触发源（类目、品牌）后，我们去关联一些商品。这里比较重要的一部分就是通过商品-商品的关联。也就是推荐里面协同过滤发挥作用的地方。
3. rank:排序阶段，召回后的商品量很大，我们可以通过一些ctr(点击率)、cvr(转化率)模型对topN进行精细化排序。

4. rerank：重排序，多为全局性考虑，需要对结果再次排序。比如类目打散、品牌打散，所以很多时候也叫打散阶段。

   
   推荐pipeline

好叻，根据上图简单介绍下推荐流程：

• trigger: 一个用户浏览一件连衣裙。
• match:看了这件连衣裙的用户也看了很多别的连衣裙。
• rank:对关联出来的n件商品进行点击率预估，此处加入个性化。
• rerank:对时间因素、品牌因素进行一些大散，避免品牌过于集中等。

推荐pipeline的思考

这里针对每个阶段进行一个细节讲解，指出个人觉得重要的地方。

思考1：关于trigger选取

• 电商场景中trigger的时效性很重要，用户越近操作的商品对于商业指标越好。
• trigger多样性很重要，多路trigger能提升丰富度。
• trigger中重点关注用户直接操作过的商品。

思考2：关于是否需要trigger

• 向量化的思路席卷各个领域，user-vector item-vector的匹配可以替换现有的trigger+协同过滤的方案。该方案目前没有进行尝试，不确实是否是个比较好的baseline，一方面vector的graph embedding不一定能训练出来，中间不可控因素较多，在初期建议以可控的方式去搭建系统。
• 全向量化无疑是个值得探索的路子，更优雅。据说效果也更好，后续有积累后再分享。

思考3：协同过滤user to item VS item to item

• 电商场景item to item可能更为合适：商品变化小、用户变化快；item-item比user to item的结果上兴趣度更集中；

思考4：协同过滤的优劣

• 协同过滤是推荐的老姜了，协同的效果也非常ok,比内容匹配的指标要好很多。协同的力量是强大的。
• 劣势一般都来自冷启动，所以一定要搭配内容匹配去辅助冷启动。
• 匹配能力：深度学习来后，很多会进行高阶匹配，相比之下协同过滤也是有劣势的，不过这里很细了，不多说，更多会在rank做这部分改进。

思考5：rank VS match

• match和rank都有打分功能，为什么要单独弄rank，大部分原因还是来自复杂度，如果复杂度允许的情况下，当然全局打分最好了。目前阿里在这个上面有出文章 任意深度学习+树状全库检索。
• 通常match量比较大，进行一个粗略的打分，然后对较为匹配的商品再给rank精细打分。

思考6：rank 模型

• 关于模型，这可以单开一篇了，这里以wdl做baseline即可。
• 做ctr、cvr的话ESMM是一个非常好的通用架构，个人觉得该模型泛化能力强，可以尽早入手。
• 关于深度模型：DeepFM DCN DIN DIEN 这里模型太多，需要积累一段时间后才需要在rank阶段深耕，前期没必要在这里投入太多。

思考7：rerank VS rank

• 打散阶段更多是一个全局的考虑，目前的rank模型都是单个打分，没有全局打分的，全局信息目前来看包括时效性、兴趣集中度、业务逻辑等。
• 现在有些研究直接对序列进行打分，主要问题还在复杂度上，目前没有看到特别好的案例，所以基本还是分开这两个步骤，理论上可以统一的吧。

推荐业务思考

思考1：推荐场景差异度巨大

• 推荐活动场景、购物前置链路、购物后置链路差异巨大，需要差异化对待。
• 购物前置链路可能逛的需求更高，后置链路买的需求更高。
• 应该为每个场景培养用户心智，而不是大一统模型。

思考2：如何发现迭代点

• 任何看上去不合理的地方都是优化点，能做到像阿里这样的不多，很多公司的推荐、搜索仔细看都是能看出问题的，这里就是迭代点。

思考3：迭代流程

• 发现一个迭代点，找到可能有增益的地方，如果可以的话，事先评估下收益。
• 开发，评估，验证和思路是否不符。
• 如果没有提升：当所有可被证明的思路被证明后，仍然无提升，可以终止本次迭代，得出结论。
• 通常对一个不合理的地方进行迭代，都是可以有提升的，不要轻易放弃。

推荐系统思考

思考1：数据很重要，数据很重要，数据很重要！！！

• 同样是数据，相比于NLP中的数据，推荐的数据来源很杂，可控度不是那么高，里面噪声多，需要更细的去查，在做任何模型的时候要全面检查数据各个指标。分布是否合理，数值范围，默认值，数据规模，数据源，是否重复等。走模型前对数据一定要心里有数。

思考2：探案一样进行探索

• 一个迭代动作做完之后，如果没有效果或者负向效果，仔细去对比每个步骤，找到可以说服自己的理由。如果找不到就更细化的去分析，分用户，分不同trigger去分析。就像探案一样，推荐很多时候解释性还是非常强的，环环相扣，不要因为系统复杂有蒙混的心理。解释不通的地方通常可能会有惊喜。

思考3：快速部署

• 推荐系统比较复杂，搭建更快的部署方案能让开发时间大大缩减。把系统做好后，算法同学更好的集中精力处理问题，而不是花费大量的时间在部署上。

思考4：关于深度学习

• 做好wdl可能对于很多场景来说已经够了。做好细节可能比搞个高大上的模型有效的多，系统初期不建议花很多时间追高大尚的模型。

思考5：关于离线评估

• 推荐很多时候是做ctr、cvr等指标。所以线下不好评估。但是找到一个合适的指标非常重要。比如auc、gauc（按用户级别平均）、xgboost里面的特征重要性。比如常用的AUC可能就不是个好指标，因为用户等级不同，点击率分布就不同，随便一个模型就能把auc提升，但平均auc则不尽然。所以一个合适的离线指标很重要。有的时候需要和线上多次对比才能找到一个合适的指标。

思考6：推荐系统高性价比部分

• 复用组件：组件化能方便开发。
• AB测试：有效的线上测试是迭代的基础。
• 监控：对核心指标监控能让我们及时发现问题。