知识图谱+大语言模型：为什么结构化知识正在重新变得重要？

一、LLM出现后，知识图谱过时了吗？

大语言模型刚兴起时，一些观点认为：

“模型什么都能理解，以后不需要知识图谱了。”

但实际工程恰恰显示，两者并不是竞争关系。

LLM擅长：

• 自然语言理解；
• 信息抽取；
• 内容生成；
• 模糊语义推理。

知识图谱擅长：

• 表达实体；
• 表达明确关系；
• 路径查询；
• 可解释查询；
• 结构化约束。

二者非常互补。

---

二、什么是知识图谱？

最简单的知识图谱由三元组组成：

实体1 —关系→ 实体2

例如：

NX —开发商→ Siemens
NX —属于→ CAD软件
NX —支持→ 参数化建模

对应：

graph LR
A[NX] -->|开发商| B[Siemens]
A -->|属于| C[CAD软件]
A -->|支持| D[参数化建模]

这种方式让计算机不仅知道：

“文档中出现过NX。”

还知道：

“NX是什么，以及它与其他知识有什么关系。”

---

三、LLM可以帮助知识图谱自动构建

传统知识图谱建设最大的痛点之一是：

数据整理成本太高。

过去往往需要人工定义规则：

if "公司" in sentence:
    ...

而现在可以让LLM从自然语言中抽取结构。

输入：

小米公司于2010年成立，雷军是主要创始人之一。

要求模型输出：

{
  "entities": [
    {"name": "小米公司", "type": "Company"},
    {"name": "雷军", "type": "Person"}
  ],
  "relations": [
    {
      "source": "雷军",
      "relation": "创始人",
      "target": "小米公司"
    }
  ]
}

这样，大模型成为了知识图谱的“信息抽取器”。

---

四、知识图谱又可以反过来帮助LLM

用户询问：

“A项目负责人所在部门还有哪些项目？”

系统可以首先进行图查询：

A项目
 ↓负责人
张三
 ↓所属部门
研发部
 ↓负责项目
项目B / 项目C

再把结果交给LLM组织语言。

flowchart LR

A[用户问题]
--> B[LLM理解]

B --> C[生成图查询]

C --> D[(Knowledge Graph)]

D --> E[结构化结果]

E --> F[LLM]

F --> G[自然语言答案]

---

五、图数据库与向量数据库可以一起使用

实际系统不一定二选一。

可以同时使用：

Vector DB
+
Graph DB
+
Relational DB

例如用户问：

“A设备最近频繁出现振动异常，可能与哪些部件有关？”

系统可以：

1. 向量数据库检索维修文档；
2. 图数据库查询设备零件关系；
3. SQL查询传感器历史数据；
4. LLM综合判断。

架构如下：

flowchart TD

A[用户问题] --> B[LLM Router]

B --> C[(Vector DB)]
B --> D[(Graph DB)]
B --> E[(SQL DB)]

C --> F[文本知识]
D --> G[关系知识]
E --> H[实时数据]

F --> I[LLM推理]
G --> I
H --> I

I --> J[答案]

---

六、知识图谱还有一个重要优势：可解释性

如果模型直接回答：

“A零件可能是故障源。”

用户可能会问：

为什么？

而图谱可以提供明确路径：

设备X
→包含
模块Y
→包含
零件A
→历史故障
振动异常

这条关系链本身就是一种证据。

---

总结

大语言模型让机器越来越擅长理解非结构化语言。

知识图谱则让机器能够明确表达：

谁、是什么、和谁有什么关系。

未来比较成熟的知识系统，可能并不是：

LLM OR Knowledge Graph

而是：

LLM
+
Vector Database
+
Knowledge Graph
+
Structured Database

让模型同时拥有语言能力、语义搜索能力和结构化知识推理能力。