清澈如初|个性化推荐算法（推荐系统）概要读者读完本文后

读者读完本文后，你会知道每类范式常用的算法有哪些、实现的思路是什么、以及常用的应用场景。本文也可以作为读者落地推荐算法到真实推荐场景的参考指南。
一、推荐算法与产品介绍什么是推荐系统？
在介绍推荐算法之前需要先介绍一下什么是信息过载。
信息过载就是信息的数量远超于人手工可以遍历的数量。比如，当你没有目的性的去逛超市，你不可能把所有的商品都看一遍都有什么。同样，无论是去书店看书，还是在电影网站上搜索电影，这些物品的量级对于没有目的性、需求性的用户而言都是信息过载。
那么什么是推荐系统呢？
就是当用户的目的不明确、且该服务对于用户而言构成了信息过载；但该系统基于一定的策略规则，将物品进行了排序，并将前面的物品展示给了用户，这样的系统就可以称之为推荐系统。
举例说明，在网站购物过程中，无论是天猫或者京东这样的平台，如果我们有明确的需求去搜索框里检索。如希望买啤酒，那么检索结果就是很多种类的啤酒；如果没有明确的需求，就会有猜你喜欢等等模块，这些模块就是推荐系统基于一定的规则策略计算出来的，这些规则策略就是个性化推荐算法。
在工业级推荐系统的推荐业务流程一般分为召回和排序两个阶段，召回就是将用户可能会感兴趣的标的物通过算法从全量标的物库中取出来，一般会采用多个算法来召回，比如热门召回、协同过滤召回、标签召回等，排序阶段将召回阶段的标的物列表根据用户可能的点击概率大小排序(即所谓的ctr预估) 。在实际业务中，在排序后还会增加一层调控逻辑，根据业务规则及运营策略对排序后的列表进一步增补微调，满足特定的运营需求。
个性化召回
1、什么是个性化召回？在item全集中选取一部分作为候选集。这里就存在一个问题，就是说为什么要选取一部分作为作为候选集，而不是全部？其原因在于：

1.不同的用户不会喜欢所有类型的item；
2.基于服务性能的考虑，如果选择了全部的item作为候选集，对于后续的排序就将耗费大量的时间，对于整体推荐的后端，服务响应时间将会是灾难性的。

根据用户的属性行为上下文等信息从物品全集中选取其感兴趣的物品作为候选集。
下面举例说明：
如果某个推荐系统中，物品全集是如下左图中9个item ，这里有两个用户A和B ，他们分别对不同的item感兴趣。这里拿信息流产品举例，如果user A对体育类新闻感兴趣， user B对娱乐类新闻感兴趣，那就按照简单的类别召回，得到结果如下右图所示。
在候选集{a,b,c,….,g,h,i}中为User A,User B选取一部分item作为候选集

2、召回的重要作用召回决定了最终推荐结果的天花板
为什么这么说呢？这里先看一下推荐系统的整体架构，工业中的个性化推荐系统中的策略部分的架构主要由一下三部分构成：召回、排序、以及最后的策略调整部分（同上文提到），其中召回部分包括各路个性化召回之后将所有的item merge进入rank部分， rank只是调整召回完item的展现顺序， rank完之后还有一些策略的调整，比如信息流场景中的控制相同作者的数目等等，所以可以看到个性化召回的候选集是多么的重要，因为最终展现给用户的就是从这个候选集中选出来的。那么就可能会有疑问，为什么不能将所有的item进行排序？这是为了保证后端响应时间。

与用户离的最近的是端，在移动互联网的时代主要的流量集中在了移动app也可以是网站前端。连接接前后端的是WEB API层。 WEB层主要给APP端提供API服务，解析端上发来的请求，调用后端rpc服务。得到的结果投全到端上。 web api层尽量不做策略业务逻辑，但是会做一些诸如log写实时信息队列，或写分布式存储这样的事情来方便后续的数据分析和模型训练。