万字长文｜知识图谱之本体结构与语义解耦——知识建模看它就够了！ - 阿里技术
本文总结了我们过去参与的知识图谱项目中的一般问题和难点，沉淀为体系化的方法论，并针对不同复杂程度的知识建模问题，进行实操指南。
前言
过去两年多的时间，针对蚂蚁域内业务场景和知识体系多样、复杂，知识建模成本高导致图谱项目启动难的问题，我们提出了一种结构与语义解耦的知识建模及schema设计方法，并在商家图谱、事理图谱、保险图谱等多个项目中进行实践。相关简化schema设计及帮助对知识的属性语义化、标准化的能力已经集成到蜘蛛知识平台。本文总结了我们过去所工作，沉淀为体系化的方法论，并针对不同复杂程度的知识建模问题，进行实操指南。
说明
本指南在背景部分对知识建模的发展历程、相关问题、蚂蚁场景下的挑战进行书录说明，如果对这部分已经清楚或不感兴趣可以跳过。
在基础篇、进阶篇、高阶篇，针对不同业务场景的建模需求，由浅及深讲解知识建模的方法和案例，并涉及术语的解释。本文档所提出的建模方案，已经在蜘蛛平台做了对应的能力支持实现(或开发迭代中)。独立于蜘蛛平台，读者也可以按本文的方法论对自己的业务问题简化抽象，实施对领域知识的建模及对已有常识图谱的复用。
- 如果你对知识图片已有一定了解或实践，可跳过基础篇(基础篇的“属性语义标化”依然值得一读)。
- 如果你的图谱，涉及对业务类目体系、常识概念(如“行政区划”)的应用，请仔细阅读进阶篇。
- 如果你的图谱，涉及对带有时空信息的行为事件的表达，或建模场景下的业务规则、专家经验，需要对所定义“概念”的内涵和外延有计算机可处理可计算的逻辑语义解释，高阶篇中有你所需知道的一切。
- 由于高阶篇的内容有一定的阅读门槛，如果你的场景只需要描述相对静态的事实关联，不包含用户行为、新闻事件的建模，没有语义推理的需求，可以跳过高阶篇，参考基础篇和进阶篇就够用了。
背景
知识建模是解决将真实世界中的海量信息转化为符合计算机处理模式的结构化数据，其中包括对真实世界中事物的属性特征及其关系的共性的抽象，制定表示的规范，同时兼顾对常识或领域概念及概念层级体系的语义理解，即体现了对知识的认知过程。
相关工作
图1 知识建模方法回顾
表1 知识建模方法对比
| 方法 | 特点 |
|---|---|
| 关系型数据库 | 用实体及其属性（关系也体现为外键）对数据结构化，不包括语义的建模，容易存在大量的数据冗余，多跳跨表查复杂、效率低。 |
| 知识工程 | 本体表示：将知识表示为辑符号的形式，构建特定领域概念类别及其层级细分关系，并用 一阶谓词逻辑、生产式规则表示领域专家经验，支持知识的符合推理。 框架(frame)表示：强调将所描述的每类事物都抽象为出特定的slot-value的结构化表示(例如目前百科词条就是frame表示)。 弊端：人工构建成本太高，知识获取困难。 |
| 语义网 | 出发点是用文档中的数据关联+逻辑描述，让计算机能认识和理解世界万物。语义网发展过程中先后制定了基于描述逻辑的DAML、RDF、OWL、OWL2等语言，语义完备性的强调，成为逻辑学家的游戏，无法工业化落地。 |
| 知识图谱 | 以基本的SPO三元组，表示实体间的事实关系；但SPO对由多个要素（>2）共同决定的多元关系表示存在缺陷；图谱schema的设计是主观的，不同图谱的异构导致知识难以对齐融合。 |
| 事理图谱 | 将事件以及事件之间的关系抽取并抽象出来，构建描述事件之间演化规律和模式的事理逻辑知识库。事件有frame框架表示、verb+nound表示等流派。 |
| 常识概念图谱 | 围绕常识性概念建立的实体以及实体之间的关系，帮助自然语言文本的理解。涵盖“是什么”的概念Taxonomy体系结构，“什么样”的概念属性关系，“给什么”的概念承接关系。 |
| 知识超图 | 超图(Hypergraph)：就是每一个边可以包含两个以上的点所构成的图，解决多元知识的表示。 |
业务问题
表2 蚂蚁域内常见建模问题
| 建模问题 | 现有解决方案及不足 |
|---|---|
| 商家资产等实体-关系schema设计 |
| ●无论是ER建模、本体、rdf、owl，都只是语法定义，不解决“设计模式”本身的问题。 ●schema设计启动难，难以决策属性/关系的设计、实体类型的划分。 ●schema的设计是主观的，导致不同图谱间知识的异构性（数据结构不同），阻碍知识的复用。 |
| 常识、领域结构化语义理解
| ●不同业务有各自体现业务语义的类目体系，同时蚂蚁域内的场景也涉及对常识的理解 ●传统的本体建模，在同一个分类体系上，既要对schema的扩展建模，又要对语义上的细分类建模，数据结构定义和语义建模的耦合，导致工程实现及维护管理的复杂性，也增加了业务梳理和表示(认知)领域知识的困难。 |
| 跨图谱融合场景
| ●不同业务部门构建图谱时先专注于自身领域的知识建模，但随着业务的开展，需要引入其他领域的知识。 ●跨图谱融合，解决提高数据的复用性、提升数据治理能力，减少数据冗余重复及帮助发掘业务价值拓展。 ●需要对领域内有共有的实体，如：用户、商家、POI等，提供统一的schema规范，并对域内常识或公用类目，如：行政区划、mcc类目等，沉淀为通用语义资产。 |
| 保险、黑产等业务逻辑表达需求
| ●保险产品运营、保险健告、黑产洞察等场景有着丰富的业务逻辑、业务规则沉淀 ●需要支持业务规则、专家经验的形式化表达及推理能力 ●一阶谓词、dsl等，对用户有门槛，业务规则较多时，需要有更简洁、快速的对规则建模的方法 |
| 用户行为建模场景
| 多元关系建模问题 ●用户行为、金融事件、业务状态流，都可以抽象为多元时空行为事件建模 ●spo三元组表达多元关系是有损的 ●超图结构的理解，对于非算法用户有学习门槛，难以直接可视化 ●行为时间事件之间，本身存在着时序、因果、共现的等关系 |
| 事理图谱及事理关系建模
| 已有的研究或工作，都只解决了事件图谱、事理（概念）图谱或事理常识中特定一类的表示，蚂蚁场景中需要对从实例到概念，从事实到常识的整体架构 ●每种事件的实例需要frame表示 ●事件概念体系需要本体表示 ●事件实例之间的事实关系需要spo表示 ●事件概念之间的顺承、因果等需要逻辑表达 |
方案概述
本体是偏哲学的学术概念，指“特定领域之中某套概念及其相互之间关系的形式化表达（formal representation）”。在知识工程、语义网时代，都用本体建模指代知识建模，利用rdf、owl等规范的语言，核心定义严格完备的逻辑。但这套方法不适合大数据时代知识的多样性、跨领域复杂性，无法满足数据的便捷迭代生产。
我们认为，“本体”在知识图谱建模阶段，存在误用。换言之，知识图谱建模，不需要“本体”，而应该关注数据结构上的“元数据”的定义，以及知识语义关联的标签概念体系及概念网络。
基于MOF四层元模型框架，我们提出知识认知建模方法论，串联了知识建模、知识生产、知识管理应用的全生命周期流程。其中，元元概念指所定义的建模规范，如本文提出的MOF建模标准中的实体、概念、关系等建模要素就是元元概念，“元概念”对应定义实体类型的schema，是对拥有同样数据结构的知识的结构化定义，如“商家schema”、“事件schema”；“概念”是对实体的语义细分，如“蚂蚁商家”、“外卖商家”，“白酒板块事件”、“蚂蚁高管变化事件”；实例对应于现实中一个具体的事实，一般是ID化的，如id为2088xxxx的A空间肯德基商户。
图2 MOF知识建模方法
- 提供统一的数据结构抽象及本体语义建模方法论，规范图谱“设计模式”，降低知识认知的主观偏差解决schema设计难、启动成本高问题；
- 提出概念语义建模框架，将知识的结构化表示与语义常识建模解耦，并用等价谓词表达式支持概念的逻辑表示和推理，降低认知复杂度和工程实现难度；
- 定义核心实体schema及沉淀通用语义概念体系，帮助解决多元异构知识的跨域融合；
- 定义多元关系、逻辑规则、事理关联的建模方法，满足复杂业务场景知识表达的需求。
基础篇·实体关系设计
解决问题
解决数据的结构化表示，包括实体各属性字段的规范定义，及设计实体间的关系，以便将数据最终构建为有别于传统数据表的图结构形式，便于基于路径的多跳关系查找。
适用场景
- 业务场景关注于静态的，体现物理世界或业务流中客观存在的“事实知识”;
- 已有结构化数据为主（实体表、关系表、用户行为数据等）的数据资产;
- 已有数据资产及业务场景，能够抽象出传统ER关系图的数据建模，可以直接套用实体-关系-属性的建模范式；
- 业务对实体的类型存在划分，如对用户的细分或对商户、门店的细分；这种细分类是有限的（一般只有两三种），每种细分有特定的属性（如线下门店才有poi）。
- 业务对实体特定属性有枚举描述，如“商户评级 = [S, A，B，C]”，业务应用只需要使用确定值将数据查出来，但不需要基于属性传播。
术语定义
Schema
Schema是知识的“元数据”表达方式，定义了知识的概念的属性，关系，属性及约束。主要实现了实体的结构化和实体间的关系的定义。
实体
物理世界或数字世界存在的事物是一个实体，实体对应于数据表中的一行记录。
实体类型，即实体的“schema”。它是对具有共同数据结构（特征）的一类数据实例的“元数据”模式定义。因此每一个实体类型，都有自身特定的schema。同时，实体类型存在上下位关系，通过继承，下位类拥有上位类已定义的属性和关系及其约束。在知识图谱平台中，实体类型用于对具有共同数据结构的个体进行分组管理。可以将实体类型理解为，对知识结构化表示的语法规范。如下表所示，是对自然人的schema定义。
| 自然人模型（Person）示意 | ||||
|---|---|---|---|---|
| 属性英文名 | 属性中文名 | 属性类型 | 属性值 | 是否必填 |
| id | id | String | 12345xxx | 是 |
| name | 姓名 | String | 张三 | 是 |
| certId | 证件号 | String | 330121xxx | 否 |
| certType | 证件类型 | 枚举类型 | 身份证 | 否 |
| birthday | 出生日期 | 时间类型 | 20230215 | 否 |
| gender | 性别 | String | 男 | 否 |
| occupation | 职业 | String | 白领 | 否 |
| …… | …… | …… | …… | …… |
关系
描述实体-实体间的关联。在基础的实体关系设计时，只考虑满足SPO(Subject-predicate-Object)表示的二元关系，既两个实体间确定的关系。如定义一个关系：公司-法人->自然人，“法人”是关系谓词，关系主体是“公司”这种实体类型，客体是“自然人”；注意，关系是有向的，则一个“公司”的实例拥有一个出边到确定的“自然人”，且该自然人是这个公司的法人。
自然人相关关系定义
| Subject | Predicate | Object | 是否唯一 |
|---|---|---|---|
| Company | 法人 | Person | 是 |
| Person | 好友关系 | Person | 否 |
| Person | 夫妻关系 | Person | 是 |
| Person | 居住地 | POI | 否 |
| …… | …… | …… | …… |
属性语义标化
属性 vs 关系
在实体-关系建模时，对于实体的特性字段，到底应该建模为属性，还是应该将特征key构建为关系，特征值(value) 建模为实体，设计者经常陷入两难的抉择。例如：
在对商户建模的典型场景，一般商户会有关联的PID，在关系型数据表（odps）中，PID是一个id字段，pid本身也没有特别的属性，为了挖掘同pid的商户、发现用户对商户的消费行为，pid应该建模为实体，但Pid没有任何属性，这样做合适吗？
在例如对于商户的发货地址、所在省市区等特征，在数据表中一般是个string。但为了同地址、同地区的发现，甚至特定业务场景本来就有地址实体库。那么就需要对地址属性建模为关系了。但这带来两个问题：1.商户的发货地址、用户的收货地址可能存在变动，特别是用户收货地址，在图谱中维护时，需要在新增地址时，把历史地址边删除；2. 对于所属省、所属城市、所属区等，若都建为实体拉边，将造成“热点”(即某个点有巨量的边)，为路径推理、采样带来困难。
- 属性：易维护(值覆盖)、存储量小、不传播，难以发现关联（属性值相同的实体并没有显式的关联）
- 关系：有维护成本（修改需要删边再拉边）、储存量大、可传播(可加强图结构，发现节点间的共边关系)、同关系类型的边过多(例如，明星的社交关系，作为关注者只有几百条边，作为被关注者有千万级的边)，对图学习的关系采样带来干扰(对图谱中的“热点”，若采样策略为不限定边类型但对邻边限定数量随机采样时，可能采到的都是数量大但重要性不大的点)
属性标化
为解决上述的属性/关系难以抉择，及提高知识管理的效率及降低存储压力，我们提出一种基于属性语义标化的建模方法，并在蜘蛛产品功能上已经交付可用。
属性语义标化能力体现为：
- 用户在实体建模时，不必纠结实体特征需要定义为属性or关系，统统建模为属性；
- 在属性类型选择时，除了int、float、text三种基本类型外，提供具有语义传播能力的语义类型(如内置的概念类型、内置的标准属性类型、用户自定义的实体类型或概念类型等)
- 在实例数据生产时，用户当作属性维护（如属性一样做知识导入的字段映射，属性值修改直接覆盖
- 根据所选择的属性语义标化类型，根据所填充的属性值语义（以文本匹配、id匹配的方式）系统自动构建“虚拟边”；
- 系统自动创建及维护的虚拟边，在查询效率、图算法邻边采样时，与用关系建模、关系导入生产的物理边效果一致；
- 当语义属性为多值时（如一个user拥有多个手机号码），用英文逗号分割。注意：对于实体的某特征，值是有限个（一般<10，如关联邮箱、所属业务类目、银行账户等），可以用属性语义标化建模来简化知识的管理维护。当特征值数量极大时（如：用户-消费->小程序id）,依然建议使用关系建模。
表3 属性语义标准化类型
| 属性类型 | 类型细分 | 属性定义 | 用法及示例 |
|---|---|---|---|
| 内置类型 概念类型 | 通识概念 | 一个描述常识分类体系的树状知识库，现覆盖17个大类的2W+常识概念。 | 当实体的类型需要细粒度的分类，且该实体的细分类可以用常识知识体系描述时，定义描述实体细分类的属性（如：对于BaikeEntry定义了子类型 subType），并将属性类型选择为“内置类型- 概念类型-CKG.AntTermType”。 知识生产时，对实体实例的subtype赋值为常识知识树上任意的概念的文本名称，则平台自动将该属性转为一个 BaikeEntry-subtypestd->常识概念 的边。 则细粒度一样的 BaikeEntry在图结构上能够拥有共同的概念节点邻居（如姚明、易建联都是“篮球运动员”） |
|
| 行业类目 | ●MCC类目 ●POI类目 ●门店类目等 | ●蜘蛛平台上集成维护了蚂蚁域内常用的MCC2.0、高德POI类目和门店类目 ●以往对相关商户、门店、POI/AOI实体建模时，业务往往用多个字段维护各级类目的code和名称 ●现在对实体-特定类目的信息维护，只需定义一个属性（如定义一个“所属类目”属性），并将属性类型选择为“内置类型-概念类型-具体的某个类型体系”。 ●知识实例生产时，将属性值填充为类目的code或名称(一般是叶子节点的类目)，则平台能力可以追溯类目的上级路径，并自动拉边，关联具有同类目的实体实例。 ●同时，平台提供存量迁移的能力，对于历史遗留的相关属性，也能够迁移为语义标化属性，如图为对蚂蚁POI库进行的迁移维护。
|
| 内置类型 标准语义类型 （编码id相关） | 虚拟地址 | ●邮箱 ●网址等 ●手机号码 ●Mac地址 ●国内电话号码 ●…… | 这类属性标化类型是指，用户选择特定的“内置类型-标准语义类型-特定可传播的标准id类型”，则实例数据生产时，属性字段值填写对应的id、url、电话号码等(多值用英文逗号分隔)，平台提供： ●正则检测：平台会对邮箱、手机号码、国内号码、银行账户、2088账户等，对所填编码的逻辑格式进行正则检测 ●ID链指：平台会对每个语义类型下，每个存在的id构建一个虚拟节点，并按照实例知识中实体-id的属性值，构建实体与该id所属虚拟节点的边关系；这项机制能够帮助用户发现及可视化同id、同电话号码、同邮箱的实体。
|
| ID属性 | ●身份证号码 ●2088账号 ●支付宝PID ●银行账户 ●蚂蚁POI ●…… |
| 内置类型 标准语义类型 （时间相关） | 时间戳 | 1665476056 | 时间标准化及时间的计算比较 |
| 时间区间 | [起始时间,结束时间] | 时间戳是否落入时间区间的检测，蜘蛛能力待开发 |
| 时间间隔 | ●一天 ●一年 ●24小时等 | 判断两个时间戳是否满足时间间隔，蜘蛛能力待开发 |
| 内置类型 标准语义类型 （空间类型） | 行政区划 | 国家-省-市-区四级（目前仅支持中国行政区） | ●蜘蛛平台集成了四级标准行政区划类目 ●以往业务为了表示结构化的标准多级地址，一般会构建国家编码/国家、省编码/省、市编码/市、区编码/区，共8个属性字段，存在着属性的冗余储存。且plain text的文本属性，不利于快速的发掘同地区的实体。 ●利用语义标化，将表达实体行政区域特性的属性，类型选择为“内置类型-概念类型-行政区划”，数据生产时，将属性值填充为能够识别到的最细粒度的行政区划单位（平台提供兜底默认算子，帮助地址的结构化理解及标准化） ●通过语义标化链指能力，对于填充的行政区划属性值，其上级类目是可追溯的（如所在区县为“西湖区”时，西湖区-位于->杭州市-位于->浙江省-位于->中国，是已维护在“行政区划”类目树上的） ●平台能够自动拉边，维护实体(如poi、aoi、门店等)到特定省、市、区县的关系，并实现不同粒度下所属行政区划的查询。
|
| 经纬度坐标点 (Position) | (经度,纬度) | 同POI计算发现（球面距离小于epsilon），蜘蛛能力待开发 |
| 经纬度范围 | (Position1，Position2）地理区块四边形（左上-右下坐标） | 判断一position是否在该范围内，蜘蛛能力待开发 |
| 自定义属性类型 实体/概念 | | | 平台内置的概念类目体系、可传播的语义属性类型，无法完全满足特定业务的建模需要；因此，用户可以将属性类型赋值为“内置类型-自定义属性类型”，则在高级配置页面，选择将属性标准化为自定义的一个实体类型(默认用id链指)或概念类型(默认用概念名称链指)。 如果所示，对于“公司事件”实体，拥有两个语义标准化属性的应用——1.公司id，选择为“工商机构”实体，则能够利用平台id链指能力自动拉边到确定的“工商机构”实例；2.事件类型标签，定义为“概念事件”(业务自定义的一套为金融事件分类体系，概念建模详见进阶篇)，则能够利用平台的概念标化链指能力自动拉边挂载到“概念事件”树。
|
| 其他待开发 的属性 | 数量类型 | 数额 | ●度量/指标类型+数值表示 ●对度量/指标类型标准化 ●同一数量类型的比较 ●区间数值合法性检验 |
| 指标 |
| 区间数值属性 | ●年龄 ●年份 |
建模步骤及案例
实体关系设计，是为具有同样结构化特性(即有同样的特征要素)的实体定义的实体类型的schema，并建立实体类型间的关系。实体schema包含实体类型的命名、属性定义、属性类型及属性值的约束，关系schema约束关系主体和关系客体的实体类型。我们推荐在启动一个新的图谱项目时，按照以下步骤进行实体-关系建模：
1. CoreKG schema复用
schema的设计具有主观性，为了消除这种主观偏差，特别是降低跨图谱知识融合的复杂性，我们从过去的业务图谱设计经验中，总结了蚂蚁场景下常见的实体类型schema，并商家到corekg核心图谱；当业务涉及到这些实体数据时，可以直接对实体schema及数据引用/复用，减少重复建设，快速启动新的图谱项目。
如果为了业务安全/数据隔离等的考虑，业务需要自定义及构建自己的实例数据，我们也推荐对于corekg已有的实体类型，用户可以对其schema设计，特别是属性的定义和命名参考借鉴。
图3 corekg核心实体定义
2. 实体关系设计
参考corekg中已有实体的schema，针对业务问题及数据，构建业务所需实体定义。
比如前文所述对蚂蚁用户定义的自然人模型，包括"姓名(name)"、"年龄(age)"、"身份证号(certNo)"、"家庭住址(homeAddr)"等基础属性，此外，定义"Person-好友关系-Person"、"Person-夫妻关系-Person"等关系。
| 自然人模型（Person）示意 | ||||
|---|---|---|---|---|
| 属性英文名 | 属性中文名 | 属性类型 | 属性值 | 是否必填 |
| id | id | String | 101xxx | 是 |
| name | 姓名 | String | 张三 | 是 |
| certId | 证件号 | String | 330121xxx | 否 |
| certType | 证件类型 | 枚举类型 | 身份证 | 否 |
| birthday | 出生日期 | 时间类型 | 20230215 | 否 |
| gender | 性别 | String | 男 | 否 |
| occupation | 职业 | String | 白领 | 否 |
| …… | …… | …… | …… | …… |
不同业务因领域模型不同会有自己的业务知识，比如同样一个用户，由于归属的业务不同，在蚂蚁会存在"支付宝用户(AlipayUser)"、"财富用户(FortuneUser)"、"网商用户(MyBankUser)"、"保险用户(BaoxianUser)"等用户模型，虽然这些用户模型背后指向的是同一个自然人模型，但在不同业务域有新增的属性字段，则利用schema的继承复用已定义的属性/关系约束，并在此基础上扩展新的特性。
| 支付宝用户模型（AlipayUser）示意 | ||||
|---|---|---|---|---|
| 属性英文名 | 属性中文名 | 属性类型 | 属性值 | 是否必填 |
| id | AlipayId | 编码类型 | 2088 | 是 |
| name | 姓名 | String | 张三 | 否 |
| memLevel | 会员等级 | 枚举类型 | 黄金会员 | 否 |
| shoppingPref | 购物偏好 | 物品概念 | 小吃 | 否 |
| …… | …… | …… | …… | …… |
用户统一模型示意
对于不同业务实体归属同一主体的情况，一是可以在Schema层归类到统一实体模型上（深度继承），二是可以在数据层在相同实例之间增加isA或sameAs谓词关系（实体融合），达到主体分类一致的目的。
3. 语义标准化
参考“属性语义标化”章节的内容，优化属性/关系的定义，将可以标化的属性选择为标准属性类型，对于适用id链指/概念链指的关系，转化为语义属性。例如，由于夫妻关系是唯一的，则可以将夫妻关系建模为语义属性。而朋友关系是多对多的，一个人可能有上百个朋友，因此依然用关系建模朋友关系。
进阶篇·概念语义建模
解决问题
在知识图谱中，除了知识的元数据定义（即schema），通用常识和领域知识的语义关系、常识/业务类目的分类体系，体现了对语义的认知。为了将语义建模与知识的结构化表示解耦，我们提出的方案是用“概念语义建模”来对常识概念及常识关系建模，对特定领域知识的认知体系和经验规则建模。
如图4所示，在概念建模中，构建对常识/特定实体类型的分类体系。Root节点，代表“常识知识树”的根结点，在这棵概念树上，我们预定义了17种实体的分类体系，如“角色”、“物体与物品”、“组织机构”、“品牌”、“事件”都是一个“元概念”（即一个分类体系的根结点），每个元概念作为起点的子树，定义了对该类实体的语义细分，目前蚂蚁知识树上已经有超过2W+的节点。此外，在常识概念图谱中，我们还集成了高德poi类目、意图图谱、mcc2.0行业类目、行政区划概念树、hownet义原语义网络，作为跨领域可插拔的常识语义认知系统，帮助各个业务图谱深度实体类型理解及属性语义标准化。
例如对于图中所示的描述服务内容结构化理解的领域图谱，在领域图谱中，小米10-手机类型->“智能机”，“智能机”是结构化抽取到的spo mention，通过概念链指标准化到知识树上的概念“智能手机”，则通过知识树的可追溯链路，能够知道小米10同时也属于手机、数码产品、电子电器产品。同时，为了保障语义的内聚性，尽量为用户提供简洁的描述并加强信息间的关联，“概念”也提供对关系谓词（即属性名称、关系名称）标准化的能力。如“所属公司”这个谓词，其实约束了尾节点的实体是一个公司。
图4 概念语义建模
适用场景
- 除了将图谱当作一个能具备增删改查功能的数据库，还希望对业务逻辑、领域经验进行管理；对文本属性，不只是作为“符号”，还希望能理解文本背后的语义，挖掘知识间的隐含关联；
- 业务上对实体定义了非常详细的分类类目，一般这种类目是以树状形式组织的；
- 实体的属性字段的值是行政区划、职业、行业类型等常识术语，并希望这些属性在图上是“可传播”的（即通过这个值，可能关联扩散到其它拥有同样值的属性节点），这些常识术语本身有层级蕴含关系（如：位置在西湖区，则一定也位于杭州市）
- 业务定义的类目，不仅仅是一个用来区分实例的标签值，还存在背后的定义逻辑（如：活跃人群 = 过去30天支付宝访问超过1次的user）
- 希望表达领域常识(程序员有夜间出行偏好)并应用，而不是记录具体实例的事实(行为事实：小蚂在x年x月x日晚上21:00在A空间打车；偏好事实：小蚂的“偏好属性”字段被打上了“夜间出行偏好”)。
术语定义
概念
把所感知的事物的共同本质特点抽象出来，加以概括，是自我认知意识的一种表达，形成概念式思维惯性。概念的意思：思维的基本形式之一，反映客观事物的一般的、本质的特征。
概念建模，期望通过对实体分类体系和基于common sense的通用语义元素的定义，并以树状层级体系进行组织，自顶向下的体现实体语义的细分。其中我们将满足以下任意一个特性的短语定义为一个概念（concept）。
图5 概念是什么
元概念
meta-concept，即概念的概念，在蜘蛛上是指用来组织一个特定概念体系的规范。元概念定义，就是根据对特定领域/业务的认知或常识，定义该类型概念的结构，约定概念的属性、层级结构及表达层级结构的语义谓词。
当我们需要在语义上对实体类型细分时，实体类型的schema可以对应一个元概念，以表现对该类型实体类型的分类体系。例如图四中的“角色”、“物体与物品”、“组织机构”、“品牌”、“事件”都是“元概念”，定义了对特定实体的语义细分体系。
概念 VS. 实体
表4 概念和实体的区别
| 概念 | 实体 | |
|---|---|---|
| 什么是概念 | ●概念是对具有同样特征的实例的抽象，是语义上/认知上能够被“归类”为同一类型的实例的集合。 ●概念是符号化的，但领域内的人对它这个符号的语义是有共识的。 ●概念带有领域/业务/常识的主观或经验，是人为定义的，概念的内涵/语义是相对恒定的。 ●概念的符号体现了自身的语义，概念之间构建的语义关系边 (白酒板块事件 -涉事产品-> 白酒，白酒-原料->粮食，猪瘟疫情事件-影响->猪肉价格上涨，形成了描述领域常识的语义网络。以上举例的三元组中的S和O都不是具体的、特定的实例，而是对同一类实体，及同类实体所具备共有特性的概括) ○可以先简单粗暴的认为，“概念”是没有“属性”的（除了编码、别名、描述） ○事件抽取出的mention，无法与实体库对齐的文本类型要素（非时间、非数值），都可以认为是概念 | ●实体类型，是对拥有同样数据结构/论元要素的数据的定义 ●实体实例，是id化的，唯一存在的实例。 ●实体是客观的存在，实体的特征是动态变化的。 ●实体拥有特异的属性/关系定义。例如：某个事件的发生事件、地点、主体、客体；某部手机的型号、屏幕、尺寸、内存等参数。 |
| 什么应该被定义为概念 | ●类目概念：对具有同样特征的一类实体的语义抽象，可以来自业务类目、领域的taxonomy，比如POI类目、MCC类目等。 ●常识概念：在特定领域(元概念)下，人们有共识的无歧义短语，比如杭州市、手机、中秋节。 ●原子概念：一般存在于L0-L2级的概念，概念名是不可拆分的表达完整语义的核心词，一般直接来源于领域常识术语。如：产业链事件、芯片、有色金属。业务类目、领域的分类体系(职业分类、企业分类、品类、产业分类、NER_Label、实体类型、属性名称、边关系类型、人群标签、星座、血型、人种、民族、学历、奖项、各种title，都是概念。———————————————————————— ●复合概念：在一个核心词概念上增加语义修饰限定（该限定可以是概念, 也可能代表特定实例），例如：“白酒”+“产品价格上涨” = 白酒产品价格上涨 “杭州” + “互联网”+“上市公司” = 杭州互联网上市公司 "腰封偏好" +"高日活"+ "支付宝账户" = 高日活的腰封偏好支付宝账户 “阿里巴巴”+“公司” = 阿里系公司 “华为”+“手机” = “华为手机” 复合概念 可以拆解为等价的谓词逻辑表达式（见后文） | ●品牌不是“概念”，它是特定厂商定义的一个IP，本身不具备认知的层级体系。如果品牌有类目体系，则品牌类型是概念。 ●物理世界真实存在的一个个体，蚂蚁内部特定的一个账户、一个商家、一个供给内容，是实例。 |
| 概念能够表达那些语义 | 1.对实体进行细分类，完成schema无法体现的更详细的语义 ●通过逻辑表达式定义的规则，自动完成“复合概念”的生成及帮助推理属于该集合的实例 2.提供属性的标准化及语义化，则属性值不再只是一个plain text，而是依靠概念语义网络，可关联可追溯的子图。 ●对多跳上下游产业链关系、上下位产品品类的召回进行处理 | ●实体类型的schema是在知识管理的角度，来选则粗粒度的“类型”。 |
建模步骤及案例
我们以事理图谱的概念语义建模为例，介绍用户自定义概念体系并使用概念为实体做细分类的方法。
事件体系语义建
在事理图谱场景下，需要金融事件相关的各种事件类型建模，包括宏观的行业时间、国家政策事件，也有微观的局部地区的牲畜疫情事件、个股涨跌事件、公司事件；宏观事件可能影响微观事件，微观事件的发生可能引发另一个微观事件。
金融场景下包含的事件类型十分庞大，每种事件在业务上所关注的事件要素是不同的。同时，业务会对同一大类的事件继续语义细分以便套用业务逻辑去做风险预警、评级，例如图6所示，公司事件下，会细分出工商信息变更事件、高管变动事件等，高管变动事件下又有实控人变更、股东跑路、实控人涉诉等。当事件类型语义细化到很细节的粒度时，不再涉及事件要素的新增（即元数据结构上没有变化）。
图6 事件概念体系示意（局部）
因此，如图7所示，在知识建模时，将事件的结构化表示所需要的schema定义，和业务上的事件认知分类体系解耦为两个独立的树状体系，再使用标准谓词、逻辑规则等构建结构与语义的对应关系。具体步骤如下：
图7 事件概念体系构建及管理
1.定义实体类型schema。
对于事件的结构化表示，先构建一个定义所有事件共有事件要素的schema：Event。
2.建立实体类型对应的元概念。
实体类型的schema定义，只是对结构化表示的约束。为了体现对实体的语义的认知，用概念建模来定义实体的细分类体系。对于事件的分类体系，定义EventConcept作为元概念。并在这个元概念下，类似决策树一样，根据特定场景/业务最重要、最有区分度的特征为度，按照树状层级，细分出细粒度层级的概念。
在元概念上，可以定义概念的属性，如概念别名等。元概念上还需要定义该概念体系的谓词，用于解释这颗概念树上下层级概念间的语义关系。一般默认为“isA”，体现上下位关系。但对于行政区划等类目，需要重写为locatedAt等特定谓词，以更明确、恰当的表面概念树的组织形式。
3.为实体类型schema设置专属分类体系。
belongTo是蜘蛛平台的保留谓词，用于为一个实体类型schema设置专属的概念分类体系。例如，建立Event-belongTo->EventConcept的关系，则定义了Event(及其子类型)的实例，由EventConcept为_Root的概念体系做细分类。
4.schema的结构细化
由于不同事件可能需要抽取和结构化的特有的事件要素，则通过schema的继承，来定义一个子类的事件schema及增加要素定义。如companyEvent增加了“涉事公司”，LivestockEpidemicEvent增加了涉事牲畜、牲畜死亡规模、疾病类型等要素。对于schema上定义的属性，能够进行标准化或概念化的事件要素，属性类型选择为语义类型（需要提前定义概念体系)。
本方案所体现的建模方式是强schema约束（为了便于知识的规范管理）及语义标准化的。当细粒度的分类不涉及事件要素的新增时，则在对应概念体系上增加概念事件来完成对语义的细化。如在图7的概念树上，对牲畜疫情事件，继续细化为猪疫情事件、禽流感疫情事件等。
5.实例生产
实例生产有两种模式：1.非结构化数据：基于schema约束的信息抽取，并将抽取到的信息标准化(依赖实体链指、概念链指)后，对schema定义的实体要素（属性、关系）进行填充，完成实例知识的结构化；2.结构化数据：这类数据一般已经是在odps表中，自身是有schema的，则对odps表和实体类型schema的知识结构映射，完成数据实例化及入图谱。
如图8所示，描述了受schema结构约束和最终语义标准化的事件实例的生产过程推演
6.语义网络构建
每个概念体系本身是树状结构，但概念之间还可能存在丰富的常识语义关联，概念建模也包含着对常识/领域语义网络的构建。如图7中，在事件概念树上，选择将“猪口蹄疫事件”的上级概念设置为“猪疫情事情”；同时“猪口蹄疫事件”也是一种“口蹄疫事件”，则定义事件概念间的subtype语义关系（与实体关系建模类似的方式），来构建细粒度语义概念与其关联的其他概念间的关系。
图8中，白酒-原料->小麦，白酒-上游产业->粮食，也体现了概念间的常识语义关系建模。
事件生产链路
1.使用一个统一的模型/框架进行所有类型事件的抽取
2.抽取完成，相关事件要素及所属的粗粒度事件类型（schema类型）变成已知
3.拿到schema后，完成抽取的槽位跟schema定义的论元的映射，则该槽位值是实体（及其EntityType）还是概念（及其元概念）是已知的
4.根据schema映射，进行相关要素的实体链指、挂念挂载
5.完成要素的标化及链指后，用规则谓词推理其belongto的概念事件类型
6.最终完成子图构建（图中围绕实例事件e1、e2及其关联实体、概念组成的子图）
图8 强schema、强语义约束的事件实例生产
通用常识语义建模
基于对蚂蚁内部常见主体及其相关类目、属性字段的分析，并参考百科词条分类体系、Hownet、termtree体系，我们定义了覆盖17个“元概念”类型的常识知识树的主干框架。
L0-元概念（概念类型）
对应为实体类型。例子：品牌、术语、事件、组织机构。即一个特定的schema实体类型，对应拥有一个概念类目体系，则L0为该体系的root节点。
L1-概念分型的模式
决定了概念类目细分的方式。这里就像是决策树一样，先选择最有区分度、子概念类型不重合的方向细分。在L1定义的概念，是概念类型在不同纬度、行业、领域、应用场景的类目树的根节点。
L2-类目细分
L2-Ln，为概念类型在确定子领域/场景下的细分。
在蚂蚁常识知识图谱，我们集成了常识知识树、行政区划类目树、MCC2.0、高德POI、意图知识树等蚂蚁域内通用的常识认知体系和领域分类体系，来帮助跨业务的概念类目集成和内容理解。
图9 常识概念建模及应用（清晰大图可后台回复“图9”获取）
保险语义网络建模
保险产品图谱，是为了将保险业务中对保险产品的业务分类类目、领域标准分类、保险产品的各个重要特性建模，并将对每个业务自定义的产品标签概念（如“心血管保障好”）背后关联的产品特性、产品分类的逻辑固化到图谱中，进而使用图谱的路径推理能力帮助具体保险产品实例所属类型的判断。
如图10中，显示了对保险产品的schema定义，业务对“产品渠道”、“保障风险项”、“人群特征”、“产品分类”、“特色保障”等属性都做了语义标准化，即这些属性的取值都受到某个元概念体系的约束，而这些元概念体系是业务根据自身领域的各个类目树预先定义的。
图11中，在模式层定义了保险产品schema专属的分类体系——“产品类型”元概念；在概念层，构建了各个业务概念类目体系及这些概念间的语义关联。最终在实例层，演绎了如何准对一个具体保险产品的语义字段，套用概念语义网络及逻辑规则，实现对实例产品类型的推理。
图10 保险产品语义网络构建及应用
图11 保险产品语义网络构建及应用
意图语义网络建模
意图图谱的核心本体主要共包含四类节点（意图,功能词,产品词,义原）和三类关系（isA,Consist,Has），如图所示。具体来说，“意图”描述了用户需求背后的动机，主要由一个功能动词（动词）和一个产品实体（名词）组成动宾结构，例如“打网约车”、“买咖啡”和“维修家电” 等。此外，“功能动词”和“产品实体”可以用更细粒度的Hownet义原表示，拆分为最基本的语义单位，如“movie ticket|电影票 = {coupon|票证, look|看, shows|表演物}”。
构建意图图谱，主要有两个作用：1.功能词、产品词、义原实体可以丰富意图的语义信息；2.拥有相同功能词/产品词/义原的意图之间建立起新的关联关系。
图12 意图概念图谱构建及应用
高阶篇·多元关系架构
术语定义
多元知识
根据论元个数把关系分为：一元关系、二元关系和多元关系
- 一元关系：表示实体/概念的性质、属性等，有翅膀(鸟)
- 二元关系：表示两个实体之间的关系。例如：中国-首都->北京
- 多元关系：多个论元共同决定的事实
传统的知识图谱建模，主要解决静态事实、常识的表示，以三元组表示两个实体间的二元关系为主。但现实中的事件、规则、场景知识，是多元关系。即一个事实的成立，是由多个元素共同决定的（如用户交易行为，是对用户在确定时间、地点下对产品的交易行为的描述）
超图
超图(hypergraph)是一种更加抽象的图，与传统图的区别主要在于超边可以同时包含多个(>2)结点。超图通过引入超边关系，能够完整表达各种复杂的关系类型。
事件
事件是加入时间、空间，区分行为主体、客体的实体类型，以事理图谱和用户行为事件为典型应用场景，是对动态行为的建模，需要反应在不同时间点、时间区间上事物的状态。事件类型对实体类型补充了“随时空动态变化”的信息和“事物发展的规则”（因果、顺承等关系），是一种多元知识。可以回答诸如“怎么了”，“接下来会怎么样？”，“为什么”，“怎么做”的一系列问题；例如表达“用户在工作日点外卖，在周末用叮咚买菜”——“那么可以在工作日推荐外卖品牌，在周末推荐厨具品牌”。
概念的内涵与外延
概念的内涵就是指反映在概念中的对象的本质属性或特有属性。概念的外延是指具有概念所反映的本质属性或特有属性的对象，即概念的适用范围。
在进阶篇的概念建模，我们主要描述了如何基于领域常识或业务知识，构建树状的概念类目，以便于概念的复用、加强实体间语义关联。同时我们应该注意到，如果没有定义概念的内涵与外延，那么“概念”只是一个人工定义的符号，无法起到语义上的可解释、推理的能力。对于概念的等价语义表达式，在owl、rdf等框架中，一般使用一阶逻辑表达式实现。同样，我们也在蜘蛛平台上实现了对“分类概念的等价逻辑表达式”的实现。概念的等价逻辑表达式，体现为当实例知识的多个特征要素满足一定值约束时，该实例可以被推断属于某个概念。概念的等价语义表达式的定义，也属于一种多元关系。
解决问题
如图13，是一个在支付宝账单中典型的用户出行行为事件。每个出行行为，体现为特定用户在特定的出发时间从出发地点起始并在特定到达时间抵达特定地点的行为事件。因此每一个行为事件记录，都是一个多元关系。在数据表中的行为表达是完整无歧义的。但如何将它图结构化呢？
如前文提到，超图是解决多元关系表示的图结构，但显然，超图不是一种直观的对数据结构化和可视化的方法。而直接将超图表示转换为行为事件要素间的三元组关联，可能是有损的转换，例如小蚂并没有从灵隐寺出发并到达浙江大学的行为。但传统的图谱三元组表示却可能导致这样的歧义。
因此我们提出兼容与超图结构互相无损互转㩐的时空行为事件表示方法，主要体现为将时空多元关系（即事件或行为）本身抽象为一个事件节点，并定义事件节点与其各事件要素间的关联。则事件节点本身即为超边的具像化，能够的在spo表示与超图表示间进行结构化知识的无损转换。
同时，对于规则的表示，体现概念语义内涵和外延的逻辑表示，都有提供了相应的解决方案。在本篇中，我们将介绍如何综合使用实体关系建模、概念语义建模及多元关系建模，来对一个领域内的知识做整体的认知和架构。
图13 多元关系建模难点
适用场景
-
多元时空事件：对用户行为、金融事件、保险理赔、业务流程等，受时间和空间(具体的地点、poi、业务流程工段位等)约束，由多个（>2）要素共同确定的事实，提供简洁而统一建模范式，在蜘蛛平台，对该类知识的储存管理、结构化抽取、查询、可视化、包含时空信息的图学习等进行了支持和优化。
-
概念的语义定义：目前对事件/实体的分类仍然较黑盒，往往业务类目体系是领域专家/运营自定义的类目体系，导致只有定义者/生产者自己才能理解标签类目的内涵，专家经验没有存在图谱中，当要跨域复用时消费者需线下咨询生产者。因而定义概念的等价逻辑规则，结合概念层类目体系+概念的语义规则定义，帮助具体业务场景下的知识决策管理。
-
多视角的知识建模架构：如背景章节所述，已有的研究或工作，都只解决了事件图谱、事理（概念）图谱或事理常识中特定一类的表示，它们要么专注于对单个实例事件、实例知识及其关联的事实关系的刻画；要么在相对抽象的层次，描述基于常识的事理关系。蚂蚁场景中需要对从实例到概念，从事实到常识的整体架构。本章介绍的时空多元知识建模，也从事件实例表示、事件概念表示，事件实例所关联客观事实关系及事件实例关联，事件概念关联常识及事件概念间因果顺承等事理关系的表示，等视角的知识建模架构解决方案。使用该方案建模，能够快速的帮助从概念事件/时间区间/空间范围的约束或约束的组合查询实例事件，从实例事件的关联中发掘抽象事理关系，从事理关系反向推理预测事件的发展。
建模步骤及案例
-
事件表示
-
支付宝覆盖的数字生活场景及新闻事件中的金融事件有不计其数的事件类型；导致在知识抽取和管理时，每新增一类事件就需要设计一个新的Schema。算法上计划通过统一的SPO抽取来解决这个问题。但因为数据入图谱仍然需要依赖Schema，所以产品上需要有一套通用的事件建模规范来简化事件建模的复杂性。
-
如表5所示，我们对多元时空行为事件定义了统一的建模框架，将事件的属性分为基本要素、时间要素、空间要素、主体要素和客体要素。
-
基本属性：定义一个新的事件类型时默认的属性，不能删除，包括：主键id、name、description。
-
时间要素：对事件发生时间、报道时间、起始时间、终止时间、状态变化时间等的定义，时间一般被标准化为时间戳类型。
-
空间要素：对事件发生地点、起始地点、终止地点等的空间要素的定义，蚂蚁场景下的空间要素一般为确定的AOI/POI实体，标准化的行政区划概念或格式化表示的经纬度坐标点。
-
主体要素：事件的主体要素是指事件的执行者、行为人；如公司事件的主体是一个工商企业，用户行为事件的主体是2088开头的支付宝账户id所代表的支付宝用户。
-
客体要素：事件的客体是事件的被执行对象。例如：“北向资金净买入赛托生物526.97万元，赫美集团62.79万元 ”中，主体为：北向资金，客体为：赛托生物，赫美集团。一般金融事件的客体可能为：公司、板块、股票、基金等，用户行为事件的客体可能为：产品、品牌、意图、服务、门店等。需要注意，一个事件的主体或客体可能有多个，且可能属于不同的实体/概念类型（见图14）。
-
表5的框架，介绍了能够覆盖蚂蚁场景下大部分事件/行为建模的要素定义；在面向特定业务场景的行为事件建模时，建模者根据需要选择表5中预定义的要素及增加各种需要的要素定义，如表6和表7分别给出了在对金融事件和用户行为事件建模的案例。
表5 事件定义框架
| 要素类型 | 事件要素 | 解释 | 事件要素值类型（实体） | 事件要素值类型（概念） | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 基本要素 | id | 事件唯一id | 概念事件的名称即为其id | |||||||||
| 基本要素 | name | 事件标题，行为事件可以没有名称 | ||||||||||
| 基本要素 | description | 事件描述摘要 | ||||||||||
| 时间要素 | happenTime | 发生时间 | 年份、时间点 年份、时间点 年份、时间点 | 时间段标签（如：上午、傍晚、下午、周末） 特殊节日概念（如：清明节、国庆节） | ||||||||
| 时间要素 | startTime | 起始时间 | ||||||||||
| 时间要素 | endTime | 终止时间 | ||||||||||
| 空间要素 | happenLoc | 发生位置 | 经纬度坐标点、POI、AOI | 行政区划概念 行政区划概念 行政区划概念 | ||||||||
| 空间要素 | startLoc | 起始位置 | 经纬度坐标点、POI、AOI | |||||||||
| 空间要素 | endLoc | 终止位置 | 经纬度坐标点、POI、AOI | |||||||||
| 主体要素 | eventSubject | 事件主体 | uid、公司id等 | 公司类型、品类等概念 | ||||||||
| 客体要素 | eventObject | 事件客体 | 产品、门店、小程序、公司、品牌、股票、基金等 | 公司类型、品类、基金板块、常识概念等 | ||||||||
| 客体要素 | intent | 行为意图 | 意图概念 | 意图概念 | ||||||||
| 客体要素 | behavior | 行为类型 | 交易 | 搜索 | 点击 | 使用 | 出行 | 交易 | 搜索 | 点击 | 使用 | 出行 |
表6 金融事件-产业链事件定义
| 产业链事件schema模型（EL.IndustrialChainEvent）示意 | |||||
|---|---|---|---|---|---|
| 要素类型 | 属性英文名 | 属性中文名 | 属性类型 | 属性值举例 | 是否必填 |
| 基本要素 | id | id | String | 85869e7bf616a21a628e25331754156b | 是 |
| 基本要素 | name | 事件名称 | String | 汽车整车销量预计上涨50% | 是 |
| 基本要素 | belongTo | 所属类型 | Concept | EventConcept | 否 |
| 基本要素 | docSentList | 相关内容 | String | 23594049:<p>6月3日，中国汽车工业协会根据重点企业上报的周报数据推算，5月汽车行业销量预计完成176.65万辆，环比增长49.59%，同比下降17.06%；…… | 否 |
| 基本要素 | eventState | 状态 | 枚举类型 | 预计发生 | 否 |
| 基本要素 | eventInfo | 事件要素 | String | 汽车整车,销量,上涨,50%,预计发生 | 否 |
| 时间要素 | pubDate | 发布日期 | 时间类型 | 20220601 | |
| 空间要素 | happendIn | 发生区域 | 行政区划 | 否 | |
| 主体要素 | eventProduct | 产品 | 产品 | 汽车整车 | 否 |
| 主体要素 | eventIndicator | 指标 | 指标 | 销量 | |
| 客体要素 | eventTrend | 趋势 | 趋势 | 上涨 | |
| 客体要素 | eventExtent | 幅度 | 百分数 | 50% | 否 |
| …… | …… | …… | …… |
表7 用户行为事件-用户出行事件定义
| 用户出行行为schema模型（TrafficBehavior）示意 | |||||
|---|---|---|---|---|---|
| 要素类型 | 属性英文名 | 属性中文名 | 属性类型 | 属性值举例 | 是否必填 |
| 基本要素 | id | id | String | xxxxx | 是 |
| 主体要素 | user_id | 行为主体 | 支付宝账号 | 2088xxxxx | 是 |
| 客体要素 | opposite_user_id | 服务方 | 支付宝账号 | 2088xxxxx | 是 |
| 基本要素 | consume_title | 事件描述 | String | 地铁-古墩路-正常行程扣费 | 否 |
| 基本要素 | consume_fee | 交易金额 | float | 5.00 | 否 |
| 时间要素 | gmt_biz_create | 发生时间 | 时间戳 | 2023-03-22 9:41:57 | 是 |
| 空间要素 | start_station | 起始poi | poi | 凤起路地铁站 | 是 |
| 空间要素 | end_station | 终止poi | poi | 古墩路地铁站 | 是 |
| 时间要素 | start_time | 起始时间 | 时间戳 | 2023-03-22 9:24:32 | 是 |
| 时间要素 | end_time | 结束时间 | 时间戳 | 2023-03-22 9:41:57 | 是 |
| 空间要素 | city_name | 涉事城市 | 行政区划 | 杭州 | 是 |
| 基本要素 | trip_ext | 出行信息 | String | 否 | |
| 客体要素 | od_biz_type | 交通工具 | 枚举字段 | metro | 否 |
多要素建模链指
无论是在金融事件还是用户行为事件，其事件要素及同一个事件要素所关联的实体/概念都可能是多值的。如图14展示的“3月20日永安林业领涨”事件，其关联的事件客体有“林业”和“永安林业”两个节点，其中“林业”是一个“板块”概念，“永安林业”是一个股票实体；再例如“张三购买咖啡”行为事件，其客体属性有“少糖星冰乐”和“抹茶拿铁”两个实体。为了满足对事件多要素、要素多值类型的建模要求，在蜘蛛平台提供以下能力：
- 多要素建模：每种时间要素可以定义多个属性，如对时间要素定义发生时间、结算时间等；
- 要素的多值类型定义：对于同一个要素，可以将其语义属性类型选为多个类型。例如个股/上市公司上涨事件，所关联的客体值域可选[板块、股票]。
- 多值链指能力：在确定的属性上（如“个股/上市公司上涨”的“关联”属性，“用户消费行为”的“商品”属性）绑定链指算子，并在算子的实现逻辑中，支持对多类型值的链指。例如，对于“3月20日永安林业领涨”，结构化抽取结果中包括：{关联: 林业@板块, 永安林业@股票}，则事件节点本身通过链指拉边，关联到属性值对应的实体对象、概念节点上。
- 语义关联：依托基础篇中所提到的属性语义标化能力，能够在事件实例间建立广泛的语义关联。例如，对于“张三购买咖啡事件”，其发生时间是一个标准化的时间戳值。在物理上，它并不是一个数据上存在的节点，而是利用时间语义标准化能力，能够发掘发生时间在一定时间范围内的事件，进而建立其事件间的“同时间”共边关系（同理，时间间也可建立“同人”、“同地点”、“同商户”等关系）。事件之间的语义共边关系是不胜枚举，难以穷极的，用本文建模方式重的语义标准化拉虚拟边的方式，既能广泛的构建和挖掘事件的语义关联并用于图算法的子图特征采样，又能降低物理储存的压力。
图14 事件多要素多主体链指
概念语义定义
1.分类定义没有显示化：
目前对事件/实体的分类体系建模仍然是较黑盒的符号性的定义，只有建模者自己才能理解和解释概念的意义。因此，结合蜘蛛的产品功能实现，定义了用于概念管理的标准谓词，及概念等价语义规则表达方法。
2.建模门槛高：
由于“概念语义建模”是我们的建模方法中为了与结构化表示解耦而提出的一种解决方案，在涉及多元时空知识的表示时，需要与事件建模搭配使用，导致对新用户有一定复杂性。为此，我们以事理图谱的概念定义、概念语义演绎推理为例，介绍实体schema与概念体系及逻辑规则的结合应用，一起完成多维度的知识认知架构。
事件概念管理
即通过对实体分类体系和领域知识/常识中的通用语义元素的定义，以树状层级体系进行组织，自顶向下的体现实体语义的细分。
表8 概念建模相关语义谓词定义
| 谓词定义 | 谓词语义 | 举例 |
|---|---|---|
| 实体类型-belongTo-> 概念 | 在实体类型Schema上指定该类型的实例belongTo概念c（概念c是元概念树T上的一个概念），其语义为该实体类型下的实例可以被分类为以c为根结点的子树上的概念。 | # 任意事件的实例可被分类为事件概念树上的一个概念事件 EL.Event-belongTo-> EventConcept #趋势事件的实例，可以被分类为趋势概念事件下的子类型 EL.TrendEvent -belongTo->TrendEventConcept |
| 实体实例-belongTo-> 概念 | 该实体的属于概念所指的grained type | x年x月alibaba股价上涨 5%-belongTo->股票价格上涨事件 |
| 概念-isTypeOf->元概念 | 一个元概念下的概念，都是该体系下的类型。 | 趋势事件-isTypeOf->事件概念 |
| 概念-特定语义->概念 | 定义概念上下层级间的语义关系 | 股票价格上涨事件-isA->价格上涨事件 价格上涨事件-isA->趋势事件 西湖区-LocatedAt->杭州市 |
概念事件的逻辑语义
对于一个“分类概念”，即在元概念上限制了该概念体系特定的用于某个schema约束的实体类型的语义细分，支持定义等价的逻辑表达式，定义该概念的语义内涵。当概念定义了逻辑表达式后，可以根据逻辑表达式进行双向推理：
- 基于规则的实例细分：当算法分类只分到较粗粒度，或没有接概念类细分算子，可以使用逻辑表达式根据实例数据各属性/关系的值，帮助推断出实例的细分类型
- 一致性检测：对于已知所属概念细类的实例，用逻辑规则帮助检验其个字段属性是否满足概念的定义。
例如，下例是对“汽车整车销量事件”的语义内涵的定义（通过dsl语言）
汽车整车销量事件（Concept） <=> if s isInstanceOf IndustrialChainEvent and s.产品 == 汽车整车 and s.指标 ==销量
Define (s:EL.IndustrialChainEvent)-[p:belongTo]->(o:汽车整车销量事件) {
GraphStructure {
s : Event
Rule {
p: s.eventProduct == '汽车整车' and s.eventIndicator == '销量'
}
}
}概念演化挖掘
在具体业务场景中，概念类目树随着业务语义的细分，可能无限膨胀。此时人工对概念进行定义，特别是定义概念的等价逻辑，变得繁琐。当分类概念所服务的实体类型schema的论元已知且约束了取值范围（实体类型、概念类型）时，对于概念及其逻辑表达式的自动挖掘和生成提供了可能。下面以“产业链事件”的语义概念细分为例，探索在业务场景下如何自动做概念语义演化及沉淀业务规则。
IndustrialChainEvent
{
eventState 事件状态 枚举值 [example：预计 发生]
eventProduct 涉事产品 产品概念 [example：白酒 生猪 粮食 有色金属 ……]
eventTrend 发生趋势 趋势(枚举值) [example：上涨 下降 由涨转跌 ……]
eventExtent 发生幅度 百分数(枚举值) [example：大幅 小幅 缓慢 ]
eventIndicator 涉事指标 指标 (概念) [example：价格 销量 产量 库存 成本 ……]
}
1.概念自动生成
对产业链事件设置分类层次，即自顶向下类型细分的优先级：
涉事指标->发生趋势->发生幅度->涉事产品->事件状态
定义概念事件生成命名模版 ：
[产品][指标][事件状态][幅度][趋势] + ‘事件’
如图15所示，按照分类层次优先级的顺序，对已经抽取沉淀的事件实例的论元要素值进行统计，能够将具有同样特征的事件实例归纳为一个概念事件。例如先根据指标类型，将产业链事件细分为：产能事件、销量事件、价格事件等。当每类事件积攒到一定规模时，根据变化趋势、发生幅度、产品类型等要素值，对概念进一步细分。注意在基于实例的统计对概念细分时，要注意剪枝，避免概念树过于庞大及拥有无实例的概念。
该模版在概念挖掘时，与“分类层次”结合应用，并需要排除可能生成的没有意义的概念如：“白酒小幅事件”
图15 事件概念演化
2.概念事件逻辑表达式
如下面定义的dsl模版所示，可以在一定层级的概念上定义“概念等价式模版”，帮助子树上细分语义概念演化的同时，自动生成其逻辑语义表达式，用于对实例的推理和分类。
- 给定规则表示模版生成逻辑表达式
if existed &conceptEvent = [产品][指标][事件状态][幅度][趋势] + ‘事件’
&conceptEvent.name = [&产品][&指标] + '事件'
Define (s:EL.IndustrialChainEvent)-[p:belongTo]->(o: &conceptEvent ) 3
GraphStructure {
s : Event
Rule {
p: s.eventProduct == &产品 and s.eventIndicator == &指标
}
}
}3.概念语义应用
通过上述的概念挖掘模版，可以用同种方法对概念细化、概念语义关系中的论元要素槽位值进行替换，以演化生成其他概念间的语义关系，用于辅助事件实例间的关系挖掘。
已知：
白酒价格大涨事件 -引发-> 白酒板块股价变化事件
白酒板块(板块概念) -关联产品-> 白酒(品类概念)
定义规则（其中 X、Y为可替换的事件要素槽位值）：
X价格大涨事件 -引发-> Y股价变化事件
iif Y[板块概念] -关联产品-> X[品类概念]
演绎规则（X=有色金属，Y=有色金属板块）：
有色金属价格大涨事件 -引发-> 有色金属板块股价变化事件
应用：
已知：x年x月黄金价格上涨 -belongTo->有色金属价格大涨事件
推论：有色金属板块股价变化事件
多元时空认知架构
多元时空认知架构，是对基于schema的实体关系定义，概念语义建模及事件行为的多元关系定义的综合应用，主要用于事理图谱、用户行为等场景。如保险产品、黑产等需要沉淀领域专家知识及通过领域知识对特定实例进行判例的场景，也可以运用多元时空认知架构的思路来描述其业务问题。
如图16所示，多元时空认知架构，体现在以下三个方面：
1.在模式层，定义知识的结构化表示（即schema）、语义规则、事理关系。其中将语义规则和事理关系也定义在模式层，是因为对于概念的等价逻辑，可以认为是对实例推理的一种模式、规则，而事理关系也是对具有共性的事件见关系的抽象，因此认为属于模式层。
2.在概念层，定义知识的语义认知体系，及对业务中所设计的常识或关于特定领域术语的概念体系建模，其中也包含了概念之间的二元常识关联。
3.在实例层，首模式层的约束，对非结构化文本做信息抽取，对于结构化的信息，也受概念层的语义约束，标准化、语义化为规范的属性值表示，以建立实体-实体、实体-概念间的语义关联。在实例知识标准化、结构化到图谱后，受模式层的语义规则、事理关系、业务逻辑的约束，对知识进一步挖掘和推理。
整个多元时空认知架构，将展示特定领域知识的结构范式、逻辑语义，并对该领域的概念常识和实例间的客观事实进行多维度的建模展示。
图16 知识的多元时空认知架构（清晰大图可后台回复“图16”获取）
图17、图18展示了在前文所属实体关系定义、概念语义建模对多元行为知识结构化、语义化后，对于用户行为知识多视角的建模表示。
- 多元时空知识可包含多元时空事件实体以及多元时空概念事件。多元时空事件实体对应于客观存在的多元知识，而多元时空概念事件是对客观存在的具有共性的多元知识的抽象。以用户行为为例，“张三下午3点在星巴克购买了一杯咖啡”这是一个多元事件实体，“年轻白领在工作日的下午点咖啡”这是一个概念事件，是基于大量的相似的实体多元知识抽象而来。事件实例的至少一个论元对应客观存在的事物，如行为主体对应具体的某个人，而如图18，概念事件的论元均对应抽象知识。
- 可以将多元知识建模为一个“超边”节点，体现其多个论元要素的关联。以图17中的“观影事件”为例，其行为主体论元的实例值为“李四”，而图谱中已经具有节点李四（即自然人实体节点实例），则将“观影事件”这一事件实例与节点李四进行边连。又例如，该事件的行为类型要素的值为“观影”，而图谱中已经存在行为类型的各种概念节点，则可以将“观影事件”关联到“观影”概念节点。同时，“观影”概念节点又存在与其他事件间的关联，进而建立起了相同行为事件实例间密集的邻居关系。
- 多元知识节点实例之间也可以具有边连。以事件为例，多元知识节点实例间的边可以表示以下关系中的一种或多种：顺承、因果、伴随以及组成。其中，顺承表示头节点事件时间上先于尾节点事件发生。因果表示头节点事件是导致尾节点事件发生的原因。伴随表示头节点事件和尾节点事件通常伴随、共现发生。组成表示头节点事件是尾节点事件的一部分。
- 通过对多元时空行为知识的概念化，有助于进一步挖掘多元知识中的规律，进行信息预测。概念事件间的边与事件实体类似，可以是顺承、因果、同主体等等。以图18为例，图中的下午茶事件以及观影事件为两个概念事件，其具有顺承关系，进而构成一个反应概念事件间关联的子图。需要说明的是，实体事件间的关系体现的是单个具体事件间的关联，而概念事件间的关系体现的是通用知识或常识的沉淀。
图17 多元时空事件实体及关联
图18 多元时空概念事件及关联
由于在多元知识的模式层进行schema定义时，对各个事件要素的类型和格式做了约束，因此对于时空信息标准化后，能够方便的基于数值计算或行政区划的概念层级进行推理，确定事件实例之间的“同主体”、“同地点”、“同时间”等语义关系，这些语义关系也可以作为图采样结果中的边关系。蜘蛛提供了对各种组合条件下的子图查询和子图采样，并得到查询结果的可视化子图。
由于事件间的语义关系是难以穷尽的，因此在工程实现上，并不对事件间的同主体、同时间、同地点等关系边做物理存储（同样对于标准化的语义属性值其实也并不存在物理节点），而是基于查询条件进行图采样，并实时或按需进行语义化计算确定采样结果中各事件间的语义边，有效避免了图谱中边“爆炸”的问题，节约了存储空间。
未来展望
在大模型的冲击下，知识图谱与大模型的融合成为一个有意义的探索方向。图谱本身是对数据/文本的压缩，通过知识建模定义的知识的结构规范，提炼出知识最本质的特征和语义。因此，schema本身可以作为一种强范式的instruction。结合大模型和in-context learning，很自然的能够想到，让大模型来帮助我们自动生成常识知识的schema定义（领域、业务实体特有schema仍然需要人工定义）、以schema作为prompt约束，生成高质量的结构化知识并沉淀到知识图谱。我们尝试了在知识建模、知识抽取、知识探测三个方向上图谱结构化数据与大模型的互动。
知识建模
知识抽取
知识探测
参考文献：
- 知识图谱综述——表示、构建、推理与知识超图理论
https://www.cnki.com.cn/Article/CJFDTotal-JSJY202108002.htm
- ASER: Towards large-scale commonsense knowledge acquisition via higher-order selectional preference over eventualities
https://www.sciencedirect.com/science/article/pii/S0004370222000807
- Atomic: An atlas of machine commonsense for if-then reasoning
https://ojs.aaai.org/index.php/AAAI/article/view/4160
- AliCoCo2: Commonsense knowledge extraction, representation and application in E-commerce
https://dl.acm.org/doi/abs/10.1145/3447548.3467203
