【知识图谱】产品视角下的知识图谱构建流程与技术理解
2022-2-26 08:0:0 Author: www.woshipm.com(查看原文) 阅读量:11 收藏

编辑导语:随着人工智能的发展,知识图谱也变得越来越重要。知识图谱是一种特殊类型的图,强调上下文的理解。本文在产品视角下,带大家一起看看知识图谱的构建流程与技术理解。感兴趣朋友快来看看吧。

一、引言

伴随着人工智能的逐渐落地,知识图谱也越来越进入大众的视野。

或许你并没有留意,但不论是谷歌搜索人物得到的关联图谱,购物网站越来越精确的商品推荐,还是常见的siri,小爱同学等语音助手,或者是金融放贷时的风险控制,智慧医疗的治疗方案推荐;所有这些智能应用,背后都少不了知识图谱的支撑。

如果打个比方的话,知识图谱就是人工智能的记忆系统,让机器感知世界,认识世界,并且通过规模庞大的知识图谱的融合、推理、深度学习等,将这些记忆链接、应用、产生智慧。

可以说,知识图谱已经成了人工智能时代的基础设施。

以下是我在查阅资料时看到的一句话,觉得很贴切,在此应用:

知识对于人工智能的价值就在于,让机器具备认知能力和理解能力。

构建知识图谱这个过程的本质,就是让机器形成认知能力,理解这个世界。

本文主要想以产品的视角,展示知识图谱的What,Why和How,即知识图谱是什么(定义和构成,组成元素和组织规则),知识图谱的价值(有什么应用场景,应用的效果如何) 以及如何构建一个知识图谱(技术流程和各个流程的关键技术)。

二、知识图谱是什么

目前学术界对于知识图谱还没有较为统一的定义,赵军老师的《知识图谱》中做出了如下定义:

知识图谱是一种比较通用的语义知识的形式化描述框架,用节点表示语义符号,用边表示符号之间的语义关系。

或者再通俗一点,知识图谱是一种用图模型来描述知识和建模世界万物之间的关联关系的技术方法,我个人对知识图谱的理解如下:

知识图谱基本的组成元素,是图节点和边。从生活中的经验来看,图节点可以是实例和某个实体,比如建材、水泥等等。

而节点与节点之间的边,则表示了两种节点之间的关系,比如建材水泥之间画出一条边,标注水泥是建材的子类。

当然,这样说是不严谨的。

为了让计算机能够理解和使用,需要一套计算机科学的规范定义,节点对应的是本体(Ontology)和实例,节点和节点间相互的关系可以用图结构或者相对简化的三元组来表示。

通过这样的数据结构,可以完备的表示信息。

有了信息还需要使用,比如查询、推理等。

要使计算机理解数据,就要按照一定的规则存储和组织语言,通过各种关键字标明每一处信息的含义是什么。

在知识图谱中,有RDF(Resource Description Frame 资源描述框架)和Owl语言(Ontology Web Language 网络本体语言)来对本体进行描述,让计算机理解图谱中的信息。

会有专门的结构化查询语言对图谱进行查询,比如针对RDF的查询语言SPARQL或者针对图结构的查询语言Cypher(开源图数据库Neo4j中实现的图查询语言)。

具体怎样定义与描述,会在知识图谱构建部分有限的展开。

知识图谱是一种图结构,因此可以摆脱传统关系型数据库的严格限制,在字段和实例的增加、修改等方面都更加随意和自由,可以加入新的实例,新的节点,新的关系。

还可以把不同的实体建立联系,把多个图谱的同一实体建立联系(实体对齐),这和人类认知世界的方式是类似的。

这也是知识图谱的优势,容易建模,有很大的灵活性;结构化的数据和图结构的组织,使得机器可读的同时人类也易于理解,这和人脑的神经元及记忆系统很像,也更容易产生人工智能。

三、知识图谱可以做什么

这个问题的答案是非常宽泛的,如果从一个知识库或者数据库的角度来看,知识图谱可以是任何系统的基础工程,涉及到存储、记忆、分析和智能的东西,都可以应用知识图谱。

直接思考的话,知识图谱首先是一个规模庞大的数据库(或者说知识库),百万级、亿级的数据相互关联,可以从更多维度对事物进行更精确的分析。

举个例子,金融知识图谱可以通过关联来查找异常、找出团伙、推荐目标客户等,以往这些关联业务需要结构化数据库进行查找,而大部分行业存在着许多非结构化数据,比如表格,文本、图片等,知识图谱可以从这些非结构化数据,半结构化数据中提取信息,完成分析,相当于大大扩展了应用的维度和广度。

这一类对数据的直接应用,就是图结构消费场景,包括图数据搜索,路径分析,关联分析,图谱可视化等等,其核心就是对庞大的图谱数据快速查找、关联、分析和展现。

除了对数据的直接查找和分析,还可以从自然语言的角度应用知识图谱。知识图谱天然的适合人类自然语言的处理,可以用人的思维提出问题,利用图谱庞大的数据规模,通过算法、推理规则、机器学习和深度学习等产人工智能,实现一些问答和分析。

举个例子,知识图谱中存在<砂石,组成,水泥>和<水泥,组成,混凝土>两个三元组,通过知识推理,可以得到<砂石,组成,混凝土>,即通过一定的知识推理得到未知的事实与关系。

这一类数据应用,就是语义消费场景,包括自然语言检索、智能分析、知识推理等等,其核心是把图谱中的知识通过规则或深度学习,形成一定的人工智能。

以上是从技术应用的角度分析知识图谱的应用,但所有的知识图谱最终都是要形成产品,提供服务的。

从我们接触到的各种产品来说,可以分为通用知识图谱,垂直领域知识图谱,还有针对企业提供服务的,专门构建知识图谱的组件和标准化、流程化、自动化工具。

通用的知识图谱,就是我们常见的搜索引擎,问答系统,或者各种百科。

自2012年谷歌发布知识图谱项目,并宣布以此为基础构建下一代智能化搜索引擎后,知识图谱的应用逐渐深入。

现在使用谷歌,百度等进行搜索,不再仅仅是关键字匹配,而是关键词增强检索,即以检索词在图谱中的的同义词、上下位词等词集合共同搜索,用来拓展或约束搜索。

同时还可以关联更多的本体及实例,直接找到答案或者展示与检索词有关的所有关系。

例如搜索某一个电影,可以看到以图谱形式展现的电影的所有主要演员,导演,上映日期等信息。

关于关系搜索和结构化展示,更加直观的例子是天眼查,可以通过搜索一家公司,找到其所有关联的子公司与法人等,同样是以图谱的方式展现的。

问答系统中,用户直接输入问题或通过语音识别,将问题转化为文本,再由自然语言处理找到关键信息以及应当采取的操作,将用户问题转变为知识图谱可识别的查询语句,然后在知识图谱中检索得到候选实体集合,通过对不同候选实体进行打分及排序,得到问题的答案。

知识图谱对于事实类、是非类、定义类等问答效果较好。

百科产品中,知识图谱也越来越重要。

百科本身就具有庞大且多维度的信息,如果把百科的数据转化为图谱,就可以在保证图谱数据质量的情况下,极大的拓展图谱规模,其中一个代表就是维基百科的子项目Wikidata。

Wikidata的目标是构建一个免费开放、多语言、任何人或机器都可以编辑修改的大规模链接知识库。Wikidata支持以三元组为基础的知识条目的自由编辑。

一个三元组代表一个关于该条目的陈述(Statement)。

例如,可以给“土木工程”的条目增加“<土木工程,涉及,工程施工>”的三元组陈述。自2012年启动到现在,Wikidata已经有多于5000万条目了。

垂直领域的知识图谱是相对通用知识图谱而言的,面向特定领域的知识图谱,如电商、金融、医疗等。垂直领域的知识图谱不一定是从互联网等开放数据抓取,而更可能是企业内部的专业数据。

同时知识表示也不止是三元组等事实性知识,通常由更为复杂的本体知识和规则型知识。

知识抽取的质量也要求更高,往往需要人工校验,保障质量。

更重要的是,垂直领域的知识图谱应用形式更全面,除了搜索问答,通常还有决策分析,业务管理等,这些业务对推理的要求更高,并要求更强的可解释性。

以金融知识图谱为例,Kensho采用知识图谱辅助投资顾问和投资研究,图谱的主要知识来源是于机构已有的结构化数据和公开的公报,研报和新闻的联合抽取等。

金融概念复杂性较高,并较多的依赖规则型知识进行投资因素的关联分析。此外,金融知识图谱还具有高度的时效性,需要对金融知识进行时间维度的建模。

最后一部分是知识图谱的组件和标准化,这些都是面向B端企业,为了企业更高效高质量的构建知识图谱所做的工作。

知识图谱组件是指围绕知识图谱的构建一些相关组件产品,比如本体编辑器、关系抽取器、垂直搜索等等,具体工具如斯坦福大学开源的本体编辑工具Protégé,斯坦福大学 InfoLab 实验室开源的知识抽取的系统Deepdive。

同时,知识图谱构建的标准化,流程化工作也在进行,如中国电子技术标准化研究院2019年发布的《知识图谱标准化白皮书》。

综上,知识图谱具有广泛的应用,既是一个规模庞大,查询灵活的知识库,也可以通过数据挖掘,深度学习等产生一定程度的人工智能,在可以预见的未来,知识图谱作为一种重要的人工智能基础设施,将会持续发展,带来更多变化。

四、怎么样构建一个知识图谱

知识图谱有广泛的应用和巨大的应用价值,越来越多的企业也在着手进行知识图谱的构建。

按流程来说,知识图谱具有知识表示与建模、知识抽取、知识融合、知识图谱推理、知识统计与图挖掘、知识检索与知识分析等主要的几步。

以下为知识图谱技术路线图。

五、知识表示与建模

要想实现人工智能,首先要做的就是让人和机器建立起对这个世界的统一认识,即如何把现实世界变成机器能理解,可解释的知识库,而答案也正藏在知识图谱这个名称中:将知识图谱化。

这一步也就是对知识的表示与建模。

数据本身是有价值的,但其价值是需要组织和挖掘而产生的,杂乱无章的数据是不能被识别的,也无法产生价值。

数据结构是指相互之间存在一种或多种特定关系的数据元素的集合,是计算机存储、组织数据的方式。对应到知识图谱中,主要是图结构和三元组。

图结构是很好理解的,图谱本身就是以图的结构来存储和展现的。

我们对现实世界的理解也是如此,先认识到某一个具体的事物或实例,即建立节点,再通过建立节点间的关系完成对事物的认识。

这里需要引入一些概念,首先是本体(Ontology)和实例,本体原本是一个哲学概念,知识图谱中本体实际上就是对特定领域之中某套概念及其相互之间关系的形式化表达,实例就是本体的具体例子,这就像JAVA中的类和对象,类是本体,new一个对象是实例。

不同对象之间可能存在关系,而这就是一条边。

实体是本体、实例及关系的整合,比如“手机”是本体框中的一个概念,概念中也规定了相关属性比如“处理器”,苹果手机是一个具体的手机,叫做实例,所以苹果手机也有处理器,苹果手机以及体现苹果手机的本体概念“手机”以及相关属性,叫做一个实体。

大量实体的集合形成了知识库,例如DBpedia。这些实体通过语义相互连接,就形成了语义网络,而这也即是知识图谱的前身。

大部分情况下,人们将实体和概念统称为实体,将关系和属性统称为关系,对知识图谱进行了简化,这样知识图谱就变成了描述实体以及实体之间的关系的图结构。

如果按照简化过的知识图谱定义,图谱中的两个节点和一条边就构成了一个实体,比如“水泥是建材的一个子类”,就可以表示为“水泥”和“建材”两个节点,以及一条由水泥指向建材的,属性为子类的有向边。

在图结构中,这样的边是可以快速添加的,而节点也都是可以快速添加的,这比传统的关系型数据库具有更高的灵活性,也更容易建模,修改的时候也不会造成太大的工作量。

图结构有专门的图数据库,目前知识图谱中应用的比较成熟的图数据库有Neo4J。Neo4J是一个近年来发展起来的图形化数据库,相对于关系型数据库来说,图数据库善于处理大量复杂、互连接、低结构化的数据,图数据库中通过节点可直接查询,而关系型数据库中,需要通过多张表连接查询,产生性能上的问题。

Neo4J尤其对图算法进行了改进,查询和修改的速度较快,性能也可接受。

Neo4j还提供了大规模可扩展性,在一台机器上可以处理数十亿节点/关系/属性的图,可以扩展到多台机器并行运行。Neo4j中实现的图查询语言是Cypher Quary Language,简称CQL。

除了图结构,现在大部分知识图谱中采用的结构是三元组,是一种更容易存储、识别和利用的的数据结构。

简单来说,三元组就是知识图谱中的两个节点和一条边组成的关系对,或者说是一个实体。

要让计算机理解三元组,就必须对其进行规范化定义,这就引出了RDF(Resource Description Frame 资源描述框架)和Owl语言(Ontology Web Language 网络本体语言)等定义标准。

图:三元组

RDF(Resource Description Frame 资源描述框架)是一个使用XML语法来表示的资料模型(Data model),是由W3C制定并推广的一套用于描述实体和关系的标准。

RDF使用统一资源标识(URI,Uniform Resource Indentifiers)来命名来标识资源,任何一个事物或概念,只要按照RDF表示法描述都可以成为一个资源。

有了资源之后,RDF使用属性和属性值来描述资源,属性和属性值定义了资源的形态。

特定的资源以一个被命名的属性与相应的属性值来描述,称为一个RDF陈述,其中资源是主词(Subject),属性是述词(Predicate),属性值则是受词(Object),需要注意的是,陈述的受词除了可能是一个字符串,也可能是其它的资料形态或是一个资源。

一个RDF实例<S,P,O>(也即<主语,谓语,宾语>)就是一个三元组,比如<水泥,组成,混凝土>,RDF是抽象的数据模型,支持不同的序列化格式,例如RDF/XML、Turtle和N-Triple,其中<水泥,组成,混凝土>的RDF/XML具体的表示如下:

每一个RDF实例都可以看成一个知识单元,也是图谱的最小组成部分。

RDF使用的是开放世界假设,即三元组<水泥,组成,混凝土>对于计算机而言意味着混凝土至少有水泥这一种组成材料,而不是只有水泥这一种组成材料。

RDF有一些基本词汇如rdf:

type用于指定资源类型,但如果想描述某个领域里类别和属性的层级结构、包含关系等是不够的。

比如限定<梁思成,毕业于,清华大学>,RDF可以表示梁思成和清华大学这两个实体有哪些属性,以及梁思成毕业于清华大学,但我们想定义梁思成是人,清华大学是地点,人有哪些属性,地点有哪些属性,人和地点之间存在什么关系,RDF就无法表示了。

为了解决这一问题,W3C推出RDF schema(RDFs),在RDF词汇基础上拓展了一套数据建模词汇来描述数据的模式层,对RDF中的数据进行约束与规范。

Schema英文翻译为纲要、图示、构架,Mysql中的Database又称Schema,其实就是定义了一类数据有哪些属性,RDFS可以方便的拓展类的属性。

RDF Schema 不提供实际的应用程序专用的类和属性,而是提供了描述应用程序专用的类和属性的框架,RDFS本质上就是RDF词汇的一个扩展,比如RDFs中有两个非常重要的词汇domain和range。

Domain表示属性的域,即属于哪个类别,range表示属性的取值类型,也就是,domain限定了属性的定义域,range限定了属性的值域。

举个例子,在三元组<职业,是,土木工程师>中,可以用domain限定“职业”的类别是“人”,用range限定“职业”的取值范围是字符串String。具体表示如下:

这里还有一个要点,即RDFS不是根据对象可能具有的属性来定义类,而是根据属性可能归纳的类型和取值范围来定义。

具体来说,我们可以给职业“Career”归属到人“Person”的类别下,而不是像经典的面向对象编程中采用的先定义类person,再定义Career。

RDFS的这个要点使得我们可以在不需要重新修改这些类的原始描述的情况下,完成属性的添加,人们可以很容易的向已经定义的类中增加额外的属性,这也是以属性为中心构建类型系统的优势。

虽然RDFs对RDF的词汇进行了拓展,但其表达能力还是比较弱。

比如RDFs无法说明两个类或者多个类是否等价,或者两个类是否不相交(比如人的子类男人和女人不相交),或者属性特性的描述,比如传递性,逆属性(大于的逆关系是小于)。

为了进一步提高建模和推理能力,网络本体语言 OWL(Web Ontology Language)又被提出,其实也可以看做RDFS的进一步拓展。

OWL不但具有快速,灵活的数据建模能力,还可以通过一套定义的词汇帮助计算机进行推理。以下是owl中的一些重要词汇:

通过以上图表中的词汇,owl可以进行部分推理与展示,比如A的祖先是B,B的祖先是C,自然可以得到A的祖先是C。通过不同词汇的应用,相比于RDFs,owl的表示能力和推理能力有了很大的进步。

RDFS/OWL序列化方式和RDF没什么不同,其实在表现形式上,它们就是RDF。

有了RDF数据库,还需要了解其查询语言。SPARQL提供了查询RDF数据的标准语法,查询规则以及结果返回形式。其实SPARQL和SQL很像,只是关键字的定义不同,以下是一个例子:

PREFIX部分进行命名空间的声明,使下面查询的书写更为简洁。

RDF中以“?”或者“$”指示变量,在where子句中列出关联的三元组模板(三元组中允许存在变量,所以称为模板),而select子句指示要查询的变量。

对应到上述这个例子,查询的是学生姓名,年龄以及选修的课程,OPTIONAL关键字是可选算子,指的是在这个算子覆盖范围的查询语句是可选的,有年龄则返回年龄。

filter是过滤算子,指的是这个算子覆盖范围的查询语句可以用来过滤查询结果,整句的意思是如果有年龄,则年龄必须大于25岁。

查询语句可以写的很复杂,可以层层嵌套,求并集等各种运算来实现复杂的业务逻辑。

最后说一下RDF的存储,三元组形式简单,可以简化为一张三列的表,进而存储在关系型数据库(如Mysql)中,也可以存储在专门的RDF数据库中,如RDF4J。

RDF4J是Eclipse基金会旗下的开源孵化项目,功能包括RDF数据的解析、存储、推理和查询等。

RDF4J本身提供内存和磁盘两种RDF存储机制,支持全部的SPARQL查询和更新语言,可以使用与访问本地RDF库相同的API访问远程RDF库,支持所有主流RDF数据格式,包括RDF/XML、Turtle、N-Triples等。其实现的查询语言为SPARQL。

六、知识抽取

要构建规模庞大的知识图谱,已有的文献或资源数量上肯定是不够的,需要把各种来源的数据中的知识提取出来,并且存储在知识图谱中。

知识抽取是指自动化地从文本中发现和抽取相关信息,并将多个文本碎片中的信息进行合并,将非结构化数据转换为结构化数据,包括某一特定领域的模式、实体关系或RDF三元组。

具体来说,数据的来源有结构化数据、半结构化数据、非结构化数据等,分别对于了不同的抽取方法。

而具体抽取的内容也包括实体抽取(命名实体识别)、事件抽取、关系抽取、共指消解(搞清句子中代词的指代对象)。

知识抽取的数据来源中,非结构化数据占比最高。

非结构化数据其实就是自由文本,比如新闻、论文、政策等,而面向非结构化数据的抽取涉及到机器学习和NLP等。

半结构化数据占比也很大,其数据形式不符合关系型数据库或其他形式的数据表形式结构,但又包含标签或其他标记来分离语义元素并保持记录和数据字段的层次结构,比如表格、列表等。

目前的知识抽取中,百科类数据、网页数据是重要的半结构化数据来源。

结构化数据往往是企业的业务系统中的数据,常常用于垂直领域知识图谱的抽取,比如从MySql中抽取成为RDF,因为关系型数据和RDF都是一种结构化数据,所以通常可以通过一定的规则从一种数据映射到另一种数据,目前已经有一些成熟的工具和规则。

图:知识来源及抽取方法

面向非结构化数据的知识抽取,主要包括实体抽取、关系抽取和时间抽取。

实体抽取是从文本中抽取实体信息元素,包括人名、组织机构名、地理位置、时间、日期、字符值和数值等,就是在抽取知识图谱中的各个点,是知识图谱最基本的单元,也是很多自然语言处理问题的基础。

针对实体抽取,目前已经有了很多很多方法,大致分为基于规则的方法、基于统计模型的方法和基于深度模型的方法。

关系抽取是从文本中抽取出两个或多个实体之间的语义关系,与实体识别关系密切,主要有以下几类方法:

事件抽取是指从自然语言文本中抽取出用户感兴趣的事件信息,并以结构化的形式呈现出来,例如事件发生的时间、地点、发生原因、参与者等,如下图:

图:事件抽取

半结构化数据抽取主要是从网页中提取,一般通过包装器实现,包装器是能够将数据从HTML网页中抽取出来,并将它们还原为结构化数据的软件程序。

结构化的数据抽取一般是按照规则映射,W3C的RDB2RDF工作组于2012年发布了两个推荐的RDB2RDF映射语言:DM(Direct Mapping,直接映射)和R2RML。

直接映射规范定义了一个从关系数据库到RDF图数据的简单转换,将关系数据库表结构和数据直接转换为RDF图,关系数据库的数据结构直接反映在RDF图中,基本规则包括:

  • 数据库中的表映射为RDF类;
  • 数据库中表的列映射为RDF属性;
  • 数据库表中每一行映射为一个资源或实体,创建IRI;
  • 数据库表中每个单元格的值映射为一个文字值(LiteralValue);
  • 如果单元格的值对应一个外键,则将其替换为外键值指向的资源或实体的IRI。

R2RML映射是通过逻辑表(Logic Tables)从数据库中检索数据。

数据库的直接映射中,生成的RDF图的结构直接反映了数据库的结构,目标RDF词汇直接反映数据库模式元素的名称,结构和目标词汇都不能改变。

而通过使用R2RML,用户可以在关系数据上灵活定制视图。

已经有一些标准和工具支持将数据库数据转化为RDF数据、OWL本体等,如D2RQ、Mastro、Ultrawrap、Morph-RDB等。

七、知识融合

构建一个大规模,高质量的知识图谱是需要很大工作量的,实际使用中,如果能够把已有的知识图谱和其他成熟的知识图谱联合使用,或者多个系统信息交互使用,将大大提升知识图谱的规模和效能。

目前,解决本体异构、消除应用系统间的互操作障碍是很多知识图谱应用面临的关键问题之一。

知识融合是指使来自不同知识源的知识在同一框架规范下进行异构数据整合、消歧、加工、推理验证、更新等步骤,将同一个概念或实体的描述信息关联起来。

简而言之,将多个知识图谱用一套规范联合使用起来,就叫知识图谱融合(也叫知识融合),虽然益处显而易见,但融合也存在很多问题,其中最主要的问题是异构问题。

其实异构就是不同图谱对于同一个事物的认识和表示存在冲突,没法把不同图谱中的本体和实例一一对应起来,从而造成使用出现错误。

造成异构的原因有很多,典型的如:

  • 人类的知识体系非常复杂;
  • 一些知识还受到个人主观看法的影响;
  • 前沿知识会不停的发展变化;
  • 同一领域有不同组织构建自己的知识库,交叉领域中的交叉知识往往是独立构建的等等。

由此导致的异构问题又包含本体异构和实例异构,具体表现为:

  1. 同一领域内往往存在着大量本体,且它们描述的内容在语义上往往有重叠或关联;
  2. 本体在表示语言和模型上具有差异;
  3. 同名的实例可能指代不同实体;
  4. 不同名的实例可能指代同一实体。

知识融合的目的就是解决知识图谱异构问题,建立起不同图谱内异构本体和异构实例之间的关系,要成功建立这样的关联,还需要先了解不能匹配的原因。

知识图谱中的异构形式主要可以划分为两个层次:

语言层不匹配和模型层不匹配。

具体如下:

语言层不匹配:

指的是用来描述知识的元语言是不匹配的,其中既包括描述知识语言的语法和所使用的语言原语上的不匹配,还包括定义类、关系和公理等知识成分机制上的匹配。

模型层不匹配:

指的是由于本体建模方式不同所造成的不匹配,包括不同建模者对事物的概念化抽象不匹配、对相同概念或关系的划分方式不匹配,以及对本体成分解释的不匹配。

目前,解决本体异构有两种思路:

1. 本体集成

本体集成,顾名思义,就是将多个本体合并为一个大本体,最直接的做法是将多个本体进行集成,变成一个统一的本体,提供统一的语义规范和共享词汇,这样就可以统一交互。

但这样操作容易使集成后的本体太大,不好修改与维护。

目前应用较多的是基于全局本体 – 局部本体的集成,通过抽取异构本体之间的共同知识,建立一个全局本体,这个全局本体代表了不同系统之间的共识,而每个系统可以保留自己的本体,称为局部本体。

局部本体既可以在全局本体的基础上扩充,也可以直接建立自己的本体。

全局本体与局部本体建立映射,局部本体侧重于特定的知识,全局本体保证不同系统异构间的部分能相互交互。

2. 本体映射

寻找本体间的映射规则,将不同本体间建立联系,如上边提到的局部本体和全局本体的映射。

第一步要明确本体映射分类,这是建立异构本体间映射的基础。

分类可以按照映射的对象、映射的功能、映射的复杂程度来进行。

  • 映射的对象:明确映射应该建立在异构本体的哪些成分之间。
  • 映射的功能:明确应该建立具有何种功能的本体映射。
  • 映射的复杂程度:明确说明什么形式的映射是简单的,什么形式的映射是复杂的。

在确定本体映射的分类后,最重要也是最困难的任务在于如何发现异构本体间的映射。

手工建立关系非常耗时,目前的研究热点是采用合理的方法和工具进行自动或半自动的构建。

不同的本体映射的方法使用的技术不同,但过程基本是相似的。

  1. 导入待映射的本体:不一定统一本体语言,但映射成分需方便获取。
  2. 发现映射:利用一定的算法,如计算概念间的相似度等,寻找异构本体间的联系,然后根据这些联系建立异构本体间的映射规则。
  3. 表示映射:将这些映射合理地表示起来,根据映射的类型,借助工具将发现的映射合理表示和组织。

在进行实例层之间的相互融合时,计算数据量巨大,如何在降低计算的时间复杂度、空间复杂度的前提下提升匹配质量,是一个两难的问题,目前主要方法与简介如下:

八、知识图谱推理、知识统计与图挖掘

通过知识表示,我们确定了知识以什么样的方式组织、表示和储存,使人类和计算机有了认识和使用知识图谱的基础;知识抽取则是从各种已有的数据库,专业知识和互联网上文本、表格等。

提取出我们关心的数据,并通过各种方法爬取,清洗,将原本结构化、半结构化、非结构化的各种非图谱数据变为图谱中可用的、结构化的图谱数据,相当于建成了基本的知识图谱。

建立了知识图谱后,为了实现不同系统间的的知识图谱的交互,让不同图谱对应到统一的本体和实例,需要进行知识图谱融合,知识融合极大的拓展了知识图谱的规模和应用场景。

通过以上三步,基本上就构建了有一定规模和实用性,可以实现不同系统间交互的知识图谱,即实现了数据的从无到有,从有到有用的过程。

下一步就是使用知识图谱,通过各种计算与分析从大数据中获取价值,进而进一步支持语义搜索,智能问答,辅助分析等应用场景。

从知识图谱构建到应用的中间一步,就是知识图谱推理、知识统计与图挖掘。

先说知识统计与图挖掘,其实就是传统意义上的数据统计与挖掘,只不过数据是知识图谱,而图相对树、链表等又是比较复杂的,尤其是知识图谱规模较大,有时寻找特定数据或关联数据要耗费大量的时间和算力。

查询又是知识图谱中最常见的计算,比如要查询某一个实例及其关联信息,RDF三元组中可以将其转变为对于关系型数据库的查询。

而对RDF图模型或者图数据库如Neo4J来说,这就是查询符合条件的一部分节点和关系,即子图查询,比如搜索“水泥是由什么组成的”,就是搜索“水泥”以及所有与其存在“组成”关系(或者与其他组成同义词,如“原材料”,“用于建造”等)的节点所构成的图,使用的算法如深度优先搜索或广度优先搜索等图算法。

同时还可以对图的特征进行统计,比如有向图中指向某个节点的边有多少(入度),该节点指向其他节点的边有多少(出度),节点在图中重要地位的中心度等等。

比如统计图谱中某一家公司与其他公司的到期未偿还债务关系多少(属于“到期未偿还”关系的边和节点的多少),按此来选择一批信用不良的公司,或者某些出入度离群的点,是否存在刷单情况等等,将图谱用于异常检测。

还有一种很常见的情况,就是对图谱中多个节点关系进行关联分析,比如侦破金融里的团队诈骗,往往一个诈骗团队有非常复杂的关系网,可以通过图谱查找多个账户之间的转账关系,或者与可以账户关系密切的账户。

其中常用的方法有路径查询、距离计算,输出结果为节点及节点间边 的距离和边的集合(路径)。

或者对某一个节点或事件做时序分析,观察事件发展中都涉及那些团体和事件,常见的方法如时序分析。

知识统计与图挖掘是对图谱中已有知识的查询、统计和展示,通过明细数据的展示,或者聚合成更高维度的数据来发掘价值,通常是得到新的结论,但不会拓展知识图谱中已有的数据,从知识图谱的角度来说是没有产生新的知识。

而知识推理则是根据已有的知识,按照某种规则或者策略,产生新的知识(新的三元组)。

举个前面提到的例子,知识图谱中存在<砂石,组成,水泥>和<水泥,组成,混凝土>两个三元组,通过知识推理,可以得到<砂石,组成,混凝土>,即通过一定的知识推理得到未知的事实与关系。

知识推理有很多应用,如知识问答就可以通过知识推理来实现,或者可以补全一部分知识图谱,检测与推理内容不一致的节点。这些一方面可以改正知识图谱的质量,修复一些明显的错误,另一方面在知识问答中可以推出一些新的结论和回答。

面向知识图谱的推理主要围绕关系的推理展开,即基于图谱中已有的事实或关系推断出未知的事实或关系,一般着重考察实体、关系和图谱结构三个方面的特征信息。

知识图谱的推理的主要技术手段主要可以分为两大类:

基于演绎的知识图谱推理和基于归纳的知识图谱推理。

演绎推理是一种自上而下的推理,在指在给定的一个或多个前提的情况下,推断出一个必然成立的结论的过程,我们熟悉的三段论就是典型的演绎推理。

演绎推理的过程需要明确定义的先验信息,比如在某某前提下,所以基于演绎的知识图谱推理大多围绕本体展开,比如某事物具备某一属性,则必然不存在于与该属性互斥的事物范围内。

演绎推理中的一个大类是基于描述逻辑的推理,描述逻辑(Description Logic)是基于对象的、一种形式化知识表示的逻辑。描述逻辑是OWL语言实现逻辑推理的基础,OWL语言重要的词语如互为逆关系,子类等就是实现逻辑推理的基础。

描述逻辑是一阶谓词逻辑的一个可判定子集,所谓可判定,就是保证了推理算法总是能够终止的,可以得出结论的。要理解描述逻辑就需要先理解一阶谓词逻辑。

人类的一条知识一般可以由具有完整意义的一句话或几句话表示出来,而这些话可以用一些谓词公式(用谓词联接符号将一些谓词联接起来所形成的公式)表示出来,比如张三是一个学生,可以表示为isStudent(张三),这里isStudent(x)是一个谓词,表示x是一个学生。

这样很贴近自然语言,也可以被计算机存储与识别,所以是一种很常用的知识表示方法。

一个描述逻辑系统由四个基本部分组成:

  1. 最基本的元素:概念、关系、个体
  2. TBox术语集:概念术语的公理集合
  3. Abox断言集:个体的断言集合
  4. TBox 和 ABox上的推理机制

概念即解释为一个领域的子集;关系解释为该领域上的二元关系,如<x,y>|朋友(x,y);个体解释为一个领域内的实例。
TBox为术语集,它是泛化的知识,是描述概念和关系的知识,被称之为公理。

ABox是断言集,指具体个体的信息,ABox 语言包含概念断言和关系断言,概念断言即表示一个对象是否属于某个概念,关系断言表示两个对象是否满足特定的关系。

描述逻辑的各种算子,对应到owl语言中就是各种词汇,如算子⊑对应subClassof;描述逻辑依据提供的构造算子,在简单的概念和关系上构造出复杂的概念和关系。

基于本体推理的方法常见的有基于 Tableaux 运算的方法、基于逻辑编程改写的方法、基于一阶查询重写的方法、基于产生式规则的方法等。

归纳推理是一种自下而上的推理,是指基于已有的部分观察得出一般结论的过程,典型的归纳推理有归纳泛化(指基于对个体的观察而得出可能适用于整体的结论)、统计推理(将整体的统计结论应用于个体)。

基于归纳的知识图谱推理主要是通过对知识图谱已有信息的分析和挖掘进行推理的,最常用的信息为已有的三元组。

按照推理要素的不同,基于归纳的知识图谱推理可以分为以下几类:基于图结构的推理、基于规则学习的推理和基于表示学习的推理。

九、知识检索与知识分析

经历了知识建模与表示、知识抽取、知识图谱融合、知识图谱计算与推理之后,知识图谱已经是相对完善的数据库了,可以在其基础上创造应用,服务具体的场景。

在知识图谱的应用阶段已经简要说明了通用领域知识图谱和专用领域知识图谱的应用,这里只聚焦其中三项技术:搜素、问答系统、推荐系统。

1. 搜索

知识图谱依托庞大的数据和关系对,可以对搜索进行增强,不但针对搜索词展示出最接近的信息,还把相关的选项也展示出来,提高了查准率和查全率,另外可以通过图谱化的展现和互动让用户更加方便的了解信息。

具体来说,是通过语义搜索、关系搜索和结构化展现实现的。

万维网之父Tim Berners-Lee是这样定义语义搜索的:

“语义搜索的本质是通过数学来拜托当今搜索中使用的猜测和近似,并为词语的含义以及它们如何关联到我们在搜索引擎输入框中所找的东西引进一种清晰的理解方式”。

具体来说,首先将用户输入的问句进行解析,找出问句中的实体和关系,理解用户问句的含义,然后在知识图谱中匹配查询语句,找出答案,最后通过一定的形式将结果呈现到用户面前。

知识图谱本身是一个具有属性的实体通过关系链接而成的网状知识库,同时知识图谱本身可以和网页上的内容建立概念间的联系,将网络上的信息、数据、资源关联为语义知识,也就是实现了 WEB 从网页链接向概念链接的转变。

同时,相对于原来的按字符串模糊匹配的模式而言,语义搜索对用户的问句进行分析,找到实体和关系,通过NLP和知识推理理解用户的问句,并在知识图谱中尽可能多的找到相关信息,对回答进行相关度排序,实现了用户的按主题检索而不是传统的按字符串检索。

一个语义搜索系统的基本框架包括查询构建、查询处理、结果展示、查询优化、语义模型、资源及文档等。

具体的应用中,如搜索“混凝土”,不仅搜索混凝土,还会找到其在知识图谱中的上位词,下位词,同义词等词集合,比如砼(同义词)、轻质混凝土(下位词)等等。

返回的检索结果中也会包含这些信息,从而提高了查全率,如果用户检索的本意是查找混凝土中的一个子类,那么实际上还提高了查准率。

再比如搜索“同方集团股价”,会以大写的形式展示实时股价,而不是返回一个网页,这就是从文本中检索答案。另外还可以以图谱化的形式展现,将在可视化部分有限展开。

关系搜索和结构化展示其实属于知识推理、知识统计与图计算部分,在用NLP技术理解了用户的实体和关系要求后,就可以找到两个或多个对应的实体,直接在图谱中查询其互相关系,或者通过知识推理得出其相互关系。

或者是明确了某一实体,找到与其有对应关系的其他实体,比如找到与“混凝土”有“组成”关系的实体,并将其以图谱或表格的形式展示出来,即为结构化表示。

2. 问答系统

知识问答是用自然语言的方式与机器进行交互并得到答案,是知识图谱的重要应用。

问答是一种典型的智能行为,图灵测试就是看机器能否做到人一样的问答效果。

问答系统不但要求系统本身能够理解提问者的语义,还要求根据知识图谱进行知识搜索或知识推理以形成答案。

可以说问答系统是信息检索系统的一种高级形式,因为问答系统中同样有查询式理解和知识检索这两个重要过程,且与智能搜索中相应过程中的相关细节是一致的。

多数问答系统更倾向于将给定的问题分解为多个小的问题,然后逐一去知识库中抽取匹配的答案,并自动检测其在时间与空间上的吻合度等,最后将答案进行合并,以直观的方式展现给用户。

一个问答系统应具备的四大要素:

(1)问题

是问答系统的输入,通常以问句的形式出现(问答题),也会采用选择题、多选题、列举答案题和填空题等形式。

(2)答案

是问答系统的输出,除了文本表示的答案(问答题或填空题),有时也需要输出一组答案(列举问答题)、候选答案的选择(选择题)、甚至是多媒体信息。

(3)智能体

是问答系统的执行者,需要理解问题的语义,掌握并使用知识库解答问题,并最终生成人可读的答案;

(4)知识库

存储了问答系统的知识,其形态可以是文本、数据库或知识图谱。

也有工作将知识库编码到计算模型中,例如逻辑规则、机器学习模型和深度学习模型。

智能体利用知识库实现推理。根据知识库表示形式的不同,当前知识问答可以分为传统问答方法(符号表示)以及基于深度学习的问答方法(分布式表示)两种类型。

传统问答方法使用的主要技术包括关键词检索、文本蕴涵推理以及逻辑表达式等,深度学习方法使用的技术主要是LSTM、注意力模型与记忆网络(Memory Network)。

KBQA(knowledge base question answering,基于知识库的问答系统)采用了相对统一的基于RDF表示的知识图谱作为存储基础,并且把语义理解的结果映射到知识图谱的本体后生成SPARQL查询解答问题。

通过本体可以将用户问题映射到基于概念拓扑图表示的查询表达式,也就对应了知识图谱中某种子图。KBQA的核心问题Question2Query是找到从用户问题到知识图谱子图的最合理映射。

除了KBQA外,问答系统还有 CommunityQA/FAQ-QA(基于问答对匹配的问答系统)、 Hybrid QA Framework(混合问答系统框架)、基于深度学习的传统问答模块优化、基于深度学习的端到端问答模型,感兴趣的可自行查阅。

图:问答系统

如果考虑在实际产品中涉及一个对话系统,通常需要考虑六大部分:

  1. [ 语音识别ASR ] 将原始的语音信号转换为文本信息;
  2. [ 自然语言理解NLU ] 将识别出来的文本信息转换为机器可以理解的语义查询;
  3. [ 对话管理DM ] 根据NLU模块输出的语义表示执行对话状态的跟踪,并根据一定的策略选择相应的候选动作。包括对话状态跟踪DST和候选动作选择Pollcy两部分;
  4. [ 自然语言生成NLG ] 负责生成需要回复给用户的自然语言文本;
  5. [ 语音合成TTS ] 将自然语言文本转换成语音输出给用户;
  6. [ 知识Knowledge ] 对话任务的完成离不开知识,不论是任务型中的意图及参数,问题型中的知识库,还是闲聊中的语料都属于知识(但是知识并不一定只有这三类)。对话系统结合知识后,能够形成完善的对话交互框架。

基于知识图谱的问答,是通过语义分析和答案排序完成的,即先将问题转化为知识图谱查询表达式,再通过检索和推理得到问题的候选答案集合,然后通过对不同候选答案实体进行打分,依据分数排序,选出最优答案。

3. 推荐系统

推荐系统是我们每天都能接触到的系统,如淘宝的千人千面,网易云音乐的个性化歌单,目前的个性化推荐算法中应用最广的是协同过滤算法。

协同过滤分为协同和过滤两个步骤,协同就是利用群体的行为来做推荐决策,而过滤就是从可行的推荐方案中将用户最喜欢的方案找出来。

通过群体的协同和每个用户是否喜欢推荐的反馈不断迭代,最终的推荐会越来越准确。

当前协同过滤算法主要包括基于用户的协同过滤和基于物品的协同过滤,其核心是怎么计算标的物之间的相似度以及用户之间的相似度。

将与当前用户最相似的用户喜欢的标的物推荐给该用户,这就是基于用户的协同过滤的核心思想;将用户操作过的标的物最相似的标的物推荐给用户,这就是基于标的物的协同过滤的核心思想。

推荐的过程可以简单理解为三个步骤:召回、过滤、排序。

  1. 首先系统根据获取到的信息,召回适合推荐内容,获取的信息可以是用户的搜索记录、购买记录、评论等。
  2. 召回的内容中有的是这个用户不关注的,需要根据过滤的条件,将不需要的内容进行过滤。
  3. 经过过滤产生的推荐集还需要根据内容的相关度进行排序,最后系统根据相关度的排序,将内容分配到对应的模块,这样用户就能看到自己感兴趣的内容了。

基于协同过滤的推荐系统,主要有以下问题:

(1) 数据稀疏/长尾/噪音问题

用于协同过滤计算的用户行为矩阵(用户和其对应有交互(如购买,点赞,收藏等)的物品矩阵),必然是一个稀疏矩阵,用较小范围的数据推测较大范围的数据,会存在预测不准确的问题。

(2) 冷启动问题

对于新加入的用户或者物品,系统没有其历史交互信息,很难对其进行准确建模和推荐,相对应的推荐准确率和多样性也会大打折扣。

(3)可解释性

协同过滤算法侧重输入和输出,与神经网络模型一样类似于一个黑盒,计算模型提炼出的有效特征是什么很难说明,即决策的依据模糊,缺乏可解释性。

知识图谱可以针对这些问题进行改善,知识图谱可以用来表示实体之间的关系,如推荐系统中物品与物品、用户与物品、用户与用户之间的关系。

这些关系信息可以表示用户偏好与物品相似度等信息,将这些信息引入推荐系统中可以显著缓解推荐系统面临的冷启动与数据稀疏问题。

以阿里巴巴电商知识图谱为例,该知识图谱以商品为核心,以人、货、场为主要框架,共涉及9大类一级本体和27大类二级本体。一级本体分别为人、货、场、百科知识、行业竞争对手、品质、类目、资质和舆情。

人、货、场构成了商品信息流通的闭环,其他本体主要给予商品更丰富的信息描述。

阿里巴巴电商知识图谱的数据来源包含国内-国外数据、商业-国家数据、线上-线下等多源数据。目前有百亿级的节点和百亿级的关系边;主要靠机器维护,人工辅助。

有了这样规模庞大的知识图谱,可以对个性化推荐进行改进。

知识图谱可以增加更多的特征,提供了实体与实体之间更深层次、更长范围的关联,比如根据用户喜欢的物品进行推荐,有了知识图谱后,可以拓展该产品的更多属性,并且找到更多与其在属性上有关联的商品进行推荐。

同时,知识图谱还提供了与推荐实体的各种关联实体集合,可以通过语义来推荐相近的物品,比如买了羊肉卷推荐其关联商品火锅底料,或者买了手机推荐其图谱中的下位实体,如手机贴膜,耳机等。

最后,知识图谱是实体和关系的集合,且具有知识推理功能,因此推荐物品的可解释性也更好。

十、后记

知识图谱是一门比较复杂且发展中的科学,目前还有很多不完善和不成熟的地方,每一个步骤也有太多的方法和外延,涉及到语义,逻辑,自然语言处理,机器学习、深度学习和图算法,整体是艰深并不是容易掌握的。

之前看了几本书,也听了几门课,看了不少技术帖,但脑子里还是迷迷糊糊,没有一个整体的框架。

写这篇文章的过程,也是一个不断查漏补缺,逻辑自洽的过程,写这篇文章就像完成了一篇综述,现在我对于整体的流程以及一些基础的概念有了更多的理解,输出倒逼输入,确实有道理。

然而对于产品经理来说,了解技术的底层和概况是为了更好的设计产品,我们更应该关注的是设计产品的目的是什么,面向的用户是哪些,能够提供怎样的价值和解决什么问题,产品的交互与易用性如何等等问题。

了解技术只是为了知道产品设计的边界在哪里,以及实现某些功能的路径和成本,一切还是为了产品。

虽然还未成熟,但知识图谱已经展示出巨大的价值,各种各样的应用也在不断落地。

相信在不远的将来,以知识图谱为基础的人工智能会更大范围、更深程度的改变世界。

作者:钟志伟,中国知网产品经理

本文由 @钟同学 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自 Pexels,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

2人打赏


文章来源: http://www.woshipm.com/pmd/5328539.html
如有侵权请联系:admin#unsafe.sh