知识图谱

知识图谱是一种以图结构组织领域知识的表示与应用方式：它把对象、概念或事件表示为节点，以有明确含义的关系连接它们。知识图谱不是单一软件或固定格式；其逻辑模型、术语体系和具体实现会因任务而异。

“知识图谱”在不同领域和产品中指称不完全相同。本文采用一个编辑性的跨实现工作定义：知识图谱是以图结构组织领域知识的数据模型或数据集合，其中节点代表被标识的对象、概念或事件，边代表它们之间有含义的关系。这里的“实体”是图中要表达的具体或抽象对象；名称或标识符是引用、区分实体的手段，二者不是同一事物。一个实体可以有多个名称或别名，单有相同名称也不足以证明两个记录指向同一实体。

知识图谱的要点不是把数据画成网状，而是让对象身份、关系含义和事实边界足够清楚，便于查找、整合、解释或沿关系检索。例如，在图书资源中可把作者、作品、版本分别建模为节点，并以“创作”“属于版本”等关系连接。系统能否据此正确查询，取决于图谱中的标识、关系定义和数据质量；关系线的数量、展示图的复杂程度本身不代表知识质量。

知识图谱着重描述的是逻辑数据模型，不限定后端物理存储。某个系统可以把关系表映射为明确的节点和边模型；这种情况下，图模型是显式的语义层，底层仍可能由表存储。任意一张带有外键或对象字段的表格，不会仅因字段之间有关联就自动成为知识图谱。

不同图模型对节点、关系与属性的表达方式不同。在属性图模型中，节点和边可以带标签及键值属性。例如，“账户—转账至—账户”这条边可以记录转账金额和时间，节点可记录账户属性。Google Cloud 的 Spanner Graph 文档以关系表映射为属性图，展示了这一种具体产品实现：节点和边各自具有标签、属性，并可由表格行生成。它是属性图的例子，不是对所有知识图谱的统一规定。

RDF 则采用不同的数据模型。W3C RDF 1.1 将 RDF 图定义为主语、谓语、宾语三元组的集合；关系谓语本身不能像属性图的一条边那样直接挂接键值属性。若要记录某条关系陈述的来源、时间等元数据，需按所用 RDF 版本及应用约定对该陈述另行建模，例如将陈述作为可描述对象，或使用相应的陈述引用机制。数据集也可以用默认图与命名图组织多张 RDF 图，但这不等于每条关系边天然拥有属性。关于 RDF、语义网与相关标准，可参见站内词条“语义网”。

因此，知识图谱并不等于 RDF 图，也不等于属性图：RDF 是标准化的图数据模型及技术体系的一部分，属性图是另一类常见图模型；知识图谱是本文采用的跨实现概念，描述由对象及有语义关系构成的领域知识组织方式。具体项目要说明选择了什么模型、关系怎样定义、属性属于节点还是关系，以及多来源陈述如何保留来源和时间。

构建前先划定领域范围、使用者和目标问题，而不是从“尽可能收全所有知识”开始。比如图书资源图谱究竟要用于目录合并、作品版本追踪，还是发现作者之间的合作关系，目标不同，对节点、关系、时间粒度和来源要求也不同。问题范围可转化为一组待回答的查询或业务问题，并据此确定需要记录哪些事实、覆盖哪些来源、允许多大更新延迟。

接下来制定数据模型：说明对象类型、关系词汇、标识规则、属性含义、时间表达、语言标签以及如何引用外部术语。关系设计应明确方向和语义。例如“作者创作作品”与“作品由作者创作”可以互为方向相反的表述，但不应在不同数据源中不加说明地当作同一个谓语。若“作品—属于—系列”与“作品—是系列中的作品”会被不同团队使用，也需要预先规定标准方向或映射规则。

数据处理环节会从表格、数据库、文档、开放数据或人工录入中提取、转换、对齐事实。标识符用来稳定引用对象，实体解析则判断多个来源中的记录是否指向同一对象。匹配名称可以作为线索，但应结合标识、类型、上下文和来源，避免把同名异物合并。证据不充分时保留待确认记录或不合并，通常比造成一个错误关联更安全。自动抽取或机器学习输出若用于高风险领域，应保留来源和复核机制，不能把预测结果直接当作已证实事实。

入库后可按图结构查询邻接对象、多跳路径或符合条件的子图。RDF 图常配合 SPARQL 查询，属性图系统则使用各自支持的查询语言。若要从显式关系推断新关系，还需规定采用哪些规则或形式语义，并理解它们能推出什么、不能推出什么。存在一条图路径不必然意味着现实中的因果联系；由模型推出某个结论，也只说明它在所给事实和规则下成立，不代表已独立核实现实情况。

维护通常包括来源更新、实体更名和合并、关系失效、模型变更、重复和冲突处置、版本管理以及访问控制。每项事实可以根据用途记录出处、采集或生效时间、许可、置信度和状态。不同图模型保存元数据的方式并不相同，设计时要提前说明如何追溯而非假定系统会自动记录。开放数据还要检查再分发许可和隐私风险；内部图谱则需依据用户权限控制查询，避免通过多源关联暴露原本分散的信息。

图数据库是存储和查询图结构数据的技术类别，关注数据模型、索引、查询和部署；知识图谱关注如何把对象及关系组织成可理解、可查询的知识。图数据库可以承载知识图谱，也可服务于路由、依赖关系等其他任务；图数据库中的任意网络结构也不自动构成知识图谱。

本体是对某一领域的概念、类别、属性和关系进行形式化定义的模型，可为知识图谱提供术语和语义约定。本体本身通常不等于包含大量具体事实的实例数据；知识图谱则可能同时包含模型和事实，也可能只使用较轻量的分类体系。分类法更偏向概念分类及层级组织，知识图谱还可表达具体对象、事件和非层级关系。

知识库是更宽泛的概念，可指计算机可处理的知识集合，并不必然采用图结构。语义网指向让 Web 数据以可链接、可机器处理的方式表达和复用的技术路线与标准生态；知识图谱可采用语义网技术，但并不是语义网的同义词。语义网的目标范围还包括标识符、数据表达、词汇、链接与查询等内容，见站内词条“语义网”。

当任务依赖对象间多种关系、需要合并多源实体、需要沿关系做多步查询，或希望解释一条信息与其他信息的关联路径时，知识图谱值得评估。目录整合、科研资源关联、组织关系检索、产品关系浏览或数字文化资源连接，都可以先以实际问题为中心建模，再验证图谱是否改善了目标查询。对检索或问答系统，图谱可提供显式的实体和关系上下文，但单纯建图并不能保证回答完整、准确或消除模型错误。

如果主要需求是批量数值计算、强事务更新、简单明细查询或固定报表，关系数据库、全文检索或已有数据模型可能更直接。图谱需要持续投入到实体对齐、关系定义、来源追溯、质量审核和版本更新。数据来源不全会导致“图上没有”被误认为现实中不存在；错误抽取会制造看似确定的关系；术语未统一时，跨源查询可能把不同概念混在一起。图的连通性、可视化效果和数据条目数不能代替任务效果评估。

选择是否建设图谱，应回到目标问题：它是否能更准确地回答查询，是否能追溯事实来源，关系错误能否发现与修正，更新和权限成本是否可承受。知识图谱是显式建模对象和关系的一种工程选择，并非对所有数据问题都优于表格、全文搜索或人工目录。

• W3C：《RDF 1.1 概念与抽象语法》
• Google Cloud：Spanner Graph 架构概述
• Google for Developers：Knowledge Graph Search API 文档