解构电商、O2O：探秘搜索系统的“简历”

之前的文章探讨过用户端背后系统的逻辑和结构情况，后续我会考虑逐步解构每个相关系统的情况。今天跟大家聊一聊搜索系统，搜索系统在所有电商系统里面复杂度和难度是可以排的上前列的。关于算法方面介绍的文章很多，这里不做赘述，只解构下搜索系统的基本逻辑和实现。对于产品来说未免沟通时“露怯”，了解搜索系统的基本知识和结构是有必要的。

搜索系统的“基本介绍”

搜索系统，顾名思义提供大数据查找筛选的系统功能。在电商和O2O领域作为一个主要的流量入口起到了至关重要的作用。

“基本介绍”：指标

对于搜索来说，主要的指标为准确率和召回率。我们以下图为例解释下什么叫做准确率和召回率。

图中整体的部分为所有商品数据的全集，其中包括不相关和相关的内容。

• 准确率：搜索结果中相关内容的比例，即图中A的部分
• 召回率：搜索结果占整体内容的比例，即A+B

由此我们可以看出，最完美的结果是A足够大且B足够小，但实际实现中会发现两个指标是相反的（召回率越高准确率会越低）。需要通过规则来平衡这块部分。

“基本介绍”：基础结构

搜索系统主要的组成部分有几块：

• 切词逻辑
• 词库
• 基础信息
• 加权规则
• 排序展示逻辑

整体流程如下

名词解释：

• query：是查询的意思，这里指用户在搜索框输入的内容。
• 切词：又叫分词，是根据词库/词典将一段文本进行切分以便机器识别的过程。
• 词库：指用于切词的词库。
• 加权：将检索结果集按照一定的维度、规则进行打分就叫做加权。
• 索引：商品信息存储时需要建立索引，索引作为每个商品的标识方便在大数据量的情况下快速查找筛选。

“基本介绍”：应用场景

搜索的应用一般有两种：全文检索和suggest。其中suggest的规则比全文检索要简单一些。服务上由于suggest一般支持模糊查询的情况，所以要考虑服务上是否要独立还是公用一套。

搜索系统的“工作履历”:流程解构

切词/词库

切词，又叫分词。用于将用户输入的无结构化字符变成机器可识别的词组。市面上有很多成熟的切词组件。切词逻辑有很多种，根据字符、概率等，电商和O2O一般使用字符串切词的方式处理。关于切词的方法最基础的有最大正相匹配、最大逆向匹配、双向匹配等，具体的内容可以百度查询。切词工具根据词库中的词典进行切分，一般开源的切词工具都有默认的词库和自定义词库两种情况。用户可通过添加自定义词库来完善补充。

这里面需要强调的是切词时候的过滤，尤其生鲜类非标品情况下特别需要注意。

• 单字词、助词之类的是否要过滤掉。如米、面、油等
• 别名情况的处理，尤其是生鲜类。比如在北京叫油菜，在上海叫上海青，在重庆叫漂儿白

检索结果集

根据切出的词语进行匹配，匹配到的商品信息集合为检索结果集。结果集需要做检索、过滤、标记三个步骤。

检索

检索项包括但不限于：

• 商品名称
• 商品标题、副标题
• 商品描述
• 商品参数、规格
• 商品品牌（生鲜副食品类尤为重要，比如 五得利 面粉、 鹏程 五花肉）
• 商品品类（一级类、二级类）
• 别名关联商品
• 促销类型

成熟的电商系统不仅仅实现用户的基本商品检索，还会根据query进行意图分析来进行query转换。以生鲜电商举例，当用户搜索“猪肉”时，用户希望获得的不是含有猪肉词语的商品，而是猪肉的各个部位、猪肉级别等。这时应该转化为后臀尖、前臀尖、里脊，一级白条等词语进行检索，而不是匹配猪肉。意图分析主要有两个方面

• 行为模式分析
• 用户画像分类

过滤

获取的结果集需要经过去重、过滤的处理。此部分行为可以在加权打分后进行处理，也可以安排在初选结果后处理。

• 同一个商品被多个词语命中需要去重
• 现实中的电商搜索可能会根据不同的场景构建所谓的“小搜索”，如按照类目、按照品类、按照定制化场景等。所以针对不同的搜索场景可能会有单独的过滤去重条件，也可以在构建数据的时候使用不同的库进行处理。
• O2O场景需要按照一定区域概念（城市、商圈等）进行过滤
• 售罄商品需要过滤
• 下线商品需要过滤

标记

在检索完成后需要对数据进行标记，以便后续做加权时使用。此步也可以在做加权处理的时候同步进行。

加权

加权的目的是为了根据模型确定结果集各个商品的排序优先级。加权的维度有很多，根据不同的场景考虑也会有所区别。

加权因子主要分为几个维度：

• 相关度
• 商业化因素
• 个性化因素
• 人为因素
• 数据模型统计

相关度

这里指的是分词的相关度。包括文本匹配、词间距、是否是中心词、品牌词等。中心词的概念是是否命中了核心的词语，中心词和品牌词也需要有对应的词库进行维护更新。词间距是计算相关性的一个维度，比如一段文本中包含清华、大学，“清华大学xxxxxxx”和“清华xxxxxxx大学”相比肯定是前者相关性更高一些。

这里面有几点需要注意：

1. query被完整匹配和部分匹配的权重是不同的
2. 单词命中和多词命中同一商品也需要考虑权重情况

商业化因素

考虑业务场景下需要关注的因素称之为商业化因素。

• 商品库存
• 是否新品（考虑新品的特殊性，也可以将此权重独立打分）
• 商品销量
• 是否促销商品
• 销售额
• 商品分类
• 商品品牌
• CTR（广告类的商品要考量）
• 所属平台（POP、自营）
• 区域（020属性）
• 终端情况（手机、PC）

个性化因素

按照个人使用的情况进行个性化排序，做到所谓的“千人千面”。包括下单数据分析等。这部分同意图分析的情况类似。

人为因素

在日常运营过程中，有很多需要做强制人为干预的事情（如人工置顶）。所以在加权的时候需要考虑此类行为。

数据模型统计

可以根据用户的一些行为数据或者埋点数据分析，提供综合排名靠前的商品或者分类做单独加权权重。包括：

• 用户点击
• 用户收藏
• 购买数

排序处理

根据加权的情况和一些特殊的处理，需要对最终输出的结果做排序调整。

这里提供两种方法供大家参考

1. 可以按照加权打分的分值之和做排序。这样做比较直接，但在后续调整的过程中验证规则时容易混淆不清晰。
2. 将不同的权重维度单独计算，生成一个长位数的标识符，每个权重在标识符上有自己的位置。按照优先级的顺序从左到右依次排列。考虑到机器计算的易用性上，可以在加权时使用十进制，然后统计时转换成二进制即可。类似下图这样，位数和排序可以根据具体业务场景制定。

最后要说下，在算法中要考虑相同因子下的打散，比如同一个商家店铺下的商品排序需要按照一定比例分布在不同地方，避免一次性展示过多同类商品。

如果系统能力富足，也可以增加单独的反作弊模块来处理一些恶意刷单刷榜的情况。

搜索与“大家”的关联

搜索系统主要为用户端提供搜索结果的输出，输入方面来自于相关的下游系统。

当搜索场景进一步细分时，要考虑更多数据的对接和分类。

在设计时有几个需要注意的地方：

1. 搜索数据比较庞大，直接使用API调用实时数据对于系统压力过大，一般可采取搜索自建索引库，定时（比如15分钟）从相关系统拉取数据的方式。
2. 基于不同的场景可以提供单独的索引库来实现，避免逻辑耦合不好分离做个性化。
3. 用户端在调用suggest时考虑到服务压力，建议延迟几秒请求数据。
4. 分词词库的维护也依赖于定期从相关系统中获取补充。

结语

搜索系统的核心是算法，从产品层面来说更多是关注业务逻辑规则以及上下游的依赖情况。本文对搜索的一些通用情况做了简单介绍，更深入的内容还需要大家在日常过程中进一步的深挖。

作者：高晖，微信号公众号@杂谈暖阁，10余年IT经验，互联网老兵。曾就职当当网、到家美食会、美菜网等公司，现就职饿了么。

关键字：产品经理, 搜索

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！