## 先看两组真实数据

先抛两个问题，你所在的团队大概率正在经历：

**问题一**：某股份制银行把客户征信、交易流水、关联企业数据建成了企业关联图谱（覆盖股权、担保、交易等 15 种关系类型），贷前审查时间从 **72 小时缩短到 4 小时**，关联企业风险识别率提升 **60%**，担保圈风险预警金额超过 **5 亿元**。靠的是关键词搜索？不，是图谱里的"担保链—资金往来—股权穿透"多跳关系。

**问题二**：同一份 5000 篇技术文档的语料库，纯向量 RAG 回答多跳问题（涉及 5 个以上实体）时准确率**急剧下降**；而基于知识图谱的 GraphRAG，综合类查询准确率从约 **50% 提升到 80%**（Lettria/AWS 实测：80% vs 50.8%；AIMultiple 2025 评估：跨文档推理命中率 33% vs 8%，是纯向量的 **4 倍**）。

这两组数据的背后，是四个概念的分工与配合：**本体（Ontology）、知识图谱、业务数据、RAG**。这篇文章把它们彻底讲透——不是名词解释，而是"四层分工 + 真实案例 + 落地架构"。

---

## 一句话记住四层分工

> **本体管"形"，业务数据管"值"，知识图谱是两者的交汇，RAG 是最后让 AI 用起来的那一层。**

| 概念               | 管什么               | 打比方       | 一句话定位                 |
| ---------------- | ----------------- | --------- | --------------------- |
| **本体（Ontology）** | 管"形"：概念、关系、属性、约束  | **图纸**    | 知识图谱的 Schema          |
| **知识图谱**         | 管"关联"：实体间实际关系     | **建成的大楼** | 本体（骨架）+ 实例（血肉）        |
| **业务数据**         | 管"值"：事实的当前值       | **砖瓦建材**  | 事实权威，图谱靠 sourceKey 回源 |
| **RAG**          | 管"用"：让 AI 答得准、可溯源 | **装修队**   | 应用层，GraphRAG 补关系短板    |

---

## 本体（Ontology）：那张"图纸"

**定义**：本体是对某个领域内**概念、概念间关系、属性、实例**的显式形式化规格说明（Gruber, 1993：*An explicit specification of a conceptualization*）。

四个要素用威胁情报领域举例：

- **类**：`ThreatActor`（威胁行为体）、`Vulnerability`（漏洞）、`Malware`（恶意软件）、`Product`（产品）
- **关系**：`ThreatActor exploits Vulnerability`（利用）
- **属性**：漏洞必须有 `cveId`、`severity`
- **实例**：`APT29` 是 ThreatActor 的一个实例

**为什么非要有这张图纸？** 因为不一致的语义是 AI 跨系统理解的死敌。A 系统叫 `vuln`，B 系统叫 `CVE`，C 系统叫 `weakness`——没有本体统一口径，RAG 检索到的"事实"互相打架，越查越乱。银行的风险图谱能跨 12 个业务系统识别"母公司担保—子公司融资—关联交易"链条，前提就是先有统一的"企业—股东—交易"本体。

**本体的价值在推理**：图纸不止是约束，还能推导。`Backdoor ⊑ Malware`（后门是恶意软件的子类），那么声明了 `HAMMERTOSS a Backdoor` 的实例，推理机就能推出 `HAMMERTOSS a Malware`——不用每条事实都写全。

---

## 知识图谱：图纸 + 建成的大楼

**知识图谱 = 本体（骨架）+ 实例（血肉）**，用"实体—关系—实体"三元组组织。5 条威胁情报灌进去，长这样：

```
APT29 ──exploits──► CVE-2024-3400 ──affects──► PAN-OS
   │                    │
   └──attributedTo──► Russia
```

**关键认知**：图纸决定楼的结构，但楼里住着谁（实例）是后填的——这就是 TBox（模式层）/ ABox（实例层）分离的工程基础，后文第 2 篇详述。

---

## 业务数据：砖瓦，也是唯一权威

企业里每天在变的是业务数据：工单、缺陷、漏洞库、客户需求。它们是**事实的权威来源（source of truth）**。

这里必须打破一个最普遍的误解：**知识图谱不是业务数据的全量副本，而是"瘦视图"**——只存支撑关系查询和推理的实体、关系、关键属性，明细靠一个 `sourceKey` 字段回指业务库。

为什么？两个原因：

1. **维护成本**：图谱若做全量同步，会膨胀成难以治理的脏数据仓库（真实案例：某 GraphRAG 项目从 1,028 篇论文里抽出 390,864 条原始三元组，经实体消解收敛为 36,757 个规范实体——原始数据里充斥着同名异写、关系噪声，全量进图谱是灾难）
2. **职责边界**：业务库管"当前状态"（这个漏洞今天修了没），图谱管"关系网络"（谁攻击了谁）。混在一起，两边都做不好

---

## RAG：装修队，让知识被用起来

**RAG**：先检索私有知识，再让大模型基于检索结果生成答案，解决"模型不知道私有知识 / 幻觉 / 无法更新"三大问题。

但**纯向量检索有结构性短板**——抓不住多跳关系。你问"APT29 利用的漏洞影响的产品是谁开发的"，答案藏在 `APT29→CVE→PAN-OS→Palo Alto` 这条关系链里，任何单一文档碎片里都没有这句话。实测数据很扎心：

| 查询类型               | 纯向量 RAG  | 图谱增强（GraphRAG） |
| ------------------ | -------- | -------------- |
| 单跳事实查询（"退款政策是什么"）  | ✅ 强      | ✅ 相当           |
| 多跳关系查询（"基因—通路—药物"） | ❌ 50.8%  | ✅ 80%          |
| 跨文档聚合查询            | ❌ 命中率 8% | ✅ 命中率 23%（3x）  |
| 跨文档推理              | ❌ 命中率 8% | ✅ 命中率 33%（4x）  |
| 全局趋势 / KPI 类查询     | ❌ 接近 0   | ✅ 稳定输出         |

（数据来源：Lettria×AWS 基准、AIMultiple 2025 评估、Microsoft GraphRAG 论文）

所以 GraphRAG 的正确姿势是：**向量负责模糊召回"找到门"，图谱负责沿边多跳"推开里面的门"，业务库负责"明细回源"**。

---

## 四层如何协作：一张真实系统的架构

![01-四层分工.jpg](https://developer.qcloudimg.com/http-save/yehe-11479707/0cf9e8c92db85616003b1e152fea190b.jpg)

一个可落地的企业知识系统架构：

```
业务系统（ERP / 工单 / 漏洞库 / 需求池）
   │  CDC / 事件流（幂等 upsert，带 version + sourceKey）
   ▼
知识图谱（Neo4j / Oxigraph / Jena）◄── 本体（OWL + SHACL 约束形状）
   │  瘦视图：只存实体、关系、关键属性
   ▼
检索层：向量库（Milvus / pgvector）召回入口 + 图谱多跳展开
   ▼
RAG / Agent：带引用（sourceDoc + 置信度）的答案
```

**一致性原则**：业务库是唯一权威 → 单向流 → 图谱"过期标记 + 对账回源"（有界最终一致），**绝不搞 ACID 双写**。详细存储方案见第 4 篇。

---

## 常见误区速查（开发者的高频坑）

| 误区                  | 真相                                                    |
| ------------------- | ----------------------------------------------------- |
| "知识图谱就是把文档塞进 Neo4j" | 图谱只存关系网络（瘦视图），明细在业务库                                  |
| "有了大模型就不需要本体了"      | LLM 负责抽取和起草，但输出的**一致性校验**靠 OWL/SHACL——LLM 是提案者，规则是审批者 |
| "向量 RAG 能替代图谱"      | 单跳查询可以；多跳/聚合/时序查询，向量 RAG 有结构性天花板（上文数据）                |
| "本体一次建好永不改"         | Schema 会演进，TBox/ABox 分离 + 版本冻结才是正解（第 5 篇）             |

---

## 本篇小结

1. **本体管"形"**：定义概念、关系、约束，是消除语义歧义、支撑推理的图纸
2. **知识图谱是交汇**：本体（骨架）+ 实例（血肉），存的是关系网络
3. **业务数据管"值"**：唯一权威，图谱只是瘦视图，`sourceKey` 回源
4. **RAG 管"用"**：纯向量抓不住多跳关系，GraphRAG 是关系型问题的正解

> 记住一句话：**本体管"形"、业务数据管"值"、图谱是交汇、RAG 是用。** 后面四篇全是这句话的展开。

---

## 参考资料

- [Microsoft GraphRAG: LLM-derived Knowledge Graphs for RAG](https://arxiv.org/abs/2404.16130)
- [GraphRAG - AI Wiki（LazyGraphRAG 与对比数据）](https://aiwiki.ai/wiki/graphrag)
- [Knowledge Graphs for AI Agents: Beyond Vector Search](https://swarmsignal.net/knowledge-graphs-for-ai-agents)
- [知识图谱如何重塑大模型推理（医疗/金融/法律案例数据）](https://m.betteryeah.com/blog/knowledge-graph-enhanced-llm-reasoning-complete-guide)
- [自然语言处理十年蝶变：知识图谱的技术演进与产业实践（百度）](https://cloud.baidu.com/article/4320366)


问题一：某股份制银行把客户征信、交易流水、关联企业数据建成了企业关联图谱（覆盖股权、担保、交易等 15 种关系类型），贷前审查时间从 72 小时缩短到 4 小时，关联企业风险识别率提升 60%，担保圈风险预警金额超过 5 亿元。靠的是关键词搜索？不，是图谱里的"担保链—资金往来—股权穿透"多跳关系。

一文讲透本体、知识图谱、RAG：一张图看懂"形 / 图 / 值 / 用"四层分工

一文讲透本体、知识图谱、RAG，·目标读者：后端 / 算法 / 平台工程师

运维开发工程师

人工智能

架构设计

数据库

本体管"形"、业务数据管"值"、知识图谱是两者交汇、RAG让AI用起来。基于银行风控与GraphRAG实测数据，本文讲透四层分工、落地架构与常见误区，揭示纯向量RAG在多跳查询上的结构性短板（准确率50.8%vs80%），给出企业知识系统可落地的工程方案。

自然语言处理

大模型推理

威胁情报

知识图谱

数据仓库

代码解释

风险识别

Agent

2026上云采购 | AI焕新·智启新局

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一文讲透本体、知识图谱、RAG：一张图看懂"形 / 图 / 值 / 用"四层分工-腾讯云开发者社区-腾讯云

一文讲透本体、知识图谱、RAG：一张图看懂"形 / 图 / 值 / 用"四层分工

一文讲透本体、知识图谱、RAG：一张图看懂"形 / 图 / 值 / 用"四层分工

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐