乐趣区

迈向电商认知智能时代的基石:阿里电商认知图谱揭秘

阿里妹导读:电商平台最大的挑战是从日益增长的海量商品(数十亿)中挑选出的一个小的子集(几十或上百)展示给用户,以满足用户的个性化的购物需求。为了解决仍存在的重复推荐、缺少新意等问题,我们提出建设大规模电商认知图谱。
今天,搜索推荐事业部认知图谱团队全面总结了目前在构建电商认知图谱方面的探索,主要介绍认知图谱的定义、整体的构建思路,构建过程中一些具体的算法问题,和最终在搜索推荐上的应用。
背景
纵使近年来电商搜索、推荐算法已经取得了长足的进步,但这些算法依然存在许多问题,如推荐中经常为人诟病的重复推荐、缺少新意等。究其本质,这是因为现有的算法主要还是沿袭“商品到商品”的思路,并不是直接从用户需求来驱动的,甚至对用户需求没有一个清晰的定义。而另一方面,理解并满足用户需求又是这些算法所要达成的最终目标,这两者之间的有着天然的隔阂。
为了打破这个隔阂,让搜索、推荐算法更好地认知用户的需求,我们提出建设大规模电商认知图谱(E-commerce ConceptNet),将用户需求显式地表达成图中的节点(称为 E -commerce Concept),并将这些需求点和电商领域内的商品、类目,电商外部的通用领域知识等关联起来,为商品认知、用户认知和知识认知提供统一的数据基础,并为下游搜索推荐算法提供新的优化思路和更多的可能性。
什么是 e -commerce concept?
前面提到,我们将用户需求称为“e-commerce concept”: 一个有商品需求的概念,一般情况下以一个符合常识,语义完整,语序通顺的短语表示。例如:“连衣裙”、“儿童防走失”、“烧烤必备”、“宝宝保暖”、“波西米亚连衣裙”、“春节庆祝”等。这些 concept 需要满足如下的基本原则:

如上所示,右边的短语均违背了电商概念的基本原则,所以在实际挖掘过程中都是会被过滤掉的。进一步,我们将 concept 分为了三大类:

购物场景(shopping scenario):表示一类非特定品类的用户需求,场景感较强,如“儿童防走失”、“春节送礼”等。
泛品类(extensive category):表示一类有特定品类的用户需求,可以是不加修饰的纯净品类,如“连衣裙”、“水果”等,也可以是有属性限制的品类,如“韩版波点连衣裙”、“儿童羽毛球拍”等。
通用概念(general concept):表示一类通用的概念,可以和电商外部的开放领域知识相关联,如“防晒”、“烧烤”、“老人”等。

E-commerce concept 从哪里来?
在明确了定义和基本原则之后,我们需要挖掘大量的 concept 用以覆盖各式各样的用户需求。目前,我们认为用户在使用淘宝或天猫搜索时输入的搜索词(query)和商品的标题(title)是 concept 挖掘可以利用的最大来源。而我们的工作主要是要将满足我们上述原则的 concept 短语,从充满噪音的 query、title 中挖掘出来,这一步称为“Concept Mining”。
Concept Mining 主要分为两步,一个是候选生成(Candidate Generation),另一个是概念正确性判断(Concept Classification)。总体流程如下:

其中,候选的生成分为两块,一块是使用 AutoPhrase 按照字粒度从句子中切分出来的短语信息,一块是通过序列模板抽取器 (Sequential Pattern Extractor) 做频繁序列挖掘后的模板信息,结合 2 -gram 的统计语言模型,得到 concept 候选。在得到候选后,我们会利用一个判别模型来融合语言模型 embedding,concept 的序列信息,以及规则前后缀,pv 统计等特征,判断 concept 是否是符合要求的。
Candidate Generation
我们首先通过 pattern 抽取器从现有的正负 concept 中提取 pattern 并计算权重,然后通过这些 pattern,并结合三个窗口内的统计语言模型,进行候选的剪枝,最后生成的候选基本都是符合语序,满足基本常识的。

Concept Classification
我们一方面结合一些简单的规则进行特征抽取,另一方面,利用现有的序列特征训练 Wide&Deep model,来进行 concept 的合理性判断。在初始数据的处理方面,由于我们大部分的 concept 都是短文本,而 query 和 title 中大部分的 term 序列不符合正常的语序,我们还利用长文本的 parsing infomation 进行候选抽取和截断,训练了 ELMo 作为基础的语言模型,并在同样长度的 gram 内调整语序,来得到最佳的序列信息再给判别模型。

Ontology
在明确了 e -commerce concept 的定义并挖掘出了大量的 concept 后,我们会疑惑,concept 作为一个词(phrase),除了 name 之外,没有分类(domain),没有描述(description),也没有属性(attributes),怎么叫”图谱“呢?这么少的信息量如何能在下游应用中起到作用呢?concept 要成为图中的节点,那我们的图到底是什么呢?
为了更好地理解 e -commerce concept,同时和外部知识图谱对齐,引入更多的通用知识,我们定义了一套电商认知图谱的本体(Ontology),用以描述实体、概念的属性和其之间的关系。实体表示客观世界存在的具体实例,例如,歌手刘德华为一个具体的实例。概念表示客观世界中的宽泛概念,例如,娱乐明星为一个泛指的概念。分类体系与属性关系定义(Schema),包括定义实体和概念的类别,以及实体和概念具体的属性与属性值。例如,在分类体系中,歌手刘德华属于人物→娱乐人物→歌手,属性包含出生日期,代表作等。
在这里,我们参考 Schema.org、cnSchema.org 中对客观事物进行描述的结构,建立了以事物类 (Thing) 为根节点的电商知识图谱底层本体分类体系。在事物类的子类中,包括“动作”、“创作品”、“活动”、“无形物”、“品类”、“医疗实体”、“机构”、“人物”、“地点”共 9 大类。每一个子类又有其自己的子类,每一个子类将继承父类的所有属性和关系。具体结构如下图所示:

本体分类体系,其中括号内内容为类别对应的中文名和英文缩写
在这里,中心白色节点为事物类,是所有类的根节点。环绕在事物类周围的 9 个节点是事物类的直接子类。其中每一个类别又有自己的节点。在该图中,以无形物类为例,受众类是无形物类的子节点,而受众:动物类、受众:身体部位类、受众:人群类、受众:植物类是受众类的子节点。在通过结构化、半结构化、非结构化数据进行知识获取时,数据按照该分类体系进行录入。
如前文所述,电商认知图谱的终极目标是刻画用户需求,因此,在本体中我们定义了多个电商专用类来对电商环境下的客观世界进行建模:

Brand (品牌) Category (品类):品类是顾客在购买决策中所涉及的最后一级商品分类,由该分类可以关联到品牌,并且在该分类上可以完成相应的购买选择。品类中的实例是我们进行本体构建过程中重点挖掘的内容。
Audience (受众):受众是商品直接对应的购物人群或种群,是电商场景下一个非常重要的分类。受众类下包括四个子类:受众:动物、受众:身体部位、受众:人群、受众:植物。
Style (风格):对于一件商品,一定会有其特有的风格来吸引购买的人群,风格类主要对其进行描述。风格类下包括六个子类:文学风格、音乐舞蹈风格、气味风格、触觉风格、口味风格、以及视觉风格。
Function (功能):对商品进行功能的具体描述,可以精准的定位商品,将商品和需求直接联系起来。功能类下包括四个子类:美妆功能、服饰功能、保健功能、家居功能。
Material(材质):所谓材质,简单的说就是物体看起来是什么质地。通过材质对商品进行描述,可以使商品更加具体化。

属性是词汇固有的属性,比如“别名”、“描述”等;关系是本体词汇之间存在的客观联系,如 Person 类中实例的“出生地”将链接到另外一个 Place 类的实例中。在本体的分类体系中,每个类别都有其特有的属性和关系,子类将继承父类所有的属性和关系。在这里,我们以事物类和品类类为例,介绍属性和关系,具体如下图所示:

事物类:在该类别中,我们定义了“别名”、“描述”、“图片”、“名称”共四个属性和关系。“别名”实际上是当前词汇的一个同义词,是一个属性;“描述”是对当前事物特点的一种描述;“图片”可以连接到另外一个“图片对象”,实际上是两个事物之间的关系;“名称”是当前事物的标准的名字。
品类类:品类类是事物类的直接子类,将直接继承事物类的所有属性和关系。与此同时,品类类含有自己特有的属性“品类类型”。

本体分类体系下所有的类、子类均有其特有的属性和关系,在对本体中的每个类别进行建模时,我们定义了 140+ 个属性和关系。
在进行本体词汇构建时,我们充分调动集团内各大 BU 的优质结构化资源,来源包括淘系、优酷、飞猪、神马等等,对多来源的结构化、半结构化数据进行知识的整理与融合。具体的,如果将多来源结构化数据看成不同来源的知识体系,获取和融合就包括了本体和实例的匹配 (Ontology/Enity Matching) 和知识融合(Knowledge Fusion)。
我们采用了基于文本特征的匹配方法,对多来源的数据进行了批量的合并。我们定义的知识融合任务是:在同一个类别下,含有相同意义的词汇需要合并为一个 id,其中最为常见的词汇作为主键,其他同义词汇作为别名。如“老汉”与“老朽”是同义词,在同一个 id 下,“名称”属性内容为“老汉”,“别名”属性内容为“老朽”。在匹配的基础上,通过冲突检测,Truth Discovery 等技术将知识进行一致性的合并消解。对于冲突,处理方法包括忽略,避免和消解。
常见的消解方法包括:Voting、Quality-based、relation-based 的方法。我们采用的是 Quality-based 的方法,对 single-valued attribute 进行消解。最终通过整理和融合结构化数据,获取了百万级的实体和 Concept 数据。
自然文本以非结构化的形式存在,包含了大量丰富的语义关系,描述了客观世界里面实体,概念以及相互之间的关系。因此,对文本的理解也成为了获取实体和概念信息的重要来源。实体和概念作为图谱的关键元素,对其在文本中的识别成为了知识获取的重要技术。其中命名实体识别 (NER) 将文本中提及的实体进行划分并归类,可以从海量语句中挖掘指定类别的实体。我们采用基于远程监督(Distant Supervision)的序列标注模型,标注的类型标签包含上文提到的事件,功能,对象,时间,空间,品类,风格等多个大类。
至此,我们搭建了一个为电商设计的 ontology 体系,并扩充了大量的实体、概念、属性和关系,也可以将其看做一个普通的电商知识图谱。
从知识图谱到认知图谱
上文介绍的认知图谱本体结构(Ontology),包含了比较完整的分类法以及相应的 schema,并融合了大量的外部、电商实体、概念和属性关系,是一个比较初级的电商知识图谱,其目的是为了结构化我们挖掘得到的大规模的 e -commerce concept,将这些 concept 链接到图中成为节点,让“知识图谱”真正迈向了“认知图谱”。这一步叫做 Concept Tagging。
理想情况下,我们希望 concept 经过分词后,每一个词单元都能够链接到本体词汇库的词汇上,从而获得相应的知识体系,但是由于本体不一定能覆盖全部的 concept 词汇,导致 concept 只有部分能够被链接,属性关系并不完整。其次,本体中存在一词多义的问题,相同的词汇具有不同的类型,因此需要进行词义消歧。而 concept 通常是短文本,上下文十分有限,常规的序列标注模型并不能取得可观的性能,并且目前的本体分类体系是树形结构,存在一个词汇分布于同一个大类,不同小类中。例如,“丹麦”这个词的类型有“空间→国家”以及“空间→行政区”,这也为词义消歧带来了难度。
我们的目标是准确地将 concept 链接到本体词汇库的词汇上,输入是 concept 列表以及本体库,输出是对应的词汇及类型:

针对上述难点,算法的整体流程图如下:

下面我们将针对图中的模块具体说明:
1)基于词典的最大正向匹配及前缀匹配:给定一个 concept,算法首先使用最小粒度分词,将 concept 切分成词,然后使用最大正向匹配算法,从左到右将分词后的 concept 的几个连续词与本体库的词典匹配,如果匹配上则返回本体词汇及类型(ID)。
在这个过程中,存在匹配上的词在本体分类体系中的不同位置中,即一词多义的问题,在这里,我们将所有的可能候选返回,以供后续消歧处理。值得一提的是,我们在使用词表的时候,并没有使用全部的词表,其中的品牌表和 IP 表(名人、作品、电视电影等)非常庞大,歧义词很多。
例如,我们平时十分常见的高频词也会是一个 IP 词,但大多数情况下并不表示一个 IP。因此我们在最大正向匹配的过程中去除了这一部分数据,而是增加了一个前缀匹配的模块,将未标识的前缀与品牌表和 IP 中的人名表进行匹配,能够进一步的提升覆盖度。
2)词义消歧:与常规的消歧方法不同,concept 通常由短文本组成,上下文能够提供的信息十分有限。因此我们选用了序列标注模型来学习词汇类型的组合,例如:“对象”+“风格”+“品类”等等。由于考虑到不同行业下,词汇的类型不同,例如,“拼接”这个词,在“服饰”领域下,“拼接针织连衣裙”中的“拼接”类型为“风格”,而在“家具灯具”领域中,“拼接水管”的类型为“功能”,因此我们使用了 attention 机制来学习领域相关的信息。序列标注的模型如下图所示:

得到序列标注的模型输出后,再根据单词的 sense 候选,输出最终的 tagging 结果。后续会尝试将序列标注作为特征,再结合 concept 的其他特征,使用分类模型来对候选 sense 打分排序。
3)细粒度的 tagging:在存在问题的讨论中,我们提到了存在一个词汇属于相同大类不同小类的情况。通常序列标注模型的标签类别只有十几种,而目前我们的本体库分类体系中包含几十种甚至上百种类型,传统的序列标注模型并不能够解决这个问题。因此,我们需要更细粒度的序列标注模型来进一步消歧。

4)对齐长文本召回:经过词表匹配与词义消歧后,由于现有本体库并没有涵盖 concept 中所有的词汇,因此我们需要 tagging 未标识的 term,并识别出相应的类型,可以回流本体库。一种可行的方式就是利用大量电商领域的长文本句子,将 concept 远程对齐到长文本来进行序列标注,从而将未标识的 term 召回。
认知图谱中的边
知识图谱的关系是机器能够理解知识的关键。关系类型由头尾节点类型决定,节点可以是 vocabulary、concept、entity 的任意一种。目前我们定义了 19 中关系类型,并用三元组表示所有节点之间的关系。这些关系包括“is_related_to(相关)”、“isA(是一种)“、”has_instance(有实例)“、”is_part_of(是一部分)“等。这里重点介绍对电商场景用途最大的两种关系:
concept-isA-concept
例子:波西米亚连衣裙 isA 连衣裙。
电商需求大部分是品类需求,对品类需求的语义表达至关重要。isA 关系使得我们的 concept 从偏平的结构变为图的结构,对机器理解语义非常重要。通常,isA 关系的构建包含两个步骤:

在大规模文本语料中抽取 isA 关系,这里主要包括模板匹配(pattern-based)和基于向量表示的 isA 关系预测(distributional)
在第一步抽取得到的 isA 关系集合中构建层次结构,例如去重,消歧,去环等清洗工作以及补充更细粒度的 isA 关系。

而在电商认知图谱构建的特殊场景中,isA 关系构建的主要难点在于:

电商是一个垂直领域,尤其在淘宝这样一个 ” 只有你想不到,没有淘宝买不到 ” 的平台,涉及的品类五花八门,有不少品类词相对冷门但又十分重要。
电商相关的文本语料稀缺,品类词在语料中的共现非常稀疏,给抽取带来了极大的难度。针对这些难点,我们正在着手设计一套人工 + 算法不断迭代优化的 active learning 流程,希望为后续的 concept 理解和推理应用提供可靠的支持。

concept-is_related_to-item
在现有电商环境下,构建概念和商品之间的 is_related_to 关系也会面临诸多挑战:概念过短、商品标题堆叠、无关词语、商品属性错误、商品图文不符等,这些会造成匹配错误或者带来歧义。
针对上述问题我们采用的整体方案流程如下:首先使用文本匹配 /i2i/ 语义模型的方式进行将 concept 与 item(title、描述)进行语义匹配,然后会根据 concept 到 category 分数进行校准,再经过消歧后,最终会根据概念间关系进行商品的合并。下图是深度语义匹配模型的一个示意:

完整的大图
讲到这里,电商认知图谱的大图也呼之欲出了:

如上图所示,完整的认知图谱包含以下几个部分:

Concept:表达用户需求的最重要的语义节点。
Ontology:一个为电商设计的知识图谱的分类体系、schema,通过与 concept 的连接形成最终的认知图谱,可以融合外部知识图谱数据,引入电商中很难直接挖掘到的常识。
Relation:我们定义了十几类关系,用于描述不同节点之间的语义,是机器理解语义的关键。
Item:基于图谱构建大规模的 concept、vocabulary 和 relation,可以更加精确的理解商品。
User:基于图谱构建大规模的 concept、vocabulary 和 item attributes,可以更加精准的理解用户需求、推理用户需求。

应用
显式应用
电商认知图谱现已在淘宝搜索推荐等多个产品落地应用,主要的产品形式是以 concept 为载体的主题卡片,如首页猜你喜欢瀑布流中的”购物百科“:

宝贝详情页中的场景推荐:

隐式应用
通过电商认知图谱提供的以 concept 为核心的点、边关系数据,为搜索和推荐算法增加了新的信息粒度和信息结构,会带来更大的想象空间,可以更好地满足多样的用户需求。
同时,很多新的基于认知图谱应用的课题我们还在进行中,如:

可解释推荐
Knowledge Graph Embedding
推理式推荐

总结和展望
认知图谱的建设需要耗费大量的资源,涉及领域广泛,内容繁杂,离不开算法、工程、运营、以及大量众包 / 外包资源的帮助。本文只是浅显地总结了从算法工程师的角度来讲述的认知图谱构建,很多模块仍在探索和优化中。
我们相信,以更好地认知用户需求为目标的电商认知图谱,将助力搜索推荐等从基于行为的方式迈向基于行为与语义融合的认知智能时代,将是平台生态稳定和日益进步的重要基础。
关于我们
阿里巴巴集团搜索推荐事业部认知图谱团队,旨在打造全球最大的中文电商知识图谱,支持包括淘宝、天猫优酷乃至海外电商在内整个阿里集团的推荐与搜索业务,每天服务上亿用户。电商 ” 认知 ” 图谱,从电商场景下的用户需求出发,不局限于传统的商品图谱,而是一个连接商品,用户,购物需求,以及各类开放领域知识、常识的大规模语义网络。

本文作者:华仔阅读原文
本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

退出移动版