开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2023.06.10河北
导读
本文总结了我们过去参与的知识图谱项目中的一般问题和难点，沉淀为体系化的方法论，并针对不同复杂程度的知识建模问题，进行实操指南。
前言
说明
在基础篇、进阶篇、高阶篇，针对不同业务场景的建模需求，由浅及深讲解知识建模的方法和案例，并涉及术语的解释。本文档所提出的建模方案，已经在蜘蛛平台做了对应的能力支持实现(或开发迭代中)。独立于蜘蛛平台，读者也可以按本文的方法论对自己的业务问题简化抽象，实施对领域知识的建模及对已有常识图谱的复用。
背景
知识建模是解决将真实世界中的海量信息转化为符合计算机处理模式的结构化数据，其中包括对真实世界中事物的属性特征及其关系的共性的抽象，制定表示的规范，同时兼顾对常识或领域概念及概念层级体系的语义理解，即体现了对知识的认知过程。
图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表示
●事件概念之间的顺承、因果等需要逻辑表达
方案概述
本体是偏哲学的学术概念，指“特定领域之中某套概念及其相互之间关系的形式化表达（formalrepresentation）”。在知识工程、语义网时代，都用本体建模指代知识建模，利用rdf、owl等规范的语言，核心定义严格完备的逻辑。但这套方法不适合大数据时代知识的多样性、跨领域复杂性，无法满足数据的便捷迭代生产。
基于MOF四层元模型框架，我们提出知识认知建模方法论，串联了知识建模、知识生产、知识管理应用的全生命周期流程。其中，元元概念指所定义的建模规范，如本文提出的MOF建模标准中的实体、概念、关系等建模要素就是元元概念，“元概念”对应定义实体类型的schema，是对拥有同样数据结构的知识的结构化定义，如“商家schema”、“事件schema”；“概念”是对实体的语义细分，如“蚂蚁商家”、“外卖商家”，“白酒板块事件”、“蚂蚁高管变化事件”；实例对应于现实中一个具体的事实，一般是ID化的，如id为2088xxxx的A空间肯德基商户。
图2MOF知识建模方法
基础篇·实体关系设计
解决问题
解决数据的结构化表示，包括实体各属性字段的规范定义，及设计实体间的关系，以便将数据最终构建为有别于传统数据表的图结构形式，便于基于路径的多跳关系查找。
适用场景
术语定义
Schema是知识的“元数据”表达方式，定义了知识的概念的属性，关系，属性及约束。主要实现了实体的结构化和实体间的关系的定义。
物理世界或数字世界存在的事物是一个实体，实体对应于数据表中的一行记录。
实体类型，即实体的“schema”。它是对具有共同数据结构（特征）的一类数据实例的“元数据”模式定义。因此每一个实体类型，都有自身特定的schema。同时，实体类型存在上下位关系，通过继承，下位类拥有上位类已定义的属性和关系及其约束。在知识图谱平台中，实体类型用于对具有共同数据结构的个体进行分组管理。可以将实体类型理解为，对知识结构化表示的语法规范。如下表所示，是对自然人的schema定义。
自然人模型（Person）示意
属性英文名
属性中文名
属性类型
属性值
是否必填
id
String
12345xxx
是
name
姓名
张三
certId
证件号
330121xxx
否
certType
证件类型
枚举类型
身份证
birthday
出生日期
20230215
gender
性别
男
occupation
职业
白领
......
描述实体-实体间的关联。在基础的实体关系设计时，只考虑满足SPO(Subject-predicate-Object)表示的二元关系，既两个实体间确定的关系。如定义一个关系：公司-法人->自然人，“法人”是关系谓词，关系主体是“公司”这种实体类型，客体是“自然人”；注意，关系是有向的，则一个“公司”的实例拥有一个出边到确定的“自然人”，且该自然人是这个公司的法人。
Subject
Predicate
Object
是否唯一
Company
法人
Person
好友关系
夫妻关系
居住地
POI
属性语义标化
在实体-关系建模时，对于实体的特性字段，到底应该建模为属性，还是应该将特征key构建为关系，特征值(value)建模为实体，设计者经常陷入两难的抉择。例如：
在对商户建模的典型场景，一般商户会有关联的PID，在关系型数据表（odps）中，PID是一个id字段，pid本身也没有特别的属性，为了挖掘同pid的商户、发现用户对商户的消费行为，pid应该建模为实体，但Pid没有任何属性，这样做合适吗？
在例如对于商户的发货地址、所在省市区等特征，在数据表中一般是个string。但为了同地址、同地区的发现，甚至特定业务场景本来就有地址实体库。那么就需要对地址属性建模为关系了。但这带来两个问题：1.商户的发货地址、用户的收货地址可能存在变动，特别是用户收货地址，在图谱中维护时，需要在新增地址时，把历史地址边删除；2.对于所属省、所属城市、所属区等，若都建为实体拉边，将造成“热点”(即某个点有巨量的边)，为路径推理、采样带来困难。
为解决上述的属性/关系难以抉择，及提高知识管理的效率及降低存储压力，我们提出一种基于属性语义标化的建模方法，并在蜘蛛产品功能上已经交付可用。
属性语义标化能力体现为：
表3属性语义标准化类型
类型细分
属性定义
用法及示例
内置类型
概念类型
通识概念
一个描述常识分类体系的树状知识库，现覆盖17个大类的2W+常识概念。
当实体的类型需要细粒度的分类，且该实体的细分类可以用常识知识体系描述时，定义描述实体细分类的属性（如：对于BaikeEntry定义了子类型subType），并将属性类型选择为“内置类型-
概念类型-CKG.AntTermType”。
知识生产时，对实体实例的subtype赋值为常识知识树上任意的概念的文本名称，则平台自动将该属性转为一个BaikeEntry-subtypestd->常识概念的边。
则细粒度一样的BaikeEntry在图结构上能够拥有共同的概念节点邻居（如姚明、易建联都是“篮球运动员”）
行业类目
●MCC类目
●POI类目
●门店类目等
●蜘蛛平台上集成维护了蚂蚁域内常用的MCC2.0、高德POI类目和门店类目
●现在对实体-特定类目的信息维护，只需定义一个属性（如定义一个“所属类目”属性），并将属性类型选择为“内置类型-概念类型-具体的某个类型体系”。
●知识实例生产时，将属性值填充为类目的code或名称(一般是叶子节点的类目)，则平台能力可以追溯类目的上级路径，并自动拉边，关联具有同类目的实体实例。
标准语义类型
虚拟地址
●网址等
●手机号码
●Mac地址
●……
ID属性
●身份证号码
●2088账号
●支付宝PID
●银行账户
●蚂蚁POI
1665476056
●一天
●一年
●24小时等
（空间类型）
行政区划
国家-省-市-区四级（目前仅支持中国行政区）
●蜘蛛平台集成了四级标准行政区划类目
●以往业务为了表示结构化的标准多级地址，一般会构建国家编码/国家、省编码/省、市编码/市、区编码/区，共8个属性字段，存在着属性的冗余储存。且plaintext的文本属性，不利于快速的发掘同地区的实体。
●利用语义标化，将表达实体行政区域特性的属性，类型选择为“内置类型-概念类型-行政区划”，数据生产时，将属性值填充为能够识别到的最细粒度的行政区划单位（平台提供兜底默认算子，帮助地址的结构化理解及标准化）
●通过语义标化链指能力，对于填充的行政区划属性值，其上级类目是可追溯的（如所在区县为“西湖区”时，西湖区-位于->杭州市-位于->浙江省-位于->中国，是已维护在“行政区划”类目树上的）
●平台能够自动拉边，维护实体(如poi、aoi、门店等)到特定省、市、区县的关系，并实现不同粒度下所属行政区划的查询。
经纬度坐标点(Position)
(经度,纬度)
同POI计算发现（球面距离小于epsilon），蜘蛛能力待开发
经纬度范围
(Position1，Position2）地理区块四边形（左上-右下坐标）
判断一position是否在该范围内，蜘蛛能力待开发
自定义属性类型
实体/概念
平台内置的概念类目体系、可传播的语义属性类型，无法完全满足特定业务的建模需要；因此，用户可以将属性类型赋值为“内置类型-自定义属性类型”，则在高级配置页面，选择将属性标准化为自定义的一个实体类型(默认用id链指)或概念类型(默认用概念名称链指)。
如果所示，对于“公司事件”实体，拥有两个语义标准化属性的应用——1.公司id，选择为“工商机构”实体，则能够利用平台id链指能力自动拉边到确定的“工商机构”实例；2.事件类型标签，定义为“概念事件”(业务自定义的一套为金融事件分类体系，概念建模详见进阶篇)，则能够利用平台的概念标化链指能力自动拉边挂载到“概念事件”树。
其他待开发
的属性
数量类型
数额
●度量/指标类型+数值表示
●对度量/指标类型标准化
●同一数量类型的比较
●区间数值合法性检验
指标
区间数值属性
●年龄
●年份
建模步骤及案例
实体关系设计，是为具有同样结构化特性(即有同样的特征要素)的实体定义的实体类型的schema，并建立实体类型间的关系。实体schema包含实体类型的命名、属性定义、属性类型及属性值的约束，关系schema约束关系主体和关系客体的实体类型。我们推荐在启动一个新的图谱项目时，按照以下步骤进行实体-关系建模：
schema的设计具有主观性，为了消除这种主观偏差，特别是降低跨图谱知识融合的复杂性，我们从过去的业务图谱设计经验中，总结了蚂蚁场景下常见的实体类型schema，并商家到corekg核心图谱；当业务涉及到这些实体数据时，可以直接对实体schema及数据引用/复用，减少重复建设，快速启动新的图谱项目。
如果为了业务安全/数据隔离等的考虑，业务需要自定义及构建自己的实例数据，我们也推荐对于corekg已有的实体类型，用户可以对其schema设计，特别是属性的定义和命名参考借鉴。
图3corekg核心实体定义
参考corekg中已有实体的schema，针对业务问题及数据，构建业务所需实体定义。
比如前文所述对蚂蚁用户定义的自然人模型，包括'姓名(name)'、'年龄(age)'、'身份证号(certNo)'、'家庭住址(homeAddr)'等基础属性，此外，定义'Person-好友关系-Person'、'Person-夫妻关系-Person'等关系。
101xxx
不同业务因领域模型不同会有自己的业务知识，比如同样一个用户，由于归属的业务不同，在蚂蚁会存在'支付宝用户(AlipayUser)'、'财富用户(FortuneUser)'、'网商用户(MyBankUser)'、'保险用户(BaoxianUser)'等用户模型，虽然这些用户模型背后指向的是同一个自然人模型，但在不同业务域有新增的属性字段，则利用schema的继承复用已定义的属性/关系约束，并在此基础上扩展新的特性。
支付宝用户模型（AlipayUser）示意
AlipayId
编码类型
2088
memLevel
会员等级
黄金会员
shoppingPref
购物偏好
物品概念
小吃
用户统一模型示意
对于不同业务实体归属同一主体的情况，一是可以在Schema层归类到统一实体模型上（深度继承），二是可以在数据层在相同实例之间增加isA或sameAs谓词关系（实体融合），达到主体分类一致的目的。
参考“属性语义标化”章节的内容，优化属性/关系的定义，将可以标化的属性选择为标准属性类型，对于适用id链指/概念链指的关系，转化为语义属性。例如，由于夫妻关系是唯一的，则可以将夫妻关系建模为语义属性。而朋友关系是多对多的，一个人可能有上百个朋友，因此依然用关系建模朋友关系。
进阶篇·概念语义建模
在知识图谱中，除了知识的元数据定义（即schema），通用常识和领域知识的语义关系、常识/业务类目的分类体系，体现了对语义的认知。为了将语义建模与知识的结构化表示解耦，我们提出的方案是用“概念语义建模”来对常识概念及常识关系建模，对特定领域知识的认知体系和经验规则建模。
如图4所示，在概念建模中，构建对常识/特定实体类型的分类体系。Root节点，代表“常识知识树”的根结点，在这棵概念树上，我们预定义了17种实体的分类体系，如“角色”、“物体与物品”、“组织机构”、“品牌”、“事件”都是一个“元概念”（即一个分类体系的根结点），每个元概念作为起点的子树，定义了对该类实体的语义细分，目前蚂蚁知识树上已经有超过2W+的节点。此外，在常识概念图谱中，我们还集成了高德poi类目、意图图谱、mcc2.0行业类目、行政区划概念树、hownet义原语义网络，作为跨领域可插拔的常识语义认知系统，帮助各个业务图谱深度实体类型理解及属性语义标准化。
例如对于图中所示的描述服务内容结构化理解的领域图谱，在领域图谱中，小米10-手机类型->“智能机”，“智能机”是结构化抽取到的spomention，通过概念链指标准化到知识树上的概念“智能手机”，则通过知识树的可追溯链路，能够知道小米10同时也属于手机、数码产品、电子电器产品。同时，为了保障语义的内聚性，尽量为用户提供简洁的描述并加强信息间的关联，“概念”也提供对关系谓词（即属性名称、关系名称）标准化的能力。如“所属公司”这个谓词，其实约束了尾节点的实体是一个公司。
图4概念语义建模
把所感知的事物的共同本质特点抽象出来，加以概括，是自我认知意识的一种表达，形成概念式思维惯性。概念的意思：思维的基本形式之一，反映客观事物的一般的、本质的特征。
概念建模，期望通过对实体分类体系和基于commonsense的通用语义元素的定义，并以树状层级体系进行组织，自顶向下的体现实体语义的细分。其中我们将满足以下任意一个特性的短语定义为一个概念（concept）。
图5概念是什么
meta-concept，即概念的概念，在蜘蛛上是指用来组织一个特定概念体系的规范。元概念定义，就是根据对特定领域/业务的认知或常识，定义该类型概念的结构，约定概念的属性、层级结构及表达层级结构的语义谓词。
当我们需要在语义上对实体类型细分时，实体类型的schema可以对应一个元概念，以表现对该类型实体类型的分类体系。例如图四中的“角色”、“物体与物品”、“组织机构”、“品牌”、“事件”都是“元概念”，定义了对特定实体的语义细分体系。
表4概念和实体的区别
概念
实体
什么是概念
●概念是对具有同样特征的实例的抽象，是语义上/认知上能够被“归类”为同一类型的实例的集合。
●概念是符号化的，但领域内的人对它这个符号的语义是有共识的。
●概念带有领域/业务/常识的主观或经验，是人为定义的，概念的内涵/语义是相对恒定的。
●概念的符号体现了自身的语义，概念之间构建的语义关系边(白酒板块事件-涉事产品->白酒，白酒-原料->粮食，猪瘟疫情事件-影响->猪肉价格上涨，形成了描述领域常识的语义网络。以上举例的三元组中的S和O都不是具体的、特定的实例，而是对同一类实体，及同类实体所具备共有特性的概括)
○可以先简单粗暴的认为，“概念”是没有“属性”的（除了编码、别名、描述）
●实体类型，是对拥有同样数据结构/论元要素的数据的定义
●实体实例，是id化的，唯一存在的实例。
●实体是客观的存在，实体的特征是动态变化的。
●实体拥有特异的属性/关系定义。例如：某个事件的发生事件、地点、主体、客体；某部手机的型号、屏幕、尺寸、内存等参数。
什么应该被定义为概念
●类目概念：对具有同样特征的一类实体的语义抽象，可以来自业务类目、领域的taxonomy，比如POI类目、MCC类目等。
●常识概念：在特定领域(元概念)下，人们有共识的无歧义短语，比如杭州市、手机、中秋节。
●复合概念：在一个核心词概念上增加语义修饰限定（该限定可以是概念,也可能代表特定实例），例如：“白酒”+“产品价格上涨”=白酒产品价格上涨“杭州”+“互联网”+“上市公司”=杭州互联网上市公司'腰封偏好'+'高日活'+'支付宝账户'=高日活的腰封偏好支付宝账户“阿里巴巴”+“公司”=阿里系公司“华为”+“手机”=“华为手机”复合概念可以拆解为等价的谓词逻辑表达式（见后文）
●品牌不是“概念”，它是特定厂商定义的一个IP，本身不具备认知的层级体系。如果品牌有类目体系，则品牌类型是概念。
●物理世界真实存在的一个个体，蚂蚁内部特定的一个账户、一个商家、一个供给内容，是实例。
概念能够表达那些语义
1.对实体进行细分类，完成schema无法体现的更详细的语义
●通过逻辑表达式定义的规则，自动完成“复合概念”的生成及帮助推理属于该集合的实例
2.提供属性的标准化及语义化，则属性值不再只是一个plaintext，而是依靠概念语义网络，可关联可追溯的子图。
●对多跳上下游产业链关系、上下位产品品类的召回进行处理
●实体类型的schema是在知识管理的角度，来选则粗粒度的“类型”。
我们以事理图谱的概念语义建模为例，介绍用户自定义概念体系并使用概念为实体做细分类的方法。
事件体系语义建
图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.使用一个统一的模型/框架进行所有类型事件的抽取
3.拿到schema后，完成抽取的槽位跟schema定义的论元的映射，则该槽位值是实体（及其EntityType）还是概念（及其元概念）是已知的
5.完成要素的标化及链指后，用规则谓词推理其belongto的概念事件类型
6.最终完成子图构建（图中围绕实例事件e1、e2及其关联实体、概念组成的子图）
图8强schema、强语义约束的事件实例生产
L0-元概念（概念类型）
对应为实体类型。例子：品牌、术语、事件、组织机构。即一个特定的schema实体类型，对应拥有一个概念类目体系，则L0为该体系的root节点。
L1-概念分型的模式
决定了概念类目细分的方式。这里就像是决策树一样，先选择最有区分度、子概念类型不重合的方向细分。在L1定义的概念，是概念类型在不同纬度、行业、领域、应用场景的类目树的根节点。
L2-类目细分
L2-Ln，为概念类型在确定子领域/场景下的细分。
在蚂蚁常识知识图谱，我们集成了常识知识树、行政区划类目树、MCC2.0、高德POI、意图知识树等蚂蚁域内通用的常识认知体系和领域分类体系，来帮助跨业务的概念类目集成和内容理解。
图9常识概念建模及应用（清晰大图可后台回复“图9”获取）
保险产品图谱，是为了将保险业务中对保险产品的业务分类类目、领域标准分类、保险产品的各个重要特性建模，并将对每个业务自定义的产品标签概念（如“心血管保障好”）背后关联的产品特性、产品分类的逻辑固化到图谱中，进而使用图谱的路径推理能力帮助具体保险产品实例所属类型的判断。
如图10中，显示了对保险产品的schema定义，业务对“产品渠道”、“保障风险项”、“人群特征”、“产品分类”、“特色保障”等属性都做了语义标准化，即这些属性的取值都受到某个元概念体系的约束，而这些元概念体系是业务根据自身领域的各个类目树预先定义的。
图11中，在模式层定义了保险产品schema专属的分类体系——“产品类型”元概念；在概念层，构建了各个业务概念类目体系及这些概念间的语义关联。最终在实例层，演绎了如何准对一个具体保险产品的语义字段，套用概念语义网络及逻辑规则，实现对实例产品类型的推理。
图10保险产品语义网络构建及应用
图11保险产品语义网络构建及应用
意图图谱的核心本体主要共包含四类节点（意图,功能词,产品词,义原）和三类关系（isA,Consist,Has），如图所示。具体来说，“意图”描述了用户需求背后的动机，主要由一个功能动词（动词）和一个产品实体（名词）组成动宾结构，例如“打网约车”、“买咖啡”和“维修家电”等。此外，“功能动词”和“产品实体”可以用更细粒度的Hownet义原表示，拆分为最基本的语义单位，如“movieticket|电影票={coupon|票证,look|看,shows|表演物}”。
构建意图图谱，主要有两个作用：1.功能词、产品词、义原实体可以丰富意图的语义信息；2.拥有相同功能词/产品词/义原的意图之间建立起新的关联关系。
图12意图概念图谱构建及应用
高阶篇·多元关系架构
根据论元个数把关系分为：一元关系、二元关系和多元关系
超图(hypergraph)是一种更加抽象的图，与传统图的区别主要在于超边可以同时包含多个(>2)结点。超图通过引入超边关系，能够完整表达各种复杂的关系类型。
概念的内涵就是指反映在概念中的对象的本质属性或特有属性。概念的外延是指具有概念所反映的本质属性或特有属性的对象，即概念的适用范围。
在进阶篇的概念建模，我们主要描述了如何基于领域常识或业务知识，构建树状的概念类目，以便于概念的复用、加强实体间语义关联。同时我们应该注意到，如果没有定义概念的内涵与外延，那么“概念”只是一个人工定义的符号，无法起到语义上的可解释、推理的能力。对于概念的等价语义表达式，在owl、rdf等框架中，一般使用一阶逻辑表达式实现。同样，我们也在蜘蛛平台上实现了对“分类概念的等价逻辑表达式”的实现。概念的等价逻辑表达式，体现为当实例知识的多个特征要素满足一定值约束时，该实例可以被推断属于某个概念。概念的等价语义表达式的定义，也属于一种多元关系。
如前文提到，超图是解决多元关系表示的图结构，但显然，超图不是一种直观的对数据结构化和可视化的方法。而直接将超图表示转换为行为事件要素间的三元组关联，可能是有损的转换，例如小蚂并没有从灵隐寺出发并到达浙江大学的行为。但传统的图谱三元组表示却可能导致这样的歧义。
因此我们提出兼容与超图结构互相无损互转的时空行为事件表示方法，主要体现为将时空多元关系（即事件或行为）本身抽象为一个事件节点，并定义事件节点与其各事件要素间的关联。则事件节点本身即为超边的具像化，能够的在spo表示与超图表示间进行结构化知识的无损转换。
同时，对于规则的表示，体现概念语义内涵和外延的逻辑表示，都有提供了相应的解决方案。在本篇中，我们将介绍如何综合使用实体关系建模、概念语义建模及多元关系建模，来对一个领域内的知识做整体的认知和架构。
图13多元关系建模难点
表5事件定义框架
要素类型
事件要素
解释
事件要素值类型（实体）
事件要素值类型（概念）
基本要素
事件唯一id
概念事件的名称即为其id
事件标题，行为事件可以没有名称
description
事件描述摘要
happenTime
特殊节日概念（如：清明节、国庆节）
startTime
endTime
空间要素
happenLoc
发生位置
经纬度坐标点、POI、AOI
行政区划概念
startLoc
起始位置
endLoc
终止位置
主体要素
eventSubject
事件主体
uid、公司id等
公司类型、品类等概念
客体要素
eventObject
事件客体
产品、门店、小程序、公司、品牌、股票、基金等
公司类型、品类、基金板块、常识概念等
intent
行为意图
意图概念
behavior
行为类型
交易|搜索|点击|使用|出行
表6金融事件-产业链事件定义
产业链事件schema模型（EL.IndustrialChainEvent）示意
属性值举例
85869e7bf616a21a628e25331754156b
事件名称
汽车整车销量预计上涨50%
belongTo
所属类型
Concept
EventConcept
docSentList
23594049:
6月3日，中国汽车工业协会根据重点企业上报的周报数据推算，5月汽车行业销量预计完成176.65万辆，环比增长49.59%，同比下降17.06%；……
eventState
状态
预计发生
eventInfo
汽车整车,销量,上涨,50%,预计发生
pubDate
发布日期
20220601
happendIn
发生区域
eventProduct
产品
汽车整车
eventIndicator
销量
eventTrend
趋势
上涨
eventExtent
幅度
百分数
50%
表7用户行为事件-用户出行事件定义
用户出行行为schema模型（TrafficBehavior）示意
xxxxx
user_id
行为主体
支付宝账号
2088xxxxx
opposite_user_id
服务方
consume_title
事件描述
地铁-古墩路-正常行程扣费
consume_fee
交易金额
float
5.00
gmt_biz_create
2023-03-229:41:57
start_station
起始poi
poi
凤起路地铁站
end_station
终止poi
古墩路地铁站
start_time
2023-03-229:24:32
end_time
city_name
涉事城市
杭州
trip_ext
出行信息
od_biz_type
交通工具
枚举字段
metro
无论是在金融事件还是用户行为事件，其事件要素及同一个事件要素所关联的实体/概念都可能是多值的。如图14展示的“3月20日永安林业领涨”事件，其关联的事件客体有“林业”和“永安林业”两个节点，其中“林业”是一个“板块”概念，“永安林业”是一个股票实体；再例如“张三购买咖啡”行为事件，其客体属性有“少糖星冰乐”和“抹茶拿铁”两个实体。为了满足对事件多要素、要素多值类型的建模要求，在蜘蛛平台提供以下能力：
图14事件多要素多主体链指
1.分类定义没有显示化：目前对事件/实体的分类体系建模仍然是较黑盒的符号性的定义，只有建模者自己才能理解和解释概念的意义。因此，结合蜘蛛的产品功能实现，定义了用于概念管理的标准谓词，及概念等价语义规则表达方法。
2.建模门槛高：由于“概念语义建模”是我们的建模方法中为了与结构化表示解耦而提出的一种解决方案，在涉及多元时空知识的表示时，需要与事件建模搭配使用，导致对新用户有一定复杂性。为此，我们以事理图谱的概念定义、概念语义演绎推理为例，介绍实体schema与概念体系及逻辑规则的结合应用，一起完成多维度的知识认知架构。
即通过对实体分类体系和领域知识/常识中的通用语义元素的定义，以树状层级体系进行组织，自顶向下的体现实体语义的细分。
谓词定义
谓词语义
举例
实体类型-belongTo->概念
在实体类型Schema上指定该类型的实例belongTo概念c（概念c是元概念树T上的一个概念），其语义为该实体类型下的实例可以被分类为以c为根结点的子树上的概念。
#任意事件的实例可被分类为事件概念树上的一个概念事件
EL.Event-belongTo->EventConcept
#趋势事件的实例，可以被分类为趋势概念事件下的子类型
EL.TrendEvent-belongTo->TrendEventConcept
实体实例-belongTo->概念
该实体的属于概念所指的grainedtype
x年x月alibaba股价上涨5%-belongTo->股票价格上涨事件
概念-isTypeOf->元概念
一个元概念下的概念，都是该体系下的类型。
趋势事件-isTypeOf->事件概念
概念-特定语义->概念
定义概念上下层级间的语义关系
股票价格上涨事件-isA->价格上涨事件
价格上涨事件-isA->趋势事件
西湖区-LocatedAt->杭州市
对于一个“分类概念”，即在元概念上限制了该概念体系特定的用于某个schema约束的实体类型的语义细分，支持定义等价的逻辑表达式，定义该概念的语义内涵。当概念定义了逻辑表达式后，可以根据逻辑表达式进行双向推理：
例如，下例是对“汽车整车销量事件”的语义内涵的定义（通过dsl语言）
汽车整车销量事件（Concept）<=>ifsisInstanceOfIndustrialChainEventands.产品==汽车整车ands.指标==销量
Define(s:EL.IndustrialChainEvent)-[p:belongTo]->(o:汽车整车销量事件){GraphStructure{s:EventRule{p:s.eventProduct=='汽车整车'ands.eventIndicator=='销量'}}}概念演化挖掘在具体业务场景中，概念类目树随着业务语义的细分，可能无限膨胀。此时人工对概念进行定义，特别是定义概念的等价逻辑，变得繁琐。当分类概念所服务的实体类型schema的论元已知且约束了取值范围（实体类型、概念类型）时，对于概念及其逻辑表达式的自动挖掘和生成提供了可能。下面以“产业链事件”的语义概念细分为例，探索在业务场景下如何自动做概念语义演化及沉淀业务规则。
IndustrialChainEvent
{
eventState事件状态枚举值[example：预计发生]
eventProduct涉事产品产品概念[example：白酒生猪粮食有色金属……]
eventTrend发生趋势趋势(枚举值)[example：上涨下降由涨转跌……]
eventExtent发生幅度百分数(枚举值)[example：大幅小幅缓慢]
eventIndicator涉事指标指标(概念)[example：价格销量产量库存成本……]
}
1.概念自动生成
对产业链事件设置分类层次，即自顶向下类型细分的优先级：
涉事指标->发生趋势->发生幅度->涉事产品->事件状态
定义概念事件生成命名模版：
[产品][指标][事件状态][幅度][趋势]+'事件'
如图15所示，按照分类层次优先级的顺序，对已经抽取沉淀的事件实例的论元要素值进行统计，能够将具有同样特征的事件实例归纳为一个概念事件。例如先根据指标类型，将产业链事件细分为：产能事件、销量事件、价格事件等。当每类事件积攒到一定规模时，根据变化趋势、发生幅度、产品类型等要素值，对概念进一步细分。注意在基于实例的统计对概念细分时，要注意剪枝，避免概念树过于庞大及拥有无实例的概念。
该模版在概念挖掘时，与“分类层次”结合应用，并需要排除可能生成的没有意义的概念如：“白酒小幅事件”
图15事件概念演化
2.概念事件逻辑表达式
如下面定义的dsl模版所示，可以在一定层级的概念上定义“概念等价式模版”，帮助子树上细分语义概念演化的同时，自动生成其逻辑语义表达式，用于对实例的推理和分类。
ifexisted&conceptEvent=[产品][指标][事件状态][幅度][趋势]+'事件'
3.概念语义应用
通过上述的概念挖掘模版，可以用同种方法对概念细化、概念语义关系中的论元要素槽位值进行替换，以演化生成其他概念间的语义关系，用于辅助事件实例间的关系挖掘。
已知：
白酒价格大涨事件-引发->白酒板块股价变化事件
白酒板块(板块概念)-关联产品->白酒(品类概念)
定义规则（其中X、Y为可替换的事件要素槽位值）：
X价格大涨事件-引发->Y股价变化事件
iifY[板块概念]-关联产品->X[品类概念]
演绎规则（X=有色金属，Y=有色金属板块）：
有色金属价格大涨事件-引发->有色金属板块股价变化事件
应用：
已知：x年x月黄金价格上涨-belongTo->有色金属价格大涨事件
推论：有色金属板块股价变化事件
多元时空认知架构，是对基于schema的实体关系定义，概念语义建模及事件行为的多元关系定义的综合应用，主要用于事理图谱、用户行为等场景。如保险产品、黑产等需要沉淀领域专家知识及通过领域知识对特定实例进行判例的场景，也可以运用多元时空认知架构的思路来描述其业务问题。
如图16所示，多元时空认知架构，体现在以下三个方面：
1.在模式层，定义知识的结构化表示（即schema）、语义规则、事理关系。其中将语义规则和事理关系也定义在模式层，是因为对于概念的等价逻辑，可以认为是对实例推理的一种模式、规则，而事理关系也是对具有共性的事件见关系的抽象，因此认为属于模式层。
2.在概念层，定义知识的语义认知体系，及对业务中所设计的常识或关于特定领域术语的概念体系建模，其中也包含了概念之间的二元常识关联。
3.在实例层，首模式层的约束，对非结构化文本做信息抽取，对于结构化的信息，也受概念层的语义约束，标准化、语义化为规范的属性值表示，以建立实体-实体、实体-概念间的语义关联。在实例知识标准化、结构化到图谱后，受模式层的语义规则、事理关系、业务逻辑的约束，对知识进一步挖掘和推理。
整个多元时空认知架构，将展示特定领域知识的结构范式、逻辑语义，并对该领域的概念常识和实例间的客观事实进行多维度的建模展示。
图16知识的多元时空认知架构（清晰大图可后台回复“图16”获取）
图17、图18展示了在前文所属实体关系定义、概念语义建模对多元行为知识结构化、语义化后，对于用户行为知识多视角的建模表示。
图17多元时空事件实体及关联
图18多元时空概念事件及关联
未来展望
在大模型的冲击下，知识图谱与大模型的融合成为一个有意义的探索方向。图谱本身是对数据/文本的压缩，通过知识建模定义的知识的结构规范，提炼出知识最本质的特征和语义。因此，schema本身可以作为一种强范式的instruction。结合大模型和in-contextlearning，很自然的能够想到，让大模型来帮助我们自动生成常识知识的schema定义（领域、业务实体特有schema仍然需要人工定义）、以schema作为prompt约束，生成高质量的结构化知识并沉淀到知识图谱。我们尝试了在知识建模、知识抽取、知识探测三个方向上图谱结构化数据与大模型的互动。
知识建模
知识抽取
知识探测
1.知识图谱综述——表示、构建、推理与知识超图理论
2.ASER:Towardslarge-scalecommonsenseknowledgeacquisitionviahigher-orderselectionalpreferenceovereventualities
3.Atomic:Anatlasofmachinecommonsenseforif-thenreasoning
4.AliCoCo2:Commonsenseknowledgeextraction,representationandapplicationinE-commerce