3. 知识图谱基础
知识图谱（Knowledge Graph）的本质是一种基于图数据结构的语义网络，其核心目标在于用节点和边描述真实世界中的事物及其关联。在《大模型与知识图谱融合应用》的课程体系中，理解知识图谱的基础构成是构建一切上层应用（如检索增强生成RAG、推理、决策支持）的前提。本章将系统拆解知识图谱的原子单元（实体、关系、属性、三元组），并深入探讨从数据到语义约束的升华过程——本体与模式设计。我们将不仅停留在概念定义，更会结合工程实践，剖析如何设计一套高质量、可扩展、能支撑大模型推理的知识图谱模式。
上图展示了知识图谱构建的核心逻辑闭环：左侧是数据层的原子单元（三元组），右侧是语义层的约束框架（本体与模式），底部则是从业务需求到模式落地的工程流程。接下来，我们将逐一深入这些模块的细节。
3.1 核心原理：从三元组到语义网络
知识图谱的底层逻辑极其简洁——一切知识都可以被拆解为“主语-谓语-宾语”的结构，即三元组（Triple）。这种结构在计算机科学中被称为“语义三元组”，在关系型数据库中对应一行记录，但在图数据库中，它表现为两个节点与一条边的连接。
- 实体（Entity）：客观存在的具体事物或抽象概念，如“北京”、“张三”、“自然语言处理”。实体是图的节点，具有全局唯一标识符（IRI或ID）。
- 关系（Relation/Predicate）：连接两个实体的语义联系，如“位于”、“出生于”、“研究领域”。关系是图的边，具有方向性。
- 属性（Property/Attribute）：描述实体自身特征的键值对，如“张三”的“年龄”为“30”。属性通常作为节点的内部键值存储，而非独立的节点。
- 三元组：由“实体-关系-实体”或“实体-属性-属性值”构成。前者表达关系，后者表达属性。
理解三元组的关键在于区分“关系”与“属性”。关系连接两个实体，而属性挂载在单个实体上。例如，“张三出生于北京”是一个关系三元组；“张三的年龄是30”是一个属性三元组。在知识图谱的实际存储中，属性往往被压缩为节点的属性列表，以提升查询性能。
3.2 判断方法与操作流程：本体与模式设计的五步法
本体（Ontology）是知识图谱的语义基石，它定义了概念、概念的属性、概念之间的关系以及约束规则。模式（Schema）则是本体的具体实现，通常指用特定语言（如OWL、RDFS或图数据库的标签属性）对本体进行编码。设计一套合理的模式，需要遵循以下操作流程：
- 需求驱动分析：明确图谱要回答哪些业务问题。例如，若构建“智能招聘图谱”，核心需求可能是“查找符合技能要求的候选人”或“分析岗位与技能的匹配度”。这决定了实体类型和关系类型的最小集。
- 实体与类层次定义：将业务概念抽象为类（Class）。例如，“人”是一个类，“候选人”是“人”的子类，“技术经理”是“候选人”的子类。类层次不宜过深（建议不超过5层），否则会导致查询性能下降。
- 关系与属性建模：定义关系时，需明确关系的定义域（Domain）和值域（Range）。例如，关系“就职于”的定义域是“人”，值域是“公司”。属性建模需指定数据类型（字符串、整数、日期等）和基数约束（单值或多值）。
- 规则与约束设定：包括必填属性、唯一性约束、互斥关系等。例如，一个“员工”必须属于至少一个“部门”，一个“身份证号”只能对应一个“人”。
- 迭代与验证：使用真实数据样本进行导入测试，检查是否存在孤立节点、关系断裂或属性冗余。通过SPARQL或Cypher查询验证模式是否满足业务需求。
| 设计维度 | 常见错误 | 推荐做法 |
|---|---|---|
| 类层次 | 层次过深（>6层），导致推理复杂 | 控制在3-4层，使用多级分类而非单链继承 |
| 关系命名 | 使用模糊动词如“相关”、“处理” | 使用精确动词如“购买”、“治疗”、“隶属于” |
| 属性粒度 | 将复杂对象直接作为字符串存储 | 拆分为独立实体或使用结构化数据类型 |
| 冗余关系 | 同时保留“朋友”和“好友”两个同义关系 | 建立关系别名映射，统一术语表 |
3.3 案例拆解：构建“智能招聘知识图谱”的模式设计
为了将抽象理论落地，我们以“智能招聘”场景为例，完整演示模式设计过程。该图谱需要支持大模型进行简历筛选、岗位匹配和人才画像分析。
背景与约束： 数据源包括结构化招聘系统（含岗位JD、候选人简历）、半结构化面试评价表、非结构化面试录音转写文本。业务要求图谱能回答：“找出熟悉Python和TensorFlow，且有3年以上推荐系统经验的候选人”。
初始现象与目标： 初始数据中，“技能”有时作为字符串列表存在，有时作为独立实体存在，导致查询混乱。目标是通过模式设计统一语义。
关键输入数据： 岗位JD包含“技能要求”、“经验年限”、“学历要求”；简历包含“工作经历”、“项目经历”、“教育背景”。
分析判断过程： 我们发现“技能”在JD中是要求，在简历中是能力，二者语义不同。因此，不能简单地将技能作为属性，而应建模为独立实体，并通过不同关系（“要求技能”与“具备技能”）连接。
实际操作步骤：
# 伪代码示例：定义类与关系
CREATE CLASS Person
CREATE CLASS Candidate EXTENDS Person
CREATE CLASS Skill
CREATE CLASS Company
CREATE RELATION requires_skill FROM JobPosition TO Skill
CREATE RELATION has_skill FROM Candidate TO Skill
CREATE RELATION works_at FROM Candidate TO Company
# 属性约束
CREATE PROPERTY Candidate.years_experience INT
CREATE PROPERTY Candidate.expected_salary FLOAT
CREATE CONSTRAINT Candidate.id UNIQUE结果对比： 模式调整后，查询“熟悉Python和TensorFlow且有3年以上经验”的候选人，只需匹配“has_skill”关系和“years_experience”属性，查询效率提升约40%，且语义清晰无歧义。
风险与代价： 将技能从属性提升为实体，导致数据导入工作量增加约20%，且需要维护技能同义词表（如“Python”与“python3”）。但长期来看，这为后续推理（如技能相似度计算）奠定了基础。
3.4 常见误区与总结复盘
在知识图谱模式设计实践中，初学者常陷入以下误区：
- 误区一：过度建模。试图将现实世界的所有细节都纳入图谱，导致模式极其复杂，维护成本高，且大模型难以有效利用。正确做法是聚焦业务目标，遵循“够用就好”原则。
- 误区二：属性与实体混淆。将“城市”作为“人”的属性，而不是独立的实体。这会导致无法查询“同一城市的所有人”。判断标准：如果该值需要被独立查询或关联，则应为实体。
- 误区三：忽略关系方向。关系是有方向的，但查询时可能需要反向遍历。建议在模式中显式定义逆关系（如“就职于”与“雇佣”），或利用图数据库的逆向遍历能力。
- 误区四：缺乏数据治理。没有定义实体ID生成规则、同义词映射、数据质量标准。这会导致图谱中出现大量冗余或冲突数据。