下面这篇文章是笔者整理分享的关于推荐系统的核心设计思路的相关内容，想要了解或者对推荐系统感兴趣的同学可以进来看看哦！相信你会收获到你想要的知识。
本文约5000字，阅读需15-20分钟。但笔者非常有信心，如果你之前对推荐系统的了解不多或知识零散，认真读完这篇文章，一定会让你收获颇多。
打开手机，推荐无处不在。甚至，你之所以看到这篇文章也可能来自推荐。
写推荐的文章很多，但对于非技术背景的人，阅读门槛往往较高，因为文章里可能有大量的公式、构架等，让人望文却步。
但一个好的推荐系统，除了技术本身，还需要非技术人员赋予它可靠的数据以及深入的业务理解，因此非技术人员也得懂推荐系统。懂到什么程度呢？懂到你和项目干系人不会因为在推荐系统上的认知差异而无效沟通即可。
笔者认为要想了解推荐系统，可以从以下两个部分入手：
a、推荐系统是为了解决什么问题而存在？即推荐系统的核心设计思路，也是本文的重点，不会涉及任何的公式；
b、解决对应问题的方案，包括常见的系统构架、算法、评估方式，笔者会在阐述1的过程中进行提及，但不会展开介绍，有需要或感兴趣的读者可自行扩展阅读。文章末尾也会为大家推荐相关书籍和博主。
推荐系统最早应用在20世纪90年代，至今已30年，但推荐系统真正在国内被广泛关注是在今日头条上线的2012年之后。
一方面，移动互联网的信息严重过载，在用户弱目标的情况下，如何为用户匹配感兴趣或有用的物品成为了主流诉求，而这正是推荐系统的价值所在；另一方面，移动互联网数据的丰富性、可记录性为推荐系统的发展提供了基础。
笔者认为，推荐系统的核心思路其实非常简单，即如何通过已有数据资源，为目标用户u找到更好/足够好的物品i且将物品i更有效得呈现。基于此，我们需要进一步思考4个问题：
a、我的平台有哪些数据资源？
b、更好/足够好的物品标准是什么？
c、如何找到更好/足够好的物品？
d、找到更好/足够好的物品后，如何将它们高效得呈现在用户面前？
(Tips：可以短暂停顿思考下…)
下面我们对这4个问题逐一展开：
由于目标是为用户找物品，可以分别从物品、用户两个维度来盘点平台数据资源。
（1）用户维度
a、用户本身自有的画像数据，比如用户性别、年龄、常居城市、职业类型等。平台获取这类数据的途径一般是通过让用户授权来收集或者基于用户在平台的行为进行推测；
b、用户在其他平台产生的数据，比如社交关系等。一般是通过和其他平台合作且让用户授权后进行收集；
c、用户因为使用了平台而产生的平台独有数据，比如用户ID、用户访问次数、访问时间等。这类数据由平台实时记录；
（2）物品维度
a、物品属性数据，比如在视频内容平台，视频的时长、标题、分类、来源等。这类数据一般在物品创建完成时产生，或者从外部导入的物品，在同步过来后对相关属性数据进行二次加工；
b、物品在其他平台下被用户消费所产生的数据，比如视频播放量等，在同步过来后也是对相关数据进行适配加工；
c、物品在平台下被用户消费所产生的数据，比如在电商平台，商品的浏览量、订单量、成交额等。和上面用户维度C一样，这类数据也由平台实时记录。
首先我们需要搞清楚谁来当这个裁判员？是平台还是用户？
从推荐系统的思路来看，这里的裁判员只能是用户，而平台更像是为了让裁判员给高分，不断挑选、训练运动员的教练。
因此推荐系统推的物品是好还是坏，最终均是由用户行为指标来评价的，比如在电商平台可能是点击率、GMV转化；在内容平台，可能是点击率、停留时长。
另外需要说明的是，在评价指标里，大家往往会看到部分看似与用户行为不挂钩的指标，比如物品新颖性、多样性，一来这类指标并不会作为最核心的评价指标，一般仅作为辅助；二来这类指标属于平台的生态指标，更侧重于长期价值，其设计初衷也是为了维持更长久的用户行为。
在盘点完数据资源、确定评价指标后，我们来仔细盘一盘平台如何给用户匹配物品的问题。
我们先做个简单任务。现在有一个房间，房间里有若干物品，待会儿会进来一个人，你的任务就是给这个人找到他喜欢的一个物品。为了完成这个任务，你会做些什么？
你可能会：a、去逐个了解这个房间里的物品；b、等这个人进来和他沟通，去了解他的喜好；c、把你认为他可能喜欢的那个物品给到他。
现在任务难度升级。现在有一个屋子，屋子里有上百万、千万、甚至上亿的物品，屋子有多个门，以及若干个房间，随时有大量的人涌进来，然后逛不同的房间。你的任务是在每一个人进来房间后给他找到他喜欢的物品。为了完成这个任务，你会做些什么？
这个任务的难点在于，物品和人太多，如果还像简单任务那样，逐个去了解匹配，那等你完成任务，房间里的人都成仙了。因此我们需要提前设计好让物品和人匹配的自动化程序，等人一来，程序一转，诶～物品就出来了。
由于是等人来了，程序再转出物品，因此在匹配路径上是用户在前，物品在后。目前主流的推荐系统，共4条匹配路径：用户——>物品、用户—>“物品”—>物品、用户—>“用户”—>物品、用户—>概念—>物品。下面逐个展开介绍。
（1）用户——>物品
非个性化匹配路径，某个用户群体里的所有用户看到的推荐物品列表一致。平台主要是将物品按照热门、最新、高质量等规则进行排序得出。这种方案所需数据资源少，系统程序简单，比较适合冷启动阶段。
（2）用户—>“物品”—>物品
该路径中间加入了“物品”，该“物品”与用户有某种关联的关系，最常见的就是用户消费过该“物品”。基于这个关系，又可以延伸出两种常见的匹配方式：
a、让物品等于“物品”，即给用户推荐他曾经消费过的物品。这种方案虽然简单，但使用场景有限，仅在生鲜电商、音乐这类需重复消费同一物品的平台使用较多；
b、让物品相似于“物品”，即给用户推荐他曾经消费过的相似物品，这里涉及相似度的计算（余弦相似度、jaccard定理），感兴趣可进一步了解基于物品的协同过滤（Item-CF）。这种方案系统程序不算复杂，偏统计计算。另外这种方案下，由于会不断得给用户推荐他感兴趣的相似且不重复的物品，因此适合物品丰富且用户个性化需求强烈的平台，比如电商和内容平台；
（3）用户—>“用户”—>物品
该路径中间加入了“用户”，该“用户”与用户有某种关联的关系，常见有：
a、用户和“用户”是好友关系，即给用户推荐他的好友消费过/生产的物品，比如微信视频号在冷启动阶段就是侧重使用了这一方案；
b、用户和“用户”是关注关系，即给用户推荐他的关注的账号消费过/生产的物品，这种方案在内容、社区平台使用广泛；
c、用户和“用户”是相似关系，即给用户推荐与他相似的用户消费过的物品，这里也涉及相似度的计算，感兴趣可进一步了解基于用户的协同过滤（User-CF）。这种方案下，由于是提前计算好用户之间的相似性，只要新物品一旦被某个用户消费，该物品就会立即被推荐给其他相似用户，对新物品非常友好，因此适合物品更新速度快且用户个性化需求不那么强烈的平台，比如新闻类平台。
（4）用户—>概念—>物品
该路径中间加入了概念，这里的概念是从用户或物品中提取出的抽象的东西，常见有：
a、标签，是一种业务上可解释的概念，比如某个长视频带有综艺、沈腾、喜剧等标签。前期一般由人工对物品进行提取，当积累一定数据量后也可由机器学习自动提取。然后如果某个用户经常消费某个标签的物品，那该用户也会通过数据统计的方式，被打上该标签偏好，于是会给用户推荐他所偏好的标签物品。这种方案和前面的物品相似于“物品”其实是同一种思想；
b、向量，是一种业务上不可解释的概念。前面提到的“物品”、“用户”、标签，都是为了让用户和物品之间建立关系。从技术的角度，也可以基于历史的用户行为数据，为用户和物品之间构建关系，只是中间的这个连接点由隐向量K来完成（Embedding、隐向量模型/隐语义模型（LFM）/矩阵分解模型、双塔模型）。相比前面提到的方案，这种方案能在一定程度上解决用户-物品矩阵数据稀疏的问题，但核心思想一致；
c、特征，是一种业务上可解释的概念。特征和标签的主要区别在于，标签更多是刻画物品和用户的静态属性，而特征是万物皆可刻画，你可以这样理解，只要是平台的数据资源，均可转化成特征，比如单特征（静态属性、请求属性、画像）、衍生特征（占比、转化率）、交叉特征（交叉特征有时是为了拓宽特征量，不一定具有业务意义）、实时特征（接口入参）。
那特征可以用来干什么呢？编码后的特征值可以做为入参来生成预测模型（逻辑回归、决策树算法、深度学习），预测前面提到的所有用户核心指标，比如点击率、转化率、停留时长等。这种方案在系统程序上最复杂，数据资源要求也非常高，但效果也是最佳的。
另外，匹配路径的效果评估，除了上线后看用户的行为指标外（裁判员给分），也需要在上线前评估这些路径的效果（教练员给分）。以上所提到的协同过滤、隐语义模型、逻辑回归等均属于分类任务，针对分类任务，常见的离线效果指标有混淆矩阵（召回率、精准率、准确率）、AUC等。
为用户找到物品，任务还远没有结束。我们前面完成的任务是：在每一个人进来房间后给他找到他喜欢的物品。但是，找多久呢？物品呈现足够清晰吗？用户拿取方便吗？等。毕竟评价推荐系统的核心指标是用户行为，我们所有的设计需要为相关指标的达成所服务。
这里展开谈谈找多久的问题。移动互联网用户体验的及格线大致0.5秒，也就是等人一来，程序最多只能转0.5秒，就得把物品给出来。
在前面提到的匹配路径，我们说到特征那里效果是最好的，但是由于其模型复杂，如果只采用这个方案，等程序转出来，用户早就对你say byebye了。因此，为了保证效果，又保证程序转得快，构架采用了召回层——>粗排层——>精排层的方式来进行。
其中可以提前离线算好或者系统性能耗时少的，比如规则类、协同过滤类、向量模型类，就放到召回层，它们作为多路召回（主路、旁路），负责相关性的计算，且各路有个召回的数量目标，让总物品量从万量级筛选到千量级甚至更少；
然后再用相对简单一点的模型，或者直接对前面多路召回的物品结果归一化后截断进行粗排，从千级筛选至百级甚至更少；
最后再用复杂但准确的模型，对这百级物品进行排序。由于模型复杂，光是减少计算的物品还不够，在前面提到的模型是通过编码后的特征入参来生成的，因此特征选择非常重要，特征越多，计算耗时越高，所以需要选择有效特征让模型有增益。另外前面也提到特征的分类，可以将非实时的特征在离线入参，计算出超参数，在某用户进入对应推荐场景时，超参数由于离线已经算好，只需要将该用户的实时特征进行入参计算。
所以总结下来，为了保证耗时：
a、用耗时少的路径先筛选，减少计算的物品量级；
b、有效的特征选择；
c、离线计算好超参数；
另外在构架里，还往往能看到重排层、过滤层，以及在召回、粗排、精排层里出现的保送。其中重排层是为了全局最优、过滤层和保送都是业务干预。感兴趣的读者也可自行拓展了解。
关于推荐系统相关的书籍，我目前只推荐两本。
《推荐系统实践》，作者项亮，豆瓣评分8.1。算是我入门推荐系统的一本书，当时读完脑袋里只有一些雏形，但是对于的整体的框架还是无法清晰建立。个人建议是有一定基础后再去阅读；
《策略产品经理——模型与方法论》，作者青十五，豆瓣评分8.3。这本书我是今年读的，作者是算法出身，书里作者一直非常强调将问题模型化，个人认为前面部分收获蛮多，后面部分有些凑字数，但整体还是值得一读。是目前带有“策略产品经理”字样里最好的一本了。
KingJames
账号在知乎和人人都是产品经理平台，也是算法出身，相比前面的书籍，更加通俗易懂，而且结合了业务场景。除了推荐搜索专题，还有专门的AI、机器学习专题。他的自我介绍里有这样一句——“最擅长给小白深入浅出介绍AI &机器学习知识的博主”。他也有一本策略产品经理的书籍正在出版中，还是比较期待的。
以上便是笔者对推荐系统的核心思路的解读，由于经验有限，不严谨的地方欢迎指正和探讨。本篇侧重于推荐系统的理论科普，下一篇笔者会以UGC社区为例进行推荐系统的实战介绍，欢迎关注～
本文由@wen 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来源于Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。