query 推荐系统
一、定义
在电商搜索中，query 推荐是指为用户推荐符合其意图的 query，以方便用户输入或者吸引用户点击。
1.1 query 推荐的目标
- 引导用户使用搜索，提升搜索的渗透率。提升搜索渗透率，其实是让用户有更多的渠道能够进入到：“商品详情页”。各式各样的词功能其本质上是“引流”渠道。（搜索运营关注的3个重点：流量、转化、客单价）
- 节省用户的输入成本，提升用户搜索效率，预测用户搜索兴趣，帮用户明确搜索意图。
1.2 query 推荐的产品形态
底纹词、热门搜索词、sug词、历史搜索词、猜你想搜索……
1.3 query 推荐场景
1.4 query 生效方式
- 展示词--->搜索词，展示词是用户看到的词，而当用户点击时，背后真正发起搜索的词称为“搜索词”。比如“小龙虾 15块钱一斤”是展示词，用户点击后，发起搜索的词是：“小龙虾”。
- 展示词--->活动H5链接，比如“官方补贴”是展示词，当用户点击时，跳转到一个真正的“官方补贴”活动H5页面，可理解为拼xx的百亿补贴。在“首页搜索框底纹词、引导页热门搜索词”模块配置时，可起到活动引流的效果。
二、词的召回
不同的产品形态取词参数不一样，比如商详页推荐词需要通过 spuId 取词，活动页面的热词是与参与活动的商品(关联活动id)有关的，因此会根据活动id取词，这本质上根据不同的用户使用场景，来决定召回与场景匹配的 query。
此外，在整个取词流程中，还需要一些通用的参数用于词的过滤，比如用户身份(新老客促销优惠)、用户年龄（未成年酒类词过滤）、用户定位的城市id（配送供给过滤）。
若需要人工配置一些干预词，则需要思考干预词的生效条件是什么？比如用户是通过各种各样的渠道进入商详页的，当需要在商详页新增推荐词时，针对某些渠道的用户进行“营销词”干预。因为词，本质上是广告的一种形态，是有必要区分用户身份和渠道的。因此，就需要上游传参时带上渠道参数。
词的召回规则本质上是解决 query 候选词从哪里来的问题，主要有以下几个方面：
- 取用户搜索的历史 query， 再根据一定规则抽取而来，比如按UV_CXR、搜索QV、搜索UV等指标过滤，得到候选 query。或者为每个 query 预测一个类目，将 query 组织成类目的形式。比如说引导页的热门搜索模块，它的热词一般选取“高 search_uv、高转化”，总之就是高质量的词作为候选词召回。
- 根据商品标题的本质特征抽取而来，通过本质词挖掘算法，针对每个 spu 标题挖掘出相应的本质词，以此本质词作为候选 query。这里的本质词其实是从商品的“上下位词”抽取而来，商品的上下位词是多 level 层级的(山东烟台红富士-->红富士苹果-->苹果-->水果)，选其中某个 level 的词作为本质词。
- POI2Query召回：根据商家历史30天搜索成单数据，聚合搜索场景下单到当前POI的Top Query集合，得到搜索成单商家Query召回；通过挖掘过去30天用户在点击对应POI后搜索的Top Query集合，得到点击商家后搜索Query召回
- SPU2Query召回：根据SPU历史30天搜索成单数据，聚合搜索场景下单到当前SPU的Top Query集合。
- 人工干预配置的 query
- 业务相关的热门搜索词，用于取不到其他来源的词时，最终兜底
由于词的数量庞大且一般存储在业务Hive表中，因此需要数据处理生成候选召回词。数据处理一般是Hive的离线任务，首先从不同的业务表来源抽取出词集合，再根据各种规则生成候选召回词，保存在Hive结果表中，最后通过后台任务将Hive结果表候选词处理成取词访问的KV形式，保存到缓存中，供线上服务取词。
从产品形态上看，有些 query 推荐是基于全局的商品spu，有些是基于局部的商品spu。比如“官方补贴”页面的 query 推荐词，应当只与官方补贴的商品有关，如何只生成“局部的商品”的 query 推荐词呢？目前的 query 候选集主要来源于spu本质词，也即：通过本质词挖掘算法为每个 spu 关联“一组”本质词，再为 query 关联一些特征，生成最终的 query 候选词用于词的召回、过滤、排序等。
poi2query
根据商家历史30天搜索成单数据，聚合搜索当前POI搜索下单的Top Query集合
挖掘过去30天用户在点击对应POI后搜索的Top Query集合，得到点击商家后搜索Query召回
spu2query
利用端上获取到的触发框内词智能刷新的点击和加购SPU信息作为Trigger，根据SPU历史30天搜索成单数据，得到搜索场景下当前SPU的下单的Top Query集合
三、词的过滤
- 字面量相同过滤
- 长度过滤，方便页面展示
- 运营配置强制干预过滤（类目id下不出某些词）
- 违规敏感词过滤、合规性过滤(未成年酒类)
- 供给过滤，词query必须能够召回商品，分成先验过滤和后验过滤。
- 先验过滤：返回给用户的 query 词一定是有供给的，因此在 query 进入候选词集时，就需要验证此 query 是否有无搜索结果，将无结果的query过滤掉。
先验过滤
先验过滤，是以离线方式过滤掉没有搜索结果的 query候选词，对线上取词流程无影响
候选词不能太多，太多可能无法在更新周期内将候选词的供给都验证完成
如何验证候选词有供给？（也即有搜索结果？）是调用线上的搜索接口还是直接读取索引数据？如果调用线上搜索接口，可能会影响到用户搜索主流程。如果直接读取索引数据，要能够基于索引字段计算出和线上搜索召回一些的结果。如果读取索引数据，也不能直接读取ES的索引数据，而是读取“索引基础表数据”，又需要要求：上游变更的增量的实时消息接入了“索引基础表”。
后验过滤：
后验过滤的特征
线上每次取词时都需要“供给过滤”判断
对用户而言，只有第一次点击某个词可能无结果（此 query 的结果会被更新到搜索缓存，并进入到黑名单中），后续该词再被点击时，就会被过滤掉
不需要定时任务判断 query 是否有供给，依赖用户的线上搜索 query 结果来过滤。（商品的售卖是动态的，如果某个商品售罄或者下线了，先验过滤需要重新判断 query 候选词是否有供给）
同义词过滤
四、词的排序规则
运营强制位置干预，强制将某个词插入到第N个位置上，这一般用于 query 词的营销场景，比如针对新用户的活动时，配置“新人专享” query 词，背后可以是承接的H5落地页，跳转到活动界面。
词的类目相关性，比如商详页推荐词，与商详页的商品相关，因此商品本质词>类目query词>搜索热词
4.1 词的打散
- 随机打散
- 根据类目id打散，同类目id query 词不能连续出现
- 指定位置干预
五、词的更新
5.1 时间维度
以天维度，每天更新一次。某些场景下可能需要实时更新
供给过滤，返回给用户曝光的 query，一定是要有搜索结果的，就需要做到实时的 query 供给过滤。
5.2 query维度
在业务初期，通过一些简单的 Hive 离线处理任务，能够生产出候选词，再将词导入到 MySQL，再通过后台处理任务组织成KV缓存，周期性更新就能满足要求。示意图如下：
- join 连接 query 所需的各类特征。比如UV_CXR、搜索QV、搜索UV、query的预测类目（流量表、query 类目预测表）
- 当 query 的数量太大，或者需要考虑更多的 query 召回特征时，可能就需要引入 Spark 等大数据处理工具计算
六、query 推荐相关的搜索指标
参考：https://www.cnblogs.com/hapjin/p/15926194.html
七、一些优化参考资料
7.1 query_base 系统
a) query的生产是烟囱式的，每个产品功能各自使用自己的query词，以单独的缓存 category 保存。随着产品加框的需求越来越多，没有统一的querybase来追溯各个产品下的query。
b) query目前只存储在缓存中：无可视化界面，验证排查问题比较繁杂。此外，query的变更无感知，没有定时任务失败/XT任务失败，则认为query是更新成功的。但是具体更新了哪些query、更新后的query是怎样的，系统都无法反馈。
c) query词的效果监控与评估。虽然词功能在上线时，产品有AB实验，但是功能上线之后，候选词、给用户下发的词(曝光)、用户点了哪些词(点击)，都没有统计数据，可结合埋点结果数据，按天维度计算展示词的“效果”，以更好地反馈哪些词的效果好，哪些不好，从而能分析各产品形态下 query 推荐的词效果，并不断迭代。
d）query 各维度特征的存储与应用（“搜索词分析”）
7.2 query 推荐优化
a) 召回上，目前的 query 推荐主要是从商品的角度召回词，没有考虑用户的特征信息。比如类目query词、本质词等，都是商品背后的 query 信息。可以根据各种 query 推荐的产品形态，结合用户 session 信息来进行词推荐。以商详页推荐词为例，用户在团好货首页输入"某个query"搜索，点击结果卡片进入商详页，此时：商详页出来的推荐词可以基于用户输入的query来进行推荐（比如用户输入 query 的相似 query，可参考论文《Query Clustering Using User Logs》）。再比如，用户在首页推荐 feed 流点击了若干商品卡片进入商详页，商详页的推荐词可以基于用户点击商品卡片的历史信息进行 query 推荐。业界也有类似的尝试，可参考：https://www.6aiq.com/article/1612740439865 、 https://tracholar.github.io/wiki/machine-learning/recommend/interact-rec-taobao.html 、https://arxiv.org/pdf/1907.01639.pdf
b) 排序上，目前的 query 排序是按 search_uv、uv_cxr 或者 类目id 排序（四级类目 query 词比三级类目 query 词更准确），这些本质上是规则排序。后续可以引入更多的“排序参数”－用户侧 or 商品侧，并结合具体的 query 推荐产品形态所需要的特征，确定一个优化目标（搜索渗透率 or query 的转化率）然后基于算法模型来进行 query 排序。
c) query 推荐，更多的应用场景是推荐，需要考虑“search context”下的 query 推荐。
