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 WebRDFOWL知识图谱学术论文企业知识管理甚至会觉得这东西是不是已经过时了但到了大模型和 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 GoGo 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操作 APIJSON现在变成直接说人话。例如用户问哪些系统部署在新加坡并且依赖 PostgreSQLLLM 可以把这个问题转换成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 TeamLLM 看到了这些文字。但它缺少的是一个统一的世界模型。而 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这是事实。再比如OntologyApplication deployedOn ServerKnowledge GraphPaymentService 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 部署在 ServerApplication 运行于 ContainerApplication 依赖 DatabaseApplication 由 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 领域还有一个非常重要的东西MCPModel Context Protocol。MCP 更侧重AI 如何连接外部工具和数据源。例如GitHub MCP Database MCP Slack MCP Filesystem MCP它告诉 AI有哪些工具可以调用。但 MCP 本身并不一定告诉 AI这些工具操作的对象之间是什么关系。例如GitHub Repository和Kubernetes Deployment可能其实属于同一个ApplicationOntology 可以把这种关系补出来。所以未来很可能出现Ontology 定义世界Knowledge Graph 记录事实MCP 连接工具LLM 理解用户Agent 完成任务这是一个非常值得关注的架构方向。十九、企业 AI 为什么尤其需要 Ontology个人 AI 应用可以容忍一定程度的模糊。企业应用不一样。企业数据经常存在一个非常现实的问题每个系统都有自己的语言。例如CRM 里面叫Customer订单系统叫User营销系统叫Member客服系统叫Client实际上可能全部都是客户如果 AI 直接访问不同系统它需要不断猜这几个是不是一回事Ontology 可以建立一个统一概念Customer然后CRM.Customer mapsTo CustomerOrder.User mapsTo CustomerMarketing.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 ReviewAI 可以自动发现新实体 新关系 冲突概念 重复概念 Schema 变化人只需要审核。这会大幅降低 Ontology 的维护成本。二十三、Ontology 甚至可以从代码里自动生成例如一个 Go 项目typeUserstruct{IDuint64}typeOrderstruct{UserIDuint64}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 AgentOntology 的角色发生了变化以前 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 给出了其中一个非常重要的答案。