写点什么

解读电商搜索——如何让你买得又快又好

  • 2019-04-28
  • 本文字数:11082 字

    阅读完需:约 36 分钟

解读电商搜索——如何让你买得又快又好

一. 概述

一个产品的搜索功能,是用户快速触达所需信息的通道,起到了引导用户走向的重要作用;优秀的产品必然有成熟、体验良好的搜索功能。


国内几个大型电商公司基本每日都有较大的流量通过搜索产生成交,具有优秀用户体验的搜索功能必然带来巨大的商业收益。那他们是怎么让你更快更好地找到你想要的东西呢?搜索入口很可能是用户开始使用 app 的起点,搜索的易用性是影响产品初次体验的重要要素。


本文主要结合本人的一些电商算法经验,以手淘搜索为例展开,介绍产品和诉求层面以及如何使用搜索入口来做用户引导,后续文章会结合相关算法深入展开。

什么是用户引导?

引导: 带着人们向某个目标行动,在行动上帮助人们走出困境。


搜索引导: 帮助用户更快的完成搜索过程,找到目标信息。


具体到电商: 帮助用户找到所需商品,并达成交易。

0. 电商搜索核心要点

  • 帮助用户明确搜索意图

  • 节约用户搜索时间

  • 提高搜索体验

  • 完善健康商业生态

  • 实现更高效的用户与商品/商家的连接,进而获得更高的营收


核心 &本质是理解用户

特点: 搜索和推荐场景时效性强,千人千面,用户兴趣多变


用户搜索流程:



用户输入搜索关键词,搜索系统根据输入信息,筛选出用户可能喜欢的内容,同时按照某种重要性进行排序并展示。简单而言,搜索可以分为三步。


  • 对用户输入搜索词的解读

  • 根据搜索词对内容筛选

  • 对筛选后的结果集排序并展现,并且根据用户反馈进入新的搜索服务

1. 搜索前


搜索前


  • 条件:对用户当前需求没有显式信息

  • 定位:以推荐为主

  • 典型产品:搜索底纹、搜索发现 、历史搜索词、热门搜索词

  • 搜索物料:历史搜索词、短期 &长期商品交互(点击、加购、收藏、购买)、其他人的搜索及站内行为

2. 搜索中


搜索中


  • 条件:需求部分已知

  • 定位:辅助查询输入

  • 典型产品:查询智能补全(SUG) /搜索联想

  • 搜索物料:短期 &长期商品交互(点击、加购、收藏、购买)、其他人的搜索及站内行为

3. 搜索后



搜索后


  • 条件:用户完成搜索,已获取结果列表,排序及展示结果页

  • 定位:辅助用户修正结果或重新查询

  • 典型产品:相关搜索、筛选、泛词引导/锦囊、搜索纠错,搜索确认、搜索排序

  • 搜索物料:搜索词下类目重要属性,短期 &长期商品交互(点击、加购、收藏、购买)、其他人的搜索及站内行为

4. 分类

在用户可感知层面,搜索词推荐功能可以分为联想类产品和无联想类产品

4.1 联想推荐产品

  • 下拉提示:输入部分 query 词,联想出完整 query 并推荐展示给用户,降低输入成本

  • 锦囊:类目锦囊、属性锦囊、知识锦囊、相关搜索锦囊

  • 推荐合适的细分 query,帮助用户找到更合适的词换词搜索及收敛

4.2 无联想推荐产品

  • 底纹:导购类产品;定位为个性化的根据用户历史行为推荐合适的 query 促成收敛,或发现全新的 query 帮助用户发现和种草

  • 搜索发现:导购类产品;根据历史行为推荐相关 query 促成收敛

5. 技术方案


搜索算法与业务诉求和搜索路径结合,设计更适合用户的才能做到更好的用户引导。


本节以手淘搜索元涵老师的总结作为结尾


“从 2013 年起,淘宝搜索就进入千人千面的个性化时代,搜索框背后的查询逻辑,已经从基于原始 Query 演变为【Query+用户上下文+地域+时间】,搜索不仅仅是一个简单根据输入而返回内容的不聪明的“机器”,而是一个能够自动理解、甚至提前猜测用户意图(比如用户浏览了一些女士牛仔裤商品,然后进入搜索输入查询词“衬衫”,系统分析用户当前的意图是找女性相关的商品,所以会展现更多的女士衬衫,而不是男生衬衫),并能将这种意图准确地体现在返回结果中的聪明系统,这个系统在面对不同的用户输入相同的查询词时,能够根据用户的差异,展现用户最希望看到的结果。变化是时刻发生的,商品在变化,用户个体在变化,群体、环境在变化。在搜索的个性化体系中合理地捕捉变化,正是搜索要去解决的课题。”


——阿里资深算法专家元涵

二. 搜索前

“搜索是用户把控方向及自由度的信息入口,尤其是当用户无法在产品上通过浏览找到想要的东西。”


在进行搜索功能的设计时要以简单、高效为核心目标,搜索即服务。电商搜索从大的架构或流程上来说,与通用搜索引擎有非常多的相似之处。包括对数据的收集、分析、索引,进而根据用户的搜索词在搜索引擎中检索,完成商品与搜索词之间的相关度评价,最后对结果进行排序展现,并实时响应用户的相关行为和筛选反馈


根据搜索的过程,可以拆解用户的搜索流程如下:搜索入口-搜索触发-内容输入-点击搜索-反馈结果。我们从这个流程的各个环节上来看三大电商的搜索功能,进行对比分析。


对比是个学习与分析的好方法,接下来的若干章节将从上述各个环节展开,主要介绍国内 top3 电商为主,所以分别以拼多多、淘宝、京东的搜索功能为切入点进行对比,并给出相关技术方案。


本文从前两个环节来进行介绍,搜索前(搜索入口-搜索触发):

1. 搜索入口放在哪

一级 tab(拼多多)


顶部中间搜索框(淘宝,京东,天猫)


搜索入口吸顶(淘宝,京东,拼多多,移动)


顶部右侧放大镜 icon(移动)



入口举例


这里没有找到将头部右侧 icon 作为搜索入口的电商,所以找了非电商的例子(移动)。


分析:几乎所有大型电商对搜索入口定位均较,给了相当重要的位置,尤其是拼多多给了一级 tab 作为用户的搜索入口,但首页取消了搜索入口;并且在搜索入口展现层面均设置了吸顶(下滑操作不会让搜索框消失),拼多多搜索入口在一级 tab 下吸顶。搜索位置体现了产品对搜索功能的定位问题。

2. 搜索触发

a. 触发前

默认底纹:内容前置,用户在不输入搜索词的情况下直接得到想要搜索的词


常见情况:商品名称关键词,类目词,品牌词,特定活动



底纹推荐-产品

底纹推荐技术方案

极简版:


运营人工配置


统计版:


热门搜索词、热门品类、热门活动


简单模型版:


实时对用户最近一次的点击/收藏/加购/搜索词,使用自然语言处理进行关键词、品类词、活动提取,并在搜索框内显示。这里涉及文本处理词性识别命名实体识别(NER,把无结构文字转变为有结构文字),核心词(名词)、形容词(属性/标签等)提取过程,可以考虑基于规则或统计的词性标注(HMM)。



词性识别-来自《郎君-NLP 技术的应用及思考》



实体打标词性识别-来自《郎君-NLP 技术的应用及思考》

复杂模型

embedding 方法


生成式: seq2seq,通过将用户的近期 n-1 个时间步内的行为序列输入 rnn 模型(lstm),生成预测未来第 n 时间步的行为,可以考虑将商品标题,属性,用户特征/标签一同输入训练 user embedding,然后在用过一个 decoder 对其进行解码



用户行为序列



生成式-user-embedding-《云栖社区-query 生成与推荐》



生成式-query generate-《云栖社区-query 生成与推荐》


检索式: user 与 query embedding 同一个向量空间中,并最终计算两者的相似度,最终将与用户相似较高的 topN 进行召回,并使用模型预估意图及转化最高的 query 作为底纹。



检索式-《云栖社区-query 生成与推荐》


doc2vec 和 word2vec 方式对用户和 query 进行 embedding,query 的文本为搜索曝光日志中此 query 下转化最高的 n 个商品(tittle,描述等),user 的文本则为用户近期行为交互相关商品的文本(tittle,描述等),使用 doc2vec 或 word2vec 进行训练,最终产出 query 及 user 的 embedding vector。



query 及 user 的 doc 构建


检索式向量召回性能开销大,一般现在外层使用聚类模型进行一级查找,确定一级簇以后再进行二级查找。


  • 对候选集合使用 kmeans 聚成 n 个簇

  • 遍历 n 个簇中心查找余弦距离最近的 topM 个类

  • 然后遍历 topM 个簇中的点获取 topK 个相似

  • 最后使用一个对目标建模的模型找出得分最高的搜索词作为默认词

b. 触发后,输入前

触发搜索框后,在绝大数电商搜索产品中均有不同程度的搜索推荐版本,对于业务来说,这是 cross sale 的方式。常见的有搜索历史、热门搜索、搜索发现,并且除了搜索历史,热门搜索和搜索发现一定程度上需要做语义归一化,避免浪费坑位,如“白裤子”与“裤子 白色”



热门搜索发现-产品

搜索历史

搜索历史的功能建立在一定假设的基础上,假设用户使用搜索具有一定重复性。搜索历史帮助用户快速检索历史需求,快速进行回放。并且通过数据分析可以发现,搜索历史的 query 词更加高频,转化也比其它搜索推荐词转化高;所以历史搜索一般更靠近搜索框,并且搜索词按时间先后顺序由近及远,数量过多时会进行折叠或只保留 N 个,用户有清空历史搜索词的选项

热门搜索词

通过已有用户的搜索日志,进行数据分析,选择将高频 &高转化搜索词进行展现,便于用户冷启动/意图冷启动进行筛选。这一过程中也有运营同学的参与,如大促热门活动主题。热门搜索推荐词应避免长尾,应尽量高频、宽泛、多样


注:用户冷启动一般指新用户,意图冷启动指用户之前未有的需求。

搜索发现/搜索词推荐

这一板块使用了千人千面,更加个性化。并且很多时候有换一批的功能,可以让更多内容有曝光机会。由于有搜索历史的存在,所以搜索词在个性化的同时,应尽量避免与搜索历史栏出现语义重复,提供更有价值的搜索词,从而最大化曝光效率,并且为了防止过多推荐词带来干扰,一般搜索发现词在 10 个以内


这个模块的技术方案与底纹推荐类似,只不过最终的展现不是一个,而是 topN,这里就不再赘述。

三. 搜索中

搜索词充当了用户与搜索工具之间的重要沟通载体,借助关键词实现用户自我意识与搜索引擎之间的交流,形成了一个意识产生、关键词转化、搜索、信息获取、动机满足的信息闭环。


当然还有很多因素也会去影响这个闭环,如用户(历史行为,性别、年龄等)、地域、天气,一个宏观、长周期的链路等。


根据搜索的过程,可以拆解用户的搜索流程如下:搜索入口-搜索触发-内容输入-点击搜索-反馈结果。我们从这个流程的各个环节上来看四大电商 app(京东、天猫、手淘、拼多多)的搜索功能,进行对比分析。


前文已经介绍了搜索前的一些产品及技术方案;本文还是电商搜索为例,以用户搜索过程中输入搜索词(点击“搜索“按钮到按下”回车“之间发生的事)的过程为切入点,结合产品及技术方案展开,结合相关搜索词功能进行论述。

搜索词自动补全产品形态

关键词匹配/补全/联想/纠错的作用主要有三个:引导、纠错和高效


通过统计发现,用户在第一次查询得到预期搜索结果的概率非常低,所以需要引导查询自动建议可以减少用户搜索的工作量,并通过数据挖掘(群体行为和智慧)来给出高频恰当的搜索建议。



四个电商均使用前缀匹配,但是手淘和天猫使用了拓展 icon,可快速将推荐词黏贴至搜索框,京东使用了属性、标签、类目扩展 (除了对输入内容做联想,还会展示出与关键词相关的维度,自动补全关键词,增加用户的选择),拼多多则相对搜索词产品探索较少。不过目的都是帮助用户快速锁定意图,并开展搜索


用户在搜索框输入字符时,会在搜索框下面实时显示下拉提示词给用户,方便用户选择。可以帮助用户快速输入和优化搜索条件,且避免输入错误;在此基础上很多电商 app 也出现了筛选功能,在当前搜索建议词基础上进行扩展,进一步减少用户操作一般在用户搜索的不够具体,会推荐该搜索词更细的分类。淘宝的辅助多重筛选搜索,输入时展现的一系列联想内容,点击右边的一个拓展 icon,就可以采用联想出的内容,在此基础上继续缩小范围筛选,从而帮助用户获得最接近需求的内容


通过当前实时输入的词去匹配候选词,一般查询频度和同查询词的历史查询记录重要参考依据


在搜索词补全和联想数量上,淘宝为 10 条,拼多多为 10 条,京东/天猫超过 10 条,但是不能过多,过多的选择会给用户造成记忆负担,并且占据空间,有损用户体验,所以需要控制数量以便信息不会过载


当然部分电商在历史的版本迭代中会尝试在搜索输入阶段进行纠错,比如输入联衣群,下拉框中自动纠正为连衣裙的一些选项,目前四个电商 app 均并无此功能,而是在搜索结果展示内做纠错及提醒;自动容错功能,将极大地提升用户体验,并提升用户的购买率。

技术方案

主旨:前缀匹配原则,完整词未出现时一般使用补全/联想功能,品类引导词为主;当出现明显品类词后开始出现更细粒度属性及标签筛选词。一般从 query log 中挖掘出大量候选 query,并且保证前缀相同,然后根据某种计算模型给候选 query 计算一个分数,最后按照分数选出 topK 作为最终结果。


主要考虑因素:当前搜索词,用户(性别、年龄等特征),日志中的群体智慧


极简版:


常见搜索引擎均带有 suggestion 功能,直接使用


统计版:


使用前缀匹配后的候选词(Trie 树 + TopK 算法,回溯算法遍历 trie 树),使用用户搜索频度最高的 topK 个搜索词,但是这样会使长尾词无法得到曝光机会。



trie 树


AC 算法


简单模型版:


在用户进行搜索商品时,通过用户与搜索词信息进行意图预测,并辅之以类目、性别预测,前缀匹配后最终将某个性别和类目下的共现最高的 topK 热搜词作为搜索框下拉框提示词。


复杂模型版 1:


复杂模型版,使用前缀匹配算法进行候选集召回(若召回量过少,考虑非前缀匹配结果),并做简单截断;然后使用用户特征(性别、年龄、行为序列)、context 特征(季节、天气、温度、地理位置)进行、当前搜索词的 embedding vector,然后候选搜索词也有一个 embedding vector,三个 vector 分别与候选 vector 计算 cosine similarity,最终使用一个线性模型融合三个分数,最终的排序结果会进行语义去重再选择 topK(这里也可以用生成模型来做排序)。



context embedding 的方式


这里可以将用户、context 均视为搜索词,就可以用日志数据构造 doc,最终使用 doc2vec 或 word2vec。



生成式-user-embedding-《云栖社区-query 生成与推荐》



生成式-query generate-《云栖社区-query 生成与推荐》


复杂模型版 2:



主要针对复杂模型版 1 的排序特征上,继续增加特征,并考虑更多的维度


通过语义、行为、session log 等挖掘出 query 间相似分,并加入用户、搜索词、context 类特征及其交叉特征。多维度相似融合再排序: 按照点击相似度、文本相似度、Session 相似度衡量 Query 之间的相似度,得到候选的 Pair(可选)交给重排序模块,对 Query pair 的优先级做优化,生成 Top K 的改写结果。


query2query 召回


基于行为: item cf/swing、simrank++


基于 session: word2vec、seq2seq


基于内容: query2vec(类似 word2vec,构建 query 序列)


query 排序


模型: LR/GBDT


样本: 用户日志,行为加权(展现:1,点击:5,购买:50)


特征: 搜索词的 pv/ctr/cvr,用户是否活跃,用户画像/特征,用户+候选词(查询词/浏览详情页与热搜候选词相似度),context 特征(地理位置,温度,天气等)

其它算法 &产品模块

纠错


针对纠错,还可以做一个模型,但是上述 query 方式可以一定程度上避免了很多的输入有误问题。针对纠错可以考虑如下 2 种:


Non-word 纠错(准备一个电商语料库字典,输入词不在整体字典中,即可以判定为错词)


Real-word 纠错 HMM(噪声信道模型,利用 unigram+bigram+trigram,选择最优的 token 组合,Query pair,正确及错误词候选集合训练转移矩阵)


语义归一


针对候选词进行语义归一,一般将候选 query 相对搜索 query 的扩展部分进行相似度计算,以高于某个阈值后,只保留得分高的一个候选词,这样可以节省有限的坑位资源。


产品模块


清除的 icon: 输入内容时,引导信息消失,有的还会伴随在搜索框中出现清除的 icon,清除的 icon 主要方便用户进行二次搜索时一键清空当前信息,省去了逐字删除的麻烦;根据输入内容,进行关键词的匹配。


联想词下商品数量: 产品层面还可以做一个事情,就是将关键词对应的搜索结果数量前置,便于用户控制搜索词的颗粒度,也避免出现无结果或者少结果的情况,特别是针对相对稍长尾的搜索词而言。

四. 搜索后

前面已经介绍了搜索前和搜索中的一些产品及技术方案;本节主要针对用户搜索完成后的商品检索和排序展示过程,进行产品介绍。先介绍用户直观感受到的产品层面的若干功能,后一节文章介绍用户感知较弱的召回和排序模块,前者以产品方案为主,后者以技术方案为主。


搜索引擎在信息检索上的优势,不仅体现在自身在算法和计算能力上的优势,能让搜索更加贴近需求;并且结合对用户信息的量化分析和数据把控,可以提供更加智能的信息服务(千人千面搜索)。


搜索后,能够检索出来的商品通常非常多,如何将这些商品清晰有序地展示给用户,让用户快速、准确地找到想要的商品?这涉及到以下若干个问题:


智能纠错,结果分类(如果需要),默认排序,保留搜索词,结果与搜索词对应,排序与筛选,无结果或少结果,筛选等。

1. 内容纠错


搜索词纠错-产品


难免用户在搜索过程中有错误的输入,纠错功能可以通过算法判断后输入有误,然后展示正确搜索词商品列表给用户,并友好地告知用户正确的搜索词,并确认是否需要搜索系统判断有误的搜索词(确实有长尾、低频词搜索需求存在)。考虑到了整个纠错功能的容错性,减少了用户输入错误或者本身记忆错误带来的搜索问题,用户也不用再次进行搜索了。自动容错功能,将极大地提升用户体验,并提升用户的购买率。


技术方案:前文提到的 Non-word 纠错Real-word 纠错,这里不再赘述。

2. 筛选器


搜索筛选-产品



搜索筛选-产品


当搜索结果过多相关度结果参差不齐时,召回的商品还是海量的,对于用户精准快速的获取商品仍然是一个不小的挑战,而排序和过滤的功能则能够很好的缓解这一情况。过滤和排序能够一定程度上帮用户调整和缩小搜索商品列表,大幅度降低用户下滑寻找商品的工作量


目前筛选器是各大电商的搜索产品标配,使用频率非常高。筛选器通过传递筛选参数,搜索引擎会在原有召回基础上进行商品过滤。筛选在各大电商均做了 2 类方式的展现,当筛选项维度少时,可以将筛选(与排序一起)放置商品列表结果中间(类似淘宝搜索的锦囊),一般在浏览若干个商品以后出现;若维度丰富,一般使用侧边栏形式。


技术方案:


商品类目及属性标签的挖掘:主题模型、词性挖掘、图像算法等,后续文章介绍商品结构化相关的文本及图像算法,本文先不过多介绍。

3. 无结果


无结果页-产品


用户进行搜索后,出现无结果或少结果原因可能有以下几点带来:1.输入错误的搜索词;2 筛选条件过多或搜索词过于长尾/具体;3.本身平台符合搜索需求的商品少或无。对于前两种,可以提示用户并进行自动容错,展现正确的商品列表;对于第三种情况,一般会匹配相关替代商品进行补足,或提示用户更换搜索词,有些平台推出了订阅服务,当搜索结果更新时,会向用户主动推送

五. 整流程

本节介绍用户感知较弱的召回和排序模块,主要以技术方案和实现为主进行介绍(主要为下图中,搜索服务的一些工作)。这一过程和推荐非常类似,区别主要为召回源更多地考虑了当前搜索词,排序特征也加入搜索词特征及其影响到的交叉特征,排序依据建立在相关性基础上。



往简单来讲,用户输入了搜索词,系统通过搜索词找到与搜索词相关的商品集合,系统通过用户及商品的情况进行排序,最终展现给用户。

0. 找不到

但是在构建搜索系统的初期总是无法精准地帮助用户找到想要的商品主要原因有以下几点:


  • 不同的用户对同一种诉求的表达往往是有差别的,往往会存在一种比较常见的现象,用户输入的 query 并不能清晰准确的表达需求。这一块是可以通过较好的产品设计及实时反馈精确需求表达捕捉,产品设计主要是前面介绍的引导类产品(下拉推荐、筛选、锦囊等),实时反馈是指快速捕捉用户在当前 query 下的正负反馈,系统捕捉其中的 query 意图。

  • 搜索系统对用户 query 的理解能力较弱,无法挖掘出用户的真实需求。这一块则更多是算法发力的点,通过文本、行为、session 等数据挖掘 query 本身的内涵,这一块更多是 QU(query understanding)的工作。

  • 用户输入了长尾词,过多条件无法匹配到商品。这一块也可以通过 QU 和 QR(query rewrite)来逐步解决。

  • 召回结果集的排序不合理,可能用户需求的内容被排在后面而未曝光。这一块则是排序的问题了,建立一个良性的评分排序公式,并且利用算法合理建模用户决策过程


流程上来说,如下图




接下来我们分别通过讲解 QP、召回、排序来对上述流程解构。首先来看以下 QP 里面的各个模块。

1. QP 模块

1.1 QU/query understanding

1.1.1 概述

1.1.1.1 目的


  • 拆解用户搜索词的意图

  • 比如新品,年龄,尺码,属性,类目等搜索意图识别及归一


1.1.1.2 任务


  • Query 词性及主体结构,主要词/描述词等: 2018 最新款适合胖胖的女生穿的连衣裙

  • 预测用户搜索商品类目(category)性别(gender): 手提电脑、t 恤 女

  • 属性 &标签识别: 品牌,颜色,尺寸: 裙子红色,43 码 nike 球鞋

  • 搜 &逛:强意图/转化 &弱意图/逛: 连衣裙 & Iphone XR 256G


1.1.1.3 方法


  • 方法词表穷举法,规则解析法,机器学习方法


1.1.1.4 意图识别的难点


  • 输入不规范,不同的用户对同一诉求的表达存在差异。

  • 多意图,“苹果” 可以是产品词,也可以是品牌词;可以是手机,也可以是水果。

  • 数据冷启动。当用户行为数据较少时,很难获取准确的意图。

1.1.2 词性 &主体识别 &属性/标签识别

词性的识别有助于整个搜索系统快速地找到和定位相关商品,也可以帮助快速定位核心词、属性词等。


搜索过程中,不同 term 对于检索有不同的意义,不能本末倒置。不同重要程度的词,应该在召回排序阶段给予相应不同的影响,核心词具有更高的分值。当用户搜”children toys“召回商品时,核心词是 toys,children 为修饰词,根据 term weight 来进行排序降权的。细粒度地还可以做进一步区分产品词、品牌词、型号词、停用词。query 被完整匹配和部分匹配的权重是不同的、单词命中和多词命中同一商品也需要考虑权重情况。


其它还包括了中心词逻辑、热词逻辑、纠错系统、丢弃词逻辑、词性标注等工作。常见方法词性识别有,基于规则基于统计的词性标注(HMM)。



1.1.3 词画像
  • 词属性


基础属性:pv、uv、gmv、ctr、cvr 等


业务属性:品牌词、大促属性


词质量分


  • 词关系


同义词、形近词、同音词、子母品牌、类目、文本相似性


  • 词维度的用户画像

1.1.4 强弱意图

用户强弱意图/转化意图识别,可以快速帮助搜索系统定位召回及排序策略,不同的意图可以带来不同的排序和展现效果。如强意图下相关性因子应该加强,弱意图下应该更加注重点击/转化等反馈行为量


  • 强意图/转化型: 需要快速帮助用户定位所需的商品 (因素:价格、品牌、品质、商家等),推送引导的目的是让用户作出购买,收藏等决策,追求转化的数量+速度+质量。

  • 弱意图/闲逛型: 需要帮助用户发掘新的兴趣、新的话题,但同时不能让用户 感觉无聊,目的是满足用户需求,把用户喜欢的推荐给他,追求 pv/点击率。


根据用户行为和 query 的静态信息,分析 query 是搜索型(偏向买)还是浏览型(偏向逛)。后续利用模型对 query 分类,用以分析排序策略对不同类型 query 的影响,方便对不同类型 query 作不同排序


分析用户个性化标签的浏览行,转化型趋势。



若干特征举例:


  • session+query 内商品的点击率

  • Session 内不同 query 的个数

  • 空格数量

  • 相关一级类目个数

  • 停留时长再逛和搜 query 中表现差异大

  • 行业分布:服装鞋包/3c、美容护理、食品保健、话费充值差异大

1.1.5 类目预测

Query 的类目预测主要是,分析 Query 和哪些类目的意图更相关(当然这里用户维度的信息也会被考虑进来)。query 通过搜索引擎召回后,一般将类目相关性作为重要的海选排序因子,保留一部分商品,一方面保证了效率,另一方面也从源头保证类目的相关性,保证用户体验。从实际工作来看,fasttext 是一个非常不错,实践也较快的算法。



类目举例



常见模型

1.2 QR/query rewrite

1.2.1 概述

1.2.1.1 问题


  • query 和商品描述之间存在 gap,特别是中长尾 query。多种描述,信息冗余,属性检索,宽泛意图


1.2.1.2 目标


  • 文本和意图,通过对原始 Query 进行改写,生成一系列相关 Query,把相关 Query 作为原始 Query 的补充,与原始 Query 一起参与搜索,从而得到更加丰富和准确的匹配结果


1.2.1.3 方法


  • query embedding 和 multi-method


1.2.2 query embedding
  • query embedding(query 映射到 query),可以针对“多种描述”和信息冗余问题意图改写:query 映射到意图,主要针对属性检索和宽泛意图类型;也可以进行相似 query 挖掘。

  • 向量改写流程: query 向量化->向量相似查找->相关性判断;借鉴 skip-throught-vector,使用 seq2seq 重建句子周围的句子,假设某个 session 序列是(s1,s2,…,sn),那么一条训练数据为(si-1,si,si+1),encoder 是 si 的词序列的 lstm,decoder 是分别 si-1 和 si+1,这样训练下来 decoder 的上下文向量就学到了这个句子在 session 中的上下文表示。

1.2.3 multi-method
  • 通过语义、行为、session log 等挖掘出相似的 query。

  • 多维度相似融合再排序: 按照点击相似度、文本相似度、Session 相似度衡量 Query 之间的相似度,得到候选的 Pair(可选)交给重排序模块,对 Query pair 的优先级做优化,生成 Top K 的改写结果

  • 基于行为 Item cf/swing、Simrank++

  • 基于 session Word2vec、seq2seq

  • 基于内容 Word2vec

  • 融合 LR/GBDT

2. 召回 &检索模块: ltm/learn to match

2.1 检索依据

  • 电商商品: 图片+标题+属性+交互,检索项包括但不限于:商品名称,商品标题、副标题,商品描述,商品参数、规格,商品品牌,商品品类,别名关联商品,促销类型

  • 相关性(query&tittle/content,行为,session): 融合点击相似度、文本相似度、Session 相似度衡量 Query 之间的相似度,除了前面介绍的通过 query session 来做 query embedding,用 query 来重建其点击过的宝贝标题/描述序列同样适用,只不过 decoder 阶段换成 query 点击过的标题。

2.2 语义搜索

语义搜索是指不单单考虑词维度的精确匹配,而是语义层面来做。增加搜索结果的相关性,提升用户体验外,也可以一定程度上遏制商家商品标题堆砌热门关键词的问题。

2.2.1 常见 doc&query 匹配方法
  • BM25 通常计算 query 和 Doc 文本 term 的匹配程度。由于 query 和 doc 之间的语义 gap,可能存在很多语义相关,但文本并不匹配的情况。

  • 通过商品内容理解和语义标签: 通过商品图片,详情页,评价和同义词,上下位词等给商品打标签和扩充商品索引内容

  • 语义匹配: Dssm 模型将 query 和文本变成向量,用向量内积表达语义相似度

  • 匹配深度与高度: 词->短语->语义->主题->句法



词->短语->语义->主题->句法



embedding-similar

2.3 无结果优化

  • 二次/三次召回:放弃权重低 term,扩大检索字段和检索范围

  • Query 纠错 & 同义词改写:同时用原词和同义词去检索,最后对两者返回的结果取并集。

  • 分类意图识别的优化,首先根据 Query 分布定义了 8 类意图:可以通过识别 Query 中 Term 的意图来判定整个 Query 的意图

3. ltr/learn to rank

精排系统主要服务于个性化排序,召回粗排由搜索引擎负责完成,精排侧重更细粒度特征,更复杂模型,实时性。精排所需特征,模型基本复用搜索引擎的技术,可以支持高密度的数据存储和高并发读取。


3.1 评分体系: 静态分 * 动态分

  • 静态分体现商品的转化,商品品质,背后供应商品质

  • 动态分体现商品与 query 的相关性,个性化分,用二元分类(Binary Classification)来优化点击/购买概率。

3.1.1 评分系统-静态分
  • 稳定性,连续性,区分度


3.1.2 评分系统-动态分

预测出每一条商品在给定以上条件组合(q,u,o)下发生交易行为的概率。



p(q,i,u)预估



gmv 最大化模型-洪亮颉老师



相关特征-洪亮颉老师

3.2 其它加权因子主要分为几个维度:

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

4. 总结

搜索技术服务模块必然与产品设计迭代并行,并且通过数据分析来支持整个流程优化,抓住重点和系统最大短板进行迭代。

作者介绍:

姚凯飞,Club Factory 推荐算法负责人。硕士毕业于上海交通大学,前阿里推荐算法工程师,多年电商及视频推荐经验,目前在出海电商 Club Factory 负责推荐算法工作。


本文来自 姚凯飞 在 DataFun 社区的演讲,由 DataFun 编辑整理。


2019-04-28 08:0015247

评论 4 条评论

发布
用户头像
有骨有肉, nice
2023-04-28 14:44 · 广东
回复
用户头像
写的非常好!受益匪浅
2019-12-20 16:22
回复
用户头像
写的超棒
2019-08-27 10:02
回复
用户头像
作者写的内容很丰富,产品+架构+技术,通读一遍后,对搜索有了一个框架和概貌上的了解。
2019-04-28 15:23
回复
没有更多了
发现更多内容

内容主数据 TiDB 集群写入热点优化实践

TiDB 社区干货传送门

TiDB 性能分析工具——PProf

TiDB 社区干货传送门

TiDB 底层架构

隐藏esc坑之jbd2进程io占用奇高 系统长期io占用100%

TiDB 社区干货传送门

故障排查/诊断

解决方案之:DM relay 处理单元报错

TiDB 社区干货传送门

TiDB v5.1 体验: 我用 TiDB 训练了一个机器学习模型

TiDB 社区干货传送门

TiDB 与 Flink 联合发布实时数仓最佳实践白皮书

TiDB 社区干货传送门

记一次使用TiUP半自动升级TiDB集群经验

TiDB 社区干货传送门

版本升级

TiDB 在茄子科技的应用实践及演进

TiDB 社区干货传送门

实践案例

一栈式 X 规模化 X 多元化:PingCAP 马晓宇谈 TiDB HTAP 演进之路

TiDB 社区干货传送门

速度收藏!TiDB 读、写性能慢问题排查思路汇总

TiDB 社区干货传送门

管理与运维

记一场DM同步引发的Auto_Increment主键冲突漫谈

TiDB 社区干货传送门

故障排查/诊断

TiDB in Action 开源电子书

TiDB 社区干货传送门

TiUP升级TiFlash重启失败解决方案

TiDB 社区干货传送门

TiDB 在小米的落地及云原生探索

TiDB 社区干货传送门

TiDB 多Socket 服务器性能扩展问题分析-续

TiDB 社区干货传送门

性能调优 性能测评

TiFlash5.0.1与4.0.10 对比测试

TiDB 社区干货传送门

版本测评

TIDB--不容易发现的 lightning tidb-backend 模式导入优化

TiDB 社区干货传送门

迁移 性能调优 TiDB 底层架构 管理与运维 性能测评

HTAP 会成为数据库的未来吗?

TiDB 社区干货传送门

【理财实践】 开科唯识-互联网理财为什么会选TiDB

TiDB 社区干货传送门

体验升级至4.0

TiDB 社区干货传送门

TiDB SQL 优化案例几则

TiDB 社区干货传送门

以TiDB热点问题来谈Region的调度流程

TiDB 社区干货传送门

实践案例

TiDB 在金融场景里面那些不得不说的事

TiDB 社区干货传送门

TiDB升级、TiFlash测试及对比ClickHouse

TiDB 社区干货传送门

【优质技术文章推荐】TiDB for PostgreSQL—牛刀小试

TiDB 社区干货传送门

实践案例

TiDB 升级到5.1.1 的性能表现

TiDB 社区干货传送门

猜一猜 TiDB 4.0 GA 第一个上线用户花落谁家?有惊喜!

TiDB 社区干货传送门

insert引发的TiDB hang死血案(案情一)

TiDB 社区干货传送门

故障排查/诊断

如何分析和解决 TiDB 4.0 的写热点问题

TiDB 社区干货传送门

TiDB-4.0.0-rc-性能测试

TiDB 社区干货传送门

【TiDB 最佳实践系列】HAProxy

TiDB 社区干货传送门

实践案例

解读电商搜索——如何让你买得又快又好_文化 & 方法_DataFunTalk_InfoQ精选文章