推荐本质上并不是一个很新的话题。从很早开始，尤其从互联网出现之后，大家面临一个问题，我们怎么样从海量的数据里获得自己需要的内容？这实际上也经历了很长的过程，最开始的时候并不是推荐，而是分类导航。做分类导航最好的公司就是雅虎，那个时候互联网的数据还不是特别多，可以通过人工或者一些简单的分类方法整理出一个目录出来，大家就可以按这个目录一层层往下走，比在原来在网上找好很多。但分类导航由于分类的标准不一样，人和人认知的差异性，后来谷歌的出现促使了雅虎在这个领域的沉寂。
搜索就是下一代解决从海量数据中获取信息的方法。只要知道想要什么，就可以通过搜索拿到八九不离十的结果，但前提是你想要知道你想要什么。很多时候你不知道想要什么，比如看淘宝、新闻，没看新闻之前一定不知道我想了解什么东西。所以搜索是一种主动获取信息的方式。
搜索之后会有一些新的东西出来，比如个性化推荐，它是建立在对用户兴趣或者爱好了解的基础上，有针对性的展示一些内容。时代一直在发展，今天已经进入了移动时代，移动时代最大的好处是我们可以通过手机，随时随地的了解各种各样的信息，随时随地的上网，坏处是手机的屏幕实在太小了，不管做分类也好还是搜索也好，都不是特别的方便。所以在移动的时代，推荐一定是未来下一个爆发点。总的来说，从分类到搜索到推荐，本质上都是为了解决信息过载的问题。
搜索引擎
到了今天这个时代，推荐一定会发挥更大的作用，但这里有一个问题，比如搜索、广告、推荐，这是整个互联网在大数据领域几个经典的应用，作为搜索来讲，这个体系的架构已经非常清晰了。比如有一个用户首先有一个query进来，构建一个解析，有一个索引，之后会有一些数据的准备等等，最后再采集用户的行为，最后产生这样的数据闭环。如果自己想搭一个搜索引擎的话也很简单，有各种各样开源的东西可以用。如果不想用开源的话，还有很多搜索的服务，比如谷歌、百度、Bing，在自己的网站内嵌一个他们的服务也很方便，这一块都已经非常成熟。
广告也同样，整个体系架构是在用户和广告商之间搭了一个桥，用户看到媒体，媒体通过SSP、ADX和广告需求结合起来，DMP提供数据方面的支持，相当于用户画像的支持。
推荐系统？
但是提到推荐场景，我们看到的完全不一样，上图所有的公司都在推荐里做的相当好，他们自己玩的很转，系统也很漂亮，但问题是这种能力我们怎么把它用起来？也就是说对于一般有需求的用户来讲怎么样在自己的系统里搭一个推荐引擎？海量的数据、各种各样的行为、算法，对一个新手或者对这个行业了解不是特别深的人来讲确实有很大的挑战。原因如下：
需求。对广大推荐的要求来讲，其实大家的需求都是不太一样的，比如从推荐的内容来看，有可能是商品，有可能是新闻，甚至有可能是人，各种各样的东西。数据的来源也非常不一致，有可能爬虫爬来的，也有可能自己自己买来的。这与搜索不一样，搜索大部分都是文本，但不排除图片搜索这种新的内容，但基本核心的还是在文本搜索。对推荐来讲这些东西还是有不小的区别，比如音乐往往不可能非常类似。如果我们想从一个比较高的层次看这个推荐的话，大家会觉得非常非常乱，不容易看到一根主线，这可能是一个最重要的原因。
系统。如果我们想搭建这样一个平台的话，必要的系统支持也是必不可少的。如果还是基于原来方式，自己堆几个服务器，在上面写几个程序说希望这个东西能服务到很多的用户，基本上也是不太靠谱的。这里面我们要考虑的东西很多，比如离线计算、在线计算、日志采集，还得考虑自定义中的性能，比如吞吐性、安全性。
动机。最后一个可能也是最重要的，就是动机。达未必兼济天下，穷难以独善其身。
对于这几种情况，我们应该怎么来解决？
概念抽象
对于需求，我们可能会需要对整个系统或者整个应用的情况做一个抽象，这个抽象至少能帮助我们把整个推荐里面一些关键的信息拽出来，至少能在一个框架的层面上做一些东西。阿里云的口号是无法计算的价值，我们希望构建一个在云环境里的计算生态，推荐其实是一个很好的应用入口。不夸张地讲，据原来的一些统计数字，国内在推荐这一个领域里，自建或者通过合作的方式共建的客户的数目，大约在10万能量级。就是如果说我们能把这个领域的能力能推广出来的话，对阿里云来讲一定是一个很有竞争力的点。所以从动机上，对我们来讲是非常有动力来做好这件事的。
怎么解决？可以从两个角度来讲，大数据一般会讲到三个字，存、通、用。存其实是一个很简单的要求，基本上你想做数据，这是一个必备的条件。概念抽象，其实在这个地方起的就是通的作用，把不同的领域或者不同实力下的要求串起来，抽象到一个相同的层面上来看。基本上可以从几个方面来看，首先我们会有一个用户物品和行为的基本对象的概念。我们要做推荐首先要有用户、有物品，要把物品推荐给用户，物品和用户之间其实是通过各种各样的行为发生关系，当然这个行为的种类就有很多了，物品的种类也有很多，用户的情况也很复杂，具体怎么复杂先暂时不要管。格式规范，比如用户有一张表，把所有不一致的东西隐藏到里面，用一个很长的KV的串记录下来。物品的表，行为的表，这里面的行为的话，其实是可以自由扩展的，并不局限在这些列出来的内容里。比如一些跟视频相关的，可能会有播放、暂停、快进。这些行为一定是与具体的业务类型是有关系的，不太可能能枚举到完全，就算枚举到完全，没有足够的数据训练后面模型的话，这种枚举也是没有意义的。最后是日志埋点的规范，这一点也是相当重要的，它搭起了云上推荐引擎和客户端展示的前端之间的桥梁。
数据已经通了，怎么用？我们不太可能去针对每一个业务去给它写上很多专门的算法或者专门的设计，我们也需要有一些相关的概念上的考虑。我们的做法是把它给做成了三个基本概念，第一个是业务，可以理解为就是一个数据的集合。刚才说数据有用户、物品、行为，业务就可以裂解为用户、物品、行为三张表，不同的用户或者不同的推荐物品，就会对应到不同的业务上去。比如现在打个比方，现在有一个APP，这个APP既可以推荐商品，也可以推荐跟商品相关的新闻，可以有两种做法。一是把物品分成两块，一是新闻，二是商品。另外一块可以考虑把商品和新闻看成是一个抽象的物品，他们之间可能会有一些相似的特征，把这些相似特征列出来或者取一个并集或者做一些其它方面的处理，把它变成一个新的东西，我们所有的推荐就是推这个抽象的物品。完了之后，真正在选择真实东西的时候，可能会根据这个特征，根据物品的真实情况再来做一个计算来选择，这个地方其实定义的就是业务。
第二个是场景，首页推荐的话，大家很容易想到一个用户进来了，我现在大概只能看到这个人是谁，其它的信息我可能都不知道。所以这个时候我的推荐可能只能猜一猜他可能喜欢什么东西，所谓的猜你喜欢。第二个是详情页，是说我在看具体某一个东西的时候，你给我展示跟这个东西相关或者相似的东西。这个时候其实我们可以用来做推荐的选择的参数就会多一些，除了这个用户之外，我们可能还会看一看当前看的这个东西是什么。第三个是搜索场景，除了人可能还会有一些搜索的关键词，我推荐的结果要和这个人和关键词都有一些关系。但它和搜索不一样的地方在于，搜索可能更多的考虑我给出来的结果和我输入的关键词是不是匹配，可能不太会考虑用户在这个里面的一些情况。但推荐的话，一方面要考虑关键词的匹配度，另外还要考虑用户本身的个性。还可以扩展一点推荐的结果，未必跟搜索的关联词做很好的匹配，比如说我们搜一个汽车，比如你想买车或者想看看跟汽车相关的新闻。比如我今天搜的是宝马，搜索出来的估计都是各种各样的宝马新款，你给个奔驰也不是不可以，但好像跟你这个结果不是特别好。但如果给到一个五菱弘光这可能扯的比较远。在推荐的时候，如果这个人可能收入不是很高，平常对汽车也没有特别大的兴趣，他突然搜了一个“宝马”，这个时候关于用户的画像更多一点的话，推荐的结果可能是像有一些八卦的新闻，不如宁愿坐在宝马车上哭也不愿意在自行车上笑这样的东西，这些人搜索的东西，我们猜测想看宝马车主花边新闻之类的东西，这些可能跟搜索的场景不太一样的地方。所以综合下来看，他们共同的特点是什么，其实就是反映在我在做推荐的时候，我能拿到什么样的参数，不同的参数导致的推荐的要求和推荐的结果都是不一样的，所以这一块我们把它叫做场景。
最后就是一个算法流程，它其实是对场景的具体实现。比如我要做首页推荐猜你喜欢，这可以有很多不同的方法去做，每一个方法可以做成不同的流程。这个概念一层一层往下越来越细，一个业务有不同的场景，一个场景可能有不同的实现方法，这是关于产品抽象化的概念。
平台支持
对于系统，其实刚才已经提到了需要一个很大的平台来支持，我们不能指望说什么事情都从轮子开始，一点一点往上造，造到最后造出一个航空母舰来。再看一下平台的支持，首先看看离线的计算和存储，这些都是阿里云现在已经在公有云上正式上线的组件。在线计算和存储比较多，像流计算、SteamCompute等；数据传输；监控预警；数据开发方面；弹性扩容的能力，像弹性计算、虚拟专有云。正是建立在这些强大的平台能力之上，其实我们才可以来做这个推荐的云服务的功能。
商业模式
动机就是取决于一个商业模式，公司的驱动点到底在哪里。
阿里云推荐引擎架构
上图推荐架构与一般的推荐系统没有太大的区别，只不过架在云上而已。前端是一个展示页面，是客户自己的，通过规范的数据采集，把日志收上来，可以通过实时的方法收，通过API的方式提交，也可以通过离线的方式传，这边有一个数据集成，可以做一个数据的传输，把它传递到我们需要的各种各样的地方去。
至于这下面的平台，推荐引擎一方面推荐了相关的算法，一方面把算法的能力以API、SaaS的方法推出来，并且平台是搭在虚拟机上的。
如果我们想用的话，怎么样来使用这个推荐引擎，其实一共分成五步。其实做好前面三步的话，这个事情也就OK了。首先是数据上传，第二是做配置、业务场景。我的数据要告诉这个推荐引擎数据到底在哪里，我想做什么样的推荐，把这些定义好之后要选择一些算法来完成这个工作，有一些模板其实我们都已经配置好了，直接选择就可以了。如果说我们提供的这些东西不满足要求，那你可以来做一个自定义开发。为什么推荐的这个产品没有能得到大规模的普及？这一块的功能其实现在都支持的不是太好，如果想在别的系统里嵌入一段自己的代码会有各种各样的担忧，比如安全性。但现在阿里云很好解决的这个问题，包括可以支持大家做自定义的开发，我们提供了一些默认东西随便用，如果觉得不好用的话，也可以修改，很多时候有一些业务规则也可以重新设定。
云计算可能有调度，推荐结果来了这个用户，怎么把这个结果拿回来，获取一个结果，然后我们的用户产生一些新的行为，日志怎么能实时的反馈回去，另外是有一些新的物品，新增的东西，我们希望能很快的推荐出去，也可以通过这些接口实时的反馈回来，后台会做一些计算。
这些东西集成完之后，其实整个系统可以工作了，问题不会太大。后面这两件事主要是做额外的辅助，一是日志埋点，目的是为了生成效果报表。在算效果的时候，需要能区分出来哪些行为或者哪些转化是推荐带来的，哪些转化是产品本来就有的，所以需要做一个埋点，把推荐带来的转化和原来自有的转化区分开。
用户基因分析
如果我们能把用户做选择的背后原因搞清楚，其实我们很多时候就可以做出准确的预测。其实基因分析做的就是这样一件事，首先根据用户的行为做一个因子分析，这个因子分析的目的是为了分析各个行为所代表的权重。不同的领域里，大家的行为一定是不一样的，既然大家的行为都不一样，那你想做一个统一的产品方案是不太可能的。基因分析是把各种各样的行为做了一个统一的处理，具体来说，把行为分两类：第一类是目标行为。就是希望我们用户去做的行为，比如对电商来讲，我们希望用户买东西；对视频或者音频网站的话，我们希望用户把这个视频看完或者把歌听完或者下载完，这是我们的目标行为。剩下所有的行为，比如收藏、点击等等行为，其实都是为了我们最终希望他做的那些事情在做的准备，基于上述行为我们可以训练一个模型，即用基础行为去预测目标行为的概率。实际上就可以把这些系数当做行为权重的因子。所以，我们现在的产品里有多少种行为，其实我都不太在乎，只要能把这两个东西能分的出来就好。
特征抽取后获得物品的一些各种各样的属性，比如对于歌来讲，会有很多的风格、歌名、专辑、歌手等等，这样会做一个特征抽取。现在说起来推荐的话，可能深度学习是无所不在。但实际上推荐里用的深度学习的模型一般不会超过三层，其实本质上这些事情都是比较浅层的东西，你搬一些东西进来可能效果好一些，因为加了非线性的东西进来，但其实用比较朴素的方法做也不是不可以，速度反而快一些。
特征抽取完之后，会得到一组特征的向量，总会有一个特征来基于它的内容。这一步其实只是做了一个转换，原来这些特征是针对歌曲本身的，此时就把特征变成人的特征，如果把这个特征打在人身上就理解为人对这个东西的偏好。怎么做呢？每个行为的对象（歌）都有属性，行为有系数、属性，乘乘加加就可以了。一般来说这个过程会很长，所以要降维。
实时修正
实时相关是很正常的需求，一般推荐都有这个问题，第一是新物品进来了我们怎么办，我们希望能很快的推出去。用户发生一个新的新闻，我们希望这个行为能对这个用户本身做一些修正。歌曲来了之后，第一步要做一个特征的计算，计算完了之后，要做一个倒排索引，这里一定要降维。第二是我们现在有一个人，对一个物品产生新的行为想看看怎么调整用户的特征。前面说了每一个行为有一个因子，把所有的因子乘乘加加可以得到一个修正的向量，一般来说我们希望它的行为要比作用大一些，我们要把这个α通常放大5～10倍，这样会对后面的结果产生比较明显的影响，所以这些东西其实还是比较简单的。
行业解决方案
上图是我们现在做的一些行业的解决方案，系统架构包括离线、静线和在线。对于内容导购这个领域来讲，内容领域可以理解为现在电商发展的新的模式，原来大家做广告推这个推那个，推多了看的不太爽。但如果做一些比较高大上的方式，比如我卖酒，给你讲酒的浪漫故事等等。内容营销就是这个意思，目的是导购，但手段是内容，所以本质上来讲是需要根据这些内容来做一些营销方面的工作，内容分成这几块，PBC、UGC、达人。其他的东西也都差不多，把离线做一个匹配，在线做一个调整，大概是这样。媒体咨询也差不多，媒体这一块可能会对实时要求比较高一些，因为新闻总会有一些新的东西尽量，所以在新闻会做的比较强一些，其它都差不多。
