知识图谱（一）：入门

实体、关系与属性

知识图谱是一种以实体及其关系组织知识的表示方式。实体对应需要识别的对象，关系描述对象之间的联系，属性记录对象或关系的具体特征。明确对象身份、关系含义和上下文后，不同来源的信息就能连接起来，供查询和分析使用。

例如，“订单服务依赖 checkout-sdk 2.1”包含两个实体和一项有方向的关系。订单服务是依赖方，checkout-sdk 2.1 是被依赖方；如果将方向反过来，表达的事实就改变了。“服务名称为订单 API”则是属性描述，名称用于显示，不应成为判断服务身份的唯一依据。

一项关系可以写成主体、谓词、客体组成的三元组，例如（订单服务，依赖，checkout-sdk 2.1）。主体和客体可以在其他三元组中重复出现，由此连接成图。三元组是基本表达单元，但业务事实可能还需要时间、条件和来源；这些信息可以作为关系属性，也可以通过独立的断言或事件对象表达。

实体类型与具体实体属于不同层次。Service 是服务这一类对象的类型，order-api 是该类型的一个实例；PackageVersion 是组件版本类型，parser 1.4 是一个实例。类型用于规定共同的属性和可参与的关系，实例承载具体业务数据。查询通过类型区分服务、团队和文档。

背景阅读：Hogan 等，Knowledge Graphs，ACM Computing Surveys，2021

软件依赖分析示例

假设需要分析 parser 1.4 的一则风险公告，找出需要核查的服务及责任团队。演示数据中，订单服务 order-api 依赖 checkout-sdk 2.1，后者依赖 parser 1.4；报表服务 report-api 直接依赖 parser 1.4。订单服务归交易团队负责，报表服务归数据团队负责。公告 ADV-DEMO-001 声明 parser 1.4 在启用模板扩展时受影响。

查询从 parser 1.4 出发，沿依赖关系的反方向寻找使用者。首先得到 checkout-sdk 2.1 和 report-api；继续查找 checkout-sdk 2.1 的使用者，得到 order-api。过滤出服务类型的节点后，结果为订单服务和报表服务。再沿团队归属关系查询，即可得到需要联系的两个团队。

这种连接跨越了多份资料：构建清单提供服务依赖，组件清单提供间接依赖，资产台账提供团队归属，公告提供影响版本。稳定标识使这些记录能够指向同一个对象，关系类型则使系统知道应沿哪些边展开。若不同资料中的 parser 被错误地对齐到另一个同名组件，路径虽能执行，结果仍然错误。

查询得到的是需要核查的服务。确认实际影响还要检查生产部署是否采用这份构建、是否启用模板扩展。结果中保留团队、依赖路径和原始证据，方便负责人继续排查。

知识图谱与其他数据技术

知识图谱描述的是知识如何组织；数据库描述的是数据如何保存和访问。一个图谱可以存放在图数据库、RDF 存储、关系数据库甚至文件中。图数据库也可以只保存道路或关注关系，不承担统一实体身份、解释关系含义或追溯事实来源的职责。

关系数据库通过表、键和连接同样可以表达服务依赖，递归查询也能处理多跳路径。若关系类型少、查询结构固定，现有数据库通常就能满足需求。图数据库将节点和邻接关系作为主要访问对象，在路径变化较多的查询中可能更便于表达，查询速度取决于索引、图结构和执行计划。

向量检索根据向量表示的相似程度寻找候选材料。它适合把“订单解析故障”与语义相关的文档联系起来，却不会仅凭相似度保证版本相等、依赖方向正确或时间区间有效。知识图谱可以在实体确定之后执行这些结构化判断，向量检索则可以帮助找到尚未明确命名的实体或文本。

实际系统经常组合这些技术。服务台账继续保存在关系数据库，依赖视图用于路径查询，公告全文用于关键词或向量检索，图中的证据标识将结果连接回原文。

应用场景

关系分析是知识图谱最直接的用途，例如组件影响分析、设备故障传播和组织责任查询。这些答案需要沿多步关系查找。显式关系能够提供可重复执行的查询，并保留结果所依据的路径。

异构数据整合关注的是不同系统对同一对象的描述。资产平台使用编号，文档使用简称，公告使用外部产品名称；统一标识和关系定义可以将这些信息连接起来。整合时需要先清理身份和语义差异。

知识检索与问答利用图中的对象联系扩展证据范围。用户问某组件涉及哪些团队时，图可以连接未在同一段文本出现的服务和团队。公告发布日期这类单条事实可以直接精确检索。

建设图谱前，先写下要回答的具体问题，例如“在指定生产快照中，哪些服务通过 runtime 依赖到达 parser 1.4”。再检查需要哪些实体、关系与数据源，以及资料能否持续更新。据此估算身份整理、审核和维护的工作量。

知识图谱的技术体系

建模阶段定义对象、关系、标识与上下文。构建阶段将源记录映射或抽取为候选知识，再完成实体链接、去重与冲突处理。存储与查询阶段使已发布知识能够按模式检索，并返回需要的对象或路径。稳定标识让记录能够连接，条件信息则决定查询结果的适用范围。

推理与知识补全在已有图的基础上产生新结果。规则推理给出在明确前提下成立的结论，统计模型给出需要核实的预测候选。检索增强生成则将图查询与原文材料组织为自然语言回答。保存结果时，应分别标记原始事实、规则结论和预测候选。

质量评估贯穿各阶段，持续维护负责处理数据变化。新公告可能改变影响范围，新的构建可能移除依赖，团队归属也会变动。系统需要保存来源和处理版本，才能定位哪些事实与派生产物应重新计算。

示例使用 Python 标准库、Neo4j 5 风格 Cypher 及 RDF 1.1 / SPARQL 1.1。