召回-callback

## 1. 用户常见Query分类

所有的召回都是根据用户的Query来的，首先我们要清楚用户经常搜索的Query分为哪几类，我们才能够清晰地根据用户的Query去构建我们整体的召回策略。我们将用户的Query分为以下几个大类：

![](/media/202401/rec2-1_1704612274.png)

### 1.1 单实体和多实体

从用户的Query结构上来讲，就是单实体和多实体，上篇文章介绍过经过切词后的实体识别，最终整个Query被分为几个实体。比如“苹果”就是一个实体，当然它可能有多个实体性质，“苹果”既可以是一个Brand，也可以是一个SPU。“苹果电脑”就是多实体，在此Query中“苹果”是一个Brand，“电脑”是一个SPU，该Query是由两个实体词组合而成。

### 1.2 意图明确、较明确、模糊

实体识别后得到Query的实体词，用户Query的意图也是分为几个级别：

- 明确：比如“水果”，水果是一个CATEGORY，我们返回苹果、香蕉、葡萄等是在用户的意图以内的；
- 较明确：比如“早餐”、“配菜”、“午饭”，这些词汇我们能够猜测到用户想搜索什么，早餐可以是豆浆、包子等，“配菜”可以是一些酱菜、韩国泡菜，“午饭”可以是一些便当、三明治等；
- 模糊：实际业务中用户很多的Query单凭字面意思很多时候是无法猜测到用户的实际意图， 比如“甜”、“辣”、“干”等，很多单个字的Query。“甜”到底是甜筒还是甜辣酱，这是完全两类商品，用户的本意肯定是只想其中一种。至于为什么用户会出现这类模糊的Query，一方面可能和用户的输入法有关，另外一方面可能是用户没有输入完整；同时这类Query词在线上出现的频率很高，针对这类词我们也需要猜测用户意图，尽可能召回相关度高的商品，而不仅仅是搜索无结果。
上述主要为大家介绍用户的Query分为哪些类型，那么针对各种类型的Query我们使用什么样的召回策略了？

## 2. 召回策略

### 2.1 简单Match机制

很多电商APP在最开始做搜索召回时，采用的都是比较粗暴的做法，就是简单地将用户的Query和商品名进行匹配，或者是经历切词后再和商品名进行Macth，没有实体识别这一步。这就会导致用户搜索“水”，虽然“矿泉水”、“纯净水”等会被召回，因为含有“水”。但是“水桶”、“水饺”等也含有“水”，在Macth的层面上和“矿泉水”、“纯净水”并没有差异，搜“米”，“米饼”、“虾米”和“大米”是完全一样的。此类方法虽然实现起来很简单，但是实际效果很差，召回的结果特别混乱。

此类比较粗暴的方法也慢慢被市场淘汰，目前市场上主要以2.2方式为主。

### 2.2 以实体识别为基础，配合同义词、近义词、意图词等进行Query改写，根据实际业务场景和业务需求，再结合业务运营策略和兜底策略，进行层次性召回

![](/media/202401/rec2-2_1704612528.png)

### 2.21 预处理

预处理就是对Query进行纠错、切词、拼音转汉字、去停用词等。中文的分词器目前用的比较广泛的是hanlp和ES的ik切词。

![](/media/202401/rec2-3_1704613190.png)
假设用户输入了“kangshifu红烧方便面*% ”，

切词：先对整个query进行切词，切分为“kangshifu”、“红烧”、“方便面”、“*”、“%”
拼音转汉字：再将拼音kangshifu转化为康师傅；
去停用词：将“*”、“%”没有任何意义的停用词去除掉；
### 2.22 实体识别

预处理完以后就是进行实体识别了，一般最开始我们需要先建立该领域的实体体系，也就是该领域经常关注的一些属性等。比如下图是阿里云关于电商领域建立的实体体系。

而我们对2.21预处理完剩下的“康师傅”、“红烧”、“方便面”进行实体识别，最终得到【Brand：康师傅；Taste：红烧; SPU &CATEGORY：方便面】。很多词汇并不是只有一个实体，比如这里的“方便面”，它既是一个SPU又是一个CATEGORY。

实体识别有三个非常重要的问题：

第一实体识别完全依赖词库：对于实体词库中不存在的实体词识别不出。比如用户搜索“苹果”，如果“苹果”这个词根本没有被实体词库所收集，那么我们的分析器也就识别不了“苹果”到底是代表什么实体？这就和人类学习一个新词汇一样，必须要有人教我们这个新词汇到底是什么意思，不然我们只能瞎猜；
第二实体识别不出的词如何进行处理：对于实体识别不出的词，一般我们也不是直接忽略，而是将这类词打上一个“OTHER”的性质，用“OTHER”来表示它，也会继续进入召回阶段；还有一种方式就是“瞎猜“，就和人类学习新词汇，我可以瞎猜一下它的意思。当然计算机不是瞎猜，一般情况下我们是会对历史所有的实体词进行分类，构建一个分类体系，然后基于历史数据训练一个分类模型，当一个全新的词进入时，我们就会通过该分类模型去预测，这个新词应该是属于哪个分类下面。
第三实体存在多性质如何处理：如果是单个实体Query，此时实体识别出来多性质是合理的，比如用户搜索“苹果”，它既可能是“Brand”，也可能是“SPU”，二者都存在可能性，所以实体识别出来的最终结果就是多性质。但是对于“苹果手机”，我们就不能认为“苹果”既是“SPU”又是“Brand”，因为结合后面的实体“手机”，这里的“苹果”只能是Brand。所以在多实体Query中，我们一般每个实体只取一个性质，如果某个词存在多性质，此时我们会通过模型去计算每个性质的概率，然后取最高概率的那个性质。
### 2.23 Query改写

经过实体识别后，我们需要再对Query进行改写：

同义词改写：很多实体词是存在完全一样的同义词，所以召回时我们也需要将同义词作为召回条件。比如“小番茄”和“圣女果”，“香菜”和“芫荽”。
近义词改写：很多词之间并不是完全相同，二者也不是包含关系，但是存在一定的近似性，某种程度上可以进行替代。比如“矿泉水”和“纯净水”，“纯牛奶”和“舒化奶”等。为什么我们还建立近义词词库，是因为某些场景中，比如很多生鲜电商APP中，用户在定位到某一家门店时，搜索“矿泉水”，假设该门店没有，我们如果直接展示搜索无结果，那么就是白白浪费了一个销售机会，但如果我们将“纯净水”也展示出来，其实用户很多时候也会下单，因为二者差异不大。当然此部分功能，有些APP会做在“为你推荐”里面，具体展现在哪里不重要，背后的逻辑是一致的。
意图词改写：此类词汇和近义词不同之处在于，很多时候是存在一种包含关系。比如“苹果和红富士”、“早餐和包子、馒头、豆浆”，用户搜索“红富士”时，如果没有“红富士”，通过意图词我们可能就会展示其他苹果。用户搜索“早餐”，当既没有“早餐”这个CATEGORY，又没有商品叫做“早餐”时，我们只能通过这一类意图词进行关联。
为什么我们将词库拆解的如此细致，分为同义词、近义词、意图词等等，是因为不同场景下我们需要使用不同的词库组合，如果都混合在一起就十分混乱，想拆解时都无法拆解。如何去构建积累上述的词库，一方面需要运营通过人工经验的方式进行添加，另一方面就是机器去历史用户的搜索记录、埋点数据数据等进行挖掘，形成相关词库再进行人工审核。

实体权重调整：视业务方具体需求。实体权重调整在综合电商APP使用的是最多的，也是上一篇介绍过的，比如用户搜索【王一博同款白色卫衣限量版】，我们就需要拆分召回条件，如果用【王一博 and 同款 and 白色 and 卫衣 and 限量版】去索引中进行召回，可能召回的结果就会很少。所以我们需要重新构建召回条件，进行Query改写，挑选比较重要的条件去召回，其他条件忽略。我们可以将Query改写为【王一博 and 白色 and 卫衣 】所以实体与实体之间是存在优先级的，有些实体属性是要优于其他实体属性的。
上述四大类Query改写，同义词改写是必须的，近义词改写和意图词改写一般情况我们都是用在召回结果比较少的搜索场景下使用，希望尽可能多地展示一些搜索结果，不浪费每一次曝光机会。实体权重调整有时候是召回结果过多，需要精简；有时候是召回结果过少，希望扩增，具体视业务需求。

### 2.24 业务运营策略

当经过上述一系列实体识别和Query改写后，我们就会去ES索引里已经结构化好的物料库进行商品召回。比如用户搜索“康师傅”，实体识别后为【Brand： 康师傅】，我们就会将所有物料Brand这个Label=“康师傅”的进行召回。如何对物料库进行结构化处理，可以参考上一篇文章。

![](/media/202401/rec4_1704613269.png)

但有时候业务方要求用户搜索某些词汇时，必须将一些商品召回，这些商品可能上述一整套召回逻辑无法覆盖。比如用户搜索“夏日解暑”，这个词汇可能和任何商品都无法直接形成关联，但我们通过硬编码的方式强行让该搜索词和“冰棒”、“雪糕”、“冰淇淋”等进行关联，这样也可以搜索出结果来。此策略一般我们都是开发成通用的运营操作界面，由运营在系统页人工每日进行添加、删除、修改等，做成一个通用的产品功能。

### 2.25 兜底策略

最后整个召回还会存在一个兜底策略，其实主要就是Part2.1的Match机制，比如用户只搜索一个“甜”字，也就是我们上文中介绍的实体识别出来是一个“OTHER”性质，我们很难识别用户的真实意图，到底是“甜筒”、“甜辣酱”还是“甜玉米”等，这时我们只能通过和商品名Match的机制，将所有商品名中含有“甜”字的商品全部召回。同时如果该词汇是一个正常词汇，但是并没有收录到我们的实体词库里面，我们也可以通过兜底策略保证有结果可以召回，而不是结果为空。但是召回后这些商品如何进行排序了？请看下一章推荐排序