开发者学堂课程【跟阿里云技术专家学习智能推荐系统： 推荐系统线上服务编排】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/662/detail/11077
推荐系统线上服务编排
内容介绍：
一、在线推理服务-架构说明
二、线上多目标问题
一、在线推理服务-架构说明
1、业务场景
客户业务潮汐效应很明显，业务高峰基本集中在中午和晚上。
2、方案
基于高扩展弹性业务场景，采用阿里云 ACK 构建整体推理架构。
3、调用流程
l 多路召回:物品协同过滤，语义召回，热门及运营策略召回取回上千条候选集。
l 曝光去重:基于该用户阅读历史，去掉已经曝光内容，去掉基于运营策略不能推荐的内容（敏感内容)。
l 排序:推理模块调用排序过程时根据用户 id 及物料 id，获取用户特征及物料特征( Redis)后，分批调用 PAT-EAS 服务返回排序结果。
用户的业务场景特别是互联网的推荐业务，通常都是这样的：
它的用户高峰基本上会集中在中午和晚上，与 APP 的属性相关，但有些 APP 也可以在早高峰出现使用高峰，这个时候为了减少资源的消耗，就需要利用弹性资源机制。
如果没有弹性资源机制，高峰时期可能需要十台机器，而在低谷可能只需要一台机器，但是必须要购买十台机器才能满足服务高峰的需求。
使用了云服务之后，就可以把这套推荐架构做的弹性，比如现在流行的这套框架，可以做到中午高峰的时候使用十台机器低谷的时候只用一台机器，这样的话相比于一直使用十台机器会节约很多成本，所以在服务编排阶段通常会采用云上系统去完成，保证业务的潮汐效应。
另外需要解决的问题是将召回和排序的流程进行起来，在 KBS 服务中用户首先要进行召回线路，而召回模块可以使用多种算法进行。用户进来之后要把他的 ID 以及他对应的 feature 取出来，可以从 MySQL 数据中取出，这样取出的性能比较差，而通过内存存储的 redis 取出的性能就比较好了，当然性能不同，价格也就不一样了。
把用户的 ID 以及它的特征取出来后，要把他送到 Faiss 中去查，即确定向量特征究竟与哪些商品(Item)相匹配。
但是由于使用的是多路召回，召回的结果可能出现交叉重复，比如推荐商品(Item)给客户的时候，不能连续出现两个一模一样的商品，所以中间要加一个报告去重过滤，通常叫做调动过滤器，过滤掉交叉重复的内容，其作用就是把多个召回的结果中重复的内容去掉；或是把用户之前见过的一些新闻去掉，比如一些新闻昨天刚推荐给了用户，第二天再推荐一模一样的新闻，效果肯定不好，所以通过过滤器可以把过去几周或者几天推荐的内容过滤掉，保留新鲜感。
接下来要把召回结果送到排序的模块，排序报告通常是把模型部署成 ATF，这个时候需要用户的特征和 Item 的特征去拼接成一个样品，每个样品都要进行 K8S 服务，反馈出该用户对于这个 Item 的喜爱程度。
因此可以把所有的 User Item 做一个列表排序，这就最终推荐给用户的结果。上层业务可以根据排序结果去做一个调整，比如今天的业务需要多推送一些视频，少推一些文章，就可以把视频多拿一点出来，文章少拿一点出来；或者说推荐商品时要避免香奈儿和迪奥的包同时出现，此时就要做一些上层业务的过滤等等。
4、在线监控能力
上图显示了排序 PAI—EAS 在推荐服务的在线监控能力，观察该排序模型的水位，进行一个动态的观察，防止 archie 过高或者 PSW 达不到需求。
二、线上多目标问题
方案一∶多模型解决多目标
以文章和视频推荐为例，不仅希望推荐的内容可以被用户点击，还可以让用户进行认真浏览，这样就可以规避一些标题党。
比如有些新闻与视频的标题起的很吸引人，但是内容却是十分浮躁的，没有任何实际意义，用户体验效果也不好，所以最终想要达到的目标是既能让用户对新闻或视频进行点击，又可以对内容进行仔细浏览。
因此整套方案编排的规模就有两种方法，一种是多模型解决目标问题，假设是点击和市场两个目标，可以有一套推荐召回模块，专门针对于点击，另一个专门针对使用市场，把两个结果进行融合最终得到自动推荐的内容。这种方法的代价比较大，需要同时维护两个系统，最后也不好进行量化。
方案二︰合并多目标成单模型
方案二是目前采用比较多，使用效果比较好的一种方案，首先把目标一和目标二进行融合，把目标融合为一个目标，比如把用户点击和观看时长按照比例进行压缩下，再去根据目标去训练模型，最终得到推送结果。方案二的好处是只需要维护一套推荐业务系统，方便维护。
