Ontology 为什么突然又火了？从知识图谱到 AI Agent

本仓库是一个围绕 Ontology（本体论） 进行长期研究、学习与资料整理的开源项目，主要用于收集、归纳和研究 Ontology 相关的理论知识、技术资料、实践案例与应用方向，并进一步探索 Ontology 与 AI、大语言模型、知识图谱、Agent 等技术结合的可能性。

仓库中的部分内容来源于公开资料、论文、文档及社区资源，同时也会加入我个人在学习、实践过程中的理解、分析、总结与技术解读。目前仍有部分资料处于整理阶段，后续会在完成分类、校对和研究后陆续发布。

本仓库坚持 开放、免费、共享 的原则，所有整理内容主要用于技术研究、知识交流与学习参考，不以直接商业售卖资料为目的。对于引用或整理自第三方的内容，将尽可能注明原始来源，并遵守原作者、原始数据源及相关平台的版权、许可协议与使用规则。

请勿将本仓库中的任何资料、代码、方法或技术用于违法违规、侵犯他人权益或其他不当用途。使用者应自行判断相关内容的适用性与合规性，并对自己的使用行为及由此产生的结果承担相应责任。

除了持续维护本仓库之外，我也希望围绕 Ontology、知识图谱、AI + Ontology、企业知识建模、领域知识体系建设、Agent 知识架构等方向 进行更多实践与探索。

如有相关技术研究、项目落地、架构设计或企业应用需求，也可以提供 Ontology 相关技术咨询与顾问服务。

这个仓库不会只是一个资料集合，我更希望它最终能够成为一个持续演进的 Ontology 知识库、研究笔记与 AI 实践实验场。

https://github.com/Rodert/ontology

在这里插入图片描述

这两年，如果你一直在关注 AI、RAG、知识图谱、AI Agent，可能会发现一个有意思的现象：

一个原本看起来有点“古老”的概念，正在重新进入大家的视野。

它就是：

Ontology，本体论。

以前提到 Ontology，很多程序员第一反应往往是：

Semantic Web
RDF
OWL
知识图谱
学术论文
企业知识管理

甚至会觉得：

这东西是不是已经过时了？

但到了大模型和 AI Agent 时代，Ontology 反而重新变得重要起来。

原因并不是 Ontology 本身突然变了。

而是：

AI 系统正在从“会说话”，走向“理解一个复杂世界，并在这个世界里行动”。

当 AI 只需要生成文字时，Ontology 没那么重要。

但当 AI 开始需要理解：

用户是谁；
一个服务依赖哪些数据库；
一家公司有哪些产品；
一个订单属于哪个客户；
一个服务器宕机会影响哪些业务；
一个 Agent 可以调用哪些工具；
一个工具能够操作哪些对象；

这时候，仅仅依靠自然语言和向量数据库就开始不够用了。

于是一个很多年前就存在的问题重新出现：

机器到底应该如何理解“这个世界是由什么组成的”？

而这，恰好就是 Ontology 擅长解决的问题。

在这里插入图片描述

一、Ontology 并不是一个新概念

Ontology 的历史比大模型早得多。

它最早来自哲学。

哲学里的 Ontology 研究的是：

什么东西是存在的？

后来进入计算机科学以后，它逐渐变成一种知识建模方法。

计算机领域里的 Ontology，通常可以理解成：

对某个领域中的概念、实体、关系、属性和规则进行形式化定义。

比如一个电商领域，可以定义：

User
Order
Product
Merchant
Payment
Logistics

然后定义它们之间的关系：

User creates Order

Order contains Product

Merchant sells Product

Order has Payment

Order has Logistics

再进一步：

PaidOrder is-a Order

PaidOrder canBeShipped true

这样，我们就不仅拥有了一堆数据。

而是拥有了一套：

对这个业务世界的定义。

这就是 Ontology。

二、为什么早期 Ontology 没有真正“普及”？

如果 Ontology 这么有价值，为什么过去二十年它没有成为所有程序员的标配？

一个重要原因是：

它太重了。

早期 Semantic Web 的理想非常宏大。

希望互联网不仅让人能阅读网页，也让机器能够真正理解网页里的语义。

于是产生了一套技术体系：

RDF
OWL
SPARQL
Ontology
Reasoner
Linked Data

理论上非常漂亮。

例如知识可以写成：

JavaPub creator 王仕宇

或者：

Gin writtenIn Go

Go isA ProgrammingLanguage

所有信息都被组织成：

Subject
Predicate
Object

也就是经典的三元组。

但真正落地的时候，问题来了。

三、问题一：建 Ontology 太贵

要建立一个真正可用的 Ontology，通常需要大量领域专家参与。

例如你要构建一个医疗 Ontology。

需要定义：

Disease
Symptom
Drug
Treatment
Patient
Doctor
Department

还需要定义大量关系：

Disease hasSymptom Symptom

Drug treats Disease

Patient diagnosedWith Disease

进一步还可能存在：

同义词

上下位关系

排斥关系

逆关系

传递关系

数量约束

这实际上是一个巨大的知识工程。

而知识工程最贵的部分往往不是技术。

而是：

人工。

以前机器没有能力自动完成这些事情。

于是企业要花大量人力：

整理知识
→ 建模
→ 标注实体
→ 建立关系
→ 数据清洗
→ 持续维护

成本非常高。

四、问题二：Ontology 建好了，但普通用户不会用

即使企业花了很多钱构建 Ontology，还面临另外一个问题：

普通人不会 SPARQL。

例如知识图谱里面存在：

Application
Server
Database

关系：

Application deployedOn Server

Application dependsOn Database

专业人员可以写 SPARQL 查询：

SELECT ?app
WHERE {
  ?app :dependsOn :Database01 .
}

但是普通业务人员真正想问的是：

哪些系统依赖 Database01？

以前，这中间存在一道巨大的使用门槛。

用户说自然语言。

机器要求结构化查询语言。

所以很多知识图谱最终变成：

很强，但是不好用。

五、然后 LLM 出现了

大模型改变了一件极其重要的事情：

自然语言第一次真正成为了软件系统的通用接口。

以前操作数据库：

SQL

操作搜索引擎：

Query DSL

操作知识图谱：

SPARQL

操作 API：

JSON

现在变成：

直接说人话。

例如用户问：

哪些系统部署在新加坡，并且依赖 PostgreSQL？

LLM 可以把这个问题转换成：

Entity:
Application

Condition:
deployedIn = Singapore

Relation:
dependsOn PostgreSQL

然后再转换成图查询。

也就是说：

LLM 把 Ontology 和普通用户之间的最后一公里补上了。

这件事情非常关键。

六、大模型解决了 Ontology 最难的一部分

过去构建 Ontology 最痛苦的是：

人工抽取

现在 LLM 可以帮助完成：

实体识别

关系抽取

概念归类

Schema 推荐

文本结构化

知识对齐

例如有一份技术文档：

支付服务部署在 Server01，
使用 PostgreSQL 作为数据库，
通过 Redis 做缓存。

LLM 很容易抽取成：

PaymentService instanceOf Application

PaymentService deployedOn Server01

PaymentService uses PostgreSQL

PaymentService uses Redis

也就是说：

原本最昂贵的知识工程工作，正在被 AI 大幅降低成本。

这也是 Ontology 重新受到关注的重要原因之一。

七、但反过来，大模型也暴露出了一个巨大问题

LLM 很强。

但是它的知识结构其实非常模糊。

例如你问：

Redis 是什么？

它知道。

你问：

PostgreSQL 是什么？

它也知道。

你问：

PaymentService 是什么？

如果这是你公司内部系统，它就不知道了。

即使你通过 RAG 把资料给它，它仍然面临一个问题：

企业知识非常分散。

可能存在：

Wiki
GitHub
数据库
API
监控系统
CMDB
工单
日志
Slack
邮件

LLM 可以理解每一段文本。

但它未必知道这些信息之间的稳定关系。

例如：

PaymentService

可能同时出现在：

GitHub Repository

Kubernetes Deployment

Domain

API Gateway

Database Connection

Owner Team

LLM 看到了这些文字。

但它缺少的是：

一个统一的世界模型。

而 Ontology 正是用来干这个的。

八、LLM 的问题不是“不知道”，而是“不稳定”

这是非常重要的一点。

大模型的问题很多时候并不是：

它完全不知道答案。

而是：

它对知识的结构化理解不稳定。

例如：

Employee is-a Person

Developer is-a Employee

按照逻辑：

Developer is-a Person

这是一个确定规则。

Ontology 可以明确表达。

但 LLM 的知识并不是像数据库一样：

row
column
relation
constraint

存在。

它是通过参数分布保存知识。

所以：

LLM 很擅长“模糊理解”。

但企业系统往往需要：

“明确关系”。

九、这就是 Ontology 和 LLM 的互补关系

可以把二者简单理解成：

LLM
负责理解语言

Ontology
负责定义世界

LLM 擅长：

语言理解
文本生成
知识归纳
模糊推理
意图识别

Ontology 擅长：

实体定义
关系定义
规则定义
语义统一
逻辑约束

二者结合以后：

Natural Language
        ↓
       LLM
        ↓
    Ontology
        ↓
Knowledge Graph

用户说人话。

LLM 理解问题。

Ontology 告诉 AI：

这个世界有哪些东西。

知识图谱告诉 AI：

现实里有哪些具体事实。

十、Ontology 和知识图谱并不是一回事

这是一个经常被混淆的问题。

最简单的理解：

Ontology = 世界规则

Knowledge Graph = 世界事实

例如 Ontology 定义：

Person worksFor Company

这是规则。

知识图谱里面可能存在：

张三 worksFor CompanyA

李四 worksFor CompanyB

这是事实。

再比如：

Ontology：

Application deployedOn Server

Knowledge Graph：

PaymentService deployedOn Server01

所以可以类比数据库：

Ontology ≈ Schema

Knowledge Graph ≈ Data

当然，两者实际上比传统数据库 Schema 和 Data 的关系更加丰富。

十一、为什么 RAG 出现以后 Ontology 更重要了？

RAG，全称：

Retrieval-Augmented Generation

也就是：

检索增强生成。

典型架构：

Document
   ↓
Chunk
   ↓
Embedding
   ↓
Vector Database
   ↓
Similarity Search
   ↓
LLM

它解决了一个非常关键的问题：

LLM 不知道企业私有数据怎么办？

答案就是：

搜出来，再塞给模型。

这套方法非常有效。

但它也有天然限制。

十二、Vector RAG 本质上是在找“相似文本”

例如用户问：

PaymentService 使用什么数据库？

Embedding 会搜索和：

PaymentService
数据库

语义相似的文本。

如果某份文档刚好写着：

PaymentService 使用 PostgreSQL。

那非常容易回答。

但如果问题变成：

Server01 宕机以后会影响哪些用户支付业务？

关系可能是：

User
 ↓
Order
 ↓
PaymentService
 ↓
Server01

这些信息可能散落在四份不同文档里。

Vector Search 能找到相似文本。

但是：

它并不天然擅长做关系链查询。

十三、于是 GraphRAG 出现了

GraphRAG 的核心思想可以简单理解成：

不只是搜索文本，还要搜索知识之间的关系。

例如知识图谱：

PaymentService
      │
 deployedOn
      ↓
   Server01

同时：

CheckoutService
      │
  dependsOn
      ↓
PaymentService

那么如果 Server01 出问题：

系统可以沿图查询：

Server01
   ↑
PaymentService
   ↑
CheckoutService

于是回答：

Server01 故障可能影响 PaymentService，并进一步影响 CheckoutService。

这就是图结构的优势。

十四、Ontology 在 GraphRAG 中解决什么问题？

如果知识图谱是一张地图，

那么 Ontology 就像：

地图图例 + 世界规则。

它定义：

Application
Server
Database
Team
Developer
Domain

以及：

Application deployedOn Server

Application ownedBy Team

Application dependsOn Database

Domain pointsTo Application

如果没有 Ontology，知识图谱很容易变成：

一堆杂乱的节点和边。

不同数据源可能出现：

app
application
service
system
program

实际上可能表达的是同一种东西。

Ontology 可以统一为：

Application

这就是：

语义统一。

十五、真正让 Ontology 再次变得重要的，是 AI Agent

如果说 RAG 让 Ontology 开始重新被关注，

那么 AI Agent 才真正把 Ontology 推到了更重要的位置。

原因是：

Agent 不只是需要知道知识。

Agent 还需要：

行动。

例如一个 DevOps Agent。

它不仅要回答：

PaymentService 部署在哪？

还可能需要执行：

查看 Server01 状态

检查 Kubernetes Pod

读取日志

切换流量

通知负责人

这时候 AI 必须真正理解：

Application

Server

Container

Deployment

Database

Domain

Team

Developer

之间的关系。

十六、Agent 如果没有世界模型，会发生什么？

想象一个 AI Agent 拿到了 100 个 API。

例如：

get_server_status

restart_container

query_database

update_dns

send_message

create_ticket

如果没有统一语义模型，

它看到的只是：

100 个 Tool。

但一个成熟 Agent 真正需要知道的是：

Application
部署在
Server

Application
运行于
Container

Application
依赖
Database

Application
由
Team
负责

然后：

Team
包含
Developer

这样 Agent 才能真正理解：

我现在操作的是谁？

这个操作会影响什么？

下一步应该找哪个工具？

十七、Ontology 本质上可以成为 Agent 的“世界地图”

这是我认为 AI Agent 时代非常重要的一个概念。

未来 Agent 可能拥有三张地图。

第一张：

Knowledge Map

它告诉 Agent：

世界里有什么。

第二张：

Tool Map

它告诉 Agent：

我能做什么。

第三张：

Policy Map

它告诉 Agent：

什么能做，什么不能做。

而 Ontology 很可能会参与第一张甚至第二张地图的构建。

例如：

Server

可以绑定工具：

getStatus()

restart()

getLogs()

Database

绑定：

query()

backup()

checkConnection()

Domain

绑定：

resolveDNS()

updateDNS()

这样 Agent 不再只是：

LLM + Tool Calling。

而变成：

LLM
+
Ontology
+
Knowledge Graph
+
Tools
+
Policies

十八、这也解释了 Ontology 和 MCP 的关系

现在 AI Agent 领域还有一个非常重要的东西：

MCP

Model Context Protocol。

MCP 更侧重：

AI 如何连接外部工具和数据源。

例如：

GitHub MCP

Database MCP

Slack MCP

Filesystem MCP

它告诉 AI：

有哪些工具可以调用。

但 MCP 本身并不一定告诉 AI：

这些工具操作的对象之间是什么关系。

例如：

GitHub Repository

和：

Kubernetes Deployment

可能其实属于同一个：

Application

Ontology 可以把这种关系补出来。

所以未来很可能出现：

Ontology
定义世界

Knowledge Graph
记录事实

MCP
连接工具

LLM
理解用户

Agent
完成任务

这是一个非常值得关注的架构方向。

十九、企业 AI 为什么尤其需要 Ontology？

个人 AI 应用可以容忍一定程度的模糊。

企业应用不一样。

企业数据经常存在一个非常现实的问题：

每个系统都有自己的语言。

例如：

CRM 里面叫：

Customer

订单系统叫：

User

营销系统叫：

Member

客服系统叫：

Client

实际上可能全部都是：

客户

如果 AI 直接访问不同系统，

它需要不断猜：

这几个是不是一回事？

Ontology 可以建立一个统一概念：

Customer

然后：

CRM.Customer
mapsTo Customer

Order.User
mapsTo Customer

Marketing.Member
mapsTo Customer

于是整个企业开始拥有：

统一语义层。

二十、这也是“Semantic Layer”越来越重要的原因

传统数据架构里经常有：

Storage Layer

存储层。

后来有：

Data Warehouse

数据仓库。

再后来有：

Data Lake

数据湖。

AI 时代，企业可能越来越需要：

Semantic Layer

语义层。

它解决的不是：

数据在哪里？

而是：

数据是什么意思？

例如：

GMV

到底怎么算？

Customer

到底指什么？

ActiveUser

什么才算活跃？

这些都属于：

语义定义。

Ontology 就可以成为 Semantic Layer 的重要组成部分。

二十一、一个完整的企业 AI 架构可能长这样

过去：

Application
    ↓
Database

后来：

Application
    ↓
Database
    ↓
Data Warehouse

现在：

Application
    ↓
LLM
    ↓
Vector Database

未来越来越可能出现：

              ┌─────────────┐
              │    User     │
              └──────┬──────┘
                     ↓
              ┌─────────────┐
              │     LLM     │
              └──────┬──────┘
                     ↓
        ┌─────────────────────────┐
        │    Semantic Layer       │
        │                         │
        │ Ontology                │
        │ Knowledge Graph         │
        │ Vector Search           │
        └────────────┬────────────┘
                     ↓
       ┌──────────────────────────┐
       │ Enterprise Data Sources  │
       │                          │
       │ Database                 │
       │ Documents                │
       │ APIs                     │
       │ GitHub                   │
       │ CRM                      │
       └──────────────────────────┘
                     ↓
              ┌─────────────┐
              │    Agent    │
              └──────┬──────┘
                     ↓
              ┌─────────────┐
              │    Tools    │
              └─────────────┘

这个架构和早期 Semantic Web 最大的不同是：

用户不需要理解 Ontology。

甚至开发者都未必需要直接写 SPARQL。

LLM 会成为中间层。

二十二、LLM 让 Ontology 从“人维护”变成“AI 辅助维护”

过去维护 Ontology：

专家
 ↓
人工分析
 ↓
人工建模
 ↓
人工录入

未来可能变成：

Document
Database
API
Code
 ↓
LLM
 ↓
Entity Extraction
Relationship Extraction
 ↓
Ontology Alignment
 ↓
Human Review

AI 可以自动发现：

新实体

新关系

冲突概念

重复概念

Schema 变化

人只需要：

审核。

这会大幅降低 Ontology 的维护成本。

二十三、Ontology 甚至可以从代码里自动生成

例如一个 Go 项目：

type User struct {
    ID uint64
}

type Order struct {
    UserID uint64
}

AI 可以推测：

User
creates
Order

再结合：

SQL Schema

API Schema

代码

文档

推导出：

Application
API
Database
Entity
Relationship

这意味着未来：

Ontology 不一定由人从零开始画。

而可能由 AI 从现有系统中自动学习。

二十四、但 Ontology 也不是万能药

这里必须强调一点。

Ontology 最近重新受到关注，

并不代表：

所有 AI 项目都应该上 Ontology。

对于：

普通聊天机器人

简单 FAQ

文档问答

个人知识库

简单 RAG

很多时候：

Embedding
+
Vector Database
+
LLM

就足够了。

如果业务关系非常简单，

强行加入 Ontology 反而会：

增加开发成本

增加维护成本

增加数据治理成本

二十五、什么时候值得使用 Ontology？

我认为出现以下情况时值得认真考虑。

第一，领域复杂

例如：

金融

医疗

工业

企业 IT

供应链

科研

存在大量概念和关系。

第二，跨系统很多

例如：

CRM

ERP

GitHub

CMDB

Kubernetes

数据库

监控系统

需要统一理解。

第三，需要复杂关系查询

比如：

哪些应用依赖这个数据库？

这个服务器故障会影响哪些业务？

哪些客户购买过某类商品？

第四，需要 Agent 自动执行

因为 Agent 在执行动作之前，

必须更准确地理解：

对象之间的关系。

二十六、未来真正重要的可能不是“大模型知道多少”

大模型的参数规模仍然会继续增长。

模型能力也会继续增强。

但企业 AI 最终真正需要解决的问题可能会逐渐变成：

模型如何理解我的世界？

比如一个企业自己的世界：

员工

客户

产品

系统

服务器

数据库

合同

订单

供应商

流程

这些东西 ChatGPT 不可能天然全部知道。

因为：

每个企业都有自己的世界。

Ontology 的意义就在这里。

它不是告诉 AI：

整个宇宙是什么。

而是告诉 AI：

在我的业务世界里，什么东西是什么。

二十七、从知识图谱到 AI Agent，Ontology 的角色发生了变化

以前 Ontology 更多被认为是：

知识图谱 Schema。

现在它可能逐渐变成：

AI 的世界模型。

过去：

Ontology
     ↓
Knowledge Graph
     ↓
Search

未来：

Ontology
     ↓
Knowledge Graph
     ↓
LLM
     ↓
Agent
     ↓
Action

它不再只是帮助机器：

找知识。

而是开始帮助机器：

理解世界并做事情。

这是一个非常关键的变化。

二十八、未来 AI Agent 的竞争，可能也是“世界模型”的竞争

未来不同 Agent 的差距，

可能不只是：

用了 GPT

用了 Claude

用了 Gemini

因为基础模型之间的差距可能越来越小。

真正决定 Agent 能力的可能还有：

Context

Memory

Tools

Knowledge Graph

Ontology

Workflow

Permission

其中 Ontology 决定：

Agent 对这个领域理解得有多深。

例如一个医疗 Agent，

如果它拥有一个成熟医疗 Ontology，

那么它对：

疾病

症状

药物

检查

治疗

患者

之间关系的理解会远强于一个只有文档 RAG 的系统。

二十九、我们正在从“语言模型”走向“世界模型”

过去几年 AI 最大的突破是：

让机器理解语言。

接下来更大的挑战可能是：

让机器理解世界。

而真实世界不是一堆孤立文本。

真实世界是：

Entity
+
Relationship
+
Rule
+
State
+
Action

比如：

用户
创建
订单

订单
包含
商品

商品
属于
商家

订单
支付完成后
才能发货

这就是一个世界模型。

而 Ontology 恰好是一种非常成熟的：

描述世界模型的方法。

三十、结语

Ontology 并不是因为出现了什么全新的技术，才突然重新受到关注。

恰恰相反。

它已经存在很多年。

真正发生变化的是：

AI 终于发展到了需要它的时候。

过去的 AI：

搜索

需要关键词。

后来：

RAG

需要文本。

现在：

AI Agent

开始需要：

世界。

而这个世界需要被定义。

所以可以用一句话概括 Ontology 在 AI 时代的新角色：

LLM 负责理解语言，RAG 负责寻找知识，知识图谱负责连接事实，Ontology 负责定义世界，Agent 负责在这个世界里行动。

这也是为什么一个看起来已经有几十年历史的概念，

今天又重新站到了 AI 技术栈的中央。

因为当 AI 从：

“会聊天”

走向：

“会理解、会判断、会执行”

我们最终都会面对同一个问题：

机器眼里的世界，到底应该长什么样？

Ontology 给出了其中一个非常重要的答案。

在这里插入图片描述

posted @ 2026-08-13 10:35 JavaPub 阅读(64) 评论(0) 收藏举报

刷新页面返回顶部

JavaPub

少年应有鸿鹄志，当骑骏马踏平川。

Ontology 为什么突然又火了？从知识图谱到 AI Agent

一、Ontology 并不是一个新概念

二、为什么早期 Ontology 没有真正“普及”？

三、问题一：建 Ontology 太贵

四、问题二：Ontology 建好了，但普通用户不会用

五、然后 LLM 出现了

六、大模型解决了 Ontology 最难的一部分

七、但反过来，大模型也暴露出了一个巨大问题

八、LLM 的问题不是“不知道”，而是“不稳定”

九、这就是 Ontology 和 LLM 的互补关系

十、Ontology 和知识图谱并不是一回事

十一、为什么 RAG 出现以后 Ontology 更重要了？

十二、Vector RAG 本质上是在找“相似文本”

十三、于是 GraphRAG 出现了

十四、Ontology 在 GraphRAG 中解决什么问题？

十五、真正让 Ontology 再次变得重要的，是 AI Agent

十六、Agent 如果没有世界模型，会发生什么？

十七、Ontology 本质上可以成为 Agent 的“世界地图”

十八、这也解释了 Ontology 和 MCP 的关系

十九、企业 AI 为什么尤其需要 Ontology？

二十、这也是“Semantic Layer”越来越重要的原因

二十一、一个完整的企业 AI 架构可能长这样

二十二、LLM 让 Ontology 从“人维护”变成“AI 辅助维护”

二十三、Ontology 甚至可以从代码里自动生成

二十四、但 Ontology 也不是万能药

二十五、什么时候值得使用 Ontology？

第一，领域复杂

第二，跨系统很多

第三，需要复杂关系查询

第四，需要 Agent 自动执行

二十六、未来真正重要的可能不是“大模型知道多少”

二十七、从知识图谱到 AI Agent，Ontology 的角色发生了变化

二十八、未来 AI Agent 的竞争，可能也是“世界模型”的竞争

二十九、我们正在从“语言模型”走向“世界模型”

三十、结语

公告