现阶段本体论和知识图谱出现的频率越来越高但我看很多文章的讲解似乎没太说到精髓所以今天我尝试结合过往经历把这个事情聊得更具体点。首先要说明的是本体论和知识图谱出现的时间早在大模型之前只不过之前一直运行得不好罢了。为什么呢答案很简单成本太高了无论本体论还是知识图谱都是一种非常**“精细而脆弱”**的技术举个例子第一当时做实体链接是已经很困难的事情比如苹果这个词到底是水果还是公司需要很多规则维护而实际使用文本稍微变一点点比如 iPhone、苹果手机这种人类看得懂规则看不懂的东西出现规则就会崩。一句话来说就是当时从技术上要做到最简单的语义泛化是非常难的这里大家可能有点无法理解我再举个例子在大模型之前我们如果做微信群维护需要大家将昵称固定位昵称-城市-岗位的方式想要靠程序去搞定就一定做不到而且你不能说他们的“表达”就一定错比如昵称_城市_岗位昵称城市-岗位城市-昵称-岗位…这些规则连初中生都可以识别但程序就是不行无论你怎么写规则、怎么做正则表达式都做不到虽然做不到完全覆盖但这里会写非常多的规则这些规则就是巨大的成本。第二当时做关系抽取时候也是全靠语料标注 传统SVN这种东西成本巨高而且换个行业还可能用不了第三就是更新成本了当时做本体构建的时候需要靠领域专家去手工画图一个中型企业的本体就可能搞几个月但业务一更新这套东西就全完蛋所以无论是知识图谱还是本体论在当时都是高端玩意儿一般公司根本玩不起甚至大公司都做得费劲比如IBM Watson就投入了大量资源但最终却以失败告终。综上无论本体论还是知识图谱其实已经到了一筹莫展的地步他们想要表征真实的世界最好发现技术路径上做不到再高的成本都费劲这一切在大模型这个技术到来后发生了变化。大模型、本体和图谱当前大模型解决了很多问题或者说他在大部分时间都是对的但这也只能说他是一个好的概率模型这种**“单词接龙”**的架构在底层就决定了他一定会有幻觉。AI 智能体最大的短板在于缺乏对业务实质的理解。没有明确的语义、本体和知识图谱作为支撑智能体只能依靠概率去猜测数据关联。而对于这种底层就可能出错的场景对于错一次就赔钱的企业来说是不可接受的。因为我能接受确定性的错误我很难接受不确定性的错误恐惧来源于未知的错误没有公司愿意埋明显的雷。而大模型自己搞不定的点却是本体论和知识图谱擅长的点让猜测变成更确定让整个模型推理具有完整而严谨的逻辑链故事还不止于此这里只说了本体、图谱对模型的意义巨大但反过来模型对本体和图谱的意义更加巨大可以说没有模型这两个技术依旧出不来。我们第一段说了本体和图谱维护成本奇高本体设计需要专家纯手工设计人工成本高还难以迁移实体识别和关系抽取是规则堆出来的换个领域大概率就崩了图谱填充和更新也是全靠人工往里灌而大模型的出现让这一切完全变了上述所有的事项模型都可以参与并且做得很好完全可以做到 AI 给出第一个版本答案让行业专家去审稿就我之前实际经历来说这个成本可以下降 1/4 到 1/10比较夸张的时候可以达到 1/20所以大模型让本体和知识图谱的构建变简单了而且简单了不止一个数量级在这个基础下我们再来聊聊图谱和本体的关系因为严格来说他们是两个东西知识库的发展当前知识库经过了几轮发展第一个阶段也是最初的阶段是大模型解决了语义理解。传统搜索靠关键词匹配“网络很卡匹配不上高延迟丢包”。大模型能理解语义关联还能组织成自然语言答案。但模型的参数知识有三个硬伤没私有数据、更新得重训、答案来源说不清所以第一步是引入外部知识阶段二是将长上下文直接把文档塞进去。这个阶段现在很多同学还在玩几十页资料全塞模型。但资料一多问题就来了成本高、无关内容干扰、关键信息被淹没、多份文档互相冲突、模型容易忽略中间部分。所以需要先找相关资料再给模型于是就进入了下个阶段阶段三基础 RAG切块、向量化、召回 Top-K。这个阶段开始着眼解决大量私有资料的使用问题这也是最初 AI 客服的技术基石但复杂度再往上升RAG的五个短板暴露出来切块割裂关系相似度 ≠ 业务关联没有稳定身份答不了全局问题判断不了业务状态于是乎这里又有一次升级阶段四生产级能力补足。遇到上述问题后混合检索、Rerank、父子文档、元数据过滤等方案就来了但随着业务越来越复杂我们会发现数据和数据之间有关系于是就不得不进入知识图谱阶段。知识图谱知识图谱和知识库非常相似可以说**知识图谱是知识库的一种有机表现形式。**在逻辑上知识库通过关系链的建立能够形成图谱结构。具体来说知识库是对各种知识的组织、存储和管理而知识图谱则是在此基础上通过图的结构实体、关系和属性来呈现知识的内在联系和结构。知识图谱通常包括三大元素**实体Entities**即图中的节点代表真实世界中的事物、概念等如人、地点、物品、概念、类别。**关系Relations**实体之间的连接或联系描述实体之间的互动。**属性Attributes**描述实体或关系的特征信息如一个实体的具体属性值。通过这种标准化的表示形式知识图谱不仅能够展示实体之间的关联还能够进行语义分析帮助计算机理解和推理这些关系。它为我们提供了一种更加直观、结构化的方式来管理和呈现知识库中的信息。更粗暴的理解可以是图谱就是强制将知识库按照实体、关系、属性的标准做结构化两者间界限很模糊为方便理解给一个案例首先是没有关系的知识库疾病: { 名称: 糖尿病, 类型: 慢性疾病, 并发症: [心血管疾病, 肾脏病, 神经损伤]}症状: [ { 名称: 口渴, 常见疾病: 糖尿病 }, { 名称: 频繁排尿, 常见疾病: 糖尿病 }, { 名称: 体重下降, 常见疾病: 糖尿病 }, { 名称: 疲劳, 常见疾病: 糖尿病 }]药物: { 名称: 胰岛素, 类型: 药物, 用途: 控制血糖, 使用方法: 注射}然后是有关系的知识图谱实体: [ 疾病(糖尿病): { 类型: 慢性疾病 }, 并发症(心血管疾病): {}, 并发症(肾脏病): {}, 并发症(神经损伤): {}, 症状(口渴): { 常见疾病: 糖尿病 }, 症状(频繁排尿): { 常见疾病: 糖尿病 }, 症状(体重下降): { 常见疾病: 糖尿病 }, 症状(疲劳): { 常见疾病: 糖尿病 }, 药物(胰岛素): { 类型: 药物, 用途: 控制血糖, 使用方法: 注射 }]关系: [ (疾病(糖尿病) - 表现为 - 症状(口渴)), (疾病(糖尿病) - 表现为 - 症状(频繁排尿)), (疾病(糖尿病) - 表现为 - 症状(体重下降)), (疾病(糖尿病) - 表现为 - 症状(疲劳)), (疾病(糖尿病) - 引发 - 并发症(心血管疾病)), (疾病(糖尿病) - 引发 - 并发症(肾脏病)), (疾病(糖尿病) - 引发 - 并发症(神经损伤)), (疾病(糖尿病) - 治疗 - 药物(胰岛素))]PS上述只是为了便于各位理解图谱是什么真实的情况会更复杂但大体是这么个意思比如常见的贝叶斯预测P(糖尿病|多饮多尿) P(多饮|糖尿病) x P(多尿|糖尿病) x P(糖尿病) / P(多饮多尿)在大模型时代当前模型对于根据症状推导常见疾病已经非常擅长但是依旧会由于幻觉有各种问题于是出现类RAG技术比如输入咳嗽 呼吸急促 发热 胸痛图谱推理路径症状 → 咳嗽、呼吸急促、发热、胸痛症状 → [常见疾病类别] → 呼吸系统疾病可能的疾病肺炎、支气管炎、慢性阻塞性肺疾病COPD进一步筛查 → [检查指标] → 血氧饱和度、白细胞计数、胸部影像如果胸部影像显示肺部浸润阴影高度怀疑肺炎或肺结核影像学特征差异 → [不同疾病影像学差异] → 肺炎浸润阴影 vs 肺结核钙化灶若影像学表现为浸润阴影进一步考虑细菌性肺炎最终诊断 → [关联知识库] → 确定细菌性肺炎可能性若有相关临床史如吸烟史、基础疾病可能进一步确定为慢性阻塞性肺疾病合并肺炎。综上大模型其实就是我们所谓的快思考而知识图谱知识库就是我们所谓的慢思考了在快慢结合下医疗AI的答案将更为靠谱。但到这里还不算结束知识图谱把实体连起来了但它回答不了**这个连接在业务上是什么意思。**举个例子腹泻 ——相关→ 脱水腹泻 ——相关→ 口服补液盐口服补液盐 ——相关→ 严重脱水患者三条都是正确的医学事实。但如果所有关系都叫相关系统只知道这三样东西有关联却区分不了腹泻表现为脱水是症状关系腹泻使用口服补液盐治疗是治疗关系口服补液盐禁忌于严重脱水患者是禁忌关系换句话说知识图谱能把事实连成网但不告诉机器这些连接怎么理解、怎么组合、怎么冲突。这个问题的根源在于图谱定义了实例腹泻、补液盐、脱水都是具体的东西但没有定义类型和关系语义什么是疾病、什么是症状、什么是药物什么是表现、什么是治疗、什么是禁忌PS这里有个主意点医疗多数数据已经被内化进了模型所以他大概率是知道这里的问题的但如果用知识图谱去构建企业级的其他知识那么模型就不会知道了我这边使用医疗的案例主要原生是他简单并且大家都有感知我如果用企业案例大家理解起来会很费劲而这些类型和关系语义恰恰是推理的前提。没有它们AI 看到的只是一堆带标签的节点和边做不了判断。所以在知识图谱之上需要再加一层定义这个领域里有哪些类型的事物、它们之间允许什么类型的关系、什么组合是合法的、什么情况是矛盾的。这层定义就是本体论。这里稍微夸张的描述是只要加了足够的说明其实知识图谱完成的工作和本体差不多比如我们做医疗场景的时候只是构建了连接但模型自己内置了大量医疗信息完全可以补足 AI 欠缺的知识本体论知识图谱已经把关系写清楚了本体继续定义关系的准确含义、适用范围和推理边界。下面用一个更严谨的案例来展开知识图谱可以做到关系命名清晰比如糖尿病 ——表现为→ 多饮糖尿病 ——表现为→ 多尿胰岛素 ——用于治疗→ 糖尿病糖尿病 ——可能并发→ 肾脏疾病同时患者事实也能正常记录张三 ——出现→ 多饮张三 ——出现→ 多尿关系名字已经写清楚了但 AI 仍然面临三个问题问题一能否根据多饮、多尿直接推出张三患有糖尿病不能。因为疾病表现为症状不能随意反向推导成出现症状就患有疾病。问题二如果张三被确诊为糖尿病能否直接推荐胰岛素不能。因为药物用于治疗某种疾病不代表适用于该疾病的每一个类型、每一个阶段、每一位患者。问题三张三患有糖尿病能否直接判断他已经并发肾脏疾病不能。因为可能并发描述的是风险关系不能直接转化为某位患者已经发生的事实。所以问题已经超出了实体有没有连起来。系统还需要知道糖尿病属于疾病多饮属于症状胰岛素属于药物表现为能否反向推导可能并发代表可能性还是确定事实用于治疗需要满足什么前提哪些关系可以继承哪些不能传递知识图谱记录了关系叫什么、连接了哪些对象AI 还需要一套公共定义说明这些类型和关系应该怎样理解、怎样组合以及推理可以走到哪里。这套公共定义就是本体。什么是本体本体是一套针对特定领域的公共语义模型它明确规定这个领域中有哪些类型的对象对象之间允许建立什么关系每种关系代表什么哪些推导成立、哪些推导存在矛盾这里继续用糖尿病案例【类型】疾病、症状、药物、患者【具体概念】糖尿病疾病多饮症状胰岛素药物【患者实例】张三患者知识图谱主要保存具体事实本体主要定义这些事实采用什么语义结构。本体定义了哪些内容本体定义了四样东西1. 类型本体首先回答这是什么糖尿病属于疾病多饮属于症状胰岛素属于药物。2. 类别层级本体还要回答它属于哪一类疾病└── 代谢性疾病 └── 糖尿病 ├── 1型糖尿病 ├── 2型糖尿病 └── 妊娠期糖尿病**PS**这里要注意了我们在实际实体构建过程中这个部分的内容是最难最难的包括医疗场景这块都非常难这样系统可以推出张三被诊断为1型糖尿病 → 张三患有糖尿病 → 张三患有代谢性疾病。但不能反向推出张三患有糖尿病 → 张三一定患有1型糖尿病。为什么会这样设计大家这里要理解下因为这里很多表现会具备继承的关系便于我们做收敛至于什么是收敛这个就涉及敏感课程信息了大家可以下来联系3. 关系本体规定哪些类型之间可以建立什么关系最关键的是区分疾病层面的通用知识和患者层面的实际事实糖尿病表现为多饮疾病层面的通用关系张三出现多饮患者层面的观察记录有了这个区分系统才不会把疾病可能表现为什么直接当成患者已经被诊断为什么。PS这里再强调下在医疗领域模型没这么白痴是因为所有数据都内化进模型了但企业场景里面黑话那么多大概率会的4. 约束与边界本体还会规定关系两端的类型限制例如“出现症状”的起点必须是患者、终点必须是症状。如果大模型抽取出血糖检查出现多饮系统可以发现类型错误。更重要的是本体决定哪些结论可以推出哪些不能1型糖尿病属于糖尿病 → 张三被诊断为1型糖尿病 → 张三患有糖尿病继承成立出现多饮、多尿 → 确诊糖尿病反向推导不成立只能说是有概率胰岛素可以治疗糖尿病 → 所有糖尿病患者都应该使用胰岛素关系泛化不成立还要分期分级本体不仅帮助机器推出新知识也帮助机器知道哪些结论不能随意推出。知识图谱和本体论的关系至此大家对于图谱和本体的关系应该也非常清晰了知识图谱是业务事实的数据层本体是约束这些事实如何表达、如何解释、如何推理的语义层。应用系统再基于二者完成检索、判断和执行关于如何落地本体论这块篇幅有限今天就不展开了感兴趣同学可以下来联系这个板块其实复杂度有点高…安全是最大的奢侈IBM Watson 当年投入巨资做 CDSS最终没能跑通核心原因就一句话代价太高了。为了保证诊断不出错专家要手工定义疾病、症状、药物之间密密麻麻的关系还要说清楚哪些结论能推、哪些不能推、哪些知识已经过期。系统越接近真实医疗这套知识工程就越庞大、越脆弱。最后连 IBM 都扛不住这套东西贵到只有少数体系付得起。大模型来了之后事情确实起了变化这东西泛化能力起来了它能听懂胸口沉甸甸的像压了块石头其实是指胸闷也能抽取出胸痛放射至背部这种关键信息语义理解的成本骤降IBM Watson 想做而没做成的事今天有了重新落地的可能。大模型补上了语义理解这块短板本体和图谱的构建成本也从专家纯手工降到了AI 出初稿、专家来审稿。曾经只有巨头才敢碰的知识工程正在变得触手可及。综上大模型把获取知识变便宜了本体和图谱把使用知识变安全了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】