导读：上一篇为大家介绍完电商APP搜索引擎中如何召回搜索结果，本篇为大家详细介绍如何排序搜索结果，建议新手读者先阅读前两篇文章。

一、排序的目标

电商APP搜索返回的召回结果如何进行排序了？首先我们要明确排序的目标，为什么我们要对搜索召回结果进行排序，如果乱排会怎么样？

1.1 提升用户体验

排序的直接目的就是为了提升用户对于搜索功能的使用体验，用户搜索“矿泉水”，搜索引擎能够将用户平时常买，兴趣度最高的“农夫山泉”排序在前，不符合用户消费习惯的“百岁山”等排序在后。

如果搜索引擎经常将一些和Query相关度低以及用户感兴趣不高的商品排序在前，用户就需要经常一直下滑去找自己想要的搜索结果，或者用户更换Query词重新进行搜索，整体对用户体验影响很大。大家通过下图就可以感受出排序对用户体验的影响。

1.2 提升点击率、转化率、下单率

在提升了用户体验的同时，用户对于搜索结果感兴趣了进而提升了对于搜索结果的点击率，最终转化率、下单率也会提升，从而提升了整体的流量转化，提升整体的GMV。

1.3 提升GMV

影响搜索功能的整体成交金额的因素会有很多，但排序效果提升了，一定程度是会对搜索功能促成的整体交易额GMV有提升。但是我们在评估该指标时会考虑比较多的因素，因为整体GMV提升了，是不是将较多促销的商品排序在前了，短期内GMV确实提升了，但是否会出现业务的毛利率下滑了。

二、排序策略

目前工业界一般是三大类排序策略：相关性排序、粗排和精排。

2.1 相关性排序

相关性的整体策略就是考虑搜索召回结果和Query的相关性，按照相关性进行打分，最终相关性从高到低进行排序。简单的搜索，比如用户搜索“水”，实体识别以后水是一个SPU+CATEGORY属性的搜索词，我们分别去结构化的物料库里面，SPU列和CATEGORY列进行召回，命中的商品则进行加分。

实体的属性Label，我们是存在优先级的，每个实体我们会配置一个相应的分数，比如我们认为SPU的重要性高于CATEGORY，我们给SPU设置为100分，CATEGORY为80分。那么一个商品如果SPU和CATEGORY都命中了，则相关性分数就为180分。同时对于同义词、近义词、意图词召回的结果我们进行相应的降权。比如用户搜索“圣女果”，A商品名为“小番茄”，“小番茄”和“圣女果”是同义词，我们对同义词命中的乘以0.9系数，则A商品的相关性分数即为100*0.9=90分。

下图即为用户搜索“康师傅方便面”，每个商品对应的相关性Score。

对于上述相关度分数一致的商品，ES索引会自行随机排序，线下测试时会发现相同分数的商品每次排序可能都不太一样。

2.2 粗排 （相关性 + 人气 + 历史购买记录等）

用户搜索“矿泉水”，物料库里的“康师傅矿泉水”、“怡宝矿泉水”、“依云矿泉水”。这三个物料的相关性都是和“矿泉水”完全一样，那么如何排序了？随机排序嘛？所以很多时候我们只考虑Query的相关性是完全不够的，我们还需要考虑业务因素。

2.2.1 考虑业务因素

业务因素总的来说就是希望通过历史数据来评估用户对商品的喜好程度，然后将“喜好程度”进行量化，不同商品之间可以相互比较。一般情况下我们考虑的业务因素有：

• 销量：销量是排序当中非常重要的一个因素，销量直接反映该商品的受欢迎程度；
• 收藏：商品的收藏量也间接反映出用户对该商品的期待程度和受欢迎程度；
• 点击&加购：通过埋点行为数据跟踪商品的历史点击和加购行为，也可以一部分反映用户对商品的喜好程度。

可以考虑的业务因素有很多，同时每个业务因素的配对的比重分数具体看每个业务方的业务需求。但业务因素配置的分数肯定不会超过相关性，而且一般会低较多，比如SPU设置100分，可能销量只设置50分。具体分数也要根据实际情况进行调试。

促销：有时候我们设置要考虑当前商品是否促销，为了配合市场推广策略等，有时业务部门希望将促销的商品排序靠前，短期内增加商品的总销量。这时排序的时候也需要针对“促销”这个因素设置一定的排序权重分数，不同的促销类型配置不同的分数。

2.2.2 归一化方法

业务因素我们罗列完以后，如何将这些因素进行量化？让不同商品之间可以进行比较。

统计口径：

销量的统计通常我们会按照订单维度进行统计，而不是商品的具体销售个数。因为有些商品之间按照销售个数是无法比较的，完全不在一个维度，比如瓶装康师傅矿泉水和茅台的销量对比，前者肯定要多很多。虽然是这样

同时销量的统计我们还会把那些大促期间的销量剔除掉，因为这部分销量并不能代表用户真实的需求和意志。

统计周期：

统计近半年，近三个月，近一个月，近15天等等。时间周期一般会设置多个，然后不同的时间周期我们会按照重要性进行百分比权重配比，最后加起来等于100%。只统计一个时间维度，很多时候商品的销量具有欺骗性。比如夏天的时候冷饮销量火爆，但如果将时间维度拉长到半年，可能冷饮销量就没有那么火爆，所以需要不同的时间维度进行组合。

统计门店or区域：

我们不会将平台上所有的数据汇总在一起统计，一般情况下像生鲜电商类APP，我们会按照门店进行数据统计，综合性电商APP我们可以按照每个省份区域进行数据统计。因为不同区域不同门店的用户偏好是完全不一样的，比如北方人可能偏好康师傅矿泉水，南方人偏好怡宝矿泉水。

归一化公式：

归一化比较简单的公式，我们可以用：

（商品订单数 — 门店最少的商品订单数 ）/ （门店最高的商品订单数 — 门店最少的商品订单数 ），这只是其中一种方法，有很多种归一化的方法。最终我们计算出的是一个系数，然后我们将该系数乘以我们最初设置的权重分数，比如销量为50分，康师傅矿泉数计算出来的系数为0.5，那么0.5*50 = 25分，再将该分数和相关性分数进行相加，得到一个综合性分数再排序。

2.2.3 潜在问题

上述将业务因素考虑进排序中也会带来一些实际的问题

马太效应：

销量高的商品得到的曝光机会越来越多，销量低的商品得到的曝光机会会越来越少；

新品曝光机会少：

很多新品刚上市，根本不存在任何销量，此时相关业务性分数均为零，导致新品得到的曝光机会非常少；

品类会比较集中：

因为消费品的使用周期完全不一样，比如像矿泉水可能几天就会购买一次，但是像SK-2神仙水可能几个月才会购买一次。对于部分表述比较宽泛的搜索词，有可能排序前列的都来自于一个小品类，比如用户搜索肉，可能猪肉相关的商品整体销量就是高于鸭肉、鸡肉等，那么展示的结果中排序前列的可能都是猪肉。

当然上述列举的三大类问题，我们都可以有相应策略进行调整和优化，但基于粗排和精排的模式对于整个业务的增长慢慢来到了瓶颈期。互联网电商巨头们慢慢积累了大量的用户行为数据，工业界开始探索构建模型来进行排序，预测探索用户的偏好，实现按照用户维度的千人千面排序。

2.3 精排

上述介绍的“相关性排序”或者是“粗排”，其实都是基于规则来做的。目前工业界电商巨头们更加常用的做法是基于历史订单数据、用户信息、埋点数据、用户历史Query等，使用传统机器学习或者深度学习来构建CTR模型。构建排序模型，第一件事情就是模型的学习目标是什么，是以CTR为目标还是CVR为目标。通常情况下，模型一般以CTR为目标，同时也会关注CVR和整体带来的GMV提升等相关指标。

关于千人千面排序模型，工业界也存在一个演进的过程。下面我们引用美团点评技术团队公开发布的文章里面部分的真实数据进行讲解，讲解各个排序模型的特点和实际的线上效果。

在美团酒店业务搜索这个场景中，效果最好的模型是以高维Wide特征为基础的LR模型和以神经网络为基础的Deep模型相结合得到的一个综合类模型。但不同的业务场景，用户的数据维度和数据量都完全不一样，所以相同的模型在不同业务场景的效果完全不一样，需要具体问题具体分析。

2.4 业务策略干预

模型排序完的结果并不是最终展示给用户的结果，因为很多时候会存在一些业务策略的干预，强制将某些商品排序靠前或者调后，甚至将一些商品过滤掉；

• 比如说生鲜电商盒马搜索场景中，排序完的结果会需要根据定位的门店进行商品有无上架，商品当前有无库存等进行过滤，未上架和当前无库存的商品会直接过滤掉；假设当前盒马和康师傅品牌达成合作，康师傅希望借助盒马的平台做一些新品的市场推广活动，则搜索结果中存在该新品的，盒马都会一定程度排序调前甚至是置顶；
• 比如说综合电商淘宝搜索场景中。购买了淘宝的店铺推广服务的店铺，这些店铺的商品最终排序时淘宝就会适当地往前排。

业务策略会有很多很多，具体视每一家电商平台的业务需求而制定。一般这种业务策略，都是通过后台产品化的工具进行配置，而不是说通过hard code写进代码中。产品化的工具更加灵活，因为这些策略经常变动，需要支持产品运营人员更加灵活地进行配置。

2.5 小结

相关性排序和粗排我们统称为专家规则，每次调整影响比较大，无法及时地发现用户的行为变化，但是可解释性很强。

排序模型，能够让模型不停地训练自学习，及时发现用户的行为变化，不过需要大量数据的支撑。有些时候在部分业务场景下，排序模型的线上效果并不一定强于专家规则。业务量小的电商APP，专家规则的效果要优于排序模型，LR模型的效果要优于深度学习模型。

只有一些业务量很大的电商APP，数据量足够，用户特征维度足够，排序模型效果才会优于专家规则，深度学习模型效果才会优于高维LR模型。实际场景采用哪种策略，都需要根据线下静态测试效果和线上生产效果PK，最终决定使用哪种方式。

该系列其他文章：

https://www.woshipm.com/pmd/5544514.html

https://www.woshipm.com/pmd/5549184.html

本文由 @King James 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议