课程地址：https://developer.aliyun.com/course/2052

首先给大家分享一下什么是推荐系统，为什么要有推荐系统。伴随着互联网应用的发展，人们可以涉猎到更多的资讯。比如说进入到一个淘宝的平台，有非常多的商品，如何将适合用户的商品去触达他，是淘宝需要解决的一个问题。本质上，推荐系统解决的是一个信息比对的问题。怎么样基于用户的信息和商品的信息去做一个更好的匹配，这是推荐系统要解决的问题。大家平时在用各种手机APP的时候，其实已经对很多的推荐场景或多或少的有些了解。常见的推荐业务场景有两个。一个是基于搜索Query的推荐，还有一个是基于用户和商品属性的Feed流的推荐。

大家看左边这个图，什么叫Query推荐，比如说我搜索一个口罩，它下面展示的肯定都是跟口罩相关的东西。可能有11万多个口罩相关的商品，哪些排在前面，哪些排到后面，这里需要有推荐系统。它需要根据用户的属性，比如说他喜欢的颜色、价格偏好等，来进行排序。如果他喜欢买贵的奢侈品，我肯定把一些贵的、性能好的口罩放在前面。如果他是一个价格敏感的用户，我可能要把价格稍微便宜、性价比高的口罩放在前面。综上，就是说Query推荐要基于用户的购买偏好，还有商品的属性去做一个匹配。

再来看右图，Feed流推荐越来越成为很多APP跟用户交互的主流。打开虎扑、今日头条这样的APP，你会发现首页的新闻都是根据你日常的偏好去推荐的。比如说你喜欢篮球相关的新闻，它可能更多的把体育相关的内容推荐给你。基于用户和商品的Feed流推荐，我们采用机器学习推荐模型，它既要学习用户，也要学习商品的属性。我们今天介绍的推荐系统架构，在用户属性和商品属性的匹配过程中，底层的系统实现，更多的是偏向于基于用户和商品属性的Feed流推荐这样的一个场景。

首先我把整个推荐业务做了一个简图，如下图所示。假设我们有一个新闻平台，用户A进来，它有一个ID。这个平台有成千上万的新闻，我们把它叫item。每个item有一个ID，比如说1、2、3这样排列下去。我们现在要把10万个item中筛选出用户A喜欢的新闻。我们看一下要做这件事，在底层的业务架构要有哪些模块。在一个经典的排序推荐召回系统里，它会有两个模块。第一个叫召回，第二个叫排序。召回模块把这10万个新闻做一个初筛，选出A可能喜欢的，比如说500个item先放到这里，我们只知道A大致会喜欢这500个item，并不知道这500个item哪个是A最喜欢的，哪个是他第二喜欢的。接下来是排序模块，对这500个item做一个排序，按照喜爱的顺序去制定最终投放给A的item的列表。所以在整个的推荐业务中，召回模块更多的是一个初筛，确定一个大体的轮廓和范围。这样的话可以加速排序模块对于每个商品的属性排序，用户得到推荐反馈的效率会更高。一个专业的推荐系统需要在几十毫秒内，即用户一进来就可以给他推荐反馈。对Feed流的内容，用户在网上刷一下屏幕，可能有几十毫秒，然后我们马上要把新推荐的item又展示出来。这是整个推荐业务的逻辑。

推荐系统可以理解为推荐算法和系统工程的总和，即推荐系统=推荐算法+系统工程。关于推荐系统，很多的书和网上的资料更多的是聚焦到这个算法怎么做，包括很多paper都说的是最新的推荐算法。但是，当你真正动手去搭建这套业务系统，特别是在云上去做的时候，你发现其实是一个系统化的工程。即使你知道推荐业务需要用哪些算法，你依然会面临很多问题。比如说性能的问题、数据存储的问题，等等。所以我们这一次分享的重点，把系统工程的问题也给大家阐述出来，既讲算法也讲系统，两者结合就是一个完整的推荐系统。

接下来我们看一下整个的企业级推荐系统架构。设计这样的一个架构，有四个基本要求。第一个要求，目标客户有百万级MAU（monthly active user）的一个推荐业务需求的应用，每一次参与模型训练的时候，整个的训练样本量可能是上亿级别的。需要基于整个平台过去一个月甚至半年的数据做一个整体的建模，因为在机器学习领域数据量越大，模型越精准。数据可以拆分为三种：用户的行为数据、商品的行为数据、用户商品之间的交互数据。第二个要求，它要有算法插件化部署的能力。大家知道机器学习这个领域，包括推荐领域发展特别快，每年都会衍生出一些新的算法。这些算法在整个系统中能不能做到灵活地插拔。比如说今天我用算法A，明天算法B。我可不可以方便的把算法A直接踢掉。这就是你的系统的鲁棒性，包括对于算法组件化支持的能力。我们现在推出的阿里云机器学习平台PAI有这样的一个能力。第三个要求，就是服务的性能问题。你是否可以做到每次请求毫秒级反馈。第四个要求，就是支持资源的弹性拓展。比如说对于一些APP，可能下班的时候大家在地铁上刷得比较多，凌晨大家刷得很少，你的推荐模型底层的使用资源，在用户量大的时候需要更多资源，在凌晨需要更少的资源。为了平衡成本，你能否实现底层资源的灵活拓展性。这个可能适用云上的服务，它的一个优势是资源的弹性。如果搭建一个企业级的推荐系统，一定要满足上述四个基本的要求。

接下来我们重点讲一下推荐的整体架构。如下图所示，最下面就是基础数据层。我们可以看到有用户的画像数据，有物料本身的数据，行为数据，评论数据。用户画像数据可能是用户的身高体重，过去买过的东西，购买偏好，他的学历等等。物料数据就是说物品的价格、颜色、产地。如果是视频的话，视频的内容、标签等等都属于物料本身的数据。行为数据是指用户和物料之间的交互。比如说用户看了一个视频，他点赞，收藏，投币。这些都是用户的行为数据。还有评论数据，第三方数据等等，可能不一定每个平台每个产品都会有。但是基本上这三个数据，user的数据、item的数据、还有behavior的数据是一定要有的。当我们有了这三份数据之后，就会进入到数据加工存储层。在这一层我们会做一些数据加工，比如说把用户的特征加工出来，把物料的特征加工出来，把这个事件的特征加工出来。再往上一层就是基于这些特征去建模。我们刚才介绍了整个的推荐流程包含召回和排序这两个重要的模块。召回模块中，可以有多个算法并行去做。召回完之后你需要排序，也有很多算法，究竟选哪一种算法，后续第三节课再说。接下来，你要有一个新的策略，还不能把推荐结果直接拿到线上，要有一些过滤去重、AB测试、运营策略。比如说我昨天刚推荐给你一个小米手机，然后你就买了。我今天再推荐小米手机肯定是不合适的。最上层就是推荐业务，可以推荐一个广告，可以推荐商品，也可以推荐用户。比如说在社交应用中，可以把用户推荐给用户，让他们互相关注。有了这一整套推荐架构，怎么样让它去符合企业级推荐系统的四个基本要求，需要应用到一些云产品。最常见的做法是，基于云服务、云生态去搭建这些模块。

在阿里云这边的整个的实现方案是这样的。基于PAI的推荐平台，在基础数据层，我们可以提供给你网站的一些离线数据，可以存到RDS::MySQL这样的一个数据库里。线上的一些行为数据，比如说你实时有一些点击，有些关注，你可能想做一些实时的处理。你可以做Kafka。然后到上一层，数据加工层你可以用Flink做一个加工，产生一些实时的行为数据。生成了样本之后，可以发到模型训练层。在模型训练层就会用到PAI的一些算法。最上面应用的时候，为了保证整个服务的弹性，我们推荐通过云原生的方案去做，保证资源的弹性。最终在服务编排阶段，你可以先调一下召回，拿到召回的结果，然后去重，拿到最终的一个给排序的样本，然后排序的结果就会反馈给用户。这是我们整体的技术架构。

最后，介绍一下我们给大家准备的一些资料。这第一个link它对应的是PAI团队结合自身过去几年在推荐领域的一些探索，总结了140页的推荐业务的动手实践文档。没有机器学习背景的人基于我们这些文档，也可以在一周之内搭建一套企业级的推荐系统，大家如果感兴趣可以去用一下。另外这一个是PAI的产品地址，我后面会基于这个产品介绍一些推荐算法。