搜索推荐在app中的应用导入

1. 搜索引擎是什么？
   首先确定一下我们聊得搜索并不是Baidu、Google这种综合搜索引擎，而是像淘宝、京东、美团这类电商APP里面的搜索引擎。
   用户通过在搜索框中输入关键词，然后搜索引擎返回相关商品，并按照一定顺序返回展示给用户。APP里的搜索引擎和我们平时使用的Baidu、Google主要有什么差异了：
   
- 用户的Query复杂度差异较大：用户使用综合类搜索引擎Query的复杂度很高，很多时候是一种探索式的搜索，比如用户搜“经典电影”，百度会首先返回百度自身推荐的经典电影，然后后面会有大量含“经典电影”字样的帖子。很多时候用户的Query甚至是一种描述性的语句比如“含有爱情的诗句”。而电商APP里的搜索引擎因为场景固定，用户搜索目的性很强，Query意图比较明确如“男鞋”、“长裤”、“可乐”等，一方面用户目的性强，另一方面用户也知道该场景下Query过于探索是不会有结果的，用户有一定的认知判断。所以综合类搜索引擎需要对用户的搜索意图识别的很准确，而电商场景的搜索引擎会相对要求低一些；
- 搜索结果池差异太大：二者背后存储的数据多样性差异很大，体量差异更大。APP搜索引擎搜索的结果一定都是呈现在APP上的。但是综合类搜索引擎完全不是，搜索结果来自于各大网站，很多结果是外部链接。内容形式各种各样：视频、文字、音频等等。综合类搜索引擎背后存储着大量的数据，同时数据在不停地增加和更新。而电商APP搜索引擎背后的数据池都仅限于该APP上的商品，即使商家不停地上下架商品，整体数据量和综合类搜索引擎差距也是巨大的。

2. APP中的搜索引擎为什么重要、
那么我们为什么说APP中的搜索引擎特别重要。
搜索引擎在APP中扮演着重要的角色。它是让用户直接到达目的地的通道，起到了一个引导用户走向的重要作用. 一个成熟的搜索功能是产品优秀的表现. 搜索功能影响到用户对产品资源的充分调动使用. 大部分的APP都有搜索功能，搜索功能影响到用户对产品资源的充分调动使用. 搜索功能的入口和方式会影响到用户的使用体验. 目前在搜索形式上主要有文字搜索、语音搜索、图片搜索等。

3. 搜索的整体框架
介绍完搜索的重要性，那么我们如何去提升搜索的转化率，如何去搭建一个搜索引擎，在电商APP中的搜索引擎整体框架到底是怎么样的了？我们用下图来进行表示：

![](/media/202401/rec1_1704546651.png)
下面我们针对上图中的每个模块一个一个进行详细介绍。
### 3.1 分析器
分析器的作用就是对用户的Query进行处理，进行纠错预处理后，然后再进行切词、拼音转汉字、去停用词等，最后将整个Query分成单个词组合以后再进行实体识别。

比如用户输入了“kangshifu红烧方便面*% ”，

![](/media/202401/rec2_1704548071.png)
- 切词：先对整个query进行切词，切分为“kangshifu”、“红烧”、“方便面”、“*”、“%”。切词这部分功能工业界有一些通用的切词器，比如ik切词、hanlp切词器，但是我们实际使用时都会再加入更多的词库进行切词，不仅仅是使用现成的切词器。
- 拼音转汉字：再将拼音kangshifu转化为康师傅；
- 去停用词：将“*”、“%”没有任何意义的停用词去除掉；
- 实体识别：最后对剩下的“康师傅”、“红烧”、“方便面”进行实体识别，我们不仅需要把固定搭配的词切分出来，我们还需要知道这些词代表的实体含义，最终得到【Brand：康师傅；Taste：红烧; SPU &CATEGORY：方便面】。很多词汇并不是只有一个实体，比如这里的“方便面”，它既是一个SPU又是一个CATEGORY。

### 3.2 词库
3.1里面提到的一系列操作都离不开词库，没有词库分析器寸步难行。我们知道“kangshifu红烧方便面%”里面的kangshifu应该是“康师傅”，然后Query的断句应该是“康师傅”、“红烧”、“方便面”而不是“康”、“师傅”、“红”、“烧方便面”，就因为我们已经对这些词汇固定搭配有了一定知识积累，同时“*%”对于查询是没有任何意义的，也是基于我们历史的词汇和知识积累。但是计算机不知道，我们如何让计算机知道“康师傅”是一个固定搭配，同时它是一个Brand，这就需要我们建立各种各样的词库了。

电商APP搜索引擎中词库是非常重要的，第一词库全不全，第二词库准不准。不同行业不同领域会有自己专门的词库，大部分词库都不是通用的。下图是阿里云Opensearch建立的电商行业的实体词库类型。

实体识别，全称命名实体识别（Named Entity Recognition，简称NER），指对查询词中的具有特定意义的语义实体进行识别。查询分析根据识别的结果，依据实体类型的权重对查询词进行改写，使得召回的文档符合查询的意图。目前，OpenSearch的实体识别只支持电商行业。主要实体类型如下：

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

但其实还有很多实体词库类型需要补充，比如生鲜电商业的SPU、口味、包装等。同时还会存在大量的同义词库、近义词库、纠错词库、拼音词库等等。计算机如何知道用户搜索“圣女果”和“小番茄”是一种东西，这就需要同义词库。同义词库需要大量的积累，尤其是在生鲜电商领域，同样一种菜，全国各地叫法都不一样，但是对应的是同一种菜。同时还存在同一种叫法，对应的是不同种食物，比如“珍珠米”在上海就是玉米粒，在东北是一种大米。

所以词库的建立是必不可少的，同时又是一个需要长久积累，且持续更新不断细化的过程
### 3.3 Recall & Elasticsearch索引
当我们将“kangshifu红烧方便面*% ”经过分析器处理后，得到【Brand：康师傅；Taste：红烧; SPU&CATEGOY：方便面】后，我们需要构建召回条件，就是用上述哪些实体去物料库中进行召回。
- 物料库结构化梳理
召回的基础就是电商APP的搜索针对的物料是固定的，也就是当前APP上架的所有商品，背后对应的就是整个APP物料库。在最开始时我们就需要对整个物料库进行结构化梳理，数据库里面存储的是结构化数据，而不只是一个商品名“康师傅红烧牛肉面100g”。结构化数据如下图：

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

如何对物料进行结构化梳理，一方面就是物料入库时商品运营需要人为手动地对商品进行CATG1、2、3进行分类，需要分类清楚，相应的规格、产地等等都需要输入准确，另一方面就是模型根据一定的规则通过商品名进行相关实体的提取，比如口味、SPU等，这个前提建立在商品名是正确且完整的，如果商品名本身没有该实体信息，模型也是无法提取的。

目前业内通用的分布式搜索引擎是Elasticsearch,查询速度很快。结构化的物料数据都存储在Elasticsearch中。

- 召回条件构建

【Brand：康师傅；Taste：红烧; SPU&CATEGOY：方便面】通常情况下我们会将实体之间通过and关系去物料库中进行召回，但上述“方便面”存在两个属性，所以会两个属性分别去进行召回。同时我们也会加入同义词，构建新的召回条件，比如“方便面”的同义词存在“泡面”，同时同义词性是在SPU这个实体下存在的，所以我们会再构建一个召回条件【Brand：康师傅；Taste：红烧; SPU：泡面】。

在生鲜电商中召回条件构建比较简单，但在综合电商中比如用户搜索【王一博同款白色卫衣限量版】，我们就需要拆分召回条件，如果用【王一博 and 同款 and 白色 and 卫衣 and 限量版】去索引中进行召回，可能召回的结果就会很少。所以我们需要重新构建召回条件，进行Query改写，挑选比较重要的条件去召回，其他条件忽略。我们可以将Query改写为【王一博 and 白色 and 卫衣 】所以实体与实体之间是存在优先级的，有些实体属性是要优于其他实体属性的。

最终我们召回得到搜索结果。

### 3.4 Ranking
召回的搜索结果如何进行排序了，一般我们从以下两个方面进行考虑：

- 相关性排序：商品和Query的相关性程度，比如用户搜“康师傅红烧牛肉面100g”那么肯定是“康师傅红烧牛肉面100g”的商品排序在最前面，“康师傅红烧牛肉面150g大袋”排序在后；
- 业务规则排序：另外我们也要结合商品历史的销量、用户的喜爱程度、价格、促销等一系列因素综合考虑，比如用户搜索“方便面”，方便面的种类太多：康师傅、统一、汤达人等等。和“方便面”的相关性都是完全一样的，这时候我们可能会将历史销量高的、用户喜爱程度高的商品排序在前。

通常情况下第一种和第二种我们是综合在一起进行加分，然后再对商品进行综合排序。
- 机器学习模型：通过历史用户的点击、购买、收藏、加购数据等，构建机器学习模型，然后模型来进行千人千面的排序，这也是目前市场上主流电商APP的做法，每个人搜索同一个词，看到的结果是完全不一样的，

上述整体地介绍了召回和排序模块，实际应用中召回和排序模块还有很多细节，后续我们会专门再对这两个模块进行详细介绍。

### 3.5 Reranking

上述是一些通用的规则或者模型排序策略，实际业务方还会有一些其他要求，比如最近业务方在对“康师傅”牌的方便面做市场推广活动，那么在用户搜索“方便面”时，业务方就希望我们将所有“康师傅”品牌的方便面排序在前。所以很多时候Ranking的结果还需要经过一层Reranking再排序，这一层主要是业务策略的排序。

### 3.6 AB Test

最后就是AB Test实验台，很多时候我们线上有很多套搜索策略，为了对比不同策略的用户点击效果等，我们需要同时进行AB Test实验，也就是我们类似我们高中学过的控制变量法，同一时间段线上生产APP，用户的访问进行随机切分到不同的实验桶中，最终对比二者的效果。

上面就是一个电商APP搜索引擎通常的整体框架了。

### 4. 搜索的效果评估

当我们将搜索引擎搭建好以后，如何去评估搜索引擎的好坏了？通过哪些指标去评估搜索的效果。

### 4.1 线下评估

线下评估对于搜索来说是最难评估的，当搜索引擎没有上线时我们如何去评估搜索引擎的效果好坏。这个时候我们需要构建测试case，并对这些测试case进行数据标注。比如我们从用户历史搜索词中随机抽取100个Query，然后人工针对这些Query进行物料标注，每一个Query应该召回哪些商品，每个商品的相关度分数是多少。我们不会对所有物料进行标准，因为工作量太大了，通常标注几千到1万个物料。然后将相关度分为几个档次，比如【2，1，-1】三个档次，2表示强相关，1表示一般相关，-1表示不相关。然后人工根据自己的经验进行标注。

比如物料是【康师傅方便面、统一方便面、康师傅矿泉水、汤达人方便面】

那么Query=“方便面”时，我们可以标注为【2，2，-1，2】；

Query=“康师傅方便面”时，可以标注为【2，1，-1，1】；

这些标注都是人工进行标注的，标注员的标准不一样，可能整个结果完全不一样，所以最开始就需要大家统一好标准，很多时候我们是根据搜索引擎的策略进行标注。

- 召回率（评估召回结果是否齐全的指标）：
用户搜“方便面”，只召回了“康师傅方便面”，那么召回率=1/3；如果三款方便面全部召回了，召回率=3/3=100%；

- DCG&NDCG指标（评估排序是否合理的指标）：
搜索引擎不仅要将所有商品召回，排序也要合理，理论上打分结果最高的结果排序在最前面，打分结果最低的排序在最后面，搜索“康师傅方便面”，不能是“汤达人方便面”排序第一位。

### 4.2 线上评估

线上我们可以使用很多种指标进行多方面效果评估，一般采用如下指标：

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

- 查询无结果率：评估召回效果，通常该指标越低越好，说明大部分搜索都是有结果的；
- 平均点击商品位数：评估排序效果，通常该指标越小越好，说明用户在结果页的前面就找到了自己感兴趣的商品；
- CTR：点击转化率是综合评估搜索的效果，用户搜索后的点击情况，是否点击是由召回结果和排序情况共同决定的，CTR越高越好；
- 加购率：加购率也是综合评估搜索的效果，对于搜索结果是否加购，加购率越高越好；
- 跳失率：进入搜索结果页后用户是否没有任何操作就跳出了，如果该指标很高，说明用户对于搜索结果不满意和不感兴趣，跳失率越低越好。