搜索召回
概念
用户输入搜索query后，系统如何从库中找到命中query词的商品？暴力的方法是先对query进行分词得到每个query的term，而后遍历每个商品信息的每个term词，如果query term在商品信息中全部命中，则召回该商品。
召回是对于输入query，能够高效的获取query相关的候选doc集合。
所有的召回都是根据用户的Query来的，首先我们要清楚用户经常搜索的Query分为哪几类，我们才能够清晰地根据用户的Query去构建我们整体的召回策略。我们将用户的Query分为以下几个大类
召回策略
简单Match机制
很多电商APP在最开始做搜索召回时，采用的都是比较粗暴的做法，就是简单地将用户的Query和商品名进行匹配，或者是经历切词后再和商品名进行Macth，没有实体识别这一步。这就会导致用户搜索“水”，虽然“矿泉水”、“纯净水”等会被召回，因为含有“水”。但是“水桶”、“水饺”等也含有“水”，在Macth的层面上和“矿泉水”、“纯净水”并没有差异，搜“米”，“米饼”、“虾米”和“大米”是完全一样的。此类方法虽然实现起来很简单，但是实际效果很差，召回的结果特别混乱。
层次性召回
以实体识别为基础，配合同义词、近义词、意图词等进行Query改写，根据实际业务场景和业务需求，再结合业务运营策略和兜底策略，进行层次性召回。
预处理
预处理就是对Query进行纠错、切词、拼音转汉字、去停用词等。
实体识别
一般最开始我们需要先建立该领域的实体体系，也就是该领域经常关注的一些属性等。
实体识别有三个非常重要的问题：
- 第一实体识别完全依赖词库：对于实体词库中不存在的实体词识别不出。
- 第二实体识别不出的词如何进行处理：对于实体识别不出的词，一般我们也不是直接忽略，而是将这类词打上一个“OTHER”的性质，用“OTHER”来表示它，也会继续进入召回阶段；还有一种方式就是“瞎猜“，一般情况下会对历史所有的实体词进行分类，构建一个分类体系，然后基于历史数据训练一个分类模型，当一个全新的词进入时，通过该分类模型去预测，这个新词应该是属于哪个分类下面。
- 第三实体存在多性质如何处理：如果是单个实体Query，此时实体识别出来多性质是合理的，比如用户搜索“苹果”，它既可能是“Brand”，也可能是“SPU”。但是对于“苹果手机”，结合后面的实体“手机”，这里的“苹果”只能是Brand。所以在多实体Query中，一般每个实体只取一个性质，如果某个词存在多性质，此时我们会通过模型去计算每个性质的概率，然后取最高概率的那个性质。
Query改写
经过实体识别后，我们需要再对Query进行改写：
- 同义词改写：很多实体词是存在完全一样的同义词，所以召回时也需要将同义词作为召回条件。比如“小番茄”和“圣女果”。
- 近义词改写：很多词之间并不是完全相同，二者也不是包含关系，但是存在一定的近似性，某种程度上可以进行替代。比如“矿泉水”和“纯净水”，“纯牛奶”和“舒化奶”等。
- 意图词改写：此类词汇和近义词不同之处在于，很多时候是存在一种包含关系。比如“早餐和包子、馒头、豆浆”。用户搜索“早餐”，当既没有“早餐”这个CATEGORY，又没有商品叫做“早餐”时，只能通过这一类意图词进行关联。
- 实体权重调整：视业务方具体需求。
业务运营策略
有时候业务方要求用户搜索某些词汇时，必须将一些商品召回，这些商品可能上述一整套召回逻辑无法覆盖。比如用户搜索“夏日解暑”，这个词汇可能和任何商品都无法直接形成关联，但我们通过硬编码的方式强行让该搜索词和“冰棒”、“雪糕”、“冰淇淋”等进行关联，这样也可以搜索出结果来。
兜底策略
整个召回还会存在一个兜底策略，比如用户只搜索一个“甜”字，也就是我们上文中介绍的实体识别出来是一个“OTHER”性质，很难识别用户的真实意图，到底是“甜筒”、“甜辣酱”还是“甜玉米”等，这时我们只能通过和商品名Match的机制，将所有商品名中含有“甜”字的商品全部召回。同时如果该词汇是一个正常词汇，但是并没有收录到我们的实体词库里面，我们也可以通过兜底策略保证有结果可以召回，而不是结果为空。
