首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 本体论和AI大模型01-本体和AI的关系,本体建模和传统OO建模

    今天继续聊本体论,本体建模和AI方面的话题,因为有些观点和想法会比较零散,所以我准备单独写一个本体和AI的系列来记录我这些重要的观点。 本体论是否是AI必须? 如果熟悉OOA和OOD面向对象分析和设计,包括传统的数据架构和数据建模,你发现本体建模很多类似完全跟面向对象分析设计类似。那么为何还要去做本体建模? 所以大家看斯坦福的本体建模工具,实际对SWRL和SHACL支持的并不好。 所以到了Palantir的本体论,实际整个本体建模包括了静态建模和动态建模两个部分的内容。 那么好了,问题又来了,既然传统的APS分析推理已经可以做,为何还要进入本体建模和AI大模型来做同样的事情? 本体和AI的结合 最后一个点,还是要谈下本体论,本体建模和AI大模型结合的事情。 还有就是基于AI自动去完成本体建模,这个更加不应该,本体建模的核心是业务建模,业务建模必须静态行业和业务域的领域专家才能够完成,AI帮你构建的通用本体模型实际没有什么价值。

    40310编辑于 2026-09-10
  • 本体论思想-本体建模真正实现的业务价值

    今天接着聊本体论方面的内容。因为前面我在聊本体论的时候,更多的是在讲如何构建一个本体,如何进行抽象建模,实现对象、行为、规则三者之间的一个融合统一。 本体论的建模它就不是单纯的传统的数据建模,而是一种对象、行为、规则的融合建模。在对象建模里面包括了对象的关系建模,在行为建模里面包括了事件和状态转换的建模。 本体论通过这个建模,核心它要起的作用就是:打通OLAP到OLTP的这个路线,实现数据分析到后续的数据业务执行行为之间的一个关键的穿透。这个原来是传统情况下面根本没办法做到的。 但是到了本体论阶段,它实现一个关键的东西是什么呢?由于它有完整的对象、行为、规则建模,当某一个核心材料供应链中断以后,它就是一个关键的事件。 这个是本体论带来的巨大的一个价值。 所以说本体论,在当前的情况下面,它有可能是依托在我传统已有业务系统、已有主数据或者是数据中台产品上面的本体论的建模。

    84510编辑于 2026-03-26
  • 来自专栏深圳架构师同盟

    从本体论到本体建模,从本体建模到 AI 原生—我这一年关于本体的系统性复盘

    我在自己的实践里得出了一个可能有点反直觉的结论:本体建模不会对实例层单独建模。实例层不存在单独建模的问题,只涉及实例数据的存储问题。第二个结论是,本体论建模本质上是一个两阶段的认识论过程。 我最先成型的是一套基于OBR思想的可视化建模方法。OBR就是对象、行为、规则。落到软件建模上,对象本体回答"存在什么",行为本体回答"能做什么",规则本体回答"什么必须成立"。三者缺一不可。 因为这正是本体建模和传统流程建模最根本的区别。流程会天天变,但对象和它们之间的引用关系相对稳定。 再往后一路走到V6,形成了十一个模型的完整版:M1对象模型、M2行为模型、M3规则模型、ME事件模型、M4场景模型、M5主体模型、M6流程模型、M7查询统计与报表模型、MUUI模型、MM对象数据表映射模型 每个模型可以用一句话说清职责:M1定义"是什么",M2定义"做什么",M3定义"为什么",ME定义"如何传播",M4定义"怎么编排",M5定义"谁能做",M6定义"怎么走",M7定义"怎么看",MU定义

    43411编辑于 2026-09-20
  • 从本体论到本体建模,从本体建模到AI原生-长文系统总结我历史文章观点和思维演进

    二、抽象建模:本体论思想的本质 2.1 软件建模的来路:UML、MDA 与领域驱动 我特别想说一句:如果你原来做过类似抽象建模的工作,其实是很方便理解本体论的。 不管是软件建模、企业架构、BIM 建模,各种建模,通过这种建模你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 2.3 对象、行为、规则三位一体 讲到这里,本体论建模的核心三要素就呼之欲出了:对象建模、行为建模、规则建模。我一直把它叫做 OBR 三要素,它是整个本体论建模方法论的基石。 什么是本体? 这才是本体模型在数据治理上带来的最大价值。 四、本体建模的方法论与落地 4.1 OBR 可视化建模:对象链即流程 理解了本体的价值,下一个问题是:到底怎么把一个业务建成本体? 场景,还增加了:M5 主体模型,定义参与者、角色和权限边界,采用 RBAC 为基础、ABAC 扩展;M6 异常补偿模型,定义行为失败时的 Saga 补偿策略;ME 事件模型,显式定义流转的领域事件;M7

    4.6K21编辑于 2026-06-03
  • 火热的本体论背后——警惕本体论和本体建模滥用和过度神话

    这大半年,本体论实在是太火了。我自己也在公众号和视频号里聊了很多期,从西方哲学的本体论,到 Palantir 的本体,到对象行为规则建模,再到本体驱动 AI 原生应用。 不是否定本体论,而是想认真地划一划它的边界:本体论到底适合解决什么问题,又有哪些场景根本不该硬上本体。讲清楚边界,本体论才不会沦为一个空洞的口号。 一、脱离场景谈本体,是水中月镜中花 我一直坚持一个原则:本体论必须是问题驱动、场景驱动的。 也就是说,拿到一个具体的场景,我们要先问一句:这个场景到底适不适合构建本体模型来解决? 是否适合用本体模型结合 AI 大模型去做动态推理? 如果这些问题的答案都是否定的,那就别硬上本体。脱离了具体场景和具体问题去空谈本体论,基本就是水中月、镜中花,看着很美,抓不到手里。 大量的本体论滥用,恰恰是混淆了这两件事。要么是拿本体去抢"算法早就固定好了"的活,画蛇添足;要么是指望本体模型本身能直接产出"精确结果",缘木求鱼。

    82811编辑于 2026-06-02
  • 从知识图谱到本体建模-本体论核心思想

    所以再次重申我的观点,即在本体建模中,不会对实例层单独建模,实例层不存在单独建模的问题,只涉及到实例数据的存储问题。 当我谈到这你是否会发现这个和Palantir做的事情很类似,但是这里没有提本体论和本体建模。 这个是真正存在业务需求和业务痛点的地方,如果应用本体论可以更好的解决这个问题,那么本体论就能够更好的体现业务价值。 最后再次强调,本体论或本体建模本质是一个业务建模的事情。 作者明确指出两者的根本差异:知识图谱的核心在于实例层的关系发现,而本体建模的重心在于抽象模型层的构建,实例层不需要单独建模,只涉及数据存储。这个判断是准确的。 若要进一步完善,建议在"本体建模复杂性"这一挑战上补充更多具体的降低门槛的方法论,例如领域优先、渐进建模的实操路径,这将使文章的实践指导价值更加完整。

    1.8K10编辑于 2026-04-24
  • 本体论建模-合同管理本体模型深度分析与语义构建

    然后再和 AI 大模型交互,让大模型基于文本文件来输出完整的符合 OWL 本体建模语言标准的 OWL 完整模型文件。这个本身也给我们后续构建本体模型给出一种新的参考思路。 本体建模的核心价值在于通过"关联、集成、分组、结构树"等语义逻辑,将零散的合同要素转化为可计算、可推理的知识网络。 合同管理业务场景与本体建模需求分析 深入分析销售合同业务全流程,我们识别出从合同签字生效到最终开票收款的闭环需求。 需求-语义映射表 业务痛点 本体建模目标 语义实现手段 对象属性定义的模糊性 构建标准化的核心实体网络 显式定义顶层类与对象属性(Object Properties) 跨部门协作中的权责冲突 确保组织架构与合同责任的一致性 7. 智能语义:SWRL 规则与推理机制 语义模型的精髓在于将业务治理规则固化为机器可自动执行的推理逻辑。

    97610编辑于 2026-03-26
  • 本体论和本体建模-必须搞清两个关键场景

    为何当前本体建模+AI的时候,就一定要把OWL作为一种或唯一的本体语言定义规范呢?这个问题我个人不想争论谁对谁错,但是我们在思考本体建模的时候必须要把这个事情想清楚,我们究竟需要一个什么样的本体模型。 本体建模必须要搞清楚两个关键场景 在我们进行本体建模的时候,一定要首先区分两个关键场景。 搞不清楚这两类研究和实践本体,很容易犯错。 对于场景一,你研究半天可能发现这不就是传统的面向对象分析建模吗?你如果回到传统面向对象建模,为何又硬生生的搞个本体建模的概念出来?这个问题需要思考清楚。 我最近看到不少的关于本体建模的文章,感觉作者都在谈面向对象的建模,确实本体建模和面向对象建模很类似,都涉及到类,属性,关系,行为,规则等的定义。但是大家一定要注意里面的关键差别。 首先要注意OO建模的出发点是封装(属性和方法紧耦合),而本体建模的出发点是断言(事实和规则解耦)。

    1.5K20编辑于 2026-07-06
  • Palantir 本体论建模平台深度解析

    本文档整理自我和Claude大模型关于Palantir本体建模的一次完整的技术对话,涵盖 Palantir Foundry / AIP 平台的本体论建模机制、供应链场景应用、与数据中台的集成方案,以及大模型决策回写的实现路径 目录 Palantir 本体论建模平台概览 供应链场景:数据在可视化图谱上的流动 大模型决策如何回写业务系统 与已有数据中台的集成方案 库存周转率告警驱动决策的完整解决方案 1. Palantir 本体论建模平台概览 问:你是否对 Palantir 的基于本体论建模的平台熟悉?在该平台上有一个运营平台,可以对本体论模型进行动态模拟或推演。 平台整体架构 Palantir Foundry / AIP 平台由五个层次构成,自上而下协同运转: 【架构图占位】 Palantir 本体论平台五层架构图 (数据采集层 → 集成与转换层 → 本体论建模层 那么 Palantir 进行本体对象建模的时候是否会有库存周转率这个对象?还是只有底层的订单、库存、入库单等对象?

    6K13编辑于 2026-03-26
  • 本体论建模-Protégé 开源本体(Ontology)编辑器-构建本体模型和知识图谱

    今天继续聊本体论建模。 因为最近写本体论方面的文章比较多,包括前面也分享了一个基于已经有的本体元模型,通过AI编程的方式输出一个可视化的本体语义知识网络图谱。 当然这个仅仅是简单的可视化展示的示范,还是有不少朋友问当前有无一些开源的本体论建模工具可以参考。最近也查找了不少资料,找了一个斯坦福大学开源的本体建模工具。 有了这个提示词后,AI输出完整的OWL本体模型定义源代码文件如下: 接着我们把这个OWL文件导入到本体建模中。在导入后如下: 注意在这个图左边可以看到完整的类层次结构展开。 所以你已有的数据库设计经验完全可以平移过来理解本体建模,只是 OWL 在语义表达上比数据库更强一层。 当然,本体建模另外一个核心还是规则。 注意前面的建模并没有去实现本体模型的可视化。

    8.5K31编辑于 2026-03-09
  • Palantir本体论,规则和行为建模才是核心

    如果你再看Palantir的本体论,会发现它的核心不仅仅是数据和数据关系,更重要的是行为建模。这个行为就是我们讲的算法规则——促进数据形成的行为,促进数据流转的行为。 行为建模,包括行为的可视化、显性化,才是整个本体论最核心的内容。 理解这个后,举个最简单的例子: 生产管理中的生产排产。 缺的是规则建模,缺的是行为建模,缺的是怎么样把这部分内容更好地去显性化。 那么我原来有没有做这个事情呢? 原来我们在聊数据中台的时候,更多的是在聊大数据平台,聊BI分析决策这么一个纵向的线条。 当我的目的是数据支撑决策的时候,数据和数据之间的关系建模、行为建模就没有这么重要。 这才是我们去构建数据本体、包括构建行为建模最核心的内容。 它不再是简单的支撑决策了,而是更好地支撑整个企业的业务运营。 那么这个时候,我们整个核心的本体论价值就会越来越大。

    1.6K10编辑于 2025-12-29
  • 本体论思想-抽象建模的本质是什么?

    我在一个群里面就一直在讲,如果你原来做过类似于抽象建模的工作,其实是方便你了解本体论的。 不管是类似于软件建模、企业架构、BIM建模,各种建模,因为你通过这种建模,你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 我怎么样去构建这么一个本体?那就是需要在我传统的数据模型的基础上,增加行为建模,增加规则建模,这样就构建了一个完整的本体。 行为规则来源于哪里? 在原来我讲的时候我就一直谈到:本体论它其实没有什么太多新鲜的东西,本体论的建模的思路本身就跟我们原来讲的面向对象分析设计建模的思路完全是一致的。那为什么现在回来又要谈到本体论的建模? 这样建出来的模就是一个核心的事情或者是事件,它最最本质的底层本体模型。 而且在前面我有一个视频,我专门在讲本体论建模的时候,我还讲了一个相当重要的东西:本体论的建模一定是围绕对象这个核心展开的。

    51410编辑于 2026-03-26
  • 来自专栏数智转型架构师

    本体论思想-抽象建模的本质是什么?

    我在一个群里面就一直在讲,如果你原来做过类似于抽象建模的工作,其实是方便你了解本体论的。 不管是类似于软件建模、企业架构、BIM建模,各种建模,因为你通过这种建模,你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 我怎么样去构建这么一个本体?那就是需要在我传统的数据模型的基础上,增加行为建模,增加规则建模,这样就构建了一个完整的本体。 行为规则来源于哪里? 在原来我讲的时候我就一直谈到:本体论它其实没有什么太多新鲜的东西,本体论的建模的思路本身就跟我们原来讲的面向对象分析设计建模的思路完全是一致的。那为什么现在回来又要谈到本体论的建模? 这样建出来的模就是一个核心的事情或者是事件,它最最本质的底层本体模型。 而且在前面我有一个视频,我专门在讲本体论建模的时候,我还讲了一个相当重要的东西:本体论的建模一定是围绕对象这个核心展开的。

    56710编辑于 2026-03-04
  • 大模型时代,本体建模还是个好技能吗?

    本体与AI · 第5篇 上个月参加一个技术沙龙,茶歇的时候有个年轻人问我:"现在LLM什么都能干,本体建模还有学的必要吗?" ▎ 我拿LLM试了试本体建模 去年底,我拿一个真实项目试了试——让GPT-4帮我设计一个"设备运维知识图谱"的本体。 业务语义的精确建模 本体建模的核心是对业务领域的深刻理解——你们公司的"设备"到底指什么,包含哪些状态,状态之间怎么转移,这些业务知识LLM没有,你得自己定义。 ▎ 我的结论:本体建模值得学,但学法要变 直接说结论:本体建模在2026年仍然值得学,而且值得学的人比想象中多。 但学法跟5年前不一样了。 如果你是学生/刚入行:本体建模可以作为"差异化竞争力"来学——LLM时代,会调API的人很多,懂知识建模的人不多,这个组合反而稀缺。 ▎ 互动时间 投票:你会让LLM帮你做本体建模吗?

    14910编辑于 2026-09-09
  • 本体平台总体架构:从需求到本体建模,从本体模型驱动的AI应用构建和数据分析推理

    二、需求探索与本体建模的背景说明 平台的前置基础有两个:需求探索方法和本体建模规范。 需求探索方法解决“原始需求如何变成完整需求”的问题。 本体建模规范解决“完整需求如何变成可运行模型”的问题。 7. 存储引擎 存储引擎负责保存平台资产。 第一阶段先做“本体建模到智能分析”的最小闭环。核心模块包括本体模型引擎、数据连接引擎、AI分析推理引擎和存储引擎。先选一个明确业务场景,例如合同履约分析、库存积压分析或销售回款风险分析。 九、落地时要注意的几个边界 第一,不要把本体建模做成纯文档工作。本体模型必须能被程序读取、校验和使用。如果模型只停留在图和说明文档里,就很难支撑应用生成和智能分析。 第二,不要让AI绕过业务确认。

    34910编辑于 2026-09-10
  • 从知识图谱到本体论-本体建模究竟解决什么问题,带来什么价值?

    而这个也正是后续本体建模需要解决的关键问题。 所以这个本体建模实际包括了静态的知识图谱和动态的行为规则两个层面建模。 在我构建的本体建模规范里面实际我将其拆分为了三个方面的内容,即行为建模,规则建模和事件建模。 最近我又详细学习了Palantir涉及到本体建模的用户手册,再次确认一个关键事情,就是Palantir的本体建模已经不是简单的类似OWL的建模,而是大量借鉴了传统面向对象建模内容。 但是传统建模往往是业务建模和技术实现建模完全耦合在一起的,导致整个模型体量很大,而本体建模是业务建模,我只关系核心的业务语义建模,建模阶段不要引入实现的内容。 对于从0到1构建AI原生应用,核心仍然还是在前期的需求探索和细化,在需求足够明确后基于本体建模规范输出完整的M1到M7的本体建模Yaml文件。

    1.3K10编辑于 2026-06-15
  • 基于本体驱动的完整软件建模方案和实施指南

    今天继续分享一个本体驱动的建模规范和实施指南文件,供大家参考。注意该建模规范在我前面的本体建模文章的基础上进一步将本体模型的Markdown文件转化为YAML文件的描述进行描述。 注意该本体建模参考本体论建模思想对传统的面向对象分析建模和EDA事件驱动的建模进行融合。引入EDA建模思路核心原因是原有的基于流程驱动的建模往往容易导致业务行为活动的紧耦合并引入长周期事务处理。 本体驱动的软件建模方案 Ontology-Driven Software Modeling Framework 完整建模规范 · 七大模型元文件 · 实施指南 版本: 1.0 | 2026年3月 作者: 这一复杂度需要在建模阶段明确表达,否则会成为实现阶段的隐性债务。 七个模型之间存在依赖,建议按以下顺序建模,避免循环依赖: 阶段 建模对象 说明 ① M1 对象模型 从业务词汇表开始,识别核心实体、属性和关联,先不考虑行为 ② M5 主体模型(Actor部分) 识别系统参与者和角色

    1.4K10编辑于 2026-03-26
  • 本体建模规则提取:国内外技术方案整理汇总

    01概念界定:本体系统、本体建模与规则提取 要谈「本体系统进行本体建模的规则提取」,首先需要把三个层层嵌套的概念厘清,它们分别对应知识的容器、知识的建模过程、以及知识中最难获取的「规则/公理」部分。 1.2 本体建模 本体建模是运用某种方法论,把某一领域的概念、层级、属性、约束与规则,转化为机器可读的形式化模型(通常以 OWL/RDF 编码)的系统工程。 它是本体学习「层次蛋糕」中最顶层、最难、也最有价值的一层。 02本体建模方法论(国内外经典方法对比) 规则提取不是孤立环节,而是嵌在本体建模方法论的「定义约束/规则」阶段。 此外还有再制造工艺本体(多源异构实体对齐 + 关键节点匹配的知识重用)、作战仿真本体(军事领域,OWL+SWRL 弥补事实推理)、绿色降碳技术知识图谱(本体建模 + 主题模型)等垂直案例,普遍将「本体建模 — 本体建模「规则提取」国内外技术方案深度研究报告 · 完 —

    27010编辑于 2026-09-09
  • Palantir与本体论(三):语义协议,不是数据建模

    但到这里,一个更尖锐的问题浮出来了:Palantir的ontology跟传统的数据建模,到底差在哪里?如果差别只是"换了个高级词汇",那这个概念就是泡沫。 同一条供应链,平时你可能只建模"供应商—物料—订单"。但战争爆发后,你发现"冲突区域""制裁名单""替代航线"必须被纳入。 这跟哲学本体论的关系在这里接上了:哲学本体论构建的是"看待一切存在者的最普遍方式",Palantir构建的是"看待特定业务场景的方式"。同一种认知冲动,不同的普遍性层级。 三个本质区别 搞清楚了这个前提,再来看它跟传统数据建模的区别就清晰了。差别不在技术手段,而在三个地方。 第一,建模方向不同。 俞宣孟,《本体论研究》(第三版),上海人民出版社,2012年 2.

    70812编辑于 2026-07-15
  • 再谈Palantir本体论-规则和行为建模才是核心

    再次强调下本体论的核心是行为建模。 在回到从信息化到数字化的转变演进就更加清楚。注意数字化实际希望达到的是现实世界到数字世界的完整抽象映射和模拟。 20年前再看,当时流行的规则引擎规则建模,各种原因很难真正应用起来。也就是说当前重点不是本体论这个概念,而是AI辅助下让我对业务运行完整进行建模成为了可能。 因此结合我前面的一篇文章,我上面的观点。 Palantir本体论的真正价值就在这里。它不仅建模数据和数据关系,更重要的是建模行为。这个行为就是算法规则,是促进数据形成的动作,是推动数据在不同对象之间流转的逻辑。 行为建模的可视化和显性化,才是Palantir本体论最核心的内容。 三、行为建模的三个层次:从执行到决策到适应 要真正做好行为建模,我们需要理解行为本身是有层次的。简单来说可以分为三个层次。 这就是为什么现在是重新审视本体论、大力推进行为建模的最好时机。 八、构建企业的数字原生模型:从可能到现实 总结一下我的核心观点。

    5.2K21编辑于 2025-12-29
领券