知识图谱详解：从图结构、关系建模到查询与应用

知识图谱详解：从图结构、关系建模到查询与应用

知识图谱（Knowledge Graph）是一种以**实体（Entity）和实体之间的关系（Relation）**为核心组织知识的数据结构。与传统数据库主要描述"数据是什么"不同，知识图谱更加关注"数据之间有什么关系"。例如，在一个安全领域知识图谱中，可以表示：

CVE-2025-1234
      │
   HAS_CWE
      ↓
   CWE-89
      │
    TYPE
      ↓
SQL Injection
      │
  FIXED_BY
      ↓
Parameterized Query

通过这种方式，原本分散在不同文档中的信息被组织成一个可以计算、查询和推理的关系网络。知识图谱最初主要应用于搜索、推荐和知识管理，如今也经常与 RAG、LLM、Agent 等技术结合，用于提供结构化知识和关系推理能力。

一、知识图谱的核心思想

知识图谱最重要的思想其实非常简单：

把现实世界中的对象表示成节点，把对象之间的关系表示成边。

例如有三个实体：

CVE-2025-1234
CWE-89
SQL Injection

以及两个关系：

CVE-2025-1234 ──HAS_CWE──> CWE-89
CWE-89 ──DESCRIBES──> SQL Injection

这时就形成了一个最基本的图。

在数学和计算机科学中，一个图通常可以表示为：

G=(V,E)

其中 V 表示节点集合，E 表示边集合。对于知识图谱来说，可以进一步为节点和边增加属性，从而表达更加丰富的知识。

例如：

Node:
{
    id: "CWE-89",
    type: "CWE",
    name: "SQL Injection"
}

Edge:
{
    source: "CVE-2025-1234",
    target: "CWE-89",
    type: "HAS_CWE"
}

因此，知识图谱本质上可以看成是一个**带语义的属性图（Property Graph）**或者其他形式的知识图表示。

二、知识图谱中的三个核心元素

最常见的知识表示方式可以概括为：

实体 + 关系 + 属性

1. 实体

实体代表现实世界中的对象，例如：

CVE
CWE
漏洞
公司
产品
人物
地点
论文
疾病
药物

例如：

CVE-2025-1234
CWE-89
Django
SQL Injection

这些都可以作为实体。

2. 关系

关系用于描述实体之间的连接，例如：

HAS_CWE
AFFECTS
EXPLOITS
FIXED_BY
CREATED_BY
LOCATED_IN
RELATED_TO

例如：

CVE-2025-1234 ──HAS_CWE──> CWE-89
CVE-2025-1234 ──AFFECTS──> Django

3. 属性

实体和关系还可以携带属性。

例如一个 CVE 节点：

{
  "id": "CVE-2025-1234",
  "type": "CVE",
  "severity": "high",
  "published_at": "2025-01-10"
}

这样就不仅知道"它是什么"，还知道"它有哪些特征"。

所以一个更完整的图谱结构可以表示为：

              属性
               ↓
          ┌──────────┐
          │   CVE    │
          │ id=1234  │
          │ severity │
          └────┬─────┘
               │
            HAS_CWE
               │
               ↓
          ┌──────────┐
          │   CWE    │
          │   89     │
          └──────────┘

三、为什么知识图谱和传统数据库不同

传统关系型数据库通常以表、行、列的形式组织数据。

例如：

CVE 表

id               cwe        severity
CVE-2025-1234    CWE-89     High

这种结构对于结构化业务数据非常有效，但当关系变得复杂时，需要通过 JOIN 操作将多个表连接起来。

例如：

CVE
 ↓
CWE
 ↓
Vulnerability
 ↓
Product
 ↓
Remediation

如果这些信息分别存在不同的表中，就需要多次 JOIN。

知识图谱则直接把关系表示为图中的边：

CVE
 ↓ HAS_CWE
CWE
 ↓ DESCRIBES
Vulnerability
 ↓ AFFECTS
Product
 ↓ FIXED_BY
Remediation

因此，对于关系密集型的数据，图结构通常更加直观。

但这并不意味着知识图谱可以完全替代关系型数据库。两者解决的问题不同：

关系型数据库
→ 强调结构化数据、事务、一致性

知识图谱
→ 强调实体关系、关系查询和图上的分析

实际系统中两者通常是协同工作的。

四、知识图谱是怎么构建出来的

一个完整的知识图谱通常不是直接手工创建，而是经过一个知识抽取与构建流程：

原始数据
   ↓
数据清洗
   ↓
实体抽取
   ↓
关系抽取
   ↓
实体对齐
   ↓
属性补充
   ↓
图谱构建
   ↓
图数据库 / 图计算系统

1. 数据来源

知识图谱的数据来源非常广泛，例如：

数据库
API
网页
PDF
Markdown
日志
业务系统
大语言模型
人工标注

以安全知识图谱为例，可以从 CVE、CWE、厂商安全公告、漏洞扫描报告等来源获得数据。

2. 实体抽取

从原始文本中识别出有价值的实体。

例如：

"CVE-2025-1234 属于 CWE-89，
影响 Django 5.0，并可通过参数化查询修复。"

可以抽取：

CVE-2025-1234
CWE-89
Django 5.0
参数化查询

3. 关系抽取

继续识别实体之间的关系：

CVE-2025-1234
    ↓ 属于
CWE-89

CVE-2025-1234
    ↓ 影响
Django 5.0

CVE-2025-1234
    ↓ 修复方式
参数化查询

4. 实体对齐

不同数据源可能对同一个实体使用不同名称。

例如：

SQL Injection
SQLi
SQL 注入
CWE-89

系统需要判断哪些描述实际上指的是同一个概念，并统一实体 ID。

否则图中就会出现大量重复节点。

5. 图谱写入

最后，把实体和关系写入图数据库或者图结构。

例如：

(CVE-2025-1234)-[:HAS_CWE]->(CWE-89)
(CVE-2025-1234)-[:AFFECTS]->(Django)
(CWE-89)-[:FIXED_BY]->(Parameterized Query)

至此，一张知识图谱基本形成。

五、知识图谱中的实体对齐为什么重要

实体对齐（Entity Resolution / Entity Linking）是知识图谱构建中的一个重要问题。

例如来自不同数据源的数据可能分别写成：

Microsoft Windows 11
Windows 11
Win11

如果不进行实体对齐，图谱可能认为它们是三个不同实体：

Windows 11
Windows 11
Win11

最终导致知识分散。

正确的处理应该是：

Windows 11
↑
├── Windows 11
├── Win11
└── Microsoft Windows 11

通过统一实体 ID，多个数据源中的信息才能汇聚到同一个节点上。

六、知识图谱如何查询

知识图谱的一个核心优势是能够进行关系查询。

不同图数据库使用的查询语言不同。以 Neo4j 为例，可以使用 Cypher。

例如：

MATCH (cve:CVE {id: "CVE-2025-1234"})
      -[:HAS_CWE]->
      (cwe:CWE)
RETURN cve, cwe

表示：

查找 CVE-2025-1234 对应的 CWE。

如果希望继续查找该 CWE 对应的漏洞类型和修复方案，可以进行多跳查询：

MATCH (cve:CVE {id: "CVE-2025-1234"})
      -[:HAS_CWE]->(cwe:CWE)
      -[:DESCRIBES]->(v:Vulnerability)
      -[:FIXED_BY]->(r:Remediation)
RETURN cve, cwe, v, r

这就是知识图谱非常重要的能力：

从一个实体沿着关系逐步访问相关实体。

这种查询方式通常被称为图遍历（Graph Traversal）。

七、什么是多跳查询

假设有：

CVE
 ↓
CWE
 ↓
攻击方式
 ↓
影响产品
 ↓
修复方式

如果只查询：

CVE → CWE

就是一跳。

如果查询：

CVE → CWE → 攻击方式

就是两跳。

如果继续：

CVE → CWE → 攻击方式 → Product → Remediation

则属于多跳查询。

多跳查询是知识图谱区别于普通关键词搜索的重要能力之一，因为它关注的不只是"有哪些相关文本"，还关注：

实体之间是怎样连接起来的。

八、知识图谱中的推理

知识图谱不仅可以查询已有关系，还可以在一定条件下进行推理。

例如已有：

A ──IS_A──> B
B ──AFFECTS──> C

通过规则可以推导出：

A ──AFFECTS──> C

当然，现实中的知识图谱推理更加复杂，可能涉及：

规则推理
路径推理
本体推理
概率推理
图神经网络
LLM 推理

需要注意的是，图数据库的查询和知识推理并不是同一个概念。图数据库可以很高效地执行关系查询，但复杂的知识推理通常需要额外的规则引擎、推理框架或者机器学习模型。

九、知识图谱和 RAG 有什么区别

知识图谱和 RAG 经常一起出现，但两者不是同一种技术。

传统 RAG 通常是：

文档
 ↓
Chunk
 ↓
Embedding
 ↓
Vector Database
 ↓
Similarity Search
 ↓
LLM

它擅长：

找到和用户问题语义相似的文本。

知识图谱则更加关注：

Entity
 ↓
Relation
 ↓
Entity

它擅长：

找到实体之间明确存在的关系。

因此两者可以互补。

例如用户问：

"CVE-2025-1234 属于什么 CWE？历史上有没有类似的漏洞？有哪些修复方法？"

向量检索可以找到：

相关漏洞描述
历史文档
修复文档

知识图谱则可以提供：

CVE → CWE
CVE → Product
CWE → Vulnerability Type
Vulnerability → Remediation

最终可以组成：

用户问题
   ↓
┌───────────────┐
│               │
Vector Search   Graph Search
│               │
语义相关文档    关系相关知识
│               │
└───────┬───────┘
        ↓
      Context
        ↓
       LLM

这种架构经常被称为Graph RAG或者知识图谱增强的 RAG。

十、知识图谱和向量数据库的区别

向量数据库和知识图谱解决的是两种不同类型的检索问题。

例如用户查询：

"如何防止用户输入导致数据库查询被恶意利用？"

向量检索可能找到：

SQL Injection prevention
Parameterized query
Input validation

因为它们在语义上比较接近。

而知识图谱更适合回答：

CWE-89
    ↓
属于
    ↓
SQL Injection
    ↓
影响
    ↓
某产品
    ↓
修复
    ↓
Parameterized Query

因此可以简单理解为：

向量数据库
→ "什么内容和我的问题相似？"

知识图谱
→ "这些实体之间有什么关系？"

十一、知识图谱常见的实现方式

知识图谱不一定必须使用专业图数据库。

NetworkX

NetworkX 是 Python 中非常常用的图计算库，可以直接在内存中维护节点和边。

例如：

import networkx as nx

G = nx.DiGraph()

G.add_node(
    "CVE-2025-1234",
    type="CVE"
)

G.add_node(
    "CWE-89",
    type="CWE"
)

G.add_edge(
    "CVE-2025-1234",
    "CWE-89",
    relation="HAS_CWE"
)

NetworkX 非常适合：

原型开发
图算法
实验
小规模知识图谱
知识图谱可视化

但它本质上是 Python 内存中的图结构，并不是专业图数据库。随着数据规模增加，持久化、并发访问以及复杂查询能力都会成为限制。

Neo4j

Neo4j 是比较经典的图数据库，支持节点、关系、属性以及 Cypher 查询语言。

适合：

持久化
复杂图查询
多跳关系查询
生产应用

NebulaGraph 等图数据库

对于更大规模的图数据，还可以选择分布式图数据库，例如 NebulaGraph 等。它们更加关注大规模图数据的存储和查询。

因此可以简单区分：

NetworkX
→ Python 图计算库

Neo4j
→ 图数据库

NebulaGraph
→ 分布式图数据库

十二、知识图谱的可视化

知识图谱天然适合可视化。

例如：

              CVE
             /   \
         HAS_CWE  AFFECTS
           /       \
         CWE      Product
          |
       DESCRIBES
          |
    Vulnerability
          |
       FIXED_BY
          |
      Remediation

通过可视化，可以直观观察：

哪些节点连接最多
哪些实体是核心节点
实体之间有哪些关系
是否存在异常关系
某个实体和哪些实体相关

NetworkX 可以结合 Matplotlib 进行基础图谱可视化，而 Gephi、Cytoscape 等工具更适合交互式和大规模图谱分析。

需要注意的是，图谱可视化和图谱存储是两个不同的问题。一个系统可以使用 Neo4j 存储图数据，再使用其他工具进行可视化。

十三、知识图谱适合什么场景

知识图谱尤其适合以下类型的问题：

搜索与推荐

例如：

用户
 ↓
兴趣
 ↓
内容
 ↓
作者

通过图关系可以实现更复杂的推荐。

风险分析

例如：

用户
 ↓
账号
 ↓
设备
 ↓
IP
 ↓
交易

可以利用关系发现异常行为。

医疗知识

例如：

疾病
 ↓
症状
 ↓
药物
 ↓
禁忌

用于辅助检索和知识管理。

网络安全

例如：

CVE
 ↓
CWE
 ↓
漏洞类型
 ↓
攻击方式
 ↓
受影响产品
 ↓
修复方案

非常适合构建安全知识库。

企业知识管理

例如：

公司
 ↓
部门
 ↓
员工
 ↓
项目
 ↓
文档

可以帮助企业建立统一知识网络。

十四、知识图谱并不是"把所有数据画成一张图"

这是实际开发中非常容易产生的误解。

知识图谱真正重要的是：

实体定义
+
关系定义
+
数据质量
+
实体对齐
+
查询能力
+
推理能力

图形只是知识图谱的一种展示方式。

例如下面这种漂亮的网络图：

●──●──●
 \ │ ╱
  ●─●
 / │ \
●──●──●

本身并不能说明它就是一个知识图谱。只有当节点具有明确语义、边表示具有业务含义的关系，并且这些关系能够被查询和利用时，才真正具有知识图谱的价值。

十五、知识图谱、图数据库、RAG 三者的关系

最后可以把这几个容易混淆的概念放在一起理解。

                 知识图谱
                    │
           表示实体和实体关系
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
      图数据库              图计算
          │                   │
       Neo4j              NetworkX
          │
          ↓
       持久化存储

而 RAG 是另外一层：

                RAG
                 │
       ┌─────────┴─────────┐
       ↓                   ↓
   Vector Search       Graph Search
       ↓                   ↓
     Qdrant          Knowledge Graph
       └─────────┬─────────┘
                 ↓
                LLM

所以：

知识图谱是一种知识组织方式，图数据库是一种存储和查询图数据的技术，NetworkX 是图计算库，而 RAG 是一种让模型利用外部知识生成答案的方法。

它们可以独立使用，也可以组合起来形成更加复杂的知识增强系统。