在“知识图谱之本体结构与语义解耦——基于OpenSPG的建模实践（上）”一文中，我们从实体关系设计和概念语义建模2种场景，讲解了基于SPG的知识建模的方法和案例。

本文中，我们将继续讲解多元关系架构场景中的知识建模实践。如果你的图谱，涉及对带有时空信息的行为事件的表达，或建模场景下的业务规则、专家经验，需要对所定义“概念”的内涵和外延有计算机可处理可计算的逻辑语义解释，高阶篇中有你所需知道的一切。

🌟 OpenSPG GitHub：https://github.com/OpenSPG/openspg，欢迎大家 Star 关注~

下文中提到的知蛛平台是OpenSPG在蚂蚁内部的产品化平台。

本文档所提出的建模方案，已经在OpenSPG做了对应的能力支持实现(或开发迭代中)。使用SPG，读者也可以按本文的方法论对自己的业务问题简化抽象，实施对领域知识的建模及对已有常识图谱的复用。

高阶篇·多元关系架构

01 术语定义

多元关系

根据论元个数把关系分为：一元关系、二元关系和多元关系

• 一元关系：表示实体/概念的性质、属性等，有翅膀(鸟)
• 二元关系：表示两个实体之间的关系。例如：中国-首都->北京
• 多元关系：多个论元共同决定的事实

传统的知识图谱建模，主要解决静态事实、常识的表示，以三元组表示两个实体间的二元关系为主。但现实中的事件、规则、场景知识，是多元关系。即一个事实的成立，是由多个元素共同决定的（如用户交易行为，是对用户在确定时间、地点下对产品的交易行为的描述）超图超图(hypergraph)是一种更加抽象的图，与传统图的区别主要在于超边可以同时包含多个(>2)结点。超图通过引入超边关系，能够完整表达各种复杂的关系类型。事件事件是加入时间、空间，区分行为主体、客体的实体类型，以事理图谱和用户行为事件为典型应用场景，是对动态行为的建模，需要反应在不同时间点、时间区间上事物的状态。

事件类型对实体类型补充了“随时空动态变化”的信息和“事物发展的规则”（因果、顺承等关系），是一种多元知识。可以回答诸如“怎么了”，“接下来会怎么样？”，“为什么”，“怎么做”的一系列问题；例如表达“用户在工作日点外卖，在周末用叮咚买菜”——“那么可以在工作日推荐外卖品牌，在周末推荐厨具品牌”。

概念的内涵与外延概念的内涵就是指反映在概念中的对象的本质属性或特有属性。概念的外延是指具有概念所反映的本质属性或特有属性的对象，即概念的适用范围。

在进阶篇的概念建模，我们主要描述了如何基于领域常识或业务知识，构建树状的概念类目，以便于概念的复用、加强实体间语义关联。同时我们应该注意到，如果没有定义概念的内涵与外延，那么“概念”只是一个人工定义的符号，无法起到语义上的可解释、推理的能力。对于概念的等价语义表达式，在owl、rdf等框架中，一般使用一阶逻辑表达式实现。

同样，我们也在知蛛平台上实现了对“分类概念的等价逻辑表达式”的实现。概念的等价逻辑表达式，体现为当实例知识的多个特征要素满足一定值约束时，该实例可以被推断属于某个概念。概念的等价语义表达式的定义，也属于一种多元关系。

02 解决问题

如图13，是一个在支付宝账单中典型的用户出行行为事件。每个出行行为，体现为特定用户在特定的出发时间从出发地点起始并在特定到达时间抵达特定地点的行为事件。因此每一个行为事件记录，都是一个多元关系。在数据表中的行为表达是完整无歧义的。但如何将它图结构化呢？

如前文提到，超图是解决多元关系表示的图结构，但显然，超图不是一种直观的对数据结构化和可视化的方法。而直接将超图表示转换为行为事件要素间的三元组关联，可能是有损的转换，例如小蚂并没有从灵隐寺出发并到达浙江大学的行为。但传统的图谱三元组表示却可能导致这样的歧义。

因此我们提出兼容与超图结构互相无损互转㩐的时空行为事件表示方法，主要体现为将时空多元关系（即事件或行为）本身抽象为一个事件节点，并定义事件节点与其各事件要素间的关联。则事件节点本身即为超边的具像化，能够的在spo表示与超图表示间进行结构化知识的无损转换。

同时，对于规则的表示，体现概念语义内涵和外延的逻辑表示，都有提供了相应的解决方案。在本篇中，我们将介绍如何综合使用实体关系建模、概念语义建模及多元关系建模，来对一个领域内的知识做整体的认知和架构。

图13 多元关系建模难点

03 适用场景

• 多元时空事件：对用户行为、金融事件、保险理赔、业务流程等，受时间和空间(具体的地点、poi、业务流程工段位等)约束，由多个（>2）要素共同确定的事实，提供简洁而统一建模范式，在知蛛平台，对该类知识的储存管理、结构化抽取、查询、可视化、包含时空信息的图学习等进行了支持和优化。
• 概念的语义定义：目前对事件/实体的分类仍然较黑盒，往往业务类目体系是领域专家/运营自定义的类目体系，导致只有定义者/生产者自己才能理解标签类目的内涵，专家经验没有存在图谱中，当要跨域复用时消费者需线下咨询生产者。因而定义概念的等价逻辑规则，结合概念层类目体系+概念的语义规则定义，帮助具体业务场景下的知识决策管理。
• 多视角的知识建模架构：如背景章节所述，已有的研究或工作，都只解决了事件图谱、事理（概念）图谱或事理常识中特定一类的表示，它们要么专注于对单个实例事件、实例知识及其关联的事实关系的刻画；要么在相对抽象的层次，描述基于常识的事理关系。蚂蚁场景中需要对从实例到概念，从事实到常识的整体架构。本章介绍的时空多元知识建模，也从事件实例表示、事件概念表示，事件实例所关联客观事实关系及事件实例关联，事件概念关联常识及事件概念间因果顺承等事理关系的表示，等视角的知识建模架构解决方案。使用该方案建模，能够快速的帮助从概念事件/时间区间/空间范围的约束或约束的组合查询实例事件，从实例事件的关联中发掘抽象事理关系，从事理关系反向推理预测事件的发展。

04 建模步骤及案例

事件表示

支付宝覆盖的数字生活场景及新闻事件中的金融事件有不计其数的事件类型；导致在知识抽取和管理时，每新增一类事件就需要设计一个新的Schema。算法上计划通过统一的SPO抽取来解决这个问题。但因为数据入图谱仍然需要依赖Schema，所以产品上需要有一套通用的事件建模规范来简化事件建模的复杂性。

如表5所示，我们对多元时空行为事件定义了统一的建模框架，将事件的属性分为基本要素、时间要素、空间要素、主体要素和客体要素。

• 基本属性：定义一个新的事件类型时默认的属性，不能删除，包括：主键id、name、description。
• 时间要素：对事件发生时间、报道时间、起始时间、终止时间、状态变化时间等的定义，时间一般被标准化为时间戳类型。
• 空间要素：对事件发生地点、起始地点、终止地点等的空间要素的定义，蚂蚁场景下的空间要素一般为确定的AOI/POI实体，标准化的行政区划概念或格式化表示的经纬度坐标点。
• 主体要素：事件的主体要素是指事件的执行者、行为人；如公司事件的主体是一个工商企业，用户行为事件的主体是2088开头的支付宝账户id所代表的支付宝用户。
• 客体要素：事件的客体是事件的被执行对象。例如：“北向资金净买入赛托生物526.97万元，赫美集团62.79万元 ”中，主体为：北向资金，客体为：赛托生物，赫美集团。一般金融事件的客体可能为：公司、板块、股票、基金等，用户行为事件的客体可能为：产品、品牌、意图、服务、门店等。需要注意，一个事件的主体或客体可能有多个，且可能属于不同的实体/概念类型（见图14）。

表5的框架，介绍了能够覆盖蚂蚁场景下大部分事件/行为建模的要素定义；在面向特定业务场景的行为事件建模时，建模者根据需要选择表5中预定义的要素及增加各种需要的要素定义，如表6和表7分别给出了在对金融事件和用户行为事件建模的案例。

要素类型	事件要素	解释	事件要素值类型（实体）	事件要素值类型（概念）
基本要素	id	事件唯一id		概念事件的名称即为其id
基本要素	name	事件标题，行为事件可以没有名称
基本要素	description	事件描述摘要
时间要素	happenTime	发生时间	年份、时间点年份、时间点年份、时间点	时间段标签（如：上午、傍晚、下午、周末）特殊节日概念（如：清明节、国庆节）
时间要素	startTime	起始时间
时间要素	endTime	终止时间
空间要素	happenLoc	发生位置	经纬度坐标点、POI、AOI	行政区划概念行政区划概念行政区划概念
空间要素	startLoc	起始位置	经纬度坐标点、POI、AOI
空间要素	endLoc	终止位置	经纬度坐标点、POI、AOI
主体要素	eventSubject	事件主体	uid、公司id等	公司类型、品类等概念
客体要素	eventObject	事件客体	产品、门店、小程序、公司、品牌、股票、基金等	公司类型、品类、基金板块、常识概念等
客体要素	intent	行为意图	意图概念	意图概念
客体要素	behavior	行为类型	交易	搜索

表5 事件定义框架

产业链事件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%	否
	......	......	......		......

表6 金融事件-产业链事件定义

用户出行行为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	否

表7 用户行为事件-用户出行事件定义

多要素建模链指

无论是在金融事件还是用户行为事件，其事件要素及同一个事件要素所关联的实体/概念都可能是多值的。如图14展示的“3月20日永安林业领涨”事件，其关联的事件客体有“林业”和“永安林业”两个节点，其中“林业”是一个“板块”概念，“永安林业”是一个股票实体；再例如“张三购买咖啡”行为事件，其客体属性有“少糖星冰乐”和“抹茶拿铁”两个实体。为了满足对事件多要素、要素多值类型的建模要求，在知蛛平台提供以下能力：

• 多要素建模：每种时间要素可以定义多个属性，如对时间要素定义发生时间、结算时间等；
• 要素的多值类型定义：对于同一个要素，可以将其语义属性类型选为多个类型。例如个股/上市公司上涨事件，所关联的客体值域可选[板块、股票]。
• 多值链指能力：在确定的属性上（如“个股/上市公司上涨”的“关联”属性，“用户消费行为”的“商品”属性）绑定链指算子，并在算子的实现逻辑中，支持对多类型值的链指。例如，对于“3月20日永安林业领涨”，结构化抽取结果中包括：{关联: 林业@板块, 永安林业@股票}，则事件节点本身通过链指拉边，关联到属性值对应的实体对象、概念节点上。
• 语义关联：依托基础篇中所提到的属性语义标化能力，能够在事件实例间建立广泛的语义关联。例如，对于“张三购买咖啡事件”，其发生时间是一个标准化的时间戳值。在物理上，它并不是一个数据上存在的节点，而是利用时间语义标准化能力，能够发掘发生时间在一定时间范围内的事件，进而建立其事件间的“同时间”共边关系（同理，时间间也可建立“同人”、“同地点”、“同商户”等关系）。事件之间的语义共边关系是不胜枚举，难以穷极的，用本文建模方式重的语义标准化拉虚拟边的方式，既能广泛的构建和挖掘事件的语义关联并用于图算法的子图特征采样，又能降低物理储存的压力。

图14 事件多要素多主体链指

概念语义定义

1. 分类定义没有显示化：目前对事件/实体的分类体系建模仍然是较黑盒的符号性的定义，只有建模者自己才能理解和解释概念的意义。因此，结合知蛛的产品功能实现，定义了用于概念管理的标准谓词，及概念等价语义规则表达方法。
2. 建模门槛高：由于“概念语义建模”是我们的建模方法中为了与结构化表示解耦而提出的一种解决方案，在涉及多元时空知识的表示时，需要与事件建模搭配使用，导致对新用户有一定复杂性。为此，我们以事理图谱的概念定义、概念语义演绎推理为例，介绍实体schema与概念体系及逻辑规则的结合应用，一起完成多维度的知识认知架构。

事件概念管理

即通过对实体分类体系和领域知识/常识中的通用语义元素的定义，以树状层级体系进行组织，自顶向下的体现实体语义的细分。

谓词定义	谓词语义	举例
实体类型-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->杭州市

表8 概念建模相关语义谓词定义

概念事件的逻辑语义

对于一个“分类概念”，即在元概念上限制了该概念体系特定的用于某个schema约束的实体类型的语义细分，支持定义等价的逻辑表达式，定义该概念的语义内涵。当概念定义了逻辑表达式后，可以根据逻辑表达式进行双向推理：

• 基于规则的实例细分：当算法分类只分到较粗粒度，或没有接概念类细分算子，可以使用逻辑表达式根据实例数据各属性/关系的值，帮助推断出实例的细分类型；
• 一致性检测：对于已知所属概念细类的实例，用逻辑规则帮助检验其个字段属性是否满足概念的定义。

例如，下例是对“汽车整车销量事件”的语义内涵的定义（通过dsl语言）汽车整车销量事件（Concept） <=> if s isInstanceOfIndustrialChainEvent and s.产品 == 汽车整车 and s.指标 ==销量

1Define (s:EL.IndustrialChainEvent)-[p:belongTo]->(o:汽车整车销量事件) {
2  GraphStructure {
3  s : Event 
4      Rule {
5        p: s.eventProduct == '汽车整车' and s.eventIndicator == '销量'
6       } 
7    }
8}

概念演化挖掘

在具体业务场景中，概念类目树随着业务语义的细分，可能无限膨胀。此时人工对概念进行定义，特别是定义概念的等价逻辑，变得繁琐。当分类概念所服务的实体类型schema的论元已知且约束了取值范围（实体类型、概念类型）时，对于概念及其逻辑表达式的自动挖掘和生成提供了可能。下面以“产业链事件”的语义概念细分为例，探索在业务场景下如何自动做概念语义演化及沉淀业务规则。

1IndustrialChainEvent
2{
3eventState 事件状态 枚举值       [example：预计 发生]
4eventProduct 涉事产品 产品概念 [example：白酒 生猪 粮食 有色金属 ……]
5eventTrend 发生趋势 趋势(枚举值) [example：上涨 下降 由涨转跌 ……]
6eventExtent 发生幅度 百分数(枚举值) [example：大幅 小幅 缓慢 ]
7eventIndicator 涉事指标 指标 (概念) [example：价格 销量 产量 库存 成本 ……]
8}

1. 概念自动生成

对产业链事件设置分类层次，即自顶向下类型细分的优先级：涉事指标->发生趋势->发生幅度->涉事产品->事件状态

定义概念事件生成命名模版 ：[产品][指标][事件状态][幅度][趋势] + '事件'

如图15所示，按照分类层次优先级的顺序，对已经抽取沉淀的事件实例的论元要素值进行统计，能够将具有同样特征的事件实例归纳为一个概念事件。例如先根据指标类型，将产业链事件细分为：产能事件、销量事件、价格事件等。

当每类事件积攒到一定规模时，根据变化趋势、发生幅度、产品类型等要素值，对概念进一步细分。注意在基于实例的统计对概念细分时，要注意剪枝，避免概念树过于庞大及拥有无实例的概念。

该模版在概念挖掘时，与“分类层次”结合应用，并需要排除可能生成的没有意义的概念如：“白酒小幅事件”

图15 事件概念演化

1. 概念事件逻辑表达式

如下面定义的dsl模版所示，可以在一定层级的概念上定义“概念等价式模版”，帮助子树上细分语义概念演化的同时，自动生成其逻辑语义表达式，用于对实例的推理和分类。

• 给定规则表示模版生成逻辑表达式

 1if existed &conceptEvent = [产品][指标][事件状态][幅度][趋势] + '事件' 
 2&conceptEvent.name =  [&产品][&指标] + '事件'
 3Define (s:EL.IndustrialChainEvent)-[p:belongTo]->(o: &conceptEvent ) {
 4  GraphStructure {
 5  s : Event 
 6      Rule {
 7        p: s.eventProduct == &产品 and s.eventIndicator == &指标
 8       } 
 9    }
10}

1. 概念语义应用

通过上述的概念挖掘模版，可以用同种方法对概念细化、概念语义关系中的论元要素槽位值进行替换，以演化生成其他概念间的语义关系，用于辅助事件实例间的关系挖掘。

已知：

• 白酒价格大涨事件 -引发-> 白酒板块股价变化事件
• 白酒板块(板块概念) -关联产品-> 白酒(品类概念)

定义规则（其中 X、Y为可替换的事件要素槽位值）：

• X价格大涨事件 -引发-> Y股价变化事件
• iif Y[板块概念] -关联产品-> X[品类概念]

演绎规则（X=有色金属，Y=有色金属板块）：

• 有色金属价格大涨事件 -引发-> 有色金属板块股价变化事件

应用：

• 已知：x年x月黄金价格上涨 -belongTo->有色金属价格大涨事件
• 推论：有色金属板块股价变化事件

多元时空认知架构多元时空认知架构，是对基于schema的实体关系定义，概念语义建模及事件行为的多元关系定义的综合应用，主要用于事理图谱、用户行为等场景。如保险产品、黑产等需要沉淀领域专家知识及通过领域知识对特定实例进行判例的场景，也可以运用多元时空认知架构的思路来描述其业务问题。

如图16所示，多元时空认知架构，体现在以下三个方面：

1.在模式层，定义知识的结构化表示（即schema）、语义规则、事理关系。其中将语义规则和事理关系也定义在模式层，是因为对于概念的等价逻辑，可以认为是对实例推理的一种模式、规则，而事理关系也是对具有共性的事件见关系的抽象，因此认为属于模式层。

2.在概念层，定义知识的语义认知体系，及对业务中所设计的常识或关于特定领域术语的概念体系建模，其中也包含了概念之间的二元常识关联。

3.在实例层，首模式层的约束，对非结构化文本做信息抽取，对于结构化的信息，也受概念层的语义约束，标准化、语义化为规范的属性值表示，以建立实体-实体、实体-概念间的语义关联。在实例知识标准化、结构化到图谱后，受模式层的语义规则、事理关系、业务逻辑的约束，对知识进一步挖掘和推理。

整个多元时空认知架构，将展示特定领域知识的结构范式、逻辑语义，并对该领域的概念常识和实例间的客观事实进行多维度的建模展示。

图16 知识的多元时空认知架构

图17、图18展示了在前文所属实体关系定义、概念语义建模对多元行为知识结构化、语义化后，对于用户行为知识多视角的建模表示。

多元时空知识可包含多元时空事件实体以及多元时空概念事件。多元时空事件实体对应于客观存在的多元知识，而多元时空概念事件是对客观存在的具有共性的多元知识的抽象。

以用户行为为例，“张三下午3点在星巴克购买了一杯咖啡”这是一个多元事件实体，“年轻白领在工作日的下午点咖啡”这是一个概念事件，是基于大量的相似的实体多元知识抽象而来。事件实例的至少一个论元对应客观存在的事物，如行为主体对应具体的某个人，而如图18，概念事件的论元均对应抽象知识。

可以将多元知识建模为一个“超边”节点，体现其多个论元要素的关联。以图17中的“观影事件”为例，其行为主体论元的实例值为“李四”，而图谱中已经具有节点李四（即自然人实体节点实例），则将“观影事件”这一事件实例与节点李四进行边连。

又例如，该事件的行为类型要素的值为“观影”，而图谱中已经存在行为类型的各种概念节点，则可以将“观影事件”关联到“观影”概念节点。同时，“观影”概念节点又存在与其他事件间的关联，进而建立起了相同行为事件实例间密集的邻居关系。

多元知识节点实例之间也可以具有边连。以事件为例，多元知识节点实例间的边可以表示以下关系中的一种或多种：顺承、因果、伴随以及组成。其中，顺承表示头节点事件时间上先于尾节点事件发生。因果表示头节点事件是导致尾节点事件发生的原因。伴随表示头节点事件和尾节点事件通常伴随、共现发生。组成表示头节点事件是尾节点事件的一部分。

通过对多元时空行为知识的概念化，有助于进一步挖掘多元知识中的规律，进行信息预测。概念事件间的边与事件实体类似，可以是顺承、因果、同主体等等。以图18为例，图中的下午茶事件以及观影事件为两个概念事件，其具有顺承关系，进而构成一个反应概念事件间关联的子图。需要说明的是，实体事件间的关系体现的是单个具体事件间的关联，而概念事件间的关系体现的是通用知识或常识的沉淀。

图17 多元时空事件实体及关联

图18 多元时空概念事件及关联

由于在多元知识的模式层进行schema定义时，对各个事件要素的类型和格式做了约束，因此对于时空信息标准化后，能够方便的基于数值计算或行政区划的概念层级进行推理，确定事件实例之间的“同主体”、“同地点”、“同时间”等语义关系，这些语义关系也可以作为图采样结果中的边关系。知蛛提供了对各种组合条件下的子图查询和子图采样，并得到查询结果的可视化子图。

由于事件间的语义关系是难以穷尽的，因此在工程实现上，并不对事件间的同主体、同时间、同地点等关系边做物理存储（同样对于标准化的语义属性值其实也并不存在物理节点），而是基于查询条件进行图采样，并实时或按需进行语义化计算确定采样结果中各事件间的语义边，有效避免了图谱中边“爆炸”的问题，节约了存储空间。

未来展望

在大模型的冲击下，知识图谱与大模型的融合成为一个有意义的探索方向。图谱本身是对数据/文本的压缩，通过知识建模定义的知识的结构规范，提炼出知识最本质的特征和语义。因此，schema本身可以作为一种强范式的instruction。

结合大模型和in-context learning，很自然的能够想到，让大模型来帮助我们自动生成常识知识的schema定义（领域、业务实体特有schema仍然需要人工定义）、以schema作为prompt约束，生成高质量的结构化知识并沉淀到知识图谱。我们尝试了在知识建模、知识抽取、知识探测三个方向上图谱结构化数据与大模型的互动。

01 知识建模

02 知识抽取

03 知识探测

作者：袁琳博士，蚂蚁集团高级算法工程师，浙江大学计算机应用技术博士。主要研究方向是知识工程，图谱构建。最近一年的工作聚焦于大语言模型与图谱构建的交叉方向，包括基于schema结构和语义的prompt engineering和统一信息抽取大模型的研发。

关注我们 收货更多技术干货 微信公众号：SPG知识图谱 官网：http://spg.openkg.cn Github：https://github.com/OpenSPG/openspg

本文由博客一文多发平台 OpenWrite 发布！