基于品类关系,虚拟类目如何建设?-阿里云开发者社区

开发者社区> 阿里技术> 正文

基于品类关系,虚拟类目如何建设?

简介: 类目-属性项-属性值体系(简称CPV)是淘宝建设中非常重要的基石,在商品的发布、管理,以及搜索场景下都大量应用。比如每个商品都有自己的类目、以及属性,而且需要发布在适合自己的类目下,才能够方便管理和搜索;在用户搜索的过程中,对Query的类目预测也是相关性中非常重要的一环。

image

小叽导读:类目-属性项-属性值体系(简称CPV)是淘宝建设中非常重要的基石,在商品的发布、管理,以及搜索场景下都大量应用。比如每个商品都有自己的类目、以及属性,而且需要发布在适合自己的类目下,才能够方便管理和搜索;在用户搜索的过程中,对Query的类目预测也是相关性中非常重要的一环。

作者:玉昆、云志、子尹

1.前言

每个商品在同一时刻都只属于一个叶子类目,淘宝的类目体系是树状结构,每个类目都有一个父类目,类目id=0是根类目,是所有一级类目的父类目,没有子类目的类目称为叶子类目,一般来讲,我们主要关心的是从一级类目到叶子类目这些类目。淘宝类目树体系的数据可以通过相关的odps表获取。目前有效的类目数量大概在2万多个。

虚拟类目建设的目的在于,在当前类目体系之下,根据我们搜索自身的业务特性,建设一套基于品类上下位关系的虚拟类目体系,如下图所示:

image

图1. 概念图谱

2.问题背景

虚拟类目建设是我们整个知识图谱建设中的一个部分,更多的关于搜索事业部知识图谱的信息可以参考文章:为电商而生的知识图谱,如何感应用户需求?之所以会有虚拟类目,是因为当前的类目体系下,针对搜索和推荐的场景,我们遇到了两个问题:

1)因为不同行业的原因,有的类目名称完全一样,但是却分布在了不同的一级类目下,或者有的类目非常相似,同样也有多个叶子类目,如图2所示,有多个类目都与食用油有关。这样在推荐场景带来的一个问题就是当用户想要购买的商品分布在A,B两个类目下,而这两个类目是完全一样的,当用户购买了A类目下的商品之后,我们还可能会对他推荐B类目下的商品,因为这个时候我们无法认知A类目和B类目是同质的。这样不仅在体验上会给用户带来疲劳感,在用户的发现性上也有一定的损伤。

2)有的类目内容过于宽泛,品类数量比较多,比如保健食品类目下有多种不同的保健品,这个时候在推荐场景下,如果能够按照不同的品类,而不是整个类目进行推荐,效果可能会更好,如图3所示。

image

图2. 类目相似问题

image

图3. 类目粒度过粗

3.整体解决方案

因此,为了解决上面所提到的问题,我们提出了基于品类关系的虚拟类目树的建设思路,分为三个部分:

1)针对类目相似的问题,我们将当前相似的类目合并,构建一个新的虚拟类目节点,如图4所示。

2)针对类目粒度较粗的问题,我们将粒度较粗的类目进行拆分,分解成多个新的虚拟类目节点,如图5所示。

3)根据前2点产出的虚拟类目节点,迭代地构建一棵虚拟类目树,如图6所示。

image

图4. 类目合并

image

图5. 类目拆分

image

图6. 类目树构建

我们在设计虚拟类目解决方案的时候,也考虑过根据品类词,从零开始构建一棵虚拟类目树,不过最终我们没有采用这么方法,原因如下:

1)当前的类目体系已经比较完备,同时每个类目下的商品也基本上属于当前这个类目,基于当前的类目体系进行合并或拆分,能够极大的提高整体效率;

2)从头开始根据品类词构建类目树,一是以什么粒度作为类目节点仍然是一个问题,同时还涉及到对商品打标的问题,可能带来一定的误差。

因此我们基于当前类目体系,通过合并与分拆,构建适合我们应用场景的一套虚拟类目体系。

4.类目合并方案

类目合并的目标是找到相似的类目,并对其进行合并成一个虚拟类目节点,根据对当前一些类目的分析,当前的相似类目有以下一些情况:

类目名称完全一样,这种可以合并,如:“居家布艺>>地垫 家庭/个人清洁工具>>卫浴用具/卫浴配件>>地垫”。

类目名称相似,但是有一些不同,比如“厨房/餐饮用具>>杯子/水杯/水壶>>玻璃杯” 与 “厨房/餐饮用具>>杯子/水杯/水壶>>保温杯”,这种不合并,因为从品类上看属于不同的品类。

品类差不多,但是适用对象不一样,比如“宠物/宠物食品及用品 >> 猫/狗美容清洁用品 >> 毛巾/浴巾/吸水毛巾”与“居家日用 >> 毛巾/浴巾/浴袍 >> 毛巾/面巾”,虽然都是毛巾,但是适用对象是不一样的,所以这种情况也不合并。

因此,根据问题,我们提出了以下几种相似类目发现算法:

基于Query类目预测,以及类目名称对相似类目进行发现。

基于类目下,商品标题的品类词相似度对相似类目进行发现。

基于用户行为数据对相似类目进行发现。

基于用户随机游走的方法计算类目相似度。

4.1 基于类目预测的方法

Query的类目预测是淘宝搜索相关性的重要组成部分,通过类目预测,可以把与用户搜索query意图相关的类目对应的商品靠前呈现,从而保证用户的体验效果。在一次搜索Query中,根据具体的情况可能会有1个或多个类目预测结果,我们要做的就是找到哪些类目经常共同出现,这里面我们采用了互信息的方法来计算类目之间的相关性:

image

图7. PMI

这里P(x,y)代表类目 x 和类目 y 一起出现的概率,而 P(x)为类目 x 单独出现的概率,P(y)为类目 y 单独出现的概率。

互信息是概率论中应用广泛的方法之一,如果x跟y不相关,则 P(x,y) = P(x)P(y)。二者相关性越大,则 P(x,y) 就相比于 P(x)P(y) 越大。所以通过上面的式子就能够算出相关性比较强的类目pair对。

4.2 基于标题品类词的方法

该方法的思路是通过商品标题的相似度,来判断类目之间的相似度。其步骤如下:

获取类目下商品的title,以及对该类目下商品有点击的Query。

对title以及Query进行tagging,提取其中的品类词,并计算词频等信息,形成每个类目对应的term_list词表。

根据term_list计算类目之间的两两相似度。

这种方法能够减少用户行为所带来的偏差。

4.3 基于用户行为的方法

基于用户行为也是能够有效地发现相似类目的一种方法,我们这里利用了基于频繁项挖掘的方法来找到经常出来的类目对。

这里面简单介绍下频繁项挖掘。频繁项集挖掘算法用于挖掘经常一起出现的item集合,通过挖掘出这些频繁项集,当在一个事务中出现频繁项集的其中一个item,则可以把该频繁项集的其他item作为推荐。比如经典的购物篮分析中啤酒、尿布故事,啤酒和尿布经常在用户的购物篮中一起出现,通过挖掘出啤酒、尿布这个啤酒项集,则当一个用户买了啤酒的时候可以为他推荐尿布,这样用户购买的可能性会比较大,从而达到组合营销的目的。

常见的频繁项集挖掘算法有两类,一类是Apriori算法,另一类是FPGrowth。我们这里使用了FPGrowth方法。

FPGrowth算法主要分为两个步骤:FP-tree构建、递归挖掘FP-tree。FP-tree构建通过两次数据扫描,将原始数据中的事务压缩到一个FP-tree树,该FP-tree类似于前缀树,相同前缀的路径可以共用,从而达到压缩数据的目的。接着通过FP-tree找出每个item的条件模式基、条件FP-tree,递归的挖掘条件FP-tree得到所有的频繁项集。

我们的数据样本构造方法如下:

针对每一个用户,当用户购买了类目A下的商品时,在购买时间点往前的一个小时内,获取用户点击过的商品所在的类目,以及每个类目下点击的商品个数。

取出点击商品个数最多的TOP3个类目,同时每个类目下的商品点击数要大于5个,以减少用户误点的情况。

基于上面的数据构造针对类目A与多个其它类目组合成的频繁项。

最后通过上面构造出来的样本,我们使用PAI上的FPGrowth算法得到每个类目可以推导出来的另一个类目,如下图所示,但从实际的效果来看,使用FPGrowth的效果不是太好。因此我们在这里也继续使用了PMI的方法来计算两个类目之间的相关度。样本仍然是以用户购买之前点击的类目id形成类目x与类目y的pair对。

image

图8. FP-Growth结果

4.4 基于Graph Embedding的方法

Graph Embedding是近几年研究较热的课题之一,早在2014年KDD中的论文《DeepWalk: Online Learning of Social Representations》就开启了这个方向的热潮,文中借鉴了深度学习在语言模型中的应用,以全新的方式学习网络节点的潜在向量表示,在社会化网络多标签网络分类任务中取得了很好的效果。接下来研究者们在更多的领域也尝试了Graph Embedding的方法,比如节点分类、边预测、社区发现以及网络相似性等方面。简单地讲,Graph Embedding分为两步:

先采用Random Walk 产生行为序列。

在行为序列上采用SkipGram训练word2vec模型。

image

图9. DeelWalk流程

image

图10. SkipGram流程

我们这里就基于Graph Embedding的方法来学习类目id的向量化表示。考虑到用户的点击购买行为,就如同在一张很大的图上游走,图中的每个节点就是类目id,当用户的点击、购买行为从一个商品到另一个商品,而且商品类目不是同一个类目,那么就建立这两个类目之间的关系,详细流程如下所示:

获取用户的商品点击、购买序列。

若itemA在itemB之间点击,且两者不属于同一个叶子类目,那么构建且分数为1。

若先点击了itemA,然后购买了itemB,且两者不属于同一个叶子类目,那么构建且分数为5。

根据构造出来的类目图关系,通过DeepWalk学习出每个类目id的embedding表示。

根据类目的embedding向量,计算类目之间的cos相似度。

4.5 数据

基于上面4种方法,我们得到了类目之间的相似度关系,通过对4种结果的ensemble,我们得到了相似类目pair对10000+对。

5.类目拆分方案

类目拆分是针对品类的种类较多,或者数量较大的类目,根据业务将其拆分成多个小的子类目,也可以称为对商品进行聚合。类目拆分其实是比较主观,或者说根据业务场景的需要按照某种规则进行拆分,因为不同的拆分规则都有其合理性。比如在连衣裙类目下,按照品牌可以对其进行拆分,按照尺码也可以对其进行拆分,也可以按照风格进行拆分,所以我们的拆分方式是需要为业务服务的。目前就我们了解到的,也有不少对商品进行聚合的方法,比如按照SPU维度,找相似,或者是图像同款等方面。所以我们的类目拆分方法也是根据我们自身的业务需要而制定的。

我们这里采用了两种方法对类目进行拆分,一种是基于品类上下位关系的方法,一种是基于商品聚类的方法,下面分别进行介绍。

5.1 基于品类上下位关系

上下位关系是指类似于“裙子”下位词是“连衣裙”这种形式,它是一种树状的结构。关于上下位关系的研究已经有很多年了,大部分关注的都是通用的知识图谱领域的实体关系,电商这块的研究还较少。因此,我们这里采用品类上下位关系来构建我们的虚拟类目树。

品类的上下位关系也是我们的词林图谱框架中的一点。如下图所示:

image

图11. 词林图谱

关于品类上下位关系的挖掘方法后面将专门进行介绍,这里就不展开讲了。主要用了几种方法:

Query下类目预测的分布情况

title中的品类词的偏序关系

Query Session等数据

5.2 基于商品聚类

基于商品聚类的类目拆分,是我们在猜你喜欢的推荐场景下做的类目拆分的工作,我们这里从用户的行为入手,对商品进行聚类。我们这里使用图聚类的方法。

图聚类是根据图的拓扑结构,进行子图的划分,使得子图内部节点的链接较多,子图之间的连接较少。标签传播算法(Label Propagation Algorithm, LPA)是基于图的半监督学习方法,其基本思路是节点的标签(community)依赖其邻居节点的标签信息,影响程度由节点相似度决定,并通过传播迭代更新达到稳定。大概流程如下图所示:

image

图12. 标签传播算法

具体步骤如下:

根据用户行为,获取同一类目下itemA->itemB的点击序列。

根据用户行为,获取同一类目下itemA->itemB的点击、成交序列。

针对上面的数据分别赋予不同的权重,构造成一张item-item的关系图,并基于标签传播聚类对其进行聚类,得到商品聚类表,每个item对应到一个cluster_id。

继续对商品的关系图进行DeelWalk,训练得到每个item的embedding向量。

根据一个cluster_id下所有的item,计算其平均embedding值,来表示当前的cluster_id。

针对同一类目下,计算cluster_id之间的相似度,得到与一个cluster_id最相似的其它cluster_id。

这里解释一下,这里的前3步是为了对商品进行图聚类,这样每个商品都属于一个cluster_id,当对用户进行推荐时,通过他之前的trigger item可以得到对应的cluster_id,进而得到该cluster_id下的其它商品。但是为了在召回阶段给予更多的商品池子,我们这里又计算了cluster_id与cluster_id之间的相似度,并得到与某个cluster_id最相似的top n个其它的cluster_id,这样只要知道了某个item_id所属的cluster_id,那么就能够召回更多cluster_id下的商品,有更多的海选样本。

6.效果

这里主要讲一下类目合并这块效果。类目合并这块主要是为了解决用户的疲劳度,我们分别在首图、大促场景以及购后链路都上线了虚拟类目的数据,最后通过人工评测的方法来评价用户疲劳度的改善情况。最后通过评测,用户的疲劳度在这几个场景下都有X%以上的降低。从体验上,大家也可以看一下下面的效果:

image

图13. 首图疲劳度控制情况

image

图14. 购后链路疲劳度控制情况

这里需要强调的一点就是,我们这边主要是虚拟类目数据的产出,而最终在各个场景的上线则是由各个业务场景的同学针对自身的业务做了非常多的优化,才能够在疲劳度下降的情况下,还能提升CTR,在这里向他们表示由衷的感谢。

7.总结与后续规划

虚拟类目建设是一个长期的过程,也是一个需要不断迭代完善的过程,好的数据与好的系统都是不断沉淀下来的。所以虚拟类目也会不断完善,同时在有了类目合并与拆分的基础上,还需要进一步对虚拟类目树进行构建,建立一个层次级别类目树框架。

另一方面,虚拟类目树不仅在推荐场景下有用,在搜索场景下也有用处,比如Query的类目预测等场景。

同时,前面关于虚拟类目建设的工作,还有不少需要完善和优化的地方,也欢迎大家提出建议,谢谢。

原文发布时间为:2018-10-10
本文作者:搜索事业部
本文来自云栖社区合作伙伴“ 阿里巴巴机器智能”,了解相关信息可以关注“ 阿里巴巴机器智能”。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

关于阿里的技术创新均呈现于此.

官方博客
官网链接