查询是什么意思(搜索策略产品必读系列)
编辑导语：在召回搜索结果时，我们首先要知道用户经常搜索哪些类别的查询，从而建立我们的整体召回策略。那么，根据不同类型的查询，我们应该使用什么样的回忆策略呢？我们一起来看看吧。
前言：上一篇文章介绍了电子商务APP搜索引擎的整体框架，本文详细介绍了如何召回搜索结果。
01用户常见查询分类所有召回都是基于用户的查询。首先，我们需要知道用户经常搜索哪些类型的查询，这样我们就可以根据用户的查询清楚地构建我们的整体召回策略。我们将用户的查询分为以下几类：
1.单实体和多实体就用户的查询结构而言，分别是单实体和多实体。上一篇文章介绍了分词后的实体识别，最后把整个查询分成几个实体。
例如，& quot苹果& quot是一个实体。当然，它可能有多个实体属性。"苹果& quot可以是品牌，也可以是SPU。"苹果电脑& quot是一个多实体。在此查询中，& quot苹果& quot是一个品牌& quot电脑& quot是一个SPU。这个查询由两个实体词组成。
2.实体识别后得到查询的实体词，意图明确，模糊。用户查询的意图也分为几个层次：
1)清除
例如，& quot水果& quot是一个类别，我们返回苹果、香蕉、葡萄等都在用户的意图之内。
2)更加清晰
比如& quot早餐& quot，& quot小菜& quot和& quot午餐& quot，我们可以猜测用户想要搜索什么。早餐可以是豆浆、馒头等。& quot小菜& quot可以是泡菜和朝鲜泡菜，还有& quot午餐& quot可能是一些午餐和三明治。
3)模糊
在实际业务中，很多用户的查询仅仅从字面意思是猜不到用户的真实意图的，比如& quot甜蜜& quot，& quot辣& quot和& quot干& quot，以及许多单字查询。
是否& quot甜蜜& quot是甜筒还是甜辣酱完全是两种商品，用户的本意肯定是只想到其中一种。至于为什么用户会有这样模糊的查询，一方面可能与用户的输入法有关，另一方面可能是用户没有输入完整；同时，这类查询词在网上频繁出现，我们也需要猜测用户对这类词的意图，尽可能回忆相关度高的商品，而不是只搜索没有结果。
以上主要介绍了用户的查询类型，那么对于各种类型的查询我们使用什么样的召回策略呢？
02召回策略1简单Match机制。
很多电商app在一开始做搜索召回的时候，采取的是一种比较粗暴的做法，就是简单的将用户的查询与商品名进行匹配，或者是分词后的Macth与商品名进行匹配，没有实体识别的步骤。
这将引导用户搜索& quot水，虽然& quot矿泉水& quot和& quot纯净水& quot将被召回，因为它们含有& quot水。但是，水桶，饺子等。也含有水，在Macth层面上和矿泉水、纯净水没什么区别。搜索大米，年糕，虾米，米饭都是一样的。
这种方法虽然实现简单，但是实际效果很差，召回的结果特别混乱。
这种粗糙的方法逐渐被市场淘汰，策略二是目前市场上的主要方法。
03召回策略2根据实际业务场景和业务需求，以实体识别、查询重写、分层召回为基础，结合业务运营策略和自底向上策略。
1.预处理预处理就是纠错，切字，拼音转换成汉字，去停字。目前中文分词广泛使用的是hanlp和ES ik。
假设用户输入& quot康师傅红烧方便面* % & quot。
截词：首先，将整个查询截成词，比如& quot康师傅& quot，& quot红烧& quot，& quot方便面& quot，* & quot和& quot% & quot拼音成汉字；然后，把拼音康师傅转换成康师傅，去停字；用& quot删除停用词* & quot和& quot% & quot没有任何意义；2.经过实体识别的预处理后，将进行实体识别。
识别了，一般最开始我们需要先建立该领域的实体体系，也就是该领域经常关注的一些属性等。比如下图是阿里云关于电商领域建立的实体体系。而我们对2.21预处理完剩下的“康师傅”、“红烧”、“方便面”进行实体识别，最终得到【Brand：康师傅；Taste：红烧；SPU&CATEGORY：方便面】。很多词汇并不是只有一个实体，比如这里的“方便面”，它既是一个SPU又是一个CATEGORY。
对于实体词库中不存在的实体词识别不出。比如用户搜索“苹果”，如果“苹果”这个词根本没有被实体词库所收集，那么我们的分析器也就识别不了“苹果”到底是代表什么实体？这就和人类学习一个新词汇一样，必须要有人教我们这个新词汇到底是什么意思，不然我们只能瞎猜。
对于实体识别不出的词，一般我们也不是直接忽略，而是将这类词打上一个“OTHER”的性质，用“OTHER”来表示它，也会继续进入召回阶段；还有一种方式就是“瞎猜“，就和人类学习新词汇，我可以瞎猜一下它的意思。
当然计算机不是瞎猜，一般情况下我们是会对历史所有的实体词进行分类，构建一个分类体系，然后基于历史数据训练一个分类模型，当一个全新的词进入时，我们就会通过该分类模型去预测，这个新词应该是属于哪个分类下面。
如果是单个实体Query，此时实体识别出来多性质是合理的，比如用户搜索“苹果”，它既可能是“Brand”，也可能是“SPU”，二者都存在可能性，所以实体识别出来的最终结果就是多性质。但是对于“苹果手机”，我们就不能认为“苹果”既是“SPU”又是“Brand”，因为结合后面的实体“手机”，这里的“苹果”只能是Brand。
所以在多实体Query中，我们一般每个实体只取一个性质，如果某个词存在多性质，此时我们会通过模型去计算每个性质的概率，然后取最高概率的那个性质。
经过实体识别后，我们需要再对Query进行改写：
很多实体词是存在完全一样的同义词，所以召回时我们也需要将同义词作为召回条件。比如“小番茄”和“圣女果”，“香菜”和“芫荽”。
很多词之间并不是完全相同，二者也不是包含关系，但是存在一定的近似性，某种程度上可以进行替代。比如“矿泉水”和“纯净水”，“纯牛奶”和“舒化奶”等。
为什么我们还建立近义词词库，是因为某些场景中，比如很多生鲜电商APP中，用户在定位到某一家门店时，搜索“矿泉水”，假设该门店没有，我们如果直接展示搜索无结果，那么就是白白浪费了一个销售机会，但如果我们将“纯净水”也展示出来，其实用户很多时候也会下单，因为二者差异不大。
当然此部分功能，有些APP会做在“为你推荐”里面，具体展现在哪里不重要，背后的逻辑是一致的。
此类词汇和近义词不同之处在于，很多时候是存在一种包含关系。比如“苹果和红富士”、“早餐和包子、馒头、豆浆”，用户搜索“红富士”时，如果没有“红富士”，通过意图词我们可能就会展示其他苹果。用户搜索“早餐”，当既没有“早餐”这个CATEGORY，又没有商品叫做“早餐”时，我们只能通过这一类意图词进行关联。
为什么我们将词库拆解的如此细致，分为同义词、近义词、意图词等等，是因为不同场景下我们需要使用不同的词库组合，如果都混合在一起就十分混乱，想拆解时都无法拆解。如何去构建积累上述的词库，一方面需要运营通过人工经验的方式进行添加，另一方面就是机器去历史用户的搜索记录、埋点数据数据等进行挖掘，形成相关词库再进行人工审核。
视业务方具体需求。实体权重调整在综合电商APP使用的是最多的，也是上一篇介绍过的，比如用户搜索
所以我们需要重新构建召回条件，进行Query改写，挑选比较重要的条件去召回，其他条件忽略。我们可以将Query改写为
上述四大类Query改写，同义词改写是必须的，近义词改写和意图词改写一般情况我们都是用在召回结果比较少的搜索场景下使用，希望尽可能多地展示一些搜索结果，不浪费每一次曝光机会。实体权重调整有时候是召回结果过多，需要精简；有时候是召回结果过少，希望扩增，具体视业务需求。
当经过上述一系列实体识别和Query改写后，我们就会去ES索引里已经结构化好的物料库进行商品召回。比如用户搜索“康师傅”，实体识别后为【Brand：康师傅】，我们就会将所有物料Brand这个Label=“康师傅”的进行召回。如何对物料库进行结构化处理，可以参考上一篇文章。
但有时候业务方要求用户搜索某些词汇时，必须将一些商品召回，这些商品可能上述一整套召回逻辑无法覆盖。比如用户搜索“夏日解暑”，这个词汇可能和任何商品都无法直接形成关联，但我们通过硬编码的方式强行让该搜索词和“冰棒”、“雪糕”、“冰淇淋”等进行关联，这样也可以搜索出结果来。
此策略一般我们都是开发成通用的运营操作界面，由运营在系统页人工每日进行添加、删除、修改等，做成一个通用的产品功能。
最后整个召回还会存在一个兜底策略，其实主要就是Part2.1的Match机制，比如用户只搜索一个“甜”字，也就是我们上文中介绍的实体识别出来是一个“OTHER”性质，我们很难识别用户的真实意图，到底是“甜筒”、“甜辣酱”还是“甜玉米”等，这时我们只能通过和商品名Match的机制，将所有商品名中含有“甜”字的商品全部召回。
同时如果该词汇是一个正常词汇，但是并没有收录到我们的实体词库里面，我们也可以通过兜底策略保证有结果可以召回，而不是结果为空。但是召回后这些商品如何进行排序了？这也就是下一篇要为大家介绍的：电商APP智能搜索第三讲—如何排序搜索结果。
本文由@KingJames原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议