- 综合排序
- 最热优先
- 最新优先
本体论和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就是对象、行为、规则。落到软件建模上，对象本体回答"存在什么"，行为本体回答"能做什么"，规则本体回答"什么必须成立"。三者缺一不可。 因为这正是本体建模和传统流程建模最根本的区别。流程会天天变，但对象和它们之间的引用关系相对稳定。 这十一个模型在架构上也是分层的：L0持久化映射层、L1领域对象层、L2原子能力层、L3解耦决策层、L4编排协同层、L5集成边界层、L6交互入口层。 SQL只允许SELECT、强制LIMIT、禁止DDL和DML，配合同环比、3σ、RFM、ABC这些统计算法，只负责算数，不负责解释和因果。第二层是语义锚定。
43411编辑于 2026-09-20 从本体论到本体建模，从本体建模到AI原生-长文系统总结我历史文章观点和思维演进
二、抽象建模：本体论思想的本质 2.1 软件建模的来路：UML、MDA 与领域驱动 我特别想说一句：如果你原来做过类似抽象建模的工作，其实是很方便理解本体论的。 不管是软件建模、企业架构、BIM 建模，各种建模，通过这种建模你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 2.3 对象、行为、规则三位一体 讲到这里，本体论建模的核心三要素就呼之欲出了：对象建模、行为建模、规则建模。我一直把它叫做 OBR 三要素，它是整个本体论建模方法论的基石。 什么是本体？ 但在本体论建模思路下，这个交付中断会触发一个事件，进入到本体模型的消息管道。 这才是本体模型在数据治理上带来的最大价值。 四、本体建模的方法论与落地 4.1 OBR 可视化建模：对象链即流程 理解了本体的价值，下一个问题是：到底怎么把一个业务建成本体？
4.6K21编辑于 2026-06-03火热的本体论背后——警惕本体论和本体建模滥用和过度神话
这大半年，本体论实在是太火了。我自己也在公众号和视频号里聊了很多期，从西方哲学的本体论，到 Palantir 的本体，到对象行为规则建模，再到本体驱动 AI 原生应用。 不是否定本体论，而是想认真地划一划它的边界：本体论到底适合解决什么问题，又有哪些场景根本不该硬上本体。讲清楚边界，本体论才不会沦为一个空洞的口号。 一、脱离场景谈本体，是水中月镜中花 我一直坚持一个原则：本体论必须是问题驱动、场景驱动的。 也就是说，拿到一个具体的场景，我们要先问一句：这个场景到底适不适合构建本体模型来解决？ 是否适合用本体模型结合 AI 大模型去做动态推理？ 如果这些问题的答案都是否定的，那就别硬上本体。脱离了具体场景和具体问题去空谈本体论，基本就是水中月、镜中花，看着很美，抓不到手里。 大量的本体论滥用，恰恰是混淆了这两件事。要么是拿本体去抢"算法早就固定好了"的活，画蛇添足；要么是指望本体模型本身能直接产出"精确结果"，缘木求鱼。
82811编辑于 2026-06-02从知识图谱到本体建模-本体论核心思想
所以再次重申我的观点，即在本体建模中，不会对实例层单独建模，实例层不存在单独建模的问题，只涉及到实例数据的存储问题。 当我谈到这你是否会发现这个和Palantir做的事情很类似，但是这里没有提本体论和本体建模。 这个是真正存在业务需求和业务痛点的地方，如果应用本体论可以更好的解决这个问题，那么本体论就能够更好的体现业务价值。 最后再次强调，本体论或本体建模本质是一个业务建模的事情。 作者明确指出两者的根本差异：知识图谱的核心在于实例层的关系发现，而本体建模的重心在于抽象模型层的构建，实例层不需要单独建模，只涉及数据存储。这个判断是准确的。 若要进一步完善，建议在"本体建模复杂性"这一挑战上补充更多具体的降低门槛的方法论，例如领域优先、渐进建模的实操路径，这将使文章的实践指导价值更加完整。
1.8K10编辑于 2026-04-24本体论建模-合同管理本体模型深度分析与语义构建
然后再和 AI 大模型交互，让大模型基于文本文件来输出完整的符合 OWL 本体建模语言标准的 OWL 完整模型文件。这个本身也给我们后续构建本体模型给出一种新的参考思路。 本体建模的核心价值在于通过"关联、集成、分组、结构树"等语义逻辑，将零散的合同要素转化为可计算、可推理的知识网络。 合同管理业务场景与本体建模需求分析 深入分析销售合同业务全流程，我们识别出从合同签字生效到最终开票收款的闭环需求。 需求-语义映射表 业务痛点 本体建模目标 语义实现手段 对象属性定义的模糊性 构建标准化的核心实体网络 显式定义顶层类与对象属性（Object Properties） 跨部门协作中的权责冲突 确保组织架构与合同责任的一致性 基于 OWL 语义的本体模型拓扑架构 本模型采用 W3C 的 OWL (Web Ontology Language) 标准，旨在构建一个以 cm:Contract 为核心、高度向外辐射的拓扑架构。
97610编辑于 2026-03-26本体论和本体建模-必须搞清两个关键场景
但是要注意，OWL本书是W3C提出的Web本体语言，当时提出的时候更多的是面向结构化或半结构化数据的语义抽象，为领域知识提供严格的逻辑约束和推理基础。 如果回到工程学上面。 本体建模必须要搞清楚两个关键场景 在我们进行本体建模的时候，一定要首先区分两个关键场景。 搞不清楚这两类研究和实践本体，很容易犯错。 对于场景一，你研究半天可能发现这不就是传统的面向对象分析建模吗？你如果回到传统面向对象建模，为何又硬生生的搞个本体建模的概念出来？这个问题需要思考清楚。 我最近看到不少的关于本体建模的文章，感觉作者都在谈面向对象的建模，确实本体建模和面向对象建模很类似，都涉及到类，属性，关系，行为，规则等的定义。但是大家一定要注意里面的关键差别。 首先要注意OO建模的出发点是封装（属性和方法紧耦合），而本体建模的出发点是断言（事实和规则解耦）。
1.5K20编辑于 2026-07-06Palantir 本体论建模平台深度解析
本文档整理自我和Claude大模型关于Palantir本体建模的一次完整的技术对话，涵盖 Palantir Foundry / AIP 平台的本体论建模机制、供应链场景应用、与数据中台的集成方案，以及大模型决策回写的实现路径 Palantir 本体论建模平台概览 问：你是否对 Palantir 的基于本体论建模的平台熟悉？在该平台上有一个运营平台，可以对本体论模型进行动态模拟或推演。 平台整体架构 Palantir Foundry / AIP 平台由五个层次构成，自上而下协同运转： 【架构图占位】 Palantir 本体论平台五层架构图 （数据采集层 → 集成与转换层 → 本体论建模层 3. 大模型决策如何回写业务系统 回写机制的核心：Action Type 是关键枢纽 回写发生在应用与运营层，但真正承载回写逻辑的是 Ontology 建模层定义的 Action Type。 那么 Palantir 进行本体对象建模的时候是否会有库存周转率这个对象？还是只有底层的订单、库存、入库单等对象？
6K13编辑于 2026-03-26本体论建模-Protégé 开源本体（Ontology）编辑器-构建本体模型和知识图谱
当然这个仅仅是简单的可视化展示的示范，还是有不少朋友问当前有无一些开源的本体论建模工具可以参考。最近也查找了不少资料，找了一个斯坦福大学开源的本体建模工具。 主要特性： ✓ 符合 W3C 标准 ✓ 可定制的用户界面 ✓ 可视化支持 ✓ 本体重构支持 ✓ 推理机直接接口 ✓ 高度可插拔架构 ✓ 与 WebProtégé 跨平台兼容 在下载安装了这个桌面端的本体建模工具后 所以你已有的数据库设计经验完全可以平移过来理解本体建模，只是 OWL 在语义表达上比数据库更强一层。 当然，本体建模另外一个核心还是规则。 接着第3个关键问题，我一直理解事件定义在本体模型中相对重要。 注意前面的建模并没有去实现本体模型的可视化。
8.5K31编辑于 2026-03-09Palantir本体论，规则和行为建模才是核心
如果你再看Palantir的本体论，会发现它的核心不仅仅是数据和数据关系，更重要的是行为建模。这个行为就是我们讲的算法规则——促进数据形成的行为，促进数据流转的行为。 行为建模，包括行为的可视化、显性化，才是整个本体论最核心的内容。 理解这个后，举个最简单的例子： 生产管理中的生产排产。 缺的是规则建模，缺的是行为建模，缺的是怎么样把这部分内容更好地去显性化。 那么我原来有没有做这个事情呢？ 原来我们在聊数据中台的时候，更多的是在聊大数据平台，聊BI分析决策这么一个纵向的线条。 当我的目的是数据支撑决策的时候，数据和数据之间的关系建模、行为建模就没有这么重要。 这才是我们去构建数据本体、包括构建行为建模最核心的内容。 它不再是简单的支撑决策了，而是更好地支撑整个企业的业务运营。 那么这个时候，我们整个核心的本体论价值就会越来越大。
1.6K10编辑于 2025-12-29本体论思想-抽象建模的本质是什么？
不管是类似于软件建模、企业架构、BIM建模，各种建模，因为你通过这种建模，你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 我怎么样去构建这么一个本体？那就是需要在我传统的数据模型的基础上，增加行为建模，增加规则建模，这样就构建了一个完整的本体。 行为规则来源于哪里？ 在原来我讲的时候我就一直谈到：本体论它其实没有什么太多新鲜的东西，本体论的建模的思路本身就跟我们原来讲的面向对象分析设计建模的思路完全是一致的。那为什么现在回来又要谈到本体论的建模？ 你究竟是采用3层框架还是5层框架？这些东西跟我都没有关系。这样的话我去做完领域建模，我就只做我核心的内容的抽象，或者叫业务的抽象。这样的话就是可以极大的控制我模型的规模，或者是模型的复杂度。 这样建出来的模就是一个核心的事情或者是事件，它最最本质的底层本体模型。 而且在前面我有一个视频，我专门在讲本体论建模的时候，我还讲了一个相当重要的东西：本体论的建模一定是围绕对象这个核心展开的。
51410编辑于 2026-03-26- 来自专栏数智转型架构师
本体论思想-抽象建模的本质是什么？
不管是类似于软件建模、企业架构、BIM建模，各种建模，因为你通过这种建模，你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。 我怎么样去构建这么一个本体？那就是需要在我传统的数据模型的基础上，增加行为建模，增加规则建模，这样就构建了一个完整的本体。 行为规则来源于哪里？ 在原来我讲的时候我就一直谈到：本体论它其实没有什么太多新鲜的东西，本体论的建模的思路本身就跟我们原来讲的面向对象分析设计建模的思路完全是一致的。那为什么现在回来又要谈到本体论的建模？ 你究竟是采用3层框架还是5层框架？这些东西跟我都没有关系。这样的话我去做完领域建模，我就只做我核心的内容的抽象，或者叫业务的抽象。这样的话就是可以极大的控制我模型的规模，或者是模型的复杂度。 这样建出来的模就是一个核心的事情或者是事件，它最最本质的底层本体模型。 而且在前面我有一个视频，我专门在讲本体论建模的时候，我还讲了一个相当重要的东西：本体论的建模一定是围绕对象这个核心展开的。
56710编辑于 2026-03-04 大模型时代，本体建模还是个好技能吗？
3. 跟现有系统的集成设计 本体不是孤立存在的，它要跟你的数据库、API、工作流引擎对接——这个架构设计，LLM可以给建议，但最终方案必须懂你的人来做。 4. ▎ 我的结论：本体建模值得学，但学法要变 直接说结论：本体建模在2026年仍然值得学，而且值得学的人比想象中多。 但学法跟5年前不一样了。 3. 工程落地能力——本体设计完了怎么验证、怎么部署、怎么跟现有系统集成？ 这3个能力，LLM辅助得了，但替代不了。 ▎ 给不同人的建议 如果你是企业架构师/数据工程师：本体建模值得学，而且建议学"实战导向"——别先啃W3C规范，先拿一个真实场景（比如你们公司的主数据）建一个本体，遇到问题再查。 如果你是学生/刚入行：本体建模可以作为"差异化竞争力"来学——LLM时代，会调API的人很多，懂知识建模的人不多，这个组合反而稀缺。 ▎ 互动时间 投票：你会让LLM帮你做本体建模吗？
14910编辑于 2026-09-09从知识图谱到本体论-本体建模究竟解决什么问题，带来什么价值？
而这个也正是后续本体建模需要解决的关键问题。 所以这个本体建模实际包括了静态的知识图谱和动态的行为规则两个层面建模。 在我构建的本体建模规范里面实际我将其拆分为了三个方面的内容，即行为建模，规则建模和事件建模。 最近我又详细学习了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月 作者： 这一复杂度需要在建模阶段明确表达，否则会成为实现阶段的隐性债务。 （Web Ontology Language），W3C标准的语义本体描述语言 © 2026 Ontology-Driven Software Modeling Framework v1.0
1.4K10编辑于 2026-03-26Palantir与本体论（三）：语义协议，不是数据建模
就像给一栋楼做3D模型——楼在那了，模型是它的镜像。 但Palantir的ontology做的事情比"复制"多了一步。现实世界是连续的、混沌的、充满无穷细节的，你不可能把一切都映射进去。 这跟哲学本体论的关系在这里接上了：哲学本体论构建的是"看待一切存在者的最普遍方式"，Palantir构建的是"看待特定业务场景的方式"。同一种认知冲动，不同的普遍性层级。 三个本质区别 搞清楚了这个前提，再来看它跟传统数据建模的区别就清晰了。差别不在技术手段，而在三个地方。 第一，建模方向不同。 俞宣孟，《本体论研究》（第三版），上海人民出版社，2012年 2. Translation Approach to Portable Ontology Specifications", *Knowledge Acquisition*, 5(2):199-220, 1993 3.
70812编辑于 2026-07-15再谈Palantir本体论-规则和行为建模才是核心
20年前再看，当时流行的规则引擎规则建模，各种原因很难真正应用起来。也就是说当前重点不是本体论这个概念，而是AI辅助下让我对业务运行完整进行建模成为了可能。 因此结合我前面的一篇文章，我上面的观点。 Palantir本体论的真正价值就在这里。它不仅建模数据和数据关系，更重要的是建模行为。这个行为就是算法规则，是促进数据形成的动作，是推动数据在不同对象之间流转的逻辑。 行为建模的可视化和显性化，才是Palantir本体论最核心的内容。 三、行为建模的三个层次：从执行到决策到适应 要真正做好行为建模，我们需要理解行为本身是有层次的。简单来说可以分为三个层次。 有些物料是长周期采购，交付期要3个月。排产时必须考虑物料的预计到货时间，不能安排在物料到货之前。而且还要留出一定的缓冲时间，以防物料延期。这个缓冲时间设置多少，也是一条经验规则。 这就是为什么现在是重新审视本体论、大力推进行为建模的最好时机。 八、构建企业的数字原生模型：从可能到现实 总结一下我的核心观点。
5.2K21编辑于 2025-12-29本体平台总体架构：从需求到本体建模，从本体模型驱动的AI应用构建和数据分析推理
二、需求探索与本体建模的背景说明 平台的前置基础有两个：需求探索方法和本体建模规范。 需求探索方法解决“原始需求如何变成完整需求”的问题。 本体建模规范解决“完整需求如何变成可运行模型”的问题。 3. 应用生成引擎 应用生成引擎负责把本体模型变成可运行应用。 第一阶段先做“本体建模到智能分析”的最小闭环。核心模块包括本体模型引擎、数据连接引擎、AI分析推理引擎和存储引擎。先选一个明确业务场景，例如合同履约分析、库存积压分析或销售回款风险分析。 九、落地时要注意的几个边界 第一，不要把本体建模做成纯文档工作。本体模型必须能被程序读取、校验和使用。如果模型只停留在图和说明文档里，就很难支撑应用生成和智能分析。 第二，不要让AI绕过业务确认。
34910编辑于 2026-09-10本体驱动ERP｜国家发的"本体建模"标准，我拿它给自研ERP本体做了一次"体检"
本体驱动ERP系列 · 国家标准解读 | GB/T 48000.3-2026 逐条对照，有惊喜也有差距 7月刚摸到一份 PDF——GB/T 48000.3-2026《标准数字化 第3部分：本体建模要求》 系列定位：它属于 GB/T 48000《标准数字化》系列（计划共 6 部分），这是第 3 部分"本体建模要求"。前面有通用指南、参考架构，后面还有协同制定、成熟度评价。 ■ 三、最让我拍大腿的 3 个设计决策 普通解读到上面就结束了。但作为天天跟本体打交道的人，有 3 个地方我读到直接拍大腿——因为它们和我踩过的坑、想通的道理，几乎是同一件事的官方表述。 ■ 五、给同在做本体的你 3 条落地建议 如果你也在搭本体 / 语义层 / 知识图谱，这份国标最值得直接抄作业的，是这三点： 1. 把对象属性当"动词"设计。 约束一定要单独建模成实体（Constraint 类）。 别把阈值、偏差硬编码在业务代码里。建模成实体，它才能进推理机、才能被 SHACL 验。这是我用 SWRL 跑通风险传导后最深的体会。 3.
29110编辑于 2026-09-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号