构建个性化推荐--工程方向
构建个性化推荐–工程方向
本篇文章主要面向推荐系统工程方向的介绍，而非算法相关的知识。
1 个性化推荐的演进
我算是有着做个性化推荐一路从0到1的经历的，简单分享一下我所经历的演进过程。
定义排序和筛选条件的推荐
算是个性化推荐最初始的雏形，那时候在做APP首页改版的时候，接到了这项需求。
首先让用户自主选择喜好的方向，解决一部分冷启动的问题。
然后根据PD定义的排序规则（什么时间啊，级别啊之类的）和筛选条件（主要来自于用户选择的标签）直接查库就好了，因为每个用户的标签或多或少有些不一样，算是有了一点个性化的影子了。
优点：做的快，说白了就是条SQL，实现很简单。
缺点：效果当然就不会那么好了，比如说，有很多人，他是不选标签的，那个性化就不存在了。
加入用户标签的推荐
为了解决不选标签的这些人，那就要想办法从用户的行为中推测出用户的标签。
因此我们要记录用户的行为事件，正好上一次APP改版的时候，相关事件的埋点已经记录下来了。
但是由于技术能力还不够，由行为推测标签还是靠分析师和PD设计具体的分类规则，进行计算用户标签的。并且，计算标签也是T+1，跑离线任务，而不是进实时计算。
优点：对于我们服务端人员来讲，只要改一下筛选条件就好了，埋点和计算任务是客户端和数据部门干的，标签规则是PD出的~
缺点：由于规则全靠人设定，所以，推测出的标签对于一部分人来讲会不够准确，并且有T+1的延迟，对新用户来讲不够友好。
多路召回推荐
多路召唤，其实就是多种推荐策略融合在一起使用的意思。
在上一阶段推荐中，只具有单一的策略，一旦规则本身出了问题那就全出错了，所以引入多种推荐策略，来增加容错率，提升推荐效果。
比方说，我之前做的有四种策略：用户行为事件计算出的标签、近期浏览过的标签（按照频次和时间进行评分）、优质用户发布的作品池（点赞量进行评分）、用户所关注的用户发布的作品（按照发布时间进行评分）。
由于引入了多种策略，并且每种策略的查询其实是有很大区别的，所以要最终对多种策略返回的结果进行融合再排序。
优点：多种策略混合评分，即使单一策略的失败，也不会显著的影响到整体的推荐效果，并且在多种场景下，都能有比较好的表现。
缺点：系统的复杂度会陡然上升，实现起来会困难很多，包括测试和后期的推荐效果评测都增加了很大的困难度。
2 推荐平台的设计
当推荐演化到了多路召回的时候，其实整个推荐流程下来要处理的事项就已经很多了，特别是，现在APP内都是多场景的推荐。
什么是多场景？比方说天猫里，首页的推荐和商品详情页的推荐策略是有所不同的，这就是场景的划分。这就会更加增加了系统的复杂程度，如果还是像一开始那样，每种场景一路码到底，会给后期的维护工作增加了很大的成本。
因此，我花了很多业余时间，将推荐的应用进行重构了好几次，算是达到了我比较满意的一个程度。
首先推荐流程整体如下
其中，灰色部分为未实现的功能，做实时标签的话，还要搞实时计算，等有时间的话我搭一下。
淡黄色部分为推荐的扩展点，业务端可以在调用推荐平台的接口时，传入额外的用户数据或者对返回的推荐列表进行进一步的操作。
浅绿色的推荐策略层目前不支持业务端扩展，而是由推荐平台自行维护，业务端只需能够选用推荐策略就好了。并且，如果以后发展的好，引入了机器学习、深度学习等算法，只需更换策略层即可。
从目前的实际效果来看，如果只是新增推荐场景，可以在极快的时间内，完成业务迭代，并且基本不需额外的测试工作。
3 推荐效果评测
其实，做到多路召回的时候，就应该引入AB测试等经典的推荐评测了。因为做到了多路召回这一步，包括开发人员对系统返回的推荐列表都比较困难的能做成预测了，更不用说之后如果接入了深度学习之类的，推荐的列表对于自己人来说更是个黑盒了。
所以尽可能的在推荐迭代中把AB用户分群的功能考虑进去，因为很有可能经过了很漫长的一次迭代后，发现效果还不如之前的推荐效果。
这里分享一下我目前用到的推荐效果指标数据，供大家参考
线上效果指标：
召回率 = 用户收到的推荐节目总数 / 推荐总节目
准确率 = 用户产生行为的推荐节目 / 用户收到的推荐节目总数
推荐平均停留时间 = 用户在节目详情页（来自推荐）的停留时间 / 用户点击的节目（来自推荐）总数
我这里这些名词的定义和其他人的理解会稍有偏差，但是我想不出来有更好的词汇来表述，我先解释一下
召回率反映了用户对推荐的使用程度，召回率越高，说明用户对推荐功能使用程度越高。
而准确率具体反映了用户对推荐列表感兴趣的程度，准确率越高，说明推荐的效果就越好。
但是并不是每个人都能够有有效的反馈，所以引入了推荐平均停留时间，来侧面反映推荐效果。
