CN110019844A

CN110019844A - 一种保险行业知识图谱问答系统构建方法及装置

Info

Publication number: CN110019844A
Application number: CN201910125877.6A
Authority: CN
Inventors: 陆宇杰; 李勇; 张发幼; 邹辉
Original assignee: Zhongan Information Technology Service Co Ltd
Current assignee: Zhongan Information Technology Service Co Ltd
Priority date: 2019-02-20
Filing date: 2019-02-20
Publication date: 2019-07-16

Abstract

本发明公开了一种保险行业知识图谱问答系统构建方法及装置，属于行业知识图谱问答系统，方法包括：构建保险知识图谱的本体与知识表示；将与保险行业相关的多种原始数据基于本体与知识表示，生成保险知识图谱数据，并存储至图谱数据库中；获取用户问句，并对所述用户问句进行问句理解，其中，所述问句理解包括问句类型识别、问句意图识别、实体识别以及实体标准化；基于查询模板对所述问句理解获得的信息进行问句映射，生成查询语句；使用所述查询语句在所述图谱数据库中进行查询，得到查询结果并返回。本发明实施例创新性地提出了数据层(知识表示)与逻辑层(问句映射)的联动机制，从而可以提供可靠的、可扩展的保险行业智能客服服务。

Description

一种保险行业知识图谱问答系统构建方法及装置

技术领域

本发明涉及行业知识图谱问答系统(Knowledge Graph-Based Question AnswerSystem，KBQA)领域，特别涉及一种保险行业知识图谱问答系统构建方法及装置。

背景技术

对话系统是人工智能的一个重要分支，有任务驱动型对话系统、问答系统、开放域聊天等子系统。其中，任务驱动型对话系统一般需要通过与用户进行多轮对话，逐步收集完成任务所需的必要信息，给用户提供相应的服务；而问答系统则侧重于直接理解用户的问题，给出精准的答案，必要时系统也会向用户主动发问以进行澄清。常见的问答系统基于常见问题(FAQ)的相似度计算，但是为了给用户提供更精准的回答，基于知识图谱的问答系统受到了越来越多的关注。

知识图谱可以分为常识知识图谱、百科类知识图谱、领域知识图谱等。它们各有侧重，以Cyc为代表的常识知识图谱致力于组织人类的常识知识，进而实现一般意义上的推理；以DBpedia为代表的百科类知识图谱则希望将全人类的知识图谱化，提供百科服务；而在企业应用中，由于业务差异性大，需要构建符合行业特点的领域图谱。

近年来，AI已经开始进入各行各业，行业KBQA的需求日渐增长。行业KBQA除了需要支持知识型问答外，还需要完成业务场景相关的问答，对KBQA的建设提出了更高的要求。目前，学术界关于KBQA的探讨侧重于百科类问答，关于行业KBQA的探讨还不多，例如：申请号CN201711459522.8的专利是关于金融理财产品领域，申请号CN201710318042.3的专利是关于厨房领域，而关于保险领域KBQA的探讨还是空白。

发明内容

有鉴于此，本发明实施例提供了一种保险行业知识图谱问答系统构建方法及装置。本发明实施例提供的具体技术方案如下：

第一方面，提供了一种保险行业知识图谱问答系统构建方法，所述方法包括：

S1：构建保险知识图谱的本体与知识表示；

S2：将与保险行业相关的多种原始数据基于所述本体与知识表示，生成保险知识图谱数据，并存储至图谱数据库中；

S3：获取用户问句，并对所述用户问句进行问句理解，其中，所述问句理解包括问句类型识别、问句意图识别、实体识别以及实体标准化；

S4：基于查询模板对所述问句理解获得的信息进行问句映射，生成查询语句；

S5：使用所述查询语句在所述图谱数据库中进行查询，得到查询结果并返回。

在一个优选实施例中，所述步骤S1进一步包括：

S1.1：确定保险业务涉及的保险产品领域和多个业务支撑领域，并设置本体规范；

S1.2：构建各个领域的分类体系以及知识表示，并定义保险产品实例与各个业务支撑实例之间的关系、以及各类实例的属性。

在一个优选实施例中，所述步骤S2进一步包括：

S2.1：判断所述多种原始数据中是否存在来自不同数据源且属于同种类别的数据；

S2.2：若步骤S2.1的判断结果为是，则判断所述数据是否符合融合场景；

S2.3：若步骤S2.2的判断结果为是，则对所述数据进行融合处理，否则，不进行融合处理；

S2.4：将所述多种原始数据中经过融合处理的数据以及无需融合处理的数据，基于所述本体与知识表示，生成数据结构为三元组结构的保险知识图谱数据。

在一个优选实施例中，所述步骤S4进一步包括：

S4.1：确定所述问句类型识别获得的问句类型，若问句类型为知识问答型，则执行步骤S4.2，若问句类型为场景判断型，则执行步骤S4.3；

S4.2：先确定用户问句中的实体和属性信息，再调用规则方法，以填充到知识型模板中，生成查询语句；

S4.3：确定问句意图识别获得的问句意图、实体识别获得的实体类别以及实体标准化获得的实体信息，执行步骤S4.4；

S4.4：对所述问句意图、所述实体类别和所述实体信息调用相应的处理方法，以填充到相应的场景判断型模板中，生成所述查询语句。

在一个优选实施例中，所述问句类型包括以下之一：

知识型问句、场景型问句及其他类型问句；

所述问句意图的类型包括以下之一：

核保、续保、核赔、核药、其他；

所述实体类别包括以下之一：

产品、疾病、年龄、职业、地区、药品。

第二方面，提供了一种保险行业知识图谱问答系统构建装置，所述装置包括：

本体构建模块，用于构建保险知识图谱的本体与知识表示；

图谱构建模块，用于将与保险行业相关的多种原始数据基于预先构建的本体与知识表示，生成保险知识图谱数据，并存储至图谱数据库中；

问句理解模块，用于获取用户问句，并对所述用户问句进行问句理解，其中，所述问句理解包括问句类型识别、问句意图识别、实体识别以及实体标准化；

问句映射模块，用于基于查询模板对所述问句理解获得的信息进行问句映射，生成查询语句；

图谱查询模块，用于使用所述查询语句在所述图谱数据库中进行查询，得到查询结果并返回。

在一个优选实施例中，所述本体构建模块具体用于：

确定保险业务涉及的保险产品领域和多个业务支撑领域，并设置本体规范；

构建各个领域的分类体系以及知识表示，并定义保险产品实例与各个业务支撑实例之间的关系、以及各类实例的属性。

在一个优选实施例中，所述图谱构建模块具体用于：

判断所述多种原始数据中是否存在来自不同数据源且属于同种类别的数据；

若存在，则判断所述数据是否符合融合场景；

若符合，则对所述数据进行融合处理，否则，不进行融合处理；

将所述多种原始数据中经过融合处理的数据以及无需融合处理的数据，基于所述本体与知识表示，生成数据结构为三元组结构的保险知识图谱数据。

在一个优选实施例中，所述问句映射模块具体用于：

确定问句类型识别获得的问句类型；

若问句类型为知识问答型，则先确定用户问句中的实体和属性信息，再调用规则方法，以填充到知识型模板中，生成查询语句；

若问句类型为场景判断型，则确定问句意图识别获得的问句意图、实体识别获得的实体类别以及实体标准化获得的实体信息；

根据问句意图、实体类别对调用相应的处理方法，将实体信息填充到相应的场景判断型模板中，生成查询语句。

在一个优选实施例中，所述问句类型包括以下之一：

知识型问句、场景型问句及其他类型问句；

所述问句意图的类型包括以下之一：

核保、续保、核赔、核药、其他；

所述实体类别包括以下之一：

产品、疾病、年龄、职业、地区、药品。

本发明实施例提供一种保险行业知识图谱问答系统构建方法及装置，通过构建保险行业知识图谱，并基于它实现一个保险KBQA系统，创新性地提出了数据层(知识表示)与逻辑层(问句映射)的联动机制，从而可以提供可靠的、可扩展的保险行业智能客服服务；此外，本发明实施例提供的技术方案还可以从保险行业泛化到其他行业中去。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种保险行业知识图谱问答系统构建方法的流程图；

图2为本发明实施例提供的疾病的分类体系的层级示意图；

图3为本发明实施例提供的本体的示意图；

图4为本发明实施例提供的保险知识图谱生成流程图；

图5为本发明实施例提供的问句理解流程图；

图6为本发明实施例提供的问句映射流程图；

图7为本发明实施例提供的一种保险行业知识图谱问答系统构建装置的结构框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明技术方案涉及两个主要环节：一是如何构建保险行业知识图谱，二是如何基于已构建的知识图谱构建保险行业问答系统。在保险行业知识图谱构建环节中，首先理解业务目标，比如如何实现核查用户可否投保(以下简称，核保)、核查用户可否理赔(以下简称，核赔)的任务；再者，需要理清完成业务目标需要的支撑领域知识，设计本体与知识表示；并依据本体规范，通过图谱管理与生成平台，从原始数据生成知识图谱；最后将图谱数据存入数据库，提供知识查询服务。在问答系统环节，首先需要为不同任务设定查询模版；再对用户输入的问句进行理解，包括问句类型、问句意图、实体识别、实体标准化；并根据这些提取的问句信息，进行问句映射，生成查询语句；最后完成查询，并组织返回给上层应用的结果。

图1为本发明实施例提供的一种保险行业知识图谱问答系统构建方法的流程图。该方法可以由保险行业知识图谱问答系统构建装置来执行，该装置可以采用软件/硬件的方式实现。如图1所示，该方法可以包括步骤：

S1、构建保险知识图谱的本体与知识表示。

其中，步骤S1可以包括：

(1)业务目标理解

为行业KBQA设计本体前，首先要理解KBQA需要达成的目标。只有明确了业务目标，才能确定本体需要涉及哪些领域，不需要涉及哪些领域。就保险KBQA而言，智能核保、智能核赔是用户最常使用的功能，比如，典型的核保问题“我今年30岁、住在虹口区，有高血压，可以投保尊享e生吗？”。分析可知，要完成核保任务，需要理解保险产品说明书中对相关事项的规定，每款保险产品限定了可投保年龄、可投保区域、不可投保疾病、不可投保职业等。同理，完成智能核赔，需要理解保险产品说明书对于不可理赔事项的规定，涉及不可理赔疾病、不合理用药等。

(2)本体设计与知识表示

理解用户的需求，确定业务目标后，进一步需准备为了完成这些目标所需要的知识。以智能核保、智能核赔为例，必然要求以保险产品知识为核心领域，以地区、疾病、药品等知识为支撑领域。对于每一个领域知识，需要设计合理的知识表达，以达到最方便的数据管理和生成。比如，因为地区之间具有层级关系，可以定义具有传递性的“位于”关系来描述地区实例，那么只要有“黄埔区，位于，上海”和“上海，位于，大陆地区”，就可以通过本体推理扩展出“黄浦区，位于，大陆地区”，这将大大减少数据生成的工作量。当然，并不是每个领域知识都能有地区一样简洁地表示，很多时候它们之间的实例仅能一一关联。对于实例之间的关系、实例的属性，都应当通过本体明确地定义。

S2、将与保险行业相关的多种原始数据基于预先构建的本体与知识表示，生成保险知识图谱数据，并存储至图谱数据库中。

(1)图谱数据生成

图谱数据可以使用W3C建议的RDF三元组格式。确定了图谱的本体和知识表示后，将原始数据转化为RDF格式进行存储。原始数据的来源可能是多种多样的，地区数据有国家标准地名表(比如，GB/T 2260)，疾病数据需要爬取相关主题网站，而保险产品数据多以文本形式存在。因此，对于不同形态的原始数据，需要针对性的解析，生成RDF数据。

(2)图谱存储与查询

合理生成KBQA所需的RDF数据后，需要将这些数据存储到数据库中去，以提供查询服务。常见的知识图谱数据库有两种，一种是RDF数据库，比如Jena、Stardog等；还有一类是图数据库，如Neo4J、Titan等。KBQA通过使用这些数据库支持的查询语言(如SPARQL、Cypher等)查询图谱数据库，获得相应的返回。

本实施例中，通过构建保险知识图谱，进而可以提供完成业务目标的知识图谱查询服务。

S3、获取用户问句，并对用户问句进行问句理解，其中，问句理解包括问句类型识别、问句意图识别、实体识别以及实体标准化。

本实施例中，问句理解是问答系统构建过程中的一个环节，问句理解负责理解用户问句包含的关键信息。

其中，问句分类是QA系统的一个组成部分，它基于期望的回答类型对问句进行分类。准确的问句分类，可以确定搜索策略，提高QA系统的表现。问句分类标准一般根据实际的应用场景确认。本专利的情况，需要确定用户问句是场景判断型(以下简称，场景型)、知识问答型(以下简称，知识型)、或者其他中的一类。问句分类的方法一般有基于规则的方法、基于机器学习的方法，或者基于两者的混合方法。

问句意图识别旨在确定用户问句中表达的具体意图。根据相应的意图，系统可以确定下一步的行动。意图分类是一个典型的短文本分类问题，可以采用基于规则的方法、基于机器学习的方法、基于深度学习的方法，或者它们的混合。本实施例中涉及的是保险领域，当问句类型为场景判断型时，需要确定用户问句的意图，主要意图包括核保、核赔、核查可否续保(以下简称，核续)、核查是否合理用药(以下简称，核药)、其他类别。

实体识别旨在确定了用户的意图，进一步确定某个意图的处理对象。比如，“我今年60岁，可以投保尊享e生吗？”由上一步可知，用户的意图为“核保”。但是，核保涉及的实例有“年龄”、“疾病”、“地区”、“职业”。只有确定了需要核实的实例类型，才能决定映射的方法。这一任务由实体识别完成，例句中的“60岁”被识别为“年龄”类实体。KBQA系统中，问句中的实体是与图谱中的实例是对应的。本实施例中需要识别的实体类别至少包括：产品、年龄、疾病、地区、职业、药品。

实体标准化旨在将用户的输入转化为实体的标准形式。用户的输入是多种多样的，有时候输入的年龄不是像“60岁”这样标准的形式。用户的输入可能会是“我88年生的，可以投保尊享e生吗？”。如此，需要对“88年生”进行处理，将其转化为年龄的标准形式(也就是图谱中的年龄知识的表示形式)。

S4、基于查询模板对问句理解获得的信息进行问句映射，生成查询语句。

本实施例中，问句映射是问答系统构建过程中的另一个环节，问句映射根据问句的关键信息，生成特定的图谱查询语句。具体的，问句映射是根据问句理解获得的信息生成完成任务所需的查询语句(一条或多条)，向知识图谱数据库查询后，综合查询的返回结果，并将最终结果传给上层应用。

在进行问句映射之前，需要进行模版管理。具体来说，根据业务场景，事先为不同类型的问句准备不同的模版。本实施例中主要有两类模版，一类是知识型模版，还有一类是场景型模版。其中，知识型模版比较简单，一般只需要确定需要查询的实例及其属性，就可以构造查询该实例的对应属性值的语句。而场景型模版则比较多，因为对应于一个意图，该意图可能对应的多个实体类型，所以需要准备不同的模版来生成查询语句。特别是，对于复杂场景，需要构造多条语句来完成任务。

准备好模版后，映射层根据问句类型、问句意图、问句实体类型三个信息确定具体调用哪个问句模版。如果问句是知识型问句，则会先确定问句涉及的实体，调用规则方法填充知识型模版的属性槽，生成查询语句。如果问句是场景型问句，则会根据意图和实体类型对确定调用的处理方法(即，一个意图和实体类型对对应一个处理方法)。对应的处理方法再填充具体的查询模版，生成查询语句。知识型问句对应的查询一般是一条查询语句，场景型问句一般是一条或多条查询语句。

S5、使用查询语句在图谱数据库中进行查询，得到查询结果并返回。

本实施例中，用户问句映射完成后，可以生成图谱查询语句。向图谱数据库查询后，会返回一条或多条语句的查询结果。对于知识型问题，一般会得到一个文本列表，只需要将此列表返回给上层应用即可。对于场景型问题，一般会得到一个或多个判断状态，需要综合这些判断状态后，再返回给上层应用。由上层应用使用话术模版，生成返回给用户的最终回答。

上述是一个典型的KBQA单轮会话的过程。实际上，一个完善的KBQA系统和其他对话系统一样需要多轮交互机制，用于管理上下文、澄清候选信息、或者补充缺失信息。比如，用户先问了“60岁可不可以购买尊享e生？”，接着再问“80岁呢？”，此时需要继承上一句用户问句的信息，将“60岁”替换为“80岁”后再进行图谱查询。由于本实施例更多地关注于KBQA单轮会话的完成度，侧重于图谱建设、问答系统以及它们的联动，仅在必要时讨论多轮会话。

在一个优选实施例中，步骤S1构建保险知识图谱的本体与知识表示具体实现过程可以包括：

S1.1：确定保险业务涉及的保险产品领域和多个业务支撑领域，并设置本体规范。

在本实施例中，行业知识图谱的构建服务于业务场景，而本体能起到规范业务的作用。通过构建本体，可以形式化业务场景所涉及知识的组织，避免随着业务场景增多而可能导致的混乱。

一个完善的本体可以引导事实数据的标准化，并在整合不同来源的数据时，统一具有相同内涵、不同显示的属性名和关系名。此外，本体推理以及自定义规则推理也需要建立在一个定义良好的本体之上。通过知识推理，可以扩延事实数据，方便数据管理和问句映射。

本体的描述分类两部分，一部分是领域的层级分类体系(HierarchicalTaxonomy)，另一类是实例间关系(Relation)和实例属性(Attribute)的定义。本实施例中，关系对应于Protégé中的对象属性(Object Property)，属性对应于Protégé中的数据型属性(Data Property)。(注：Protégé是一个免费的开源本体编辑器和智能系统构建框架。)

其中，本实施例的本体有如下基本规范：

(1)所有实例均会被ID化，拥有唯一编码。

对所有实例进行ID化，可以避免不同类别的同名实体，比如苹果(fruit)、苹果(company)；另外，ID化可以方便实体对齐，不同来源的相同数据，只要挂到同一个ID下即可；此外，ID的生成方式为“领域前缀_MD5随机码(前9位)”，如“青少年网络成瘾”编码为“DSS_4f30b3f28”。国家标准码或者行业标准码，则以属性的形式，附加给实例，比如“<DSS_4f30b3f28>icd10_code“F63.800A””。

(2)每个实例有一个name属性(标准名)和多个alias属性(别名)。同时，为了方便问句映射，将标准名增设为别名(通过alias属性，使用标准名也能确定实例ID)。例子如下：

<DSS_f2ae30b7>name“爱德华兹综合征”

<DSS_f2ae30b7>alias“Edwards综合征”

<DSS_f2ae30b7>alias“18-三体综合征”

<DSS_f2ae30b7>alias“爱德华兹综合征”

(3)关系用英文描述，属性用中文描述。

实例间关系一般需要根据业务场景自定义，多是动词性的，使用英文描述会更加自然。比如，“尊享e生有不可投保疾病血癌”可以表示为“<ID(尊享e生)>hasForbiddenDisease<ID(血癌)>”(下文中，事实的实体将用<>包围，ID化将使用ID()表示。)；

实例属性一般来自现有数据(比如百科、爬虫等)，用来描述该实例自身的性质，多是名词性的，直接使用中文名即可。比如，“尊享e生的法律援助额度是6000元”可表示为“<ID(尊享e生)>法律援助额度“6000元””。

(4)根据领域的知识表示，合理选用关系或属性。

比如，表示某种产品有某种不可投保疾病时，因为产品和疾病都需要表示为实例，所以使用关系进行更加合理；而表示某种产品的被保险人年龄时，因为具体的年龄(如“18岁”)没有进一步的属性，直接作为产品的属性会更加方便。两者的表示如下：

<ID(尊享e生)>hasForbiddenDisease<ID(血癌)>

<ID(尊享e生)>hasAllowedInsurantAge“18岁”

(5)简洁一致原则。

本体设计要尽量简洁。随着数据增多，过多使用复杂描述(比如数据属性限定、存在限定、全称限定等定义新类别)的本体会变得难以维护。保持本体的简洁可以避免很多不必要的麻烦。

在定义需要自定义的关系名或属性名时，要使用一致的命名。比如禁止可以用：hasForbiddenDisease、hasForbiddenRegion、hasForbiddenInsurantAge、hasForbiddenOccupation等；允许可以有:hasAllowedDisease、hasAllowedRegion、hasAllowedInsurantAge、hasAllowedOccupation等。

S1.2：构建各个领域的分类体系以及知识表示，并定义保险产品实例与各个业务支撑实例之间的关系，以及各类实例的属性。

本实施例中，通过根据保险业务方所提需求和对用户常见问题的分析，保险KBQA需要提供的功能包括两类：一类是知识型问答、一类是场景型问答。其中，场景型问答又包括智能核保、智能核赔等场景。本实施例将以某公司的一款健康险“尊享e生”为例。

分析保险业务，确定领域范围，设计各个领域的分类体系。保险业务，首先必不可少的是保险知识，保险知识的分类体系比较简单，分类体系可以按保险的种类进行，比如分为健康险、医疗险、航旅险、车险、特色保险。关于产品的知识表示，首先保险产品作为实例，因为一个具体的保险产品具有自身的属性，比如“尊享e生”有可投保年龄、被保险人年龄、住院免赔额、法律援助额度等属性。进一步地，为了完成场景型问答，比如智能核保，一般需要对用户的年龄、所在地区、已罹患疾病、是否高危职业等进行核查。这要求需要建立相应的支撑领域。下面具体说明本实施例中的疾病、地区和年龄支撑领域的知识表示，并比较它们的异同。

(1)地区的知识表示

保险的销售一般有指定的地区，比如“尊享e生”的销售范围是中国大陆地区，对于非中国大陆地区的居民不能投保。那么如何表示这种业务关系呢？一种直观的方案是收集常用的地名表(比如，国家标准地名表GB/T 2260)，将表中的所有大陆地区地名(3216个)用hasAllowedRegion关系与“尊享e生”产品进行关联，比如“<ID(尊享e生)>hasAllowedRegion<ID(北京市)>”。如此，当有用户想问“住在北京市，可以投保尊系e生吗？”时，查询是否存在“<ID(尊享e生)>hasAllowedRegion<ID(北京市)>”事实数据即可。

除了上述表示外，如果进一步分析地区领域知识的特性，还可以使用一种更加合适的知识表示方式。这种方式除了能完成上述业务问答外，还能提供额外的知识查询。因为地区之间具有层级关系，如果定义具有传递性的“isLocatedIn”关系，那么只要有“<ID(黄埔区)>isLocatedIn<ID(上海市)>”和“(ID(上海市)isLocatedIn ID(大陆地区)”，就可以通过本体推理扩展出“<ID(黄浦区)isLocatedIn ID(大陆地区)>”。另一方面，具体产品在管理可投保地区时，也只需要定义“<ID(尊享e生)>hasAllowdRegion<ID(大陆地区)>”。如此，回答用户问题时，获取了用户所在地区，检查该地区在不在尊享e生的可投保地区(大陆地区)，就可以确定用户所在地区是否可以投保。因为用户所在地区是否位于大陆地区这一知识，已经蕴含在了上述传递关系里。

本体层面，根据国家标准地名表GB/T 2260，确定地区的分类为：国家、地级市、市县区、省四个类别。如此，通过合理的知识表示，不需要显示地将所有地区的名字都关联到某个产品上，也可以获得相同的表达能力。并且，对于诸如“黄山市在不在安徽省？”等地区知识型问题也可以支持，这对于领域知识的复用是很有意义的。然而，并不是每个领域知识都能如地区一样简洁地表示，很多时候它们之间的实例仅能一一关联，下面的疾病知识就是如此。

(2)疾病的知识表示

对拟投保人的过往所罹患疾病进行核查是健康险核保业务的重要内容。疾病作为实例，因为疾病本身具有很多属性，比如科室、并发症、症状表现等。健康险产品一般会在保险条款说明书中说明不可投保疾病，比如“尊享e生”的不可投保疾病包括：1)高血压(收缩压达到160mmHg或舒张压达到100mmHg)、心脏病(包括心功能不全II级或II级以上、冠心病、心肌梗塞(梗死)、心肌病)、主动脉血管瘤、脑血管病(包括脑卒中、脑血管畸形)；2)肝硬化、慢性肝功能衰竭失代偿期、慢性活动性肝炎(包括乙型、丙型病毒性肝炎或携带者)；3)糖尿病；4)胰腺疾病(包括胰腺炎、胰腺囊肿或肿瘤)；5)溃疡性结肠炎、萎缩性胃炎或胃溃疡；6)肺部疾病(包括肺结核、慢性阻塞性肺病、尘肺、弥漫性肺间质纤维化、呼吸衰竭)；7)先天性疾病、遗传性疾病；8)红斑狼疮、肾脏疾病(包括肾萎缩、慢性肾炎、肾功能衰竭、多囊肾、肾切除三年以内)、严重的血液疾病(包括白血病、血友病、再生障碍性贫血，恶性组织细胞病)、神经疾病(包括癫痫、多发性硬化、重症肌无力)；9)精神科疾病(包括人格障碍、精神分裂症、抑郁症、燥郁症、躁狂症)；10)脑炎后遗症或脑膜炎后遗症、脑部良性肿瘤、严重脑损伤；11)阿尔茨海默病、帕金森病；12)良、恶性肿瘤(含原位癌、白血病、何杰金氏病)；13)性病、艾滋病及HIV阳性；14)接受过器官移植；15)法定传染病甲类或乙类。

关于疾病的分类体系，考虑到疾病知识是比较专业的知识，采用WHO指定的国际疾病分类(ICD-10)作为本实施例的疾病分类体系。ICD-10分类体系呈双层四级，双层是指ICD编码层及其对应的中文层(两层中的各级类别通过等价关系关联)；四级是指疾病的细分层次为4级，比如：消化系统疾病(L1)-肝疾病(L2)-酒精性肝病(L3)-酒精性脂肪肝(L4)，层次图例子具体可参照图2所示。

相对于地区的单层分类，ICD-10分类是一个非常复杂的分类体系，这主要是由疾病领域知识的复杂性决定的。在实际的使用过程中，不一定需要使用全部的层级结构，选择性的使用其中的部分层级有时并不影响业务目标。

实例层面，保险产品中的不可投保疾病的描述一般比较通俗。有的描述，比如“性病”非常宽泛，有的描述又非常具体，比如“弥漫性肺间质纤维化”。为了统一疾病的粒度，本实施例使用ICD-10的标准疾病名(共22862种)作为中轴，将产品描述中的不可投保疾病映射到ICD-10标准名。比如，ICD-10中有7类高血压，根据高血压的不可投保条件“收缩压达到160mmHg或舒张压达到100mmHg”，可将“临界性高血压”、“高血压I期”分为可投保，将“恶性高血压”、“高血压Ⅱ期”、“高血压Ⅲ期”、“高血压危象”分为不可投保。特别的，高血压病(I10.x00)又包括多种高血压，但这些高血压不是通过收缩压或舒张压的值划分的，需要医学专家的判定。这样，高血压在ICD-10粒度上，可划分如下表1。

表1：高血压在ICD-10粒度上的划分

ICD-10编号	疾病名	是否可投保？
			I10.x00	高血压病	需专家判定
I10.x01	临界性高血压	可以
			I10.x02	恶性高血压	不可以
I10.x03	高血压I期	可以
			I10.x04	高血压Ⅱ期	不可以
I10.x05	高血压Ⅲ期	不可以
			I10.x06	高血压危象	不可以

根据上述方法，确定了7428种ICD-10标准名粒度的不可投保疾病，将它们逐一与“尊享e生”产品建立关联，比如“<ID(尊享e生)hasForbiddenDisease ID(恶性高血压)>”。如此，当获得用户输入的疾病时，就可以通过查询图谱数据库，确定该疾病是否可以投保。

但是，由于知识图谱的开放世界假设，没有数据的地方，图谱不能给出确定结论。首先，数据可能是不完备的，无法覆盖所有不可投保疾病的表示；其次，用户的疾病输入常常不能对应到已登记的数据上；再者，对于“高血压”这种类别概念也无法简单地确定可不可以投保。但是，对于疾病是否可投保是比较敏感的信息，系统回复给客户的信息需要准确。因此对于疾病的知识表示，需要采用双向确认机制。

也就是说，除了构建如“<ID(尊享e生)hasForbiddenDisease ID(恶性高血压)>”的数据以外，同时建立“<ID(尊享e生)hasAllowedDisease ID(高血压I期)>”(对ICD-10中除去不可投保疾病和需专家确定的疾病以外的疾病生成该数据)。如此，可以对用户的疾病输入进行两次检查，如果其在禁止投保疾病中，则可以明确返回用户“不可投保”；如果其在可以投保疾病中，则可以明确返回用户“可以投保”；如果两次查询都返回没有数据，则返回用户“无法确定”(此时可以转接人工，或给出提供更多信息的链接)。

(3)年龄的知识表示

健康险产品的可投保年龄有限定的范围，一般要求被投保人出生30天，不超过65岁。和地区和疾病不同的是，年龄本身是一个数值，不存在实例的概念。也就说，不需要对年龄值进行ID化(比如，“30岁”本身不存在进一步的属性)。因为年龄被表示为产品的属性，因此，年龄知识也没有分类体系。

考虑问答环节的处理，比如“30岁可以投保尊享e生吗”，年龄值(30岁)会被识别出来。为了直接使用“30岁”构造查询语句、进行图谱查询，本实施例将范围序列化，也就是将年龄范围[30天，65岁]表达为序列形式(也就是，30天、364天、1岁、2岁、3岁、…、65岁)。然后，再将它们作为产品的属性与某个产品建立关联，比如“<ID(尊享e生)>hasAllowedInsurantAge“30岁””。对于数据量有限的范围，将范围序列化表示，可以方便问句映射。

综上，各个领域的知识表示，需要注意领域本身的特性和问答环节的便捷性。参考上述领域，可以设计其他领域的知识表示，此处不再赘述，本实施例的本体的示意图具体可以参照图3所示。

在一个优选实施例中，步骤S2中将与保险行业相关的多种原始数据基于预先构建的本体与知识表示，生成保险知识图谱数据，具体实现过程可以包括：

S2.1：判断多种原始数据中是否存在来自不同数据源且属于同种类别的数据。

生成保险知识图谱时，将从多个渠道收集到的原始数据，依据本体规范，依照本体的分类标准、关系命名、属性命名，通过图谱管理与生成平台生成合规的RDF数据(即保险知识图谱数据)。与本体文件只要保存领域的分类体系不同，RDF数据主要保存事实数据。这些事实数据是提供知识查询的核心数据。

当数据来源较多时，会出现数据融合的需求，需要更多的处理。对于同一领域(比如疾病)，知识来源可能不止一个，多来源虽然扩充了图谱的数量，但是多个来源之间可能存在数据重复或者冲突，因此需要先确定出多种原始数据中是否存在来自不同数据源且属于同种类别的数据。

需要说明的是，若步骤S2.1的判断结果为否时，直接执行步骤S2.4。

S2.2：若步骤S2.1的判断结果为是，则判断数据是否符合融合场景。

于本实施例中，主要的融合场景包括：

(1)不同来源的同种类别的数据的标准名不同；

(2)不同来源的同种类别的数据的属性相同。

需要说明的是，若步骤S2.2的判断结果为否时，直接执行步骤S2.4。

S2.3：若步骤S2.2的判断结果为是，则对数据进行融合处理，否则，不进行融合处理。

具体的，当不同来源的同种类别的数据的标准名不同时，对该数据进行融合处理，包括：

示例性地，疾病知识的来源途径有3个。各个来源均有自己的疾病名(记为显示名)，而这个显示名将会被作为标准名进行ID化。

如果不同来源的同种类别的数据采用了相同的显示名时，即便每个来源有的属性不同，均能被赋值到同一个疾病ID下，完成融合；

如果同种类别的数据在各个来源中具有不同的显示名，则它们会被视为不同的数据，此时，需要建立数据显示名的同义词组。

示例性地，对于相同的疾病在各个来源中具有不同的显示名时，需要建立数据显示名的同义词组，将其中的ICD-10名称作为标准名，其他名称作为别名。这样如果某个来源中的疾病显示名是别名时，它会被映射为ICD-10名称，从而获得正确的ID。

如果疾病同义词组不包括其ICD-10名称，也无法方便地将其中任意一个名称对应到ICD-10名称时，可以先将其中的一个名称作为标准名，其余的作为别名。这也是不直接使用行业标准码(比如ICD-10)作为实例ID的原因，因为实际数据中，有些来源的显示名不使用行业标准名。

具体的，当不同来源的同种类别的数据的属性相同时，对该数据进行融合处理，包括：

在本体层面进行统一表示；

如果不同来源的数据无冲突、质量均可的情况，同时加入到数据中去；

如果某两个来源的数据存在冲突，则选择其一；

如果某个来源的数据质量很差，则将其去除。

示例性地，比如，3个疾病来源均有科室这一属性，如果科室的属性显示名在不同来源不一样，首先要在本体层面统一它的表示(比如统一为“所属科室”)。

但是，各个来源的“所属科室”这一属性的分类基准、分类质量是不一样的，此时需要进一步分析数据，确定融合方案。如果不同来源的数据无冲突、质量均可的情况，可以同时加入到数据中去(查询时，返回“所属科室”的列表)；如果某两个来源的数据存在冲突，则选择其一；如果某个来源的数据质量很差，则将其去除。

S2.4：将多种原始数据中经过融合处理的数据以及无需融合处理的数据，基于本体与知识表示，生成数据结构为三元组结构的保险知识图谱数据。

该步骤可参照如图4所示，图4为本发明实施例提供的保险知识图谱生成流程图。

本实施例使用了自建的图谱数据生成与管理系统生成事实数据的过程。事实数据可以细分为三类：第1类是支持场景型问答的数据(如“<ID(尊享e生)>hasForbiddenDisease<ID(血癌)>”)，第2类是支持知识型问答的数据(如“<ID(尊享e生)>法律援助额度“6000元””)，第3类是将实例挂接到某个类别的数据(如“ID<尊享e生>”type“健康险””)。

场景型问答的知识表示是事先定义的，因此其RDF数据的生成需要遵循其知识表示和本体中定义好的关系名定制化地生成。另一方面，知识型问答一般使用从各个渠道获得的数据，依照本体规定的属性名生成实例的属性数据，相对比较容易。

保险知识图谱数据(即事实数据)的生成除了要符合本体规范外，还需详略得当。如果拿鱼网来形容事实数据的话，数据多有如网密，数据少有如网疏。所以，一般通过需要分析问答系统的日志，对于用户咨询的高频问题建立密集网络，这样可以拦截(回答)更多的鱼(问题)。保险问答中，“核保”、“核赔”都是非常高频的用户咨询。

在一个优选实施例中，步骤S2中将存储保险知识图谱数据，并提供查询服务，具体包括：

将生成RDF格式的事实数据后，将事实数据保存在图谱数据库中。本实施例选择RDF数据库Jena作为存储，Fuseki作为SPARQL查询服务器。依据上述本体设计与规范、领域知识表示、以及数据生成过程，主要的查询任务可以通过下述SPARQL语句完成。

首先，设定SPARQL查询前缀，如下：

PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>

PREFIX exp:<http://zhongan-ns#>

这里设定的rdf和rdfs为W3C标准命名空间的缩写，exp为自定义命名空间的缩写。设定查询前缀，可以简化SPARQL查询语句。

示例性地，对于某个年龄是否可以投保，以“30岁”为例，有：

ASK{

？product_id exp:name"尊享e生".

？product_id exp:hasAllowedInsurantAge"30岁".

}

该SPARQL查询第一行是产品名的ID化(确认“尊享e生”的id)，第二句是判断“尊享e生”是否有被保险人可投保年龄“30岁”。如果有话，将会返回True；没有的话，将会返回False。

对于某个疾病是否可以投保，以“高血压I期”为例，有：

ASK{

？product_id exp:name"尊享e生".

？disease_id exp:name"高血压I期".

？product_id exp:hasForbiddenDisease？disease_id.

}

ASK{

？product_id exp:name"尊享e生".

？disease_id exp:name"高血压I期".

？product_id exp:hasAllowedDisease？disease_id.

}

需要注意的是，由于疾病的判断是双向确认，所以疾病的判断有两条SPARQL语句。两条SPARQL结构类似，第一行对产品名ID化，第二行对疾病名ID化，第三句判断“高血压I期”是否不可投保(hasForbiddenDisease)，或者可以投保(hasAllowedDisease)。

示例性地，对于某个地区是否可以投保，以“泰州市”为例，有：

ASK{

？product_id exp:name"尊享e生".

？regidon_id exp:name"泰州市".

？product_id exp:hasAllowedRegion？allowed_regidon_ids.

？region_id exp:位于？allowed_region_ids.

}

注意到，和疾病检查不同的是判断地区时，除了前两条ID化语句外，实质判断语句需要两步才能完成。第一步确认“尊享e生”有哪些可投保地区(hasAllowedRegion，可以是多个)；第二步确认用户所在地区(泰州市)是否位于可投保地区。这个查询语句虽然可以完成查询任务，但是会造成问答映射环节的SPARQL模版过于臃肿。

因此，可以设定如下自定义推理规则：

ruleHasAllowedRegion:

(？product_id exp:hasAllowedRegion？allowed_regidon_ids)

(？regidon_id exp:isLocatedin？allowed_regidon_ids)

->(？product_id exp:hasAllowedRegion？regidon_id)

基于该自定义推理规则生成扩展数据，进而使用如下的简化查询语句，完成相同的任务。

ASK{

？product_id exp:name"尊享e生".

？regidon_id exp:name"泰州市".

？product_id exp:hasAllowedRegion？region_id.

}

最后，典型的知识型查询语句，如下。

SELECT？complication

WHERE{

？disease_id exp:name"人类T淋巴细胞病毒感染".

？disease_id exp:并发症？complication.

}

该SPARQL查询“人类T淋巴细胞病毒感染"有哪些并发症，返回并发症列表。

这些查询语句将被用来实际回答用户的问题(完成问句映射后)，是知识图谱提供知识服务的主要方式。

在一个优选实施例中，如图5所示，步骤S3中对用户问句进行问句理解可以采用问句类型分类、问句意图分类、实体识别(标准化)并行进行的方法。这里的并行进行是指这三个步骤不依赖于其他的任何步骤，可以同时进行，需要说明的是，因为实体识别和实体标准化关系密切，这里用“实体识别(标准化)”表示这两个连续过程；此外，还可以先进行问句类型识别，然后根据问句类型识别结果，确定是否进行问句意图分类、实体识别(标准化)。

其中，问句类型分为三类：场景型、知识型、其他；问句意图分类可以包括：核保、续保、核赔、核药、其他，对应用户经常询问的业务场景；实体识别需要识别的类别包括：产品、疾病、年龄、职业、地区、药品，对应图谱中保存的实例类型。

其中，问句的类型分类与意图分类是多分类任务。这些类别的不同组合将会确定映射策略，这将在下面的查询映射部分说明。本实施例使用的问句类型分类使用基于规则的方法；问句意图方法采用基于深度学习的方法；命名实体识别使用规则与机器学习相混合的方法。

由于这些功能属于NLP中的独立任务，并不是KBQA系统独有，在实际应用中只需要结合实际的业务场景，定义自己的分类标准，准备好相应的功能模块进行调用即可，此处具体细节不再展开。

在识别到实体类型后，进行实体标准化。示例性地，假设需要获取用户的年龄值，但是用户的输入是“我88年出生的。”，将被标记为“我/first_person 88年/date出生/v的/uj。/x”，此时，无法直接获得用户的年龄信息。而在建立知识图谱时，年龄的表示是“30岁”这种形式，因此需要将上述情况进行标准化。

实体标准化可以采用基于REFO的标准化。示例性地，首先，将“我/first_person88年/date出生/v的/uj。/x”转化为实体结构体序列；该实体结构体序列中的每个实体结构体有两个属性，一个是实体类别，一个是实体文本。然后，制定如下REFO规则：

Rule(condition＝E(type＝"date")+E(text＝"出生|生"),action＝normalize_age)

那么，对于任何的实体属性为date的实体，只要它周围存在“出生”或者“生”的语境，比如“88年出生”或者“88年生”，将会调用normalize_age函数，将“88年/date出生/v”这一信息转化为“30岁/age”。这样，就完成了年龄的标准化，其他实体类型的标准化处理类似。

在一个优选实施例中，如图6所示，步骤S4中基于查询模板对问句理解获得的信息进行问句映射，生成查询语句，具体实现过程可以包括：

S4.1：确定问句类型识别获得的问句类型，若问句类型为知识问答型，则执行步骤S4.2，若问句类型为场景判断型，则执行步骤S4.3。

具体来说，根据问句类型的不同，将使用不同的问句映射方法，将自然问句转化为SPARQL查询语句。实际映射时，根据合理的流程，将问句信息填充到预设的模版中去。

因此，需根据业务场景事先设计好SPARQL模版。根据问题类型不同，模版分类两类：ASK类模版(常用于场景型问句的查询)和SELECT类模版(常用于知识型问句的查询)。

SELECT类模版常用于回答用户的知识型问句，比如“人类T淋巴细胞病毒感染的并发症有哪些？"，用来查询某个实例的具体属性。SELECT类模版的数量一般比较少。下面是一个典型的SELECT模版：

SPARQL_SELECT_GENERAL＝

"SELECT？x

WHERE{{

？id exp:name'{entity}'.

？id exp:{attribute}？x.

}}"

使用时，只要替换{entity}为实体识别出的具体实体(比如，人类T淋巴细胞病毒感染)，替换{attribute}为映射规则识别出的具体属性(比如，并发症)，就可以构建SPARQL查询语句。

另一方面，因为ASK类问句是为了回答用户的场景型问题，面临的场景比较多，所以ASK类模版也会较多，需要根据意图及其对应实体类别进行整理与准备。比如，对于“核保”意图，某个产品设计的实体类别：年龄、地区、疾病、职业，需要准备至少四个不同的模版，以分别对应年龄、地区、疾病、职业各个实体类别。示例性地，如下为年龄和疾病实体类别对应的模板：

SPARQL_ASK_UNDERWRITE_PRODUCT_AGE_HEAD＝

"ASK{{

？product_id exp:name'{product}'.

？product_id exp:hasAllowedInsurantAge'{age}'.}}"

SPARQL_ASK_UNDERWRITE_DISEASE_HEAD＝

"ASK{{

？product_id exp:alias'{product}'.

？disease_id exp:alias'{disease}'.

？product_id exp:hasAllowedDisease？disease_id.}}"

注意到，年龄模版(SPARQL_ASK_UNDERWRITE_PRODUCT_AGE_HEAD)和疾病模版(SPARQL_ASK_UNDERWRITE_DISEASE_HEAD)是有差异的，age并不需要获取age的age_id，这是和图谱中年龄的知识表示对应的(因为年龄表示为产品的属性)。根据疾病的知识表示，问答系统会双向确认疾病是否可投保，因此，疾病还需补充反向检查疾病是否可投保的模版(如下)。

SPARQL_ASK_UNDERWRITE_DISEASE_TAIL＝

"ASK{{

？product_id exp:alias'{product}'.

？disease_id exp:alias'{disease}'.

？product_id exp:hasForbiddenDisease？disease_id.}}"

综上，对于“核保”意图的四种实体，需要准备5个模版。

本实施例中，查询映射根据问句理解信息和查询模版生成对应用户问句的SPARQL查询语句，是KBQA的核心模块。因为用户表述的复杂性和任务的多样性，其映射不是简单的从一句自然问句到一条SPARQL语句，因为为了回答用户的自然问句有时候需要调用多次不同形式的SPARQL查询。

S4.2：先确定用户问句中的实体和属性信息，再调用规则方法，以填充到知识型模板中，生成查询语句。

本实施例中，当问句被判断为知识型时，不需要获取问句的意图。系统会调用规则方法匹配问句，获得填充SELECT类模版的必要信息。本系统的规则系统也是通过REFO实现的，比如：

complication_signal＝E(text_p＝"并发症|并发症状|并发疾病")

Rule(condition＝disease+anything+complication_signal+anything,

action＝partial(generate_attribute_query,entity_type＝'disease',entity_attr＝'并发症'))

REFO规则“disease+anything+complication_signal+anything”的意思是，当遇到一个问句存在disease实体和并发症属性信号时，激活generate_attribute_query函数。函数内部会将疾病和属性的具体信息填充入模版生成SPARQL查询语句。比如，“人类T淋巴细胞病毒感染的并发症有哪些？”将会被解析为如下SPARQL语句：

SELECT？x

WHERE{

？id exp:name'人类T淋巴细胞病毒感染'.

？id exp:并发症？x.}

S4.3：确定问句意图识别获得的问句意图、实体识别获得的实体类别以及实体标准化获得的实体信息，在步骤S4.3之后，执行步骤S4.4。

本实施例中，当问句被判断为场景型时，需要获取问句的意图；确认意图后，还需确认该意图对应的实体类型对(包括左实体和右实体)，然后才能确定具体处理的方法。

S4.4：根据问句意图、实体类别对调用相应的处理方法，将实体信息填充到相应的场景判断型模板中，生成查询语句。

本实施例中，一个(意图，左实体，右实体)将会对应一个SPARQL生成函数。因此，要将这些信息以合理的形式组织起来。举个例子，对于“核保”意图的组织如下：

这表示，核保(underwrite)意图一边可以是产品(product)类型的实体(位于事实数据三元组的左边，故称left)，另一边可以是年龄(age)、疾病(disease)、职业(occupation)、地区(region)类别的实体(位于事实数据三元组的右边，故称right)。

每一个(意图、左实体、右实体)对应一个处理函数(比如，(underwrite,product,age)对应underwrite_product_age_query函数)。具体的函数指定了使用了对应关系(比如，hasAllowedInsurantAge)的模版，再通过填充实体信息，生成SPARQL查询语句。

场景型SPARQL生成要比知识型复杂。本实施例进一步将SPARQL语句与其他信息组装成一个SPARQL词典。这里的其他信息至少包括该SPARQL的类型(type)和该SPARQL语句的右实体信息(right)。比如，“60岁能投保尊享e生吗？”，这是一个(核保、产品、年龄)问题，可生成SPARQL词典如下：

{

'type':'head_only',

'right':'60岁/age',

'head':"

ASK{

？product_id exp:name'尊享e生'.

？product_id exp:hasAllowedInsurantAge'60岁'.}"

}

这里的SPARQL的类型为head_only，这表明只需要对年龄做正向检查。除了head_only外，还可以有head_tail，这表明需要做双向确认，比如对疾病的检查。保存实体信息可以方便将该信息传给上层应用，提示用户当前的输入，使回复更加自然。

特别指出的是，这里如果问题是“60岁可以续保尊享e生吗？”，那么要检查“续保”的年龄是否合理的话，需要使用的是(续保、产品、年龄)的处理函数，不会和(核保、产品、年龄)产生冲突。

除了上述基本映射外，本实施例的KBQA还支持如下复杂情况的处理。

本实施例的场景型问句映射支持同时处理一个意图下的多个实体类别。举例，当有问句"60岁，上海地区，有慢性高血压，能投保尊享e生吗？"时，确定此句意图为“核保”，涉及左实体为“尊享e生”(产品)，右实体为“60岁”(年龄)、“上海市”(地区)、慢性高血压(疾病)，此时会同时生成三组SPARQL查询语句。

此外，本实施例的场景型问句支持多意图处理(考虑到问句理解的鲁棒性，支持到两个意图为止)。两个意图的情况对应到图谱的两个关系，可以对2-hop结构进行查询。比如对某个用户罹患某种疾病，使用了某种药物，检查可否理赔的场景，不仅需要疾病属于产品的可理赔范围，还要求疾病的用药属于合理用药。实际使用过程中，可以将1个2-hop查询(比如，产品-可报销疾病-疾病-合理用药-药品)，拆解为两个1-hop查询(比如，产品-可报销疾病-疾病、疾病-合理用药-药品)。这样的好处是不仅可以告诉用户核赔的整体结果，还可以说明哪个环节有问题。

再者，有时会出现场景型问句和知识型问句易混淆的情况。比如“60岁是否可以投保尊享e生？”和“尊享e生是否包括特殊门诊？”，同样是“是否”问题，但是如果将后一句归类为场景型问句，将无法正确的获得回答。因为，“包括特殊门诊”在数据层是“尊享e生”的属性(值为yes或no)，这属于知识型问题的处理范畴。此时，有两种解决方案。一是更改图谱的知识表示，将属性表示改为关系，比如“<ID(尊享e生)>includeItem<ID(特殊门诊)>”，再为这个1-hop关系设定对应的处理函数。这种方法比较繁琐，仅适合高频任务。二是仍通过知识型映射来处理，但将“是否”问句同时分到“场景型”和“知识型”(本实施例的问句分类采用多分类)，当作为场景型问句时的其意图为“其他”时，使用知识型问句的规则进行处理。

最后一个特殊情况是，极少的时候存在一个(意图，左实体，右实体)的对应多个关系的情况。比如，“核保”意图下的右实体“年龄”一般是指“被投保人年龄”，但是不排除用户说的是“投保人年龄”，比如“我今年80岁，可以帮我儿子买尊享e生吗？”。此时，如果语言理解环节检测出存在两个人物，但未能确定该年龄值具体是哪个年龄，将无法确定需要调用的处理函数。本实施例中，因为这一信息已被事先整理(即“核保”意图下的(产品、年龄)实体对可以对应到图谱中的两种关系)，KBQA可以通过主动向用户提问，确定用户所指“80岁”是指什么年龄，生成正确的SPARQL语句，这也是需要交互对话的一种情况。

在一个优选实施例中，步骤S5中使用查询语句在图谱数据库中进行查询，得到查询结果并返回，具体实现过程如下：

通过查询映射生成的SPARQL语句，向Jena的Fuseki服务询问后，会得到返回结果。综合这些返回结果，返回给上层应用。

对于知识型问句，一般返回一个列表。比如，“人类T淋巴细胞病毒感染的并发症有哪些？”，查询图谱后，将会获得如下返回：

['胸腔积液','门静脉高压症','腹水']

对于场景型问句，一般返回一个状态词典，比如，“60岁可以投保尊享e生吗？”，查询图谱后，将会获得如下返回：

{'underwrite':{'尊享e生/product':[{'60岁/age':'Y'}]}}

该词典包含了该问句的意图，及其对应的左实体、右实体信息，以及这个任务的状态。其中，“Y”表示认同(yes)，“N”表示拒绝(no)，“P”表示需进一步确认(pending)。

对于单意图多实体的情况，比如“60岁，上海地区，有慢性高血压，能投保尊享e生吗？”，返回：

{'check_buy':{'尊享e生/product':[{'60岁/age':'Y'},{'上海市/region':'N'},{'慢性高血压/disease':'P'}]}}

因为返回的状态字典中，带有各个实体的信息，所有上层应用可以使用这些信息，组装合适的回答给用户。比如，此例可以是“对于尊享e生产品，您的年龄(60岁)满足要求，地区(上海市)不满足要求，疾病(慢性高血压)需要进一步确认。”。

综上，可以看出，问答映射和图谱知识表示是相辅相成的，通过良好的设计可以使两者完美地合作，完成业务目标。两者合理的联动才能真正发挥KBQA的价值——可扩展性。对于新任务，制定合理的知识表示和问答映射逻辑，KBQA就可以提供支持。

图7为本发明实施例提供的一种保险行业知识图谱问答系统构建装置的结构框图，参照图7所示，该装置包括：

本体构建模块70，用于构建保险知识图谱的本体与知识表示；

图谱构建模块71，用于将与保险行业相关的多种原始数据基于预先构建的本体与知识表示，生成保险知识图谱数据，并存储至图谱数据库中；

问句问句理解模块72，用于获取用户问句，并对用户问句进行问句问句理解，其中，问句理解包括问句类型识别、问句意图识别、实体识别以及实体标准化；

问句映射模块73，用于基于查询模板对问句理解获得的信息进行问句映射，生成查询语句；

图谱查询模块74，用于使用查询语句在图谱数据库中进行查询，得到查询结果并返回。

在一个优选实施例中，本体构建模块70具体用于：

构建各个领域的分类体系以及知识表示，并定义保险产品实例与各个业务支撑实例之间的关系，以及各类实例的属性。

在一个优选实施例中，图谱构建模块71具体用于：

判断多种原始数据中是否存在来自不同数据源且属于同种类别的数据；

若存在，则判断数据是否符合融合场景；

若符合，则对数据进行融合处理，否则，不进行融合处理；

将多种原始数据中经过融合处理的数据以及无需融合处理的数据，基于本体与知识表示，生成数据结构为三元组结构的保险知识图谱数据。

在一个优选实施例中，问句映射模块73具体用于：

确定问句类型识别获得的问句类型；

在一个优选实施例中，问句类型包括以下之一：

知识型问句、场景型问句及其他类型问句；

问句意图的类型包括以下之一：

核保、续保、核赔、核药、其他；

实体类别包括以下之一：

产品、疾病、年龄、职业、地区、药品。

本实施例提供的保险行业知识图谱问答系统构建装置，与本发明实施例一所提供的保险行业知识图谱问答系统构建方法属于同一发明构思，可执行本发明实施例一所提供的保险行业知识图谱问答系统构建方法，具备执行保险行业知识图谱问答系统构建方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例提供的保险行业知识图谱问答系统构建方法，此处不再加以赘述。

此外，本发明另一实施例还提供了一种电子设备装置，包括：

一个或者多个处理器；

存储器；

所述存储在所述存储器中的程序，当被所述一个或者多个处理器执行时，所述程序使所述处理器执行如上述实施例所述的保险行业知识图谱问答系统构建方法。

此外，本发明另一实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被处理器执行时，使得所述处理器执行如上述实施例所述的保险行业知识图谱问答系统构建方法。

上述所有可选技术方案，可以采用任意结合形成本发明的可选实施例，在此不再一一赘述。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关联的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种保险行业知识图谱问答系统构建方法，其特征在于，所述方法包括：

S1：构建保险知识图谱的本体与知识表示；

2.根据权利要求1所述的方法，其特征在于，所述步骤S1进一步包括：

3.根据权利要求1或2所述的方法，其特征在于，所述步骤S2进一步包括：

4.根据权利要求1所述的方法，其特征在于，所述步骤S4进一步包括：

S4.1：确定问句类型识别获得的问句类型，若问句类型为知识问答型，则执行步骤S4.2，若问句类型为场景判断型，则执行步骤S4.3；

5.根据权利要求4所述的方法，其特征在于，

所述问句类型包括以下之一：

知识型问句、场景型问句及其他类型问句；

所述问句意图的类型包括以下之一：

核保、续保、核赔、核药、其他；

所述实体类别包括以下之一：

产品、疾病、年龄、职业、地区、药品。

6.一种保险行业知识图谱问答系统构建装置，其特征在于，所述装置包括：

本体构建模块，用于构建保险知识图谱的本体与知识表示；

7.根据权利要求6所述的装置，其特征在于，所述本体构建模块具体用于：

8.根据权利要求6或7所述的装置，其特征在于，所述图谱构建模块具体用于：

若存在，则判断所述数据是否符合融合场景；

9.根据权利要求6所述的装置，其特征在于，所述问句映射模块具体用于：

确定问句类型识别获得的问句类型；

10.根据权利要求9所述的装置，其特征在于，

所述问句类型包括以下之一：

知识型问句、场景型问句及其他类型问句；

所述问句意图的类型包括以下之一：

核保、续保、核赔、核药、其他；

所述实体类别包括以下之一：

产品、疾病、年龄、职业、地区、药品。