开发者学堂课程【跟阿里云技术专家学习智能推荐系统： 推荐系统基本概念及架构说明】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/662/detail/11074
推荐系统基本概念及架构说明
内容介绍：
一、引言
二、课程介绍
三、什么是推荐系统
四、个性化推荐业务流程
五、企业级推荐系统架构
一、引言
之前的课程中是对机器学习在文本、在推荐、在视觉各方面领域做了一个比较泛的概述，今天的一系列课程是想基于推荐这样一个企业级的解决方案去做一个详细的分享，之所以选择推荐这个架构是因为当我们去探索整个机器学习的业务时，我们发现在互联网应用中，特别是我们平时常用的手机APP里，前1000名的 APP 里，大约有80%的 APP 里面或多或少都有推荐、营销、广告这样的场景，如何构建这种企业级的架构，是本系列视频要重点介绍的内容，第一课会重点介绍企业推荐系统的基本概念与架构，然后把课程大纲给大家做一个分享。
二、课程介绍
课程1:推荐系统基本概念及架构说明
课程2:推荐系统召回算法级架构说明
课程3∶推荐系统排序算法级架构说明
课程4∶推荐系统线上服务编排
课程5∶实操10分钟实现一个简单的推荐系统
在第一课会把总框架给大家做一个介绍；从第二课开始会重点介绍推荐里面的召回算法，他是怎么样去运作的，有哪些种类，以及其他一些具体的使用情况，有哪些需要注意，又有哪些算法的效果；第三课会介绍排序算法，包括常用的排序算法；第四课是整个推荐业务的线上编排，即各种算法模型怎么样在线上去变成一个服务；第五课会基于整个阿里云 PAI 去做一个基于召回算法的一个简单的推荐系统的代码。
三、什么是推荐系统
1、概念
推荐系统的诞生其实是伴随着互联网的发展，人们可以涉猎到更多的资讯，比如当用户进入到淘宝的平台，会发现有更多的商品，当商品变多之后，如何将适合该用户的商品去完成推送，这就成了淘宝或者说这样一个系统应用需要解决的一个问题。所以在本质上推荐系统，解决的是一个信息比对的问题，怎样将用户的信息与商品的信息去做一个更好的匹配。
推荐系统可以理解为推荐算法和系统工程的一个总和，目前很多的书或者说很多网上的一些资料更多的是聚焦到算法，包括很多 paper 都会说推荐算法使用什么，但是当真正去搭建这套业务系统的时候，特别是在云上做成这套系统时，会发现系统工程面临的可能会面临更多的问题，比如说性能的问题、最后线上模型服务的PPS的延时是否达标，是否真正能在30毫秒内返回结果。比如一个数据存储的问题，数据存到哪里可以更快的反馈给模型，而平时离线数仓的数据又该怎么存储。
对于线上的数据处理问题，一个p的日志数据要怎么处理？对于实时流的数据是否需要用 Flint 去做一个实时的数据仓。
2、常见应用场景
大家平时在用各种手机 APP 的时候，其实已经对很多的推荐场景或多或少有些了解了，常见的推荐场景有两个，一个是基于搜索 Query 推荐，还有一个是基于用户和商品属性的 Feed 流推荐。
l 基于搜索 Query 推荐
例如当用户搜索口罩，搜索后展示的肯定都是跟口罩相关的东西，因为口罩的种类很多，搜索结果可能多达一万多个，哪些口罩排在前面，哪些口罩排在后面，这时就需要有推荐系统，需要根据这个用户属性，该用户喜欢的颜色或者他的价格偏好等，将搜索结果进行排序。
比如说该用户喜欢昂贵的商品，喜欢买奢侈品，肯定把昂贵的、性能好的口罩排在前面；
比如说另一个用户是一位价格比较敏感的用户，可能就要把价格稍微便宜，性价比高的口罩排在前面。综合来说，Query 要集合用户的购买偏好以及商品的属性，去做一个 match。
l 基于用户和商品属性的 Feed 流推荐
Feed 流推荐现在越来越成为很多 APP 跟用户交互的主流，例如当我们打开虎扑，打开今日头条这样的 APP 会发现首页的新闻，都是根据我们日常的偏好去推荐的。例如某个用户喜欢篮球相关的新闻，那他可能更多的会把体育相关内容推荐给该用户。
基于用户和商品的 Feed 流推荐需要机器学习推荐模型，既要学习用户也要学习商品的属性，所以今天介绍的推荐系统的整个架构就是给大家介绍在底层如何实现用户的属性与商品属性的完成匹配，此课程更多的是偏向于基于用户、商品属性的 Feed 流场景。
四、个性化推荐业务流程
推荐业务的简图如下：
假设有一个新闻平台，这个平台上有非常多的新闻，用户进来后有一个 ID，比如说UserID：A，这个平台上成千上万的商品或者新闻，可以把它们称为 Item，而每一个 Item 也有一个 ID，比如说 Item123依次像这样排列下去。
现在需要从这10万个 Item 中筛选出 A 喜欢的商品或新闻，并投送到第一屏上，要完成这件事究竟在底层的业务架构有哪些模块呢？
首先在一个经典的推荐召回系统里面有两个模块，第一个叫召回模块，第二个叫排序模块，召回模块把10万件商品做一个初步筛选，选出a可能喜欢的，比如说500个商品先放到一边。
这个时候再去排序，因为走完召回后，我们并不知道用户A最喜欢的是1还是喜欢2，只能知道 A 大致喜欢的内容会在这500个候选集里，在排序模块里要对这1到500件商品做一个排序，哪个是A最喜欢的，哪个对于A来说是第二喜欢的，最终可以按照A的喜爱顺序去制定投放给A的商品列表。所以在整个推荐业务中，召回模块更多的是初步筛选，确定出一个大体的范围，这样的话可以加速排序模块对于每个商品属性的排序速度。
设想一下，如果没有召回模块，直接对10万个商品和用户 A 进行排序，它的速度会非常慢。每进入一个APP就要等待几秒钟甚至等待一分钟的时间后才能反馈出推荐的内容，用户肯定忍受不了这种等待，所以说通过召回模块的初步筛选，然后再仔细排序，整体的反馈效率更高，这样的话，基本上一个专业推荐系统可以做到几十毫秒内，即当用户一进来就可以给他反馈出要推荐的内容。
对 Feed 流的内容用户刷一下屏幕，可能几十毫秒内就可以收到新的一个推荐。
五、企业级推荐系统架构
1、企业级推荐系统架构的目标:
百万+级 MAU 应用的推荐业务
2、企业级推荐系统架构的需求
亿级别样本训练
算法插件化部署
每次请求毫秒级反馈
支持资源弹性拓展
首先企业级推荐系统架构的目标客户有百万级MAU的业务需求，而要达到百万级 MAU 的应用，每一次参与模型训练时整个的样本数量可能是上亿级别的，需要整个平台过去一个月甚至半年的数据完成整体的建模，因为在这些领域中模型越大，推送结果越精准。
所需数据可以拆分成三种，一个是用户的行为数据，一个是商品的行为数据以及用户商品之间的交互的数据。
第二要有算法插件化部署的能力，机器学习领域包括推荐领域发展的特别快，每年都会衍生出一些新的算法，这些算法在整个系统中要做到灵活的应用，例如当下使用算法A，之后衍生出的算法B，可不可以直接剔除算法A转而去使用算法B，这就是系统的鼓棒性，即对算法组件化支持的能力，现在推出的阿里机器学习PAI产品就具有这样的能力。
第三是服务器的性能问题，是否可以做到复杂排序的整合编排，并且可以做到很好的反馈。
第四是支持资源的弹性扩展，举例来说，推荐最后的模型服务，可能对于一些APP来说，其受众的浏览量与时间有关，下班点大家在地铁上浏览的比较多，凌晨大家的浏览量有所减少，因此推荐模型的底层使用资源在用户量大的时候需要更多资源，在凌晨就需要更少的资源，为了平衡这个成本，就要实现底层资源的灵活扩展，而这便是用云上服务的一个优势，线下的服务的需要按照整个服务的峰值去购买机器。
3、企业级推荐系统的整体架构
最下面是基础数据层，包括用户的画像数据(例说用户的身高、体重或者购买偏好、属性、学历等等，都属于用户的画像数据)、物料本身的数据(物料数据就是说物品的价格、颜色、产地等，如果是新闻其物料数据就指新闻的市场，如果是短视频，物料数据就是这个视频的市场、内容、标签等等都属于物料本身的数据)、用户数据的行为数据(行为数据就是指用户和物料之间的交互，比如一个用户看到一个视频点赞了，或者该用户勾选了dislike，还可以是收藏，这些都是用户的行为数据)。
而像一些评论数据、第三方数据等等，不一定每个平台每个产品都会有，但是基本上 User 的数据、Item 的数据以及 Behaviour 的数据，这三张表是一定要有的，当有了这三个数据之后，就会进入到数据加工存储这一层。这一层会做一些数据的加工，比如说去加工特征，把用户、物料以及事件的特征加工出来。
再往上一级就是基于这些特征的建模，整个推荐的序列包含召回和排序两个重要的模块。在召回模块可以有多个算法去并行完成，比如A算法召回100万个问题，B算法召回100万个问题，后续可以把它们放在一起去做一个最终的结果。召回之后需要一个排序，排序也有很多算法。
最后经过召回和排序之后，要有一个相应的策略，完成去重、测试等步骤，比如说昨天刚推荐给用户一个小米手机，然后用户购买了，再次推荐小米手机肯定是不合适的，这是典型的去重系统；
还有 AB test，我们经常有两个推荐模型，不上线就不知道哪一个模型对结果的效果最好，所以先要有一个 AB Test 的灰度发布，另外还要兼容很多用户自己的业务，比如说今天想对一个短裙做加量的投送，即使它排序在后面，但因为运营的需求，需要把短裙放在前面推送更多的用户，因此需要兼顾这些策略。
最上层就是最终的推荐业务，可以推荐商品，可以推荐用户，比如说在一些社交的应用，可以把用户推荐给用户，让他们互相关注，也可以推荐广告。
4、企业级推荐系统的整体架构如何符合四个需求？
企业级推荐系统的整体架构要符合四个需求就需要用到一些云产品，最常见的做法就是基于云服务、云生态去搭建这些模块的内容，在阿里云整个的实现方法是这样的：基于 PAI 的推荐平台，在基础数据层，可以提供一些网站的离线数据，并存到RDS（MySql ）数据库里。
实时的行为数据（比如点击、关注等）也是可以的完成的，可以利用Kafka，然后到上一层（数据加工层），利用 Flink 完成加工，加工实时的行为数据；
另外也可以用离线的数仓，比如 Max Compute 去结合 DW 完成一些实时的批量处理，生成样本之后就可以发到模型训练层，在模型训练层主要会用到 PAI 的一些算法，比如 PAI－Studio 里有很多召回算法，也有很多排序的算法，对于召回算法，比如说向量召回，生成的结果可能有一部分要从 redis 里取出来，存到 Faiss 里，然后 PAI－Studio 生成的排序模型可能要部署到一个在线的服务环境中，把这个模型部署成一个 Api。
最上面应用的时候，为了保证整个服务的弹性，推荐通过 K８S 原生的方案去做，保证资源弹性。
就是刚才所讲的，大部分客户推荐服务的高峰期集中在下班时间或者是上班时间，这段时间就要多部署一些服务，到凌晨的时候可能用户比较少，就可以相对减少一些服务，这是云上资源弹性的一个特点。
最终在服务编排阶段，可以先调一下召回，拿到召回结果，然后去重，拿到最终的排序样本，排序的结果就会反复的给用户做一个报告。
