为电商而生的知识图谱,如何感应用户需求?
1、背景
电商认知图谱从17年6月启动以来,通过不断从实践到体系化的摸索,逐渐形成了一套较为完善的电商数据认知体系。
在当前集团不断拓展业务边界的背景下,数据互联的需求越来越强烈,因为这是跨领域的搜索发现、导购和交互的基础,也是真正能让用户“逛起来”要具备的基础条件。但在此之前,我们需要对当前的问题做一个分析。
1.1 问题
更复杂的数据应用场景不仅是传统的电商,现在我们面临的是新零售、多语言、线上线下结合的复杂购物场景,所用到的数据也往往超出了以往的文本范围,这些数据往往都具有一些特点:
非结构化互联网的大量数据都是分散在各个来源而且基本是非结构化文本方式来表示,目前的类目体系从商品管理角度出发,做了长期而大量的工作,仍然只是覆盖了大量数据的冰山一角,这对于认知真正的用户需求当然是远远不够的。
充满噪声:不同于传统的文本分析,目前集团内的数据大部分是query、title、评论、攻略等,这些数据由于用户习惯和商家诉求,会存在非常不同于普通文本的语法结构,也会由于利益原因存在大量噪声和脏数据,这也为真正发现用户需求并结构化带来了极大的困难。
多模态、多源:随着集团的业务扩展,目前的搜索推荐不仅容纳了商品中的文本信息、大量视频、图片也作为内容被使用、如何融合各个来源的数据、如何在关联多模态数据也是数据建设的一个难点。
数据分散,无法互联:从目前的商品体系建设来说,各个部门由于业务快速发展,往往需要维护自己的一套cpv体系,这也是后期做商品管理和搜索的非常关键的一环,但是由于应用场景的行业属性不一样,比如闲鱼的"包配饰"由于业务场景高频会是一个需要再细分的类目,但在淘系由于交易搜索低频,"鞋包配饰"仅仅是二手闲置下的一个小类目,这造成各个部门需要费力地维护在自己的cpv体系上的查询和搜索,每次都要重建自己的类目体系,重新支持存储查询,重新关联商品,重新做类目预测等。 如何建设一个比较通用的面向应用的概念体系,支持根据业务需求提供查询服务,已经迫在眉睫。
缺少数据的深度认知:数据的深度认知不是认知商品,而是认知用户需求之间的关联,如何能在用户搜索"叶酸”的时候认知到她有备孕需求,如何能在用户大量点击烧烤调料和工具的时候认知到他需要进行野外烧烤,是目前全集团都缺少的。
1.2 需求分析
通过如下的背景介绍,我们可以明确到,为了构建一个全局统一的知识表示和查询框架,我们需要如下的关键工作。
复杂场景的数据结构化:在复杂的场景下,我们首先要做的是数据清洗,通过频次过滤、规则和统计分析把脏数据去掉,然后通过短语挖掘,信息抽取等方法把高可用的数据抓取出来,进行数据的结构化和层次划分。
分散数据的统一表示框架:对于管理分散数据,我们首先是需要定义一个全局的schema表示和存储方法,然后基于schema进行概念数据的融合,属性的挖掘和发现,在数据关联上有可能要通过各种表示学习的方法来完成。
数据深度认知:深度认知包含两个方面,一个是数据本身的认知,一个是数据关联的认知,通过行为和商品本身的信息我们可以认知到用户购买商品的意图,通过外部数据的输入和摘要我们会得到常识类和商品体系之外的用户需求的关联。
1.3 电商认知图谱
为了解决上面的问题,我们提出了电商认知图谱(E-commerce ConceptNet), 目标是建立电商领域的知识体系,通过深度认知用户需求,实现电商场景下关联人-货-场的联动,赋能业务方和行业。
1.3.1 模块划分
从整体划分上来说,认知图谱分为四块比较重要的工作,通过将不同类型的concept(user,scene,virtual category和item)构建为一个异构图,来实现用户-场景-商品的关联:
用户图谱构建 用户图谱除了通用的用户画像信息(年龄、性别、购买力),也会有“老人”,“小孩”等人群数据,和用户的品类属性偏好数据。
1.3.2 场景图谱构建
场景可以看做是对用户需求的概念化,从现有的query和title中识别出用户需求,泛化为一个通用的场景(scene concept),并建立诸如"户外烧烤","度假穿搭"之类的概念是场景图谱的主要工作。通过不断细化的场景需求,我们将跨类目和品类,代表了一类用户需求的概念抽象为购物场景(sc)。
挖掘了概念相当于我们得到了图上的节点,在概念挖掘之上,我们又着手建立概念与类目和品类,概念和概念之间的关系,相当于建立了图上的有向边,并计算边的强度,具体流程如下:
截止目前,我们已经产出10w+概念和10倍的品类类目关联。
1.3.3 品类细化
品类细化的来源是由于目前的类目体系会过粗或者过细,从构建上包括两个层面:
品类聚合:比如"连衣裙“从认知层面上来说都是一个品类,但是由于分行业管理的原因会同时存在"女装”,"男装"和"童装"等不同类目中,这时候就会存在于两个一级类目下,所以就需要有一个偏常识的体系来维护对真正"连衣裙"的认知。
品类拆分:品类细化是源于我们发现现有的类目体系不足以聚合一类用户需求,比如有一个“西藏旅游”的场景,在“纱巾”类目下我们需要更多的细节,这时候就需要一个叫做“防风纱巾"的虚拟类目。 这个过程同样是存在entity/concept extraction和relation classification的,当前我们主要针对类目和品类品类上下位建立关系。
截止目前,我们已经有融合了cpv类目树,品类类目关联,和外网数据的 pair对68.9w+对。,>
1.3.4 商品图谱构建
短语挖掘:商品图谱端我们需要的是做更多的商品属性认知,我们知道,完善的cpv体系的前提是phrase的认知,针对此我们建立了一个bootstrap框架下的cpv挖掘闭环,目标是能够长期有效积累cpv数据,扩大query和商品的认知(这也是商品打标的数据来源之一)。
举例来说:
截止至目前,我们已经完成了pv top70的类目审核,增加了12W+的cpv对,term能够全量被识别的query占比已经从30%提升到60%(由于目前采用中粒度分词进行挖掘,前期分析70%已经是极限,后续会在增加phrase mining流程后持续扩大挖掘覆盖),目前数据已经作为类目预测,智能交互的基础数据每日产出。
商品打标:商品打标是我们得以将知识和商品建立关联的关键技术,上述三点产生的数据最后都会通过打标建立与item的联系,在商品打标完成后我们就可以实现从query到商品的整个语义认知闭环。
预计到三月底我们可以实现第一版的商品打标。
2、知识体系
在知识构建的过程中,我们渐渐发现需要一套全局统一的schema表示体系,于是我们调研了wordnet和conceptnet的体系构建历程,逐渐形成了自己的一套概念表示体系,也就是现有的认知图谱的核心(E-commerce ConceptNet),它的目标是从语义层面去理解电商领域的用户需求并将其概念化(conceptulization),映射到一个语义本体(ontology),通过词汇层面的关系逐渐把本体之间的关系形式化(specific),通过本体之间的层级去表示概念之间的层级,通过概念之间的关系去抽象实体类别和关系。
从数据层面上来看,我们要描述一个事物(entity),首先需要把它定义为一种类别(instance-of-class)的实例,这种类别通常又可以通过一个概念(concept)来表示,不同的概念会有自己不同的属性(proeprty),一类概念的具有的属性集合可以称为概念的schema,有同一类schema的概念一般会属于不同的领域(domain),领域内有自己的语义本体(ontoloty),通过本体的层次(比如“英国"-is-part-of-”英国"),我们可以形式化概念的层级和表示。 那么由细到粗的,我们定义了一套电商概念体系的表示方法,通过不断细化ontology和concept,以及他们之间的关系,来关联起用户和商品,甚至外部的实体。
3、技术框架
3.1 平台模块
总体来说,我们是以一个数据服务中台支撑起上面的图引擎,再通过阡陌数据管理平台,和图灵业务对接平台来实现知识的生产和使用的。
3.2 模块细节
阡陌:数据标注和展示
阡陌作为电商知识图谱的基本平台,目前集成了所有知识标注和审核流程,并且提供了数据查询和可视化,后期算法的概念挖掘服务和商品打标服务也会通过阡陌对外提供。
● 数据审核在不断试错过程中我们已经建立了一套比较完善的从初审到终审的流程,具体见阡陌审核工具。
● 可视化:除了审核平台,阡陌还提供了更加具体的数据可视化形式,通过良好的交互方便查询知识阡陌可视化
3.3 图灵:业务全选和投放
由于目前我们的知识大部分以卡片形式提供,图灵提供了一整套经由云主题透出的业务服务工具:
概念选择 :
用户可以通过全选自己的主题进行分渠道投放
3.4 图引擎:数据存储和查询
从存储介质来说,我们使用mysql进行灵活标注,图数据库进行全量查询,odps做持久化数据版本管理。
在数据录入到igraph和biggraph之前会被拆分为点表和边表导入,在线通过gremlin进行查询。
在图数据库上层我们封装了一个图引擎模块,提供不同trigger的场景和商品多路多跳召回功能。目前提供user,item_list和query召回,已经在喵小秘使用,并且和搜索发现进行联调中,可以使用查询接口进行查询和测试。
3.5 技术落地
云主题(认知图谱) 目前在云主题已经通过知识卡片的形式上线近1w个场景,比较首猜商品来说,点击和发散性较商品均有大幅提升,现在正在做数据发散性的探索。
锦囊(全量)/底纹(bts)
搜索
穹顶
四、后期规划
目前认知图谱刚刚发展近一年,还有很多工作需要细化,后续的工作重点会放在:
● 关系挖掘和本体构建
● 通过文本增强图谱和外部数据的关联
● 常识类推理规则的挖掘
● 图推理的符号逻辑表示
本文作者:搜索事业部
本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。