知识图谱系列(4):查询与推理技术
1. 引言
知识图谱的查询与推理技术是知识图谱应用的核心,它们使得知识图谱从静态的知识库转变为动态的知识服务系统。通过查询技术,用户可以从海量的知识图谱中快速检索所需的信息;通过推理技术,系统可以基于已有知识发现隐含的关系和规律,回答复杂的问题,甚至预测未知的事实。这些能力极大地扩展了知识图谱的应用范围和价值。
2. 知识图谱查询语言与方法
知识图谱查询是指从知识图谱中检索特定信息的过程,是知识图谱应用的基础。为了有效地查询知识图谱,需要专门的查询语言和方法。本节将详细介绍知识图谱查询语言与方法,包括主流查询语言、查询模式、查询优化技术以及查询接口设计。
2.1 知识图谱查询语言
知识图谱查询语言是用于表达查询意图、检索知识图谱中信息的形式化语言。根据知识图谱的存储模型不同,主要有以下几种查询语言:
2.1.1 SPARQL
SPARQL(SPARQL Protocol and RDF Query Language)是W3C推荐的RDF查询语言,也是语义网和知识图谱领域最广泛使用的查询语言。
基本特点:
- 基于图模式匹配,通过三元组模式匹配RDF数据
- 支持变量绑定、过滤、聚合、排序等操作
- 提供丰富的查询功能,包括SELECT、CONSTRUCT、ASK、DESCRIBE等查询形式
- 支持联合查询、可选查询、子查询等复杂查询模式
- 与RDF和OWL等语义网标准紧密集成
SPARQL查询示例:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX dbo: <http://dbpedia.org/ontology/>SELECT ?name ?birth ?death ?description
WHERE {dbr:Albert_Einstein dbo:birthDate ?birth ;dbo:deathDate ?death ;foaf:name ?name ;dbo:abstract ?description .FILTER (LANG(?description) = 'en')
}
上述查询从DBpedia知识图谱中检索爱因斯坦的姓名、出生日期、死亡日期和英文描述。
SPARQL 1.1扩展:
SPARQL 1.1进一步扩展了查询功能,增加了聚合函数(如COUNT、SUM、AVG等)、子查询、否定表达式、属性路径等特性,使查询更加灵活和强大。
2.1.2 Cypher
Cypher是Neo4j图数据库的查询语言,专为属性图模型设计,具有直观、易读的语法。
基本特点:
- 声明式查询语言,关注"查什么"而非"怎么查"
- 使用ASCII艺术风格表示图模式,直观易读
- 支持属性图模型的节点、关系和属性查询
- 提供丰富的函数和操作符,支持复杂查询
Cypher查询示例:
MATCH (person:Person {name: "Albert Einstein"})-[:BORN_IN]->(birthPlace),(person)-[:DIED_IN]->(deathPlace)
RETURN person.name as name, birthPlace.name as birthPlace,person.birthDate as birthDate, deathPlace.name as deathPlace,person.deathDate as deathDate
上述查询检索爱因斯坦的姓名、出生地、出生日期、死亡地和死亡日期。
2.1.3 Gremlin
Gremlin是Apache TinkerPop框架的图遍历语言,支持多种图数据库,适合复杂的图遍历操作。
基本特点:
- 命令式查询语言,基于图遍历的概念
- 支持命令式和函数式编程风格
- 可嵌入多种编程语言,如Java、Python、JavaScript等
- 提供丰富的图遍历操作,如过滤、转换、聚合等
Gremlin查询示例:
g.V().has('name', 'Albert Einstein').as('person').out('BORN_IN').as('birthPlace').select('person').out('DIED_IN').as('deathPlace').select('person', 'birthPlace', 'deathPlace').by('name').by('name').by('name')
上述查询检索爱因斯坦的姓名、出生地和死亡地。
2.1.4 GraphQL
GraphQL是Facebook开发的API查询语言,虽然不是专为知识图谱设计,但因其灵活性和易用性,也被用于知识图谱查询。
基本特点:
- 客户端指定查询结构,服务端返回相同结构的数据
- 支持嵌套查询,一次请求获取多层关系数据
- 类型系统强大,支持自定义类型和接口
- 提供实时订阅功能,适合动态数据
GraphQL查询示例:
{person(name: "Albert Einstein") {namebirthDatebirthPlace {namecountry}deathDatedeathPlace {namecountry}}
}
上述查询检索爱因斯坦的姓名、出生日期、出生地(包括国家)、死亡日期和死亡地(包括国家)。
2.1.5 SQL扩展
一些知识图谱系统也提供SQL扩展,使用类似SQL的语法查询图数据。
基本特点:
- 基于熟悉的SQL语法,学习成本低
- 通常添加特定的图操作扩展
- 适合关系型数据库和图数据库混合环境
SQL扩展查询示例:
SELECT p.name, b.name AS birthPlace, p.birthDate,d.name AS deathPlace, p.deathDate
FROM Person p
JOIN BORN_IN ON p.id = BORN_IN.person_id
JOIN Place b ON BORN_IN.place_id = b.id
JOIN DIED_IN ON p.id = DIED_IN.person_id
JOIN Place d ON DIED_IN.place_id = d.id
WHERE p.name = 'Albert Einstein'
2.2 知识图谱查询模式
知识图谱查询可以分为多种模式,根据查询的复杂性和目的不同,可以采用不同的查询模式。
2.2.1 精确查询
精确查询是最基本的查询模式,通过指定实体、关系或属性的确切值进行查询。
特点:
- 查询条件明确,结果唯一或有限
- 通常用于检索特定实体的信息
- 查询效率高,可以利用索引加速
示例:
- 查询"爱因斯坦的出生日期是什么?"
- 查询"北京的人口数量是多少?"
2.2.2 模糊查询
模糊查询允许查询条件不完全匹配,通过相似度或模式匹配进行查询。
特点:
- 查询条件模糊,结果可能有多个
- 通常用于文本搜索或不确定查询
- 查询效率相对较低,需要特殊索引支持
示例:
- 查询"与物理学相关的科学家"
- 查询"名字包含’爱’字的人物"
2.2.3 路径查询
路径查询关注实体之间的连接路径,查找满足特定路径模式的实体对。
特点:
- 查询关注实体间的关系链
- 可以发现间接关系和隐含联系
- 查询复杂度高,尤其是长路径查询
示例:
- 查询"爱因斯坦和波尔之间的关系路径"
- 查询"从北京到上海的所有交通路线"
2.2.4 聚合查询
聚合查询对查询结果进行统计和汇总,获取总体信息。
特点:
- 使用聚合函数如COUNT、SUM、AVG等
- 通常用于数据分析和统计
- 查询结果是汇总数据而非原始数据
示例:
- 查询"诺贝尔物理学奖获得者的平均年龄"
- 查询"每个国家的大学数量"
2.2.5 复合查询
复合查询结合多种查询模式,通过子查询、联合查询等方式构建复杂查询。
特点:
- 查询条件复杂,涉及多个子查询
- 可以表达复杂的查询意图
- 查询优化难度大,执行效率可能较低
示例:
- 查询"获得诺贝尔物理学奖且在普林斯顿大学工作过的科学家及其主要贡献"
- 查询"既是导演又是演员且获得过奥斯卡奖的人物及其代表作品"
2.3 知识图谱查询优化
知识图谱查询优化是提高查询效率的关键,尤其是对于大规模知识图谱和复杂查询。
2.3.1 索引优化
索引是加速查询的基本手段,为知识图谱建立合适的索引可以显著提高查询性能。
常见索引类型:
- 三元组索引:为主语-谓词-宾语的不同组合建立索引,如SPO、POS、OSP等
- 全文索引:为文本属性建立倒排索引,支持文本搜索
- 空间索引:为地理位置数据建立空间索引,支持地理查询
- 时间索引:为时间数据建立专门索引,支持时间范围查询
索引选择策略:
- 根据查询模式选择合适的索引类型
- 平衡索引数量和存储空间
- 考虑索引维护成本和查询性能
2.3.2 查询规划
查询规划是确定查询执行计划的过程,对查询性能有重要影响。
查询规划技术:
- 基于规则的优化:使用启发式规则优化查询,如谓词下推、连接顺序调整等
- 基于成本的优化:估算不同执行计划的成本,选择成本最低的计划
- 自适应查询处理:在查询执行过程中动态调整执行计划
查询规划策略:
- 优先执行选择性高的操作,减少中间结果集大小
- 合理安排连接顺序,减少连接操作的计算量
- 利用统计信息指导查询规划
2.3.3 分布式查询
对于大规模知识图谱,分布式查询是提高查询性能的重要手段。
分布式查询技术:
- 数据分片:将知识图谱分散存储在多个节点,并行处理查询
- 查询分解:将复杂查询分解为子查询,分布执行后合并结果
- 中间结果传输优化:减少节点间数据传输,降低网络开销
分布式查询策略:
- 根据数据访问模式设计分片策略
- 尽量在本地完成查询,减少跨节点操作
- 平衡负载,避免单点瓶颈
2.3.4 缓存机制
缓存是提高查询性能的有效手段,尤其是对于重复查询。
缓存层次:
- 查询结果缓存:缓存完整的查询结果
- 中间结果缓存:缓存查询的中间结果
- 计算缓存:缓存复杂计算的结果
缓存策略:
- 根据查询频率和计算成本确定缓存内容
- 设计合适的缓存失效机制,保证数据一致性
- 平衡缓存大小和命中率
2.4 知识图谱查询接口
知识图谱查询接口是用户或应用程序与知识图谱交互的桥梁,设计良好的查询接口可以提高知识图谱的可用性。
2.4.1 编程接口(API)
编程接口允许开发者通过代码访问知识图谱,是应用集成的基础。
常见API类型:
- REST API:基于HTTP的轻量级API,易于集成
- GraphQL API:灵活的查询API,客户端可以精确指定所需数据
- SPARQL Endpoint:标准的SPARQL查询接口
- 语言特定SDK:为特定编程语言提供的开发包
API设计原则:
- 遵循标准协议和格式
- 提供清晰的文档和示例
- 考虑安全性和访问控制
- 支持版本管理和兼容性
2.4.2 自然语言接口
自然语言接口允许用户使用自然语言提问,系统自动转换为形式化查询。
自然语言接口技术:
- 语义解析:将自然语言转换为查询语言
- 意图识别:识别用户查询的意图
- 实体链接:将文本中的实体链接到知识图谱
- 对话管理:维护多轮对话的上下文
自然语言接口挑战:
- 处理语言的歧义性和多样性
- 理解复杂查询意图
- 处理不完整或模糊的问题
- 提供自然、流畅的交互体验
2.4.3 可视化查询接口
可视化查询接口提供图形化的方式构建和执行查询,降低使用门槛。
可视化查询界面类型:
- 图形化查询构建器:通过拖拽、点击等操作构建查询
- 交互式图浏览器:直观展示和探索知识图谱
- 查询模板:预定义常用查询模板,用户填充参数
- 可视化查询结果:以图表、网络图等形式展示查询结果
可视化接口设计原则:
- 直观易用,降低学习成本
- 支持渐进式探索,从简单到复杂
- 提供适当的引导和帮助
- 平衡功能丰富度和界面简洁性
2.5 知识图谱查询应用案例
2.5.1 Google知识图谱搜索
Google知识图谱将知识图谱与搜索引擎集成,在搜索结果中展示结构化信息。
特点:
- 在搜索结果页面右侧显示知识面板
- 提供实体的基本信息、图片、相关实体等
- 支持基本的实体属性查询和关系浏览
- 集成多种数据源,提供丰富的知识内容
应用价值:
- 增强搜索体验,直接展示用户所需信息
- 引导用户探索相关知识,扩展搜索范围
- 提高搜索结果的准确性和权威性
2.5.2 医疗知识图谱查询系统
医疗知识图谱查询系统整合医学知识,支持医疗诊断、药物查询等应用。
特点:
- 支持疾病、症状、药物等医学实体的查询
- 提供疾病诊断、药物相互作用等专业查询
- 结合自然语言处理,支持医学文本查询
- 整合多源医学知识,提供全面的医学信息
应用价值:
- 辅助医生诊断和治疗决策
- 帮助患者了解疾病和药物信息
- 支持医学研究和教育
- 促进医疗知识的共享和应用
2.5.3 金融知识图谱分析平台
金融知识图谱分析平台整合金融实体和关系,支持风险分析、投资决策等应用。
特点:
- 支持公司、人物、产品等金融实体的查询
- 提供股权结构、投资关系等复杂关系分析
- 结合时序数据,支持金融趋势分析
- 整合多源金融数据,提供全面的金融视图
应用价值:
- 辅助风险评估和风控决策
- 支持投资分析和决策
- 发现潜在的商业机会和风险
- 促进金融市场的透明度和效率
3. 基于规则的推理
基于规则的推理是知识图谱推理的重要方法,它利用预定义的规则和逻辑推导从已有知识中推断出新的知识。这种推理方法具有可解释性强、推理过程透明等优点,广泛应用于知识图谱的各个领域。本节将详细介绍基于规则的推理技术,包括本体推理、规则推理、推理引擎以及应用案例。
3.1 本体推理
本体推理是基于本体模式(Ontology Schema)进行的推理,利用本体中定义的类层次、属性特性和约束条件等进行逻辑推导。
3.1.1 本体语言与表达能力
本体语言是定义本体的形式化语言,不同的本体语言具有不同的表达能力和推理复杂度。
主要本体语言:
- RDF Schema (RDFS):提供基本的类层次和属性定义能力
- Web Ontology Language (OWL):提供更丰富的语义表达能力,包括OWL Lite、OWL DL和OWL Full三个子语言
- Rule Interchange Format (RIF):用于规则交换的标准格式
- Shapes Constraint Language (SHACL):用于验证RDF图的约束语言
OWL的表达能力:
- 类表达:类的交集、并集、补集、枚举等
- 属性特性:传递性、对称性、函数性、反函数性等
- 基数约束:属性值的数量限制
- 等价与不相容:类和属性的等价与不相容关系
示例(OWL表达):
# 类层次定义
:Person rdf:type owl:Class .
:Scientist rdf:type owl:Class ;rdfs:subClassOf :Person .
:Physicist rdf:type owl:Class ;rdfs:subClassOf :Scientist .# 属性特性定义
:hasParent rdf:type owl:ObjectProperty .
:hasAncestor rdf:type owl:ObjectProperty ;owl:transitiveProperty true .
:hasChild rdf:type owl:ObjectProperty ;owl:inverseOf :hasParent .# 等价关系定义
:Researcher owl:equivalentClass :Scientist .
3.1.2 本体推理机制
本体推理基于形式化的语义和推理规则,从已知事实和本体定义中推导出新的知识。
主要推理机制:
- 子类推理:如果A是B的子类,B是C的子类,则A是C的子类
- 实例推理:如果a是A的实例,A是B的子类,则a也是B的实例
- 属性继承:子类继承父类的属性
- 属性特性推理:基于属性的传递性、对称性等特性进行推理
- 等价推理:基于类、属性或实例的等价关系进行推理
- 约束检查:验证知识图谱是否满足本体定义的约束
推理示例:
已知:
- 爱因斯坦是物理学家
- 物理学家是科学家
- 科学家是人推理:
- 爱因斯坦是科学家(实例推理)
- 爱因斯坦是人(实例推理)
3.1.3 本体推理算法
本体推理算法是实现本体推理的具体方法,不同的算法适用于不同的本体语言和应用场景。
主要推理算法:
- 表格算法(Tableau Algorithm):基于模型构建的决策过程,适用于OWL DL推理
- 归结算法(Resolution Algorithm):基于反证法的推理算法,将推理问题转化为不满足性问题
- 前向链接(Forward Chaining):从已知事实出发,应用推理规则生成新事实
- 后向链接(Backward Chaining):从目标出发,寻找支持目标的事实和规则
- 混合推理(Hybrid Reasoning):结合多种推理算法,平衡效率和完备性
算法选择考虑因素:
- 本体语言的表达能力
- 推理任务的类型和复杂度
- 知识库的规模和特点
- 推理效率和完备性的平衡
3.1.4 本体推理的挑战与优化
本体推理面临多种挑战,需要采取相应的优化策略。
主要挑战:
- 计算复杂度:完整的OWL DL推理是NEXPTIME-complete问题,计算复杂度高
- 可扩展性:大规模本体和知识库的推理效率问题
- 不一致处理:处理本体或知识库中的矛盾和不一致
- 开放世界假设:处理信息不完整的情况
优化策略:
- 本体模块化:将大型本体分解为小型模块,降低推理复杂度
- 增量推理:只对变化的部分进行推理,避免全量重新计算
- 近似推理:牺牲完备性换取效率,使用近似算法
- 并行推理:利用并行计算加速推理过程
- 物化策略:预先计算和存储常用推理结果
3.2 规则推理
规则推理是基于显式定义的规则进行的推理,通过规则的条件和结论部分描述知识间的依赖关系。
3.2.1 规则表示语言
规则表示语言用于形式化描述推理规则,不同的语言具有不同的表达能力和语法特点。
主要规则语言:
- SWRL (Semantic Web Rule Language):结合OWL和RuleML的规则语言
- RIF (Rule Interchange Format):W3C推荐的规则交换格式
- N3Logic:基于N3语法的规则语言
- SPARQL规则:基于SPARQL CONSTRUCT查询的规则表示
- Datalog:基于逻辑编程的规则语言
SWRL规则示例:
Person(?p) ∧ hasParent(?p, ?parent) ∧ hasBrother(?parent, ?uncle) → hasUncle(?p, ?uncle)
上述规则表示:如果p是人,parent是p的父母,uncle是parent的兄弟,那么uncle是p的叔叔/舅舅。
SPARQL CONSTRUCT规则示例:
CONSTRUCT {?person :hasUncle ?uncle .
}
WHERE {?person a :Person ;:hasParent ?parent .?parent :hasBrother ?uncle .
}
3.2.2 规则推理机制
规则推理基于规则的条件和结论部分,通过模式匹配和逻辑推导生成新知识。
主要推理机制:
- 模式匹配:识别满足规则条件的知识图谱子图
- 变量绑定:将规则中的变量绑定到具体实体
- 结论生成:根据规则结论部分生成新的三元组
- 规则链接:一个规则的结论可能触发另一个规则的条件
- 冲突解决:处理多个规则同时适用时的冲突
推理示例:
规则:如果X是Y的父亲,Y是Z的父亲,那么X是Z的祖父已知:
- 约翰是汤姆的父亲
- 汤姆是杰克的父亲推理:
- 约翰是杰克的祖父
3.2.3 规则推理算法
规则推理算法是实现规则推理的具体方法,不同的算法适用于不同的规则语言和应用场景。
主要推理算法:
- Rete算法:经典的模式匹配算法,构建规则网络加速匹配过程
- TREAT算法:Rete的改进版本,减少内存消耗
- LEAPS算法:延迟评估策略,提高规则执行效率
- 半朴素算法:优化Datalog规则的评估
- 魔术集算法:通过规则重写优化查询评估
算法选择考虑因素:
- 规则数量和复杂度
- 知识库规模和更新频率
- 内存和计算资源限制
- 推理实时性要求
3.2.4 规则挖掘与学习
规则挖掘与学习是从数据中自动发现规则的过程,减少人工规则编写的工作量。
主要方法:
- 关联规则挖掘:发现数据中的频繁模式和关联规则
- 归纳逻辑编程(ILP):从正负例中学习逻辑规则
- 决策树学习:构建决策树并转换为规则
- 神经符号学习:结合神经网络和符号规则的学习方法
- 规则提炼:从预训练模型中提炼出可解释的规则
规则评估指标:
- 支持度(Support):规则覆盖的实例比例
- 置信度(Confidence):规则预测正确的比例
- 提升度(Lift):规则相对于随机预测的改进程度
- 复杂度:规则的长度和复杂性
- 可解释性:规则的可理解程度
3.3 推理引擎
推理引擎是执行本体推理和规则推理的软件系统,提供推理算法实现和推理服务接口。
3.3.1 主流推理引擎
开源推理引擎:
- Pellet:基于Java的OWL DL推理引擎,支持SWRL规则
- HermiT:基于表格算法的OWL推理引擎,支持OWL 2 DL
- Jena Reasoner:Apache Jena框架的推理组件,支持RDFS和OWL推理
- RDFox:高性能的内存数据库和推理引擎,支持Datalog规则
- OWLIM/GraphDB:支持OWL RL的语义存储和推理系统
商业推理引擎:
- AllegroGraph:支持RDFS++和Prolog规则的图数据库
- Stardog:支持OWL 2和用户自定义规则的知识图谱平台
- Oracle Spatial and Graph:支持RDFS和OWL推理的图数据库
- Virtuoso:支持RDFS和部分OWL推理的通用数据库
3.3.2 推理策略
推理引擎采用不同的推理策略,平衡推理的完备性、正确性和效率。
主要推理策略:
- 前向推理:预先计算所有可能的推理结果,适合查询频繁的场景
- 后向推理:查询时按需推理,适合数据频繁更新的场景
- 混合推理:结合前向和后向推理,根据查询模式动态调整
- 增量推理:只对变化的数据进行推理,避免全量重新计算
- 分布式推理:将推理任务分布到多个计算节点,提高处理能力
策略选择考虑因素:
- 知识库规模和更新频率
- 查询模式和频率
- 推理规则的复杂度
- 系统资源限制
- 推理结果的时效性要求
3.3.3 推理引擎架构
推理引擎的架构设计影响其功能、性能和可扩展性。
典型架构组件:
- 知识库管理:存储和管理本体、规则和事实
- 规则编译器:将规则转换为内部表示
- 模式匹配器:识别满足规则条件的数据
- 推理调度器:控制推理过程和策略
- 结果管理器:管理和索引推理结果
- 查询处理器:处理用户查询,利用推理结果
- 一致性检查器:检查和维护知识的一致性
架构设计考虑因素:
- 推理任务的类型和复杂度
- 系统性能和可扩展性要求
- 与其他系统的集成需求
- 用户交互和接口设计
3.4 基于规则推理的应用案例
3.4.1 医疗诊断系统
医疗诊断系统利用医学知识图谱和推理规则辅助疾病诊断和治疗决策。
应用特点:
- 基于医学本体(如SNOMED CT、ICD)构建知识图谱
- 使用医学诊断规则进行推理
- 结合患者症状和检查结果进行个性化诊断
- 提供诊断解释和治疗建议
推理规则示例:
症状(患者, 发热) ∧ 症状(患者, 咳嗽) ∧ 检查结果(患者, 白细胞增高) → 可能疾病(患者, 肺炎)
应用价值:
- 辅助医生诊断,减少漏诊和误诊
- 提供诊断依据和解释,增强可信度
- 整合最新医学知识,提高诊断水平
- 支持罕见疾病的诊断
3.4.2 法律推理系统
法律推理系统利用法律知识图谱和推理规则进行法律分析和决策支持。
应用特点:
- 基于法律条文和案例构建知识图谱
- 使用法律规则和推理进行案例分析
- 考虑法律条文的适用条件和例外情况
- 提供法律推理过程和依据
推理规则示例:
行为(X, 未经许可进入他人住宅) ∧ 目的(X, 窃取财物) → 罪名(X, 入室盗窃)
应用价值:
- 辅助法律分析和决策
- 提高法律推理的一致性和透明度
- 支持复杂法律案例的分析
- 促进法律知识的共享和应用
3.4.3 智能客服系统
智能客服系统利用企业知识图谱和推理规则回答客户问题和解决问题。
应用特点:
- 基于产品、服务和常见问题构建知识图谱
- 使用业务规则进行问题分析和解答
- 结合客户信息进行个性化服务
- 提供问题解决方案和操作指导
推理规则示例:
产品(X, 智能手机) ∧ 问题(X, 无法开机) ∧ 使用时间(X, <1年) → 解决方案(X, 保修服务)
应用价值:
- 提高客服效率和质量
- 降低人工客服成本
- 提供全天候服务
- 积累和应用企业知识
4. 基于统计的推理
基于统计的推理是知识图谱推理的另一重要方法,它利用统计学习和机器学习技术从数据中学习知识的统计规律,进行概率推理和预测。与基于规则的推理相比,基于统计的推理能够处理不确定性和噪声数据,具有更强的泛化能力。本节将详细介绍基于统计的推理技术,包括知识图谱嵌入、表示学习方法、统计关系推理以及应用案例。
4.1 知识图谱嵌入基础
知识图谱嵌入(Knowledge Graph Embedding, KGE)是将知识图谱中的实体和关系映射到低维连续向量空间的技术,是基于统计推理的基础。
4.1.1 知识图谱嵌入的基本原理
知识图谱嵌入的核心思想是学习实体和关系的低维向量表示,使得这些向量能够保留知识图谱中的语义信息和结构特征。
基本假设:
- 语义相似的实体在嵌入空间中距离较近
- 关系可以表示为嵌入空间中的操作(如平移、旋转等)
- 知识图谱中的三元组可以通过实体和关系的嵌入向量进行评分
嵌入的目标:
- 最大化已知三元组的评分
- 最小化不存在三元组的评分
- 保留实体和关系的语义信息
- 支持知识图谱补全和推理任务
形式化定义:
- 实体嵌入:将实体 e 映射为向量 e ∈ R d \mathbf{e} \in \mathbb{R}^d e∈Rd
- 关系嵌入:将关系 r 映射为向量 r ∈ R d \mathbf{r} \in \mathbb{R}^d