做任务网站源码,山东建设住建厅网站,网站建设将新建用户授权为管理员,苏州淘宝运营培训在“无需复杂图谱术语#xff0c;7个原则搞定Schema建模”一文中#xff0c;我们总结了知识建模最佳实践的7个指导原则。本文中#xff0c;我们将分基础篇、进阶篇#xff0c;针对不同业务场景的建模需求#xff0c;由浅及深讲解基于SPG的知识建模的方法和案例#xff0c…在“无需复杂图谱术语7个原则搞定Schema建模”一文中我们总结了知识建模最佳实践的7个指导原则。本文中我们将分基础篇、进阶篇针对不同业务场景的建模需求由浅及深讲解基于SPG的知识建模的方法和案例并涉及术语的解释。
本文档所提出的建模方案已经在OpenSPG做了对应的能力支持实现(或开发迭代中)。使用SPG读者也可以按本文的方法论对自己的业务问题简化抽象实施对领域知识的建模及对已有常识图谱的复用。 OpenSPG GitHubhttps://github.com/OpenSPG/openspg欢迎大家 Star 关注~下文中提到的知蛛平台是OpenSPG在蚂蚁内部的产品化平台。 如果你对知识图谱已有一定了解或实践可跳过基础篇(基础篇的“属性语义标化”依然值得一读)。 如果你的图谱涉及对业务类目体系、常识概念(如“行政区划”)的应用请仔细阅读进阶篇。
基础篇·实体关系设计
解决问题
解决数据的结构化表示包括实体各属性字段的规范定义及设计实体间的关系以便将数据最终构建为有别于传统数据表的图结构形式便于基于路径的多跳关系查找。
适用场景 业务场景关注于静态的体现物理世界或业务流中客观存在的“事实知识”; 已有结构化数据为主实体表、关系表、用户行为数据等的数据资产; 已有数据资产及业务场景能够抽象出传统ER关系图的数据建模可以直接套用实体-关系-属性的建模范式 业务对实体的类型存在划分如对用户的细分或对商户、门店的细分这种细分类是有限的一般只有两三种每种细分有特定的属性如线下门店才有poi。 业务对实体特定属性有枚举描述如“商户评级 [S, ABC]”业务应用只需要使用确定值将数据查出来但不需要基于属性传播。
术语定义
Schema
Schema是知识的“元数据”表达方式定义了知识的概念的属性关系属性及约束。主要实现了实体的结构化和实体间的关系的定义。
实体
物理世界或数字世界存在的事物是一个实体实体对应于数据表中的一行记录。
实体类型即实体的“schema”。它是对具有共同数据结构特征的一类数据实例的“元数据”模式定义。因此每一个实体类型都有自身特定的schema。同时实体类型存在上下位关系通过继承下位类拥有上位类已定义的属性和关系及其约束。在知识图谱平台中实体类型用于对具有共同数据结构的个体进行分组管理。可以将实体类型理解为对知识结构化表示的语法规范。如下表所示是对自然人的schema定义。 自然人模型Person示意 属性英文名 属性中文名 属性类型 属性值 是否必填 id id Text 12345xxx 是 name 姓名 String 张三 是 certId 证件号 String 330121xxx 否 certType 证件类型 枚举类型 Text(枚举约束) 身份证 否 birthday 出生日期 时间类型 STD.Date 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. 对于所属省、所属城市、所属区等若都建为实体拉边将造成“热点”(即某个点有巨量的边)为路径推理、采样带来困难。 属性易维护(值覆盖)、存储量小、不传播难以发现关联属性值相同的实体并没有显式的关联 关系有维护成本修改需要删边再拉边、储存量大、可传播(可加强图结构发现节点间的共边关系)、同关系类型的边过多(例如明星的社交关系作为关注者只有几百条边作为被关注者有千万级的边)对图学习的关系采样带来干扰(对图谱中的“热点”若采样策略为不限定边类型但对邻边限定数量随机采样时可能采到的都是数量大但重要性不大的点)
属性标化
为解决上述的属性/关系难以抉择及提高知识管理的效率及降低存储压力我们提出一种基于属性语义标化的建模方法并在知蛛OpenSPG在蚂蚁内部的产品化产品功能上已经交付可用。 属性语义标化能力体现为 用户在实体建模时不必纠结实体特征需要定义为属性or关系统统建模为属性 在属性类型选择时除了Integer、Float、Text三种基本类型外提供具有语义传播能力的语义类型(如内置的概念类型、内置的标准属性类型、用户自定义的实体类型或概念类型等) 在实例数据生产时用户当作属性维护如属性一样做知识导入的字段映射属性值修改直接覆盖 根据所选择的属性语义标化类型根据所填充的属性值语义以文本匹配、id匹配的方式系统自动构建“虚拟边” 系统自动创建及维护的虚拟边在查询效率、图算法邻边采样时与用关系建模、关系导入生产的物理边效果一致 当语义属性为多值时如一个user拥有多个手机号码用英文逗号分割。注意对于实体的某特征值是有限个一般10如关联邮箱、所属业务类目、银行账户等可以用属性语义标化建模来简化知识的管理维护。当特征值数量极大时如用户-消费-小程序id,依然建议使用关系建模。
属性语义化相关功能如表格所示 属性类型 类型细分 属性定义 用法及示例 内置类型 概念类型 通识概念 一个描述常识分类体系的树状知识库现覆盖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 时间标准化及时间的计算比较 内置类型 标准语义类型 空间类型 行政区划 国家-省-市-区四级目前仅支持中国行政区 知蛛平台集成了四级标准行政区划类目 以往业务为了表示结构化的标准多级地址一般会构建国家编码/国家、省编码/省、市编码/市、区编码/区共8个属性字段存在着属性的冗余储存。且plain text的文本属性不利于快速的发掘同地区的实体。 利用语义标化将表达实体行政区域特性的属性类型选择为“内置类型-概念类型-行政区划”数据生产时将属性值填充为能够识别到的最细粒度的行政区划单位平台提供兜底默认算子帮助地址的结构化理解及标准化 通过语义标化链指能力对于填充的行政区划属性值其上级类目是可追溯的如所在区县为“西湖区”时西湖区-位于-杭州市-位于-浙江省-位于-中国是已维护在“行政区划”类目树上的 平台能够自动拉边维护实体(如poi、aoi、门店等)到特定省、市、区县的关系并实现不同粒度下所属行政区划的查询。 经纬度坐标点 (Position) (经度,纬度) 同POI计算发现球面距离小于epsilon 经纬度范围 (Position1Position2地理区块四边形左上-右下坐标 判断一position是否在该范围内 自定义属性类型 实体/概念 平台内置的概念类目体系、可传播的语义属性类型无法完全满足特定业务的建模需要因此用户可以将属性类型赋值为“内置类型-自定义属性类型”则在高级配置页面选择将属性标准化为自定义的一个实体类型(默认用id链指)或概念类型(默认用概念名称链指)。 如果所示对于“公司事件”实体拥有两个语义标准化属性的应用——1.主体选择为“工商机构”实体则能够利用平台id链指能力自动拉边到确定的“工商机构”实例2.事件的客体属性值可能是“产品”或“金融指标”则能够利用平台的语义化能力帮助后续的要素链指挂载。 其他待开发 的属性 数量类型 数额 度量/指标类型数值表示 对度量/指标类型标准化 同一数量类型的比较 区间数值合法性检验 指标 区间数值属性 年龄 年份
表3 属性语义标准化类型
建模步骤及案例
实体关系设计是为具有同样结构化特性即有同样的特征要素的实体定义的实体类型的schema并建立实体类型间的关系。实体schema包含实体类型的命名、属性定义、属性类型及属性值的约束关系schema约束关系主体和关系客体的实体类型。我们推荐在启动一个新的图谱项目时按照以下步骤进行实体-关系建模
CoreKG schema 复用
schema的设计具有主观性为了消除这种主观偏差特别是降低跨图谱知识融合的复杂性我们从过去的业务图谱设计经验中总结了蚂蚁场景下常见的实体类型schema并商家到corekg核心图谱当业务涉及到这些实体数据时可以直接对实体schema及数据引用/复用减少重复建设快速启动新的图谱项目。
如果为了业务安全/数据隔离等的考虑业务需要自定义及构建自己的实例数据我们也推荐对于corekg已有的实体类型用户可以对其schema设计特别是属性的定义和命名参考借鉴。 图3 corekg核心实体定义
实体关系设计
参考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谓词关系实体融合达到主体分类一致的目的。
语义标准化
参考“属性语义标化”章节的内容优化属性/关系的定义将可以标化的属性选择为标准属性类型对于适用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. 实体 概念 实体 什么是概念 概念是对具有同样特征的实例的抽象是语义上/认知上能够被“归类”为同一类型的实例的集合。 概念是符号化的但领域内的人对它这个符号的语义是有共识的。 概念带有领域/业务/常识的主观或经验是人为定义的概念的内涵/语义是相对恒定的。 概念的符号体现了自身的语义概念之间构建的语义关系边 (白酒板块事件 -主体- 白酒板块白酒板块-产品-白酒,白酒-原料-粮食猪瘟疫情事件-影响-猪肉价格上涨形成了描述领域常识的语义网络。以上举例的三元组中的S和O都不是具体的、特定的实例而是对同一类实体及同类实体所具备共有特性的概括) 可以先简单粗暴的认为“概念”是没有“属性”的除了编码、别名、描述 事件抽取出的mention无法与实体库对齐的文本类型要素非时间、非数值都可以认为是概念 实体类型是对拥有同样数据结构/论元要素的数据的定义 实体实例是id化的唯一存在的实例。 实体是客观的存在实体的特征是动态变化的。 实体拥有特异的属性/关系定义。例如某个事件的发生事件、地点、主体、客体某部手机的型号、屏幕、尺寸、内存等参数。 什么应该被定义为概念 类目概念对具有同样特征的一类实体的语义抽象可以来自业务类目、领域的taxonomy比如POI类目、MCC类目等。 常识概念在特定领域(概念类型)下人们有共识的无歧义短语比如杭州市、手机、中秋节。 原子概念一般存在于L0-L2级的概念概念名是不可拆分的表达完整语义的核心词一般直接来源于领域常识术语。如产业链事件、芯片、有色金属。业务类目、领域的分类体系(职业分类、企业分类、品类、产业分类、NER_Label、实体类型、属性名称、边关系类型、人群标签、星座、血型、人种、民族、学历、奖项、各种title都是概念。———————————————————————— 复合概念在一个核心词概念上增加语义修饰限定该限定可以是概念, 也可能代表特定实例例如“白酒”“产品价格上涨” 白酒产品价格上涨 “杭州” “互联网”“上市公司” 杭州互联网上市公司 腰封偏好 高日活 支付宝账户 高日活的腰封偏好支付宝账户 “阿里巴巴”“公司” 阿里系公司 “华为”“手机” “华为手机” 复合概念 可以拆解为等价的谓词逻辑表达式 品牌不是“概念”它是特定厂商定义的一个IP本身不具备认知的层级体系。如果品牌有类目体系则品牌类型是概念。 物理世界真实存在的一个个体蚂蚁内部特定的一个账户、一个商家、一个供给内容是实例。 概念能够表达那些语义 1.对实体进行细分类完成schema无法体现的更详细的语义 通过逻辑表达式定义的规则自动完成“复合概念”的生成及帮助推理属于该集合的实例 2.提供属性的标准化及语义化则属性值不再只是一个plain text而是依靠概念语义网络可关联可追溯的子图。 对多跳上下游产业链关系、上下位产品品类的召回进行处理 实体类型的schema是在知识管理的角度来选则粗粒度的“类型”。
表4 概念和实体的区别
建模步骤及案例
我们以事理图谱的概念语义建模为例介绍用户自定义概念体系并使用概念为实体做细分类的方法。
事件体系语义建模
在事理图谱场景下需要金融事件相关的各种事件类型建模包括宏观的行业时间、国家政策事件也有微观的局部地区的牲畜疫情事件、个股涨跌事件、公司事件宏观事件可能影响微观事件微观事件的发生可能引发另一个微观事件。
金融场景下包含的事件类型十分庞大每种事件在业务上所关注的事件要素是不同的。同时业务会对同一大类的事件继续语义细分以便套用业务逻辑去做风险预警、评级例如图6所示公司事件下会细分出工商信息变更事件、高管变动事件等高管变动事件下又有实控人变更、股东跑路、实控人涉诉等。当事件类型语义细化到很细节的粒度时不再涉及事件要素的新增即元数据结构上没有变化。 图6 事件概念体系示意局部
因此如图7所示在知识建模时将事件的结构化表示所需要的schema定义和业务上的事件认知分类体系解耦为两个独立的树状体系再使用标准谓词、逻辑规则等构建结构与语义的对应关系。具体步骤如下 图7 事件概念体系构建及管理
1.定义实体类型schema。
对于事件的结构化表示先构建一个定义所有事件共有事件要素的schemaEvent。
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结构约束和最终语义标准化的事件实例的生产过程推演。
对于图7中“贾跃亭跑路”事件其schema是CompanyEvent则在数据结构上能够建立“贾跃亭跑路-涉事公司-乐视”等事实描述。而对该事件的细分类型基于算法模型或规则推理挂载到概念树的1个或多个节点。对于该例既是一个“经济犯罪事件”又是一个“董监高事件”。
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 常识概念建模及应用
保险语义网络建模
保险产品图谱是为了将保险业务中对保险产品的业务分类类目、领域标准分类、保险产品的各个重要特性建模并将对每个业务自定义的产品标签概念如“心血管保障好”背后关联的产品特性、产品分类的逻辑固化到图谱中进而使用图谱的路径推理能力帮助具体保险产品实例所属类型的判断。
如图10中显示了对保险产品的schema定义业务对“产品渠道”、“保障风险项”、“人群特征”、“产品分类”、“特色保障”等属性都做了语义标准化即这些属性的取值都受到某个概念类型体系的约束而这些概念类型体系是业务根据自身领域的各个类目树预先定义的。
图11中在模式层定义了保险产品schema专属的分类体系——“产品类型”概念类型在概念层构建了各个业务概念类目体系及这些概念间的语义关联。最终在实例层演绎了如何准对一个具体保险产品的语义字段套用概念语义网络及逻辑规则实现对实例产品类型的推理。 图10 保险产品语义网络构建及应用 图11 保险产品语义网络构建及应用
意图语义网络建模
意图图谱的核心本体主要共包含四类节点意图,功能词,产品词,义原和三类关系isA,Consist,Has如图所示。具体来说“意图”描述了用户需求背后的动机主要由一个功能动词动词和一个产品实体名词组成动宾结构例如“打网约车”、“买咖啡”和“维修家电” 等。此外“功能动词”和“产品实体”可以用更细粒度的Hownet义原表示拆分为最基本的语义单位如“movie ticket|电影票 {coupon|票证, look|看, shows|表演物}”。
构建意图图谱主要有两个作用
1.功能词、产品词、义原实体可以丰富意图的语义信息
2.拥有相同功能词/产品词/义原的意图之间建立起新的关联关系。 图12 意图概念图谱构建及应用 本文主要介绍了在相对静态的事实关联场景下的知识图谱建模实践分别介绍了实体语义设计和概念语义建模2种建模方式未来我们还将发布一篇高阶的实践内容。如果你的图谱涉及对带有时空信息的行为事件的表达或建模场景下的业务规则、专家经验需要对所定义“概念”的内涵和外延有计算机可处理可计算的逻辑语义解释高阶篇中有你所需知道的一切。 作者袁琳博士 蚂蚁集团高级算法工程师 袁琳蚂蚁集团高级算法工程师浙江大学计算机应用技术博士。主要研究方向是知识工程图谱构建。最近一年的工作聚焦于大语言模型与图谱构建的交叉方向包括基于schema结构和语义的prompt engineering和统一信息抽取大模型的研发。
关注我们 收货更多技术干货
微信公众号SPG知识图谱 官网http://spg.openkg.cn Githubhttps://github.com/OpenSPG/openspg
