推荐策略产品经理实操（三）：推荐系统与搜索系统的区别——整体逻辑流程对比

编辑导语：推荐的目的主要在于依据用户行为偏好，为用户推荐可能喜欢的事物；而搜索则是用户出于一定目的进行检索，前者为被动获取，后者为主动获取。具体而言，推荐系统与搜索系统有何差异？本篇文章里，作者从整体逻辑层面对推荐系统与搜索系统的区别进行了总结，一起来看一下。

根据我平时接触的推荐和搜索业务，简单地将2个业务的流程进行梳理以及知识点扩展，便于需要的同学能够快速地了解2个系统的基本逻辑。

一、推荐系统逻辑

推荐的本质就是为了解决信息过载造成的“选择困难症”，便于用户能够在自己选物之前，系统已经帮用户筛选到了最想要的信息。

以下是我按照用户打开APP进入推荐页面时，推荐系统返回给该用户推荐列表的整体流程：

整个流程的重点逻辑主要在召回、排序、重排三层，这一节专门讲这一块，至于AB实验平台上的逻辑，后面会有专门的一节进行AB实验的详解。

1. 召回

什么是召回？大多数人都会很快解释：召回是从物料库中获取一小部分物料，这一小部分物料会在后续的环节被模型用来进行打分排序。

这里我们再直白一点理解吧，召回就是捞，给用户推荐的时候，不可能把平台上所有的item都拿出来走模型排序，这样的话计算时间会很长，且资源消耗很大、不合理。这个时候就需要去平台内容库里把最适合用户的item捞出来，这就是我们说的召回。

通常都是从亿万级数据或千万级数据中捞出千百级别的item。召回这一步主要是处理数据量大，需要步骤速度够快、模型不能太复杂且使用特征相对排序少。

当然，召回也是决定个性化推荐的基础，目前来看，召回多数是多路召回（这里可以理解为通过不同限制条件去捞）。

多路召回的好处：

• 提高召回率和准确率，这里不对这2个名词作解释，可以找相关文章自行查询；

• 个性化推荐的基础，用户多样性兴趣探索，多元化召回；

• 保证线上事故发生时还有存余召回兜底，避免推荐接口没有返回的数据；

• 贴近业务，各业务需求不一样，需要进行融合（广告召回、强插、item冷启动等）。

常见的召回路径（策略都是需要数据支持且与场景强相关的）：

1）协同过滤

基于用户的协同过滤，基于item的协同过滤；简单来说就是喜欢A内容的用户，还喜欢B游戏（这种召回方式比较老，现在很少有公司会用）。

协同过滤和用户及游戏都有关，矩阵，玩过就是1，没玩就是0，没玩过的游戏很多，很多都是0，所以会做矩阵分解：用户矩阵和商品矩阵，每一列就是用户向量或商品向量。

2）word2vec（词向量）

（最早用于NLP中）需要拿到用户的玩游戏序列，每个游戏做one-hot编码，会有一个神经网络模型，输入是A→B→？→D→E，输出是C，或A→B→C→D去预测E。

模型中间的隐藏层就叫词向量，和游戏有关，和用户没关，拿数据的时候和用户有关（向量用法：用户和游戏算相似度：用户A和游戏B向量做相似度计算；用户和用户、游戏和游戏）。

3）内容匹配召回

这一块主要和标签（类别）召回有关，比如：用户玩了王者荣耀，那么可以尝试召回推荐类似王者荣耀的吃鸡游戏，这是基于内容标签的召回；又或者用户玩了植物大战僵尸1，那么也可以尝试推荐植物大战僵尸2/3等，这是基于知识储备的匹配。

4）高热召回（热门召回）

这一路召回主要是新用户用的比较多，新用户刚来APP，拿不到过多的用户信息且没有行为，这种情况下，平台高热召回就起了大作用，用来做新用户冷启动；用户冷启动这里不做过多结束，后面会有专门的一节做介绍。

5）基于上下文的召回

这个和用户在APP发生行为的时间、地点等场景有关系，例如游戏推荐在白天碎片休息时间推荐小游戏，在晚上休息时间推荐大游戏、游戏时长较长的游戏等；在其他垂类上体现的话，就像打车垂类对于用户位置信息的敏感，用户刷新闻的时间等等。

6）级联召回

一般的召回是用户点击做正样本，级联是用精排排在前面的游戏做正样本，排在后面的做负样本，做召回模型的正负样本。

7）其他召回

根据业务需求，还会有其他召回，且每路召回的数量也有差异，例如为了让新用户快速留下来，新用户高热召回占比较大，但老用户的话，为了挖掘用户兴趣多样化，高热召回占比会相对小一点。

召回层也是有模型的，尤其是做电商业务，召回的模型会更复杂。

2. 排序——粗排/精排

粗排和精排，都是排序，一个需要快速排序尽量去掉错误召回，一个需要贴合用户和业务需求精细准确排序。

粗排在召回和精排之间，一般需求从召回回来的万/千级别item集合中选择出千/百级别更符合业务需求的item送到精排层。平台内容少时，几乎很少会做粗排这一步，因为粗排最大的作用就是快速计算并截断召回量，使召回数据更准更适合推给用户，一般粗排需要在20ms内完成打分。

如果没有粗排模型，也可以在召回层和精排层用一些策略进行数量截断进精排，也是一种粗排手段，例如用点击转化率进行截断。

精排处理数据量少，需要模型做到更准确，通常会上一些复杂模型以及使用较多特征。

粗排和精排层可以是一个模型打分，也可以是多个模型打分融合再进行排序，多数业务需求情况下多数都是多个模型，根据业务需求，模型的目标不一样，但基本上都会有点击模型（ctr）。

下面就单独就点击模型来讲一下模型是怎么打分排序的，讲排序之前需要先知道2个概念——label和features，这2个数据，是ctr模型的主要训练数据。

label：用ctr模型举例，每个模型都有label（模型的预测目标），ctr模型的label就是用户对当下曝光的item有没有点击行为，有曝光点击就为正样本，label=1，有曝光无点击则为负样本，label=0。

features：就是特征。特征主要分为3类：用户特征、item特征、用户和item的交叉特征。

• 用户特征：用户本身的特征，例如年龄、性别、地理位置等、登录设备（iOS/Android）；

• item特征：item本身的特征，例如标签、物品ID、天级点击次数、评论量、热门排名等；

• 用户特征和item的交叉特征：例如item天级的点击次数、周级点击人数、天级曝光次数等。

可以看出，features是我们在推荐系统都能够收集到的数据，其中有离散型特征（例如男女、分类、整数等），也有连续型特征（例如点击率、自然数）。

在计算机只能处理数字编码的前提下，将这些信息进行编码转化，大多数推荐系统对于离散型特征多使用one-hot或embedding，对于连续性特征可以不用处理，或者先分段离散化，再使用one-hot编码。

（大多数公司使用离散型特征的较多，连续型特征使用较少，有时连续型特征也会做分桶处理——分段，其实就是变相地处理成离散型数据。）

*注，one-hot编码会将特征处理为[0 0 0 0 1]，embedding会将特征处理为[0.2 0.4 0.6 0.8]

在明确了 features 和 label 的定义之后，会构造对应的训练样本：

• 负样本 (曝光不点击)：([**0,0,0,1,0,0,**0.12,0.13,0.05, …, ], 0）

• 正样本 (曝光点击)：(**[0,0,1,0,0,0,**0.02,0.08,0.13, …, ], 1）

所以训练时 CTR 模型输入即为：特征向量和其对应的 0、 1 标签。

预测时，输入只有特征向量，模型输出一个 0~1 之间的数字，代表预估的 CTR 值，可以用来做排序。所以，建模之后，本质上 CTR 预估问题是一个二分类问题。

这就是其中一个模型的打分逻辑，有多模型打分融合的精排层，会将多个模型的分数进行打分，每个模型的重要性不一样，因此分数都会有权重，将每个模型的分数进行权重计算后相乘在一起，就是这个item的排序分数，每个item按照分数进行从高到底排序，就会得到精排打分列表。

3. 重排（混排/rerank）

这一步是推荐的最后一步，每个公司的叫法可能存在差异，有的叫重排，有的叫混排，学术一点叫rerank；虽然也是排序，但重排和粗排或精排最大的区别还是在于这一步更贴近业务需求，产品经理发挥的空间也相对多一些。

做一些强插业务的时候，需要召回配合重排层做，例如做新内容冷启动时，需要给到没有数据的内容一个曝光的机会，这个时候就需要用到重排强插；或者做一些打散逻辑时，例如连续的7个内容中不能有相似内容，或连续的10个内容中最多有2个相似内容等等。

二、搜索系统逻辑

当你在搜索框中输入一串搜索词后，页面展示出你想要的结果，但其中的逻辑却是很复杂，这里我认为搜索是比推荐相对复杂的业务：

整个流程的重点逻辑也包含了召回、排序、重排，但更为重要的是query处理部分，因为上面详细讲了 召回——排序——重排部分，因此这里不过多讲解，只将重点放在query处理上。

query主要由query预处理、意图识别、query分词、query改写4个部分组成，各公司会依照搜索业务的复杂程度进行部分简化；（query：用户搜索词，例如用户在搜索框输入“秋冬连衣裙女”并点击搜索，那么用户query就是“秋冬连衣裙女”）。

1）query预处理

这一步主要是针对用户在搜索框中输入的搜索词，进行数据清洗。

搜索词基本上都会有长度限制，一种是输入框限制搜索词长度，一种是query预处理的时候进行搜索词截断，例如超过20个字长度的搜索词只截取前20个字。

因为用户输入搜索词的不规范，且不同的用户对同一种诉求的表达往往会存在地域、文化程度以及清晰度的差异，因此会对搜索词进行转化：大小写转换，例如“太空狼人杀3d版”转换为“太空狼人杀3D版”；简繁体转换，例如“太空狼人殺”转换为“太空狼人杀”；还有全半角转换，这里就不再展开过多说明。

query预处理这一步都是根据用户主动输入的搜索词，进行高频query查询检索出的常见问题，针对问题进行本质问题本质解。

2）意图识别

意图识别的本质就是分类问题，主要是根据业务需求进行用户意图分类，分为几个大类，收集每种意图类别下的常用词进行模型训练，模型准确率越高，意图识别效果越好。意图识别在搜索系统中是必不可少的，意图识别在很大程度上决定了用户搜索质量的好坏。

*意图识别的难点：

1. 输入不规范；就像上面提到的，不同用户对同一个内容的认知存在差异，输入的搜索词也会存在不小的差异；

2. 数据冷启动，用户行为较少数据较少，意图获取会相对没那么准；

3. 多意图识别，无法定位精准意图，例如用户搜索“车”，无法知道是想要玩具车还是四轮真车，或者是摩托车；

4. 业界没有固定的评价标准，只有不同业务直接自己划分的分类进行的模型分类准确率计算，而一些业务指标例如ctr、cvr、pv等指标，都是评价整个搜索系统的，具体到意图识别上的量化指标却没有。

3）query分词

query分词主要是对用户搜索词进行切分，根据切分的词去进行改写以及后续的召回逻辑，不同业务的切词方式及自由切词库是有差异的。

4）query改写

这一步主要是针对用户搜索词进行纠错、以及同义词扩展召回等。需要做纠错词表或纠错模型，例如将“火才人”纠错为“火柴人”，将“超级猫丽奥”纠错为“超级马里奥”，将“校园”扩展为“学校”、“老师”、“教室”、“同桌”等等，同义词扩展里面会存在一些干扰词，需要根据实际业务对头部搜索词的同义词进行自定义切词表或自定义同义词表等。

三、推荐和搜索的区别

从上述对推荐系统和搜索系统的整体流程的讲述可以看出，推荐和搜索既有紧密联系，又有不小的差异。

1. 行为主动或被动

本质问题本质解，搜索和推荐都是为了解决信息过载问题，都是获取信息的方式之一，一个主动获取——搜索，一个被动获取——推荐：推荐行为是被动的，需求不是很明确，个性化和多样性会多一些，而搜索的需求是主动和相对明确的，且查询范围相对较小。

2. 使用场景目的

推荐的本质是需要留住用户在APP中，让用户使用的时间变长，并且第二天也能留住用户，逐渐产生广告收益和其他收益，让用户消费更多，需要通过分析用户的历史行为以及当前的实时行为场景等，推荐系统自发生成查询条件快速给出推荐列表的行为，是一种无声的搜索。

而搜索更像张小龙早期口中的微信，需要用完即走，搜索的本质是协助用户快速找到自己需要的结果并完成转化离开。我理解，好的搜索算法需要做的是让用户快速使用，高效查询并且停留时间更短。

3. 是互相成就

从流程来看，搜索就是限定了条件的推荐，推荐就是自发的主动搜索；从用户query中可以收集到大量个性化推荐的需求，推荐数据可以推荐用户搜索内容的相似内容，进行数据融合，而当用户搜索目的不明确时使用好的推荐，结合意图识别和推荐模型，实现类目下的更精准推荐，是提升用户体验的手段。

以上就是我对推荐和搜索场景在实际项目中的逻辑梳理，如果有感兴趣的同学，欢迎私聊。

加油，打工人！

作者 @王九蛋

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！