编辑导语：搜索在很多场景中对于流量的转化都高于推荐，对于业务的增长也远远超过推荐，然而讲搜索的文章却很少。本篇文章中作者介绍了电商APP的智能搜索引擎，讲解了AI时代如何做搜索，一起来学习一下。
现在市面上太多人聊推荐，关于推荐的书也有很多很多。
搜索聊的人却很少很少，但是搜索在很多场景中对于流量的转化远远超过推荐，搜索转化的提升对于业务的增长要远远超过推荐。
知乎和各大博客里面介绍搜索的文章相对于推荐就少太多了，专门开一个系列和大家聊一聊电商APP智能搜索，AI时代如何做搜索。
首先确定一下我们聊得搜索并不是Baidu、Google这种综合搜索引擎，而是像淘宝、京东、美团这类电商APP里面的搜索引擎。
用户通过在搜索框中输入关键词，然后搜索引擎返回相关商品，并按照一定顺序返回展示给用户。电商APP里的搜索引擎和我们平时使用的Baidu、Google主要有什么差异了：
用户使用综合类搜索引擎Query的复杂度很高，很多时候是一种探索式的搜索，比如用户搜“经典电影”，百度会首先返回百度自身推荐的经典电影，然后后面会有大量含“经典电影”字样的帖子。很多时候用户的Query甚至是一种描述性的语句比如“含有爱情的诗句”。
而电商APP里的搜索引擎因为场景固定，用户搜索目的性很强，Query意图比较明确如“男鞋”、“长裤”、“可乐”等，一方面用户目的性强，另一方面用户也知道该场景下Query过于探索是不会有结果的，用户有一定的认知判断。
所以综合类搜索引擎需要对用户的搜索意图识别的很准确，而电商场景的搜索引擎会相对要求低一些。
二者背后存储的数据多样性差异很大，体量差异更大。
电商APP搜索引擎搜索的结果一定都是呈现在APP上的。但是综合类搜索引擎完全不是，搜索结果来自于各大网站，很多结果是外部链接。内容形式各种各样：视频、文字、音频等等。
综合类搜索引擎背后存储着大量的数据，同时数据在不停地增加和更新。而电商APP搜索引擎背后的数据池都仅限于该APP上的商品，即使商家不停地上下架商品，整体数据量和综合类搜索引擎差距也是巨大的。
那么我们为什么说电商APP中的搜索引擎特别重要。
一方面随着网上购物消费群体的多样化以及年轻人不断增强的自主意识，用户已经从传统的“被动”接受网站推荐的商品信息，转变为“主动”去发现商品，发掘自己感兴趣的商品。
那么APP中的搜索功能就成为了非常重要的功能，能否识别用户的意图并且准确地返回相应的商品就十分关键。
另一方面数据显示：
搜索引擎占据的销售归因目前普遍在%以上，搜索占据淘宝的销售归因约为%左右。
销售归因即为该平台上各个流量转化入口如：搜索入口、分类页入口、首页推荐入口等对最终的销售贡献占比。通过上面的数据我们可以清晰地得出搜索目前对于整个业务流量的转化贡献是最大的。
在综合类电商APP刚刚开始时，最大的销售归因模块是分类页，也就是我们看到淘宝上的“女装”、“手机”、“男装”等模块，但现在已经是搜索入口贡献着最多的流量转化。
搜索入口占据的销售归因目前普遍在%-%左右。
生鲜电商APP为像盒马、叮咚买菜、每日优鲜这类专门卖生鲜为主的APP。因为生鲜电商整体商品相对于综合电商APP少很多，用户每日在APP上面买菜，除了搜索入口，分类页也占据着生鲜电商APP非常大的销售归因，几乎和搜索入口一样也在%-%左右。
通过上面的数据我们可以直观地看出搜索功能对于电商APP流量的转化起到多大的作用。
同时我们再算一笔账：
年淘宝全年成交金额为亿美金，假设其中%是由搜索转化的，也就是说亿美元是由搜索入口转化的。
那么如果我们通过提升搜索体验，丰富搜索辅助功能等，将%的搜索销售归因转化净提升个点到%。
淘宝全年的销售额将增长.亿美元，这是一个什么概念？年叮咚买菜全年销售额为亿RMB，大概是个叮咚买菜的体量。所以互联网企业都在大力提升搜索的转化率，转化率每一个点的提升，带来的都是全年业务量的巨大增长。
介绍完搜索的重要性，那么我们如何去提升搜索的转化率，如何去搭建一个搜索引擎，在电商APP中的搜索引擎整体框架到底是怎么样的了？我们用下图来进行表示：
下面我们针对上图中的每个模块一个一个进行详细介绍。
分析器的作用就是对用户的Query进行处理，进行纠错预处理后，然后再进行切词、拼音转汉字、去停用词等，最后将整个Query分成单个词组合以后再进行实体识别。
比如用户输入了“kangshifu红烧方便面*% ”，
）切词
先对整个query进行切词，切分为“kangshifu”、“红烧”、“方便面”、“*”、“%”。切词这部分功能工业界有一些通用的切词器，比如ik切词、hanlp切词器，但是我们实际使用时都会再加入更多的词库进行切词，不仅仅是使用现成的切词器。
）拼音转汉字
再将拼音kangshifu转化为康师傅；
）去停用词
将“*”、“%”没有任何意义的停用词去除掉；
）实体识别
最后对剩下的“康师傅”、“红烧”、“方便面”进行实体识别，我们不仅需要把固定搭配的词切分出来，我们还需要知道这些词代表的实体含义，最终得到【Brand：康师傅；Taste：红烧; SPU &CATEGORY：方便面】。很多词汇并不是只有一个实体，比如这里的“方便面”，它既是一个SPU又是一个CATEGORY。
上面提到的一系列操作都离不开词库，没有词库分析器寸步难行。我们知道“kangshifu红烧方便面%”里面的kangshifu应该是“康师傅”，然后Query的断句应该是“康师傅”、“红烧”、“方便面”而不是“康”、“师傅”、“红”、“烧方便面”，就因为我们已经对这些词汇固定搭配有了一定知识积累，同时“*%”对于查询是没有任何意义的，也是基于我们历史的词汇和知识积累。
但是计算机不知道，我们如何让计算机知道“康师傅”是一个固定搭配，同时它是一个Brand，这就需要我们建立各种各样的词库了。
电商APP搜索引擎中词库是非常重要的，第一词库全不全，第二词库准不准。不同行业不同领域会有自己专门的词库，大部分词库都不是通用的。下图是阿里云Opensearch建立的电商行业的实体词库类型。
但其实还有很多实体词库类型需要补充，比如生鲜电商业的SPU、口味、包装等。同时还会存在大量的同义词库、近义词库、纠错词库、拼音词库等等。
计算机如何知道用户搜索“圣女果”和“小番茄”是一种东西，这就需要同义词库。
同义词库需要大量的积累，尤其是在生鲜电商领域，同样一种菜，全国各地叫法都不一样，但是对应的是同一种菜。同时还存在同一种叫法，对应的是不同种食物，比如“珍珠米”在上海就是玉米粒，在东北是一种大米。
所以词库的建立是必不可少的，同时又是一个需要长久积累，且持续更新不断细化的过程。
当我们将“kangshifu红烧方便面*% ”经过分析器处理后，得到【Brand：康师傅；Taste：红烧; SPU&CATEGOY：方便面】后，我们需要构建召回条件，就是用上述哪些实体去物料库中进行召回。
）物料库结构化梳理
召回的基础就是电商APP的搜索针对的物料是固定的，也就是当前APP上架的所有商品，背后对应的就是整个APP物料库。在最开始时我们就需要对整个物料库进行结构化梳理，数据库里面存储的是结构化数据，而不只是一个商品名“康师傅红烧牛肉面g”。
结构化数据如下图：
如何对物料进行结构化梳理，一方面就是物料入库时商品运营需要人为手动地对商品进行CATG、、进行分类，需要分类清楚，相应的规格、产地等等都需要输入准确，另一方面就是模型根据一定的规则通过商品名进行相关实体的提取，比如口味、SPU等，这个前提建立在商品名是正确且完整的，如果商品名本身没有该实体信息，模型也是无法提取的。
目前业内通用的分布式搜索引擎是Elasticsearch,查询速度很快。结构化的物料数据都存储在Elast
）召回条件构建
【Brand：康师傅；Taste：红烧; SPU&CATEGOY：方便面】通常情况下我们会将实体之间通过and关系去物料库中进行召回，但上述“方便面”存在两个属性，所以会两个属性分别去进行召回。
同时我们也会加入同义词，构建新的召回条件，比如“方便面”的同义词存在“泡面”，同时同义词性是在SPU这个实体下存在的，所以我们会再构建一个召回条件【Brand：康师傅；Taste：红烧; SPU：泡面】。
在生鲜电商中召回条件构建比较简单，但在综合电商中比如用户搜索【王一博同款白色卫衣限量版】，我们就需要拆分召回条件，如果用【王一博 and 同款 and 白色 and 卫衣 and 限量版】去索引中进行召回，可能召回的结果就会很少。
所以我们需要重新构建召回条件，进行Query改写，挑选比较重要的条件去召回，其他条件忽略。我们可以将Query改写为【王一博 and 白色 and 卫衣 】所以实体与实体之间是存在优先级的，有些实体属性是要优于其他实体属性的。
最终我们召回得到搜索结果。
召回的搜索结果如何进行排序了，一般我们从以下两个方面进行考虑：
）相关性排序
商品和Query的相关性程度，比如用户搜“康师傅红烧牛肉面g”那么肯定是“康师傅红烧牛肉面g”的商品排序在最前面，“康师傅红烧牛肉面g大袋”排序在后；
）业务规则排序
另外我们也要结合商品历史的销量、用户的喜爱程度、价格、促销等一系列因素综合考虑，比如用户搜索“方便面”，方便面的种类太多：康师傅、统一、汤达人等等。和“方便面”的相关性都是完全一样的，这时候我们可能会将历史销量高的、用户喜爱程度高的商品排序在前。
通常情况下第一种和第二种我们是综合在一起进行加分，然后再对商品进行综合排序。
）机器学习模型
通过历史用户的点击、购买、收藏、加购数据等，构建机器学习模型，然后模型来进行千人千面的排序，这也是目前市场上主流电商APP的做法，每个人搜索同一个词，看到的结果是完全不一样的，
上述整体地介绍了召回和排序模块，实际应用中召回和排序模块还有很多细节，后续我们会专门再对这两个模块进行详细介绍。
上述是一些通用的规则或者模型排序策略，实际业务方还会有一些其他要求，比如最近业务方在对“康师傅”牌的方便面做市场推广活动，那么在用户搜索“方便面”时，业务方就希望我们将所有“康师傅”品牌的方便面排序在前。
所以很多时候Ranking的结果还需要经过一层Reranking再排序，这一层主要是业务策略的排序。
最后就是AB Test实验台，很多时候我们线上有很多套搜索策略，为了对比不同策略的用户点击效果等，我们需要同时进行AB Test实验，也就是我们类似我们高中学过的控制变量法，同一时间段线上生产APP，用户的访问进行随机切分到不同的实验桶中，最终对比二者的效果。
上面就是一个电商APP搜索引擎通常的整体框架了。
当我们将搜索引擎搭建好以后，如何去评估搜索引擎的好坏了？通过哪些指标去评估搜索的效果。
线下评估对于搜索来说是最难评估的，当搜索引擎没有上线时我们如何去评估搜索引擎的效果好坏。这个时候我们需要构建测试case，并对这些测试case进行数据标注。
比如我们从用户历史搜索词中随机抽取个Query，然后人工针对这些Query进行物料标注，每一个Query应该召回哪些商品，每个商品的相关度分数是多少。我们不会对所有物料进行标准，因为工作量太大了，通常标注几千到万个物料。
然后将相关度分为几个档次，比如【，，-】三个档次，表示强相关，表示一般相关，-表示不相关。然后人工根据自己的经验进行标注。
比如物料是【康师傅方便面、统一方便面、康师傅矿泉水、汤达人方便面】
那么Query=“方便面”时，我们可以标注为【，，-，】；
Query=“康师傅方便面”时，可以标注为【，，-，】；
这些标注都是人工进行标注的，标注员的标准不一样，可能整个结果完全不一样，所以最开始就需要大家统一好标准，很多时候我们是根据搜索引擎的策略进行标注。
）召回率（评估召回结果是否齐全的指标）
用户搜“方便面”，只召回了“康师傅方便面”，那么召回率=/；如果三款方便面全部召回了，召回率=/=%；
）DCG&NDCG指标（评估排序是否合理的指标）
搜索引擎不仅要将所有商品召回，排序也要合理，理论上打分结果最高的结果排序在最前面，打分结果最低的排序在最后面，搜索“康师傅方便面”，不能是“汤达人方便面”排序第一位。具体计算公式如下：
线上我们可以使用很多种指标进行多方面效果评估，一般采用如下指标：
）查询无结果率
评估召回效果，通常该指标越低越好，说明大部分搜索都是有结果的；
）平均点击商品位数
评估排序效果，通常该指标越小越好，说明用户在结果页的前面就找到了自己感兴趣的商品；
）CTR
点击转化率是综合评估搜索的效果，用户搜索后的点击情况，是否点击是由召回结果和排序情况共同决定的，CTR越高越好；
）加购率
加购率也是综合评估搜索的效果，对于搜索结果是否加购，加购率越高越好；
）跳失率
进入搜索结果页后用户是否没有任何操作就跳出了，如果该指标很高，说明用户对于搜索结果不满意和不感兴趣，跳失率越低越好。
