- 综合排序
- 最热优先
- 最新优先
从经典本体模型推理问题谈起，什么才是本体模型+AI大模型结合的最佳模式
其次注意，本体模型作用是提供更加完整的上下文给AI大模型用于推理，整个推理能力是AI推理。 本体在两处起作用，一处是基于问题识别用户意图确定需要访问哪些数据对象，拉取哪些数据；其次是本体模型和数据一起投喂给AI。 再次明确我前面分析的本体案例和演示原型，本体模型仅仅作为给AI大模型推理用的上下文就是一种最佳方式。整个问题已经转换为了如何解决大数据量下的上下文溢出问题。 AI 基于需求生成本体模型（M1对象/M2行为/M3规则/M4场景/M_Metric指标） → 知识图谱动态演进 → 字段级数据库映射 阶段三：预设场景执行 三个场景（经营异常/GMV分析 文件——M1 对象模型（17 个实体 + 完整关系）、M2 行为模型（10 个分析行为）、M3 规则模型（业务口径 + 数据质量规则）、M4 场景模型（3 个分析场景）、M_Metric 指标模型（30
1.1K30编辑于 2026-07-23本体论建模-合同管理本体模型深度分析与语义构建
今天继续分享合同管理本体模型定义。在前面我谈到了一个核心的方法思路，就是首先是通过自然语言，基于对象、行为、规则三个维度构建了本体模型的元模型 Markdown 文件。 然后再和 AI 大模型交互，让大模型基于文本文件来输出完整的符合 OWL 本体建模语言标准的 OWL 完整模型文件。这个本身也给我们后续构建本体模型给出一种新的参考思路。 4. 核心类定义与层级结构 本本体通过严谨的类层级（Hierarchy）设计，实现了业务对象的深层特征刻画与基数约束。 业务支撑：SPARQL 查询模板与应用场景 本体模型为前端应用提供了超越传统 SQL 的查询效能。 结论：本体模型对合同管理的核心价值 综上所述，本合同管理本体模型通过显式的类层级、严密的基数约束以及智能的 SWRL 规则，为企业提供了一个标准化、关联化、透明化的语义底座。
97610编辑于 2026-03-26本体论和AI大模型01-本体和AI的关系，本体建模和传统OO建模
你如果没有这种场景和需求，那么你构建本体干啥？引入大模型干啥？如果你构建的方法能够解决抽象建模，业务语义精确化表达和知识网络，闭环回路构建。那么这个模型是否叫本体模型也无关紧要。 那么好了，问题又来了，既然传统的APS分析推理已经可以做，为何还要进入本体建模和AI大模型来做同样的事情？ 本体和AI的结合 最后一个点，还是要谈下本体论，本体建模和AI大模型结合的事情。 更多的方法都是通过AI辅助来构建本体，而这个本体模型本质还是用传统的OWL2模型+SWRL等规则语义，那么你后续推理自然也是演绎推理，这个虽然有价值但是并不是最核心价值的地方。 那么本体和AI如何结合？ 又回到这个关键的问题上面。我一再强调的观点就是，本体模型提供给AI完整的精确的业务语义上下文，而基于场景的分析推理完全交给AI大模型。 但是在这种实践的过程中我们看到关键点在于这个上下文不仅仅是抽象的本体模型，还包括基于场景问题解决的时候动态拉取的实例数据，如果我们不分阶段把这些东西全部投喂给AI大模型，AI大模型实际是无法解决的，超过了
40310编辑于 2026-09-10本体论建模-Protégé 开源本体（Ontology）编辑器-构建本体模型和知识图谱
今天继续聊本体论建模。 因为最近写本体论方面的文章比较多，包括前面也分享了一个基于已经有的本体元模型，通过AI编程的方式输出一个可视化的本体语义知识网络图谱。 注意先不用生成代码片段，而是先输出完整的模型定义，我需要对模型定义进行检查和确认。 那么我们写一段提示词，让大模型基于这个提示词帮我们生成一段符合OWL语义标注的完整本体模型定义。 4. 本体中有详细的类，对象，数据，属性，属性定义规则等定义。同时形成相应的规则，关联约束等。 5. 尽量详细定义，不要丢失关键内容。 接着第3个关键问题，我一直理解事件定义在本体模型中相对重要。 注意前面的建模并没有去实现本体模型的可视化。
8.5K31编辑于 2026-03-09企业架构文档转本体模型，本体模型如何更好的解释和支撑企业LTC端到端流程
今天继续结合这套企业架构材料，来看下如何基于企业架构来构建本体模型。 这四类正好对应到本体建模的四个核心元模型。 具体怎么做的呢？ 我手上有一份《本体建模规范》（v1.0，八个模型那一套，里面把对象、行为、规则、场景的 YAML Schema 都规定好了）。 这条链路在 TOGAF 文档里是有的，但都是规划层面的；现在我用本体模型把它落实到了具体的对象和行为上，可以直接被系统读、被规则卡、被跨域穿透。 这三步做完之后我最大的感受是：规划文档再厚，没有本体模型托底，它还是浮的——落到系统里的时候照样会断链、会扯皮、会口径不一对不齐。本体模型其实不是规划之外的东西，它是规划真正"落地"的那一层。
22210编辑于 2026-09-10- 来自专栏深圳架构师同盟
本体论和本体建模规范：从三模型到十一大模型的发展演进之路
五、V4：流程模型与查询统计模型——补齐AI原生系统的拼图从M1到M5加上事件模型（ME）以后，其实整个本体模型的基本框架就已经全部完成了。但这个模型还不足以支撑我们一个AI原生应用系统的开发。 M7只与M1（对象模型）和M2（行为模型）发生直接关系，不直接引用M3（规则）、ME（事件）、M4（场景）、M5（主体）或M6（流程）。 ME事件模型业务事件、生产者/订阅者、事件链路L3解耦决策层M4场景模型跨对象事件协同的业务语义链L4编排协同层M5主体模型参与者、角色、权限边界横切层M6流程模型端到端协同流+审批流L4编排协同层M7 L3解耦决策层：ME事件模型+M3规则模型。有了领域服务层上面，你涉及到场景业务的协同，那怎么样去做相应的解耦？就会有相关的事件模型和规则模型。L4编排协同层：M6流程模型+M4场景模型。 我把整个本体建模规范叫做以核心的本体模型驱动的本体一体化平台。它的核心中间就是本体建模，围绕对象、行为、规则的十一大模型展开。
23710编辑于 2026-09-21 从OWL到OWL2和SHACL，从本体模型和AI大模型，构建本体建模和大模型推理的分离
进入大模型时代，这个前提发生了根本变化。当本体的消费者从 DL 推理机变成大语言模型（LLM）时，评价一套本体好坏的标准、它应当承载什么、以及它应当长什么样，都要重新回答。 可我真正想做的，是把本体喂给大语言模型，让它来理解和使用。这是两个完全不同的消费者。 后来我发现，这个判断和学界正在发生的一个转向是吻合的:知识工程的重心，正从"用大模型去做本体工程"，转向"为大模型服务的本体"；在这个新阶段，大家更看重事实覆盖、可扩展、好维护，而不再死磕逻辑上的语义完备性 四、于是我的主张成形了:本体定义，大模型推理 把这层窗户纸捅破之后，方法的轮廓一下子清楚了。 顺便和我绕过的两条老路放在一起对照一下: 维度 形式化本体（OWL 2 + SHACL） Palantir 工业本体 我主张的:面向大模型推理的本体 谁来推理 DL 推理机 / SHACL 校验器 平台内置动作与函数
1.4K11编辑于 2026-06-01本体平台总体架构：从需求到本体建模，从本体模型驱动的AI应用构建和数据分析推理
；M4场景模型描述端到端流程和用例编排；M5主体模型描述岗位、角色和权限边界；M6异常补偿模型描述失败、回滚和补偿策略；M7质量约束模型描述性能、可靠性、并发和安全等非功能要求。 这样后续模型生成出现问题时，可以回到需求来源定位原因。 2. 本体模型引擎 本体模型引擎负责把需求文档转成本体模型，并管理模型的生命周期。它既要支持自动生成初始模型，也要支持人工调整和版本管理。 它根据M1对象模型生成数据库结构和领域对象，根据M2行为模型生成接口和服务骨架，根据M3规则模型生成校验与计算逻辑，根据M4场景模型生成流程编排，根据M5主体模型生成权限配置。 4. 数据分析引擎 数据分析引擎负责把业务语言转成逻辑查询计划。用户可以问“今年逾期未回款的合同有哪些”“哪些客户贡献了主要收入”“库存周转异常集中在哪些品类”。 场景编排引擎 场景编排引擎负责把M4场景模型转成可执行流程。它处理顺序执行、条件分支、并行执行、事件等待、超时处理和异常补偿。
34910编辑于 2026-09-10- 来自专栏用户2133719的专栏
本体入门（一）：本体构建 101
本文旨在介绍本体的基本概念和通用构建方法。 1 为什么构建本体？ 我们要用这个本体来干什么？ 本体中的信息应该为何种类型的问题提供答案？ 谁将来使用并维护本体？ 在确定了本体的基本范围后，一种确定本体具体范围的方法是，列出一系列本体应该能够回答的问题，这些问题被称为 competency questions，其专注于本体所涉及的领域，但也不用过于具体，我们将用这些问题来对已完成的本体进行测试 第二步 考虑重用现有的本体 在从头开始构建本体之前，最好先调研是否有相关的本体已经被构建出来了。我们可以基于这些本体进行进一步的改进和扩展。 4 定义类及其层次结构 本节介绍在定义类及其层次结构中可能会出现的错误。虽然类的层次结构取决于具体的应用场景，但是存在一些通用的规则。
3.7K33发布于 2020-08-15 - 来自专栏深圳架构师同盟
本体论和AI大模型04-从本体论到认识论，本体应用和实践真正的瓶颈在哪里？
同样，对于本体模型，如果脱离场景和应用，那么本体模型本身没有体现存在的意义，或者说了为了本体而本体。在我的本体建模规范里面，我将场景问题和本体模型的映射，放到了场景模型定义中。 但是场景模型按道理不属于狭义的本体建模范畴，但是场景模型解决了一个关键点，就是本体模型存在的意义和价值问题。场景模型让本体模型的价值得以体现。 存在的本质如何定义，如何抽象，如果这是本体论研究的范畴。那么这个本体模型究竟应该如何形成？我们的建模方法论是如何的？包括这个本体模型形成后，如何应用这个本体模型去解决问题，去分析和推理。 所以本体模型本身也不是重点，重点是你如何基于业务形成本体模型，同时确保整个本体模型是正确的。包括你如何基于场景问题应用本体模型，去发挥本体模型的价值。这个才是重点。 方法论+本体模型才能够真正发挥本体应用的价值。那么AI大模型公共知识库里面有无方法论？
25420编辑于 2026-09-29 本体论和AI大模型03-什么场景要用本体论，本体论究竟解决了什么业务问题？
今天继续聊本体论和AI大模型，今天核心的主题就是本体论究竟解决了什么问题，带来什么核心的业务价值。 因此固化当前的场景虽然也可以用本体，但是从来不是本体真正的重点，真正的重点是真正理解了完整的本体模型的业务语义，真正能够做到出现新场景下的举一反三。这样才能够充分发挥AI大模型+本体的价值。 提供这个完整语义最佳的方式就是本体模型。所以原来我们只谈本体给AI大模型提供了丰富的，精确的业务语义还是没有直达最本质的东西。核心是AI要能够替代关键人员的思考过程。 这些往往就是需要本体模型+AI辅助的关键点。 所以如果你看我前面文章，我其实对经典本体论不太感冒。AI时代只有本体模型+AI大模型两者充分结合才能够真正发挥巨大的价值。 一个是最下面的Foundry+AIP的本体建模底座和AI分析推理底座的沉淀。还有一个就是面向垂直行业或者说是垂直业务的本体模型经验沉淀。而真正更加重要的我认为反而是中间层内容逻辑的沉淀。
26410编辑于 2026-09-10- 来自专栏深圳架构师同盟
本体论和AI大模型05-从本体建模和运行一体化平台到本体论咨询实施
原因就是本体建模，本体模型应用都需要底层有一个强大的Harness能力支撑。比如一个20页的原始需求，生成的软件需求存文本可能都超过10M，生成的本体模型也基本这个量级。 这些指导书真正实现了场景到本体模型之间的关键映射，脱离了这些指导书实际本体模型没法真正发挥最大的作用。这个平台我为何没有大量发布给大家下载试用？ 所以拿到本体论平台也是一样的道理。本体论平台提供了Harness底座和本体模型最终的沉淀能力。但是里面的关键是将业务目标和需求转换为本体模型的能力，基于业务目标去应用本体模型分析推理的能力。 如何更好的理解本体模型，如何基于不同的业务目标和需求去构建适合自己的本体模型并落地应用，如何让本体模型发挥传统UML模型，数据模型，AI大模型无法发挥出来的更大作用，这个才是我们需要考虑的问题。 对于本体模型一样的道理，本体模型作用不是仅仅类似企业架构抽象企业实际业务，而是要真正解决业务问题的。或者说类似Palantir的理念，本体模型是真正衔接业务和数据，打通OLTP和OLAP的关键桥梁。
4800编辑于 2026-10-06 大模型时代，本体建模还是个好技能吗？
今天我把这个问题摊开来说——大模型时代，本体建模到底还值不值得学，LLM能不能替代本体工程师，我实测下来的结论是怎样的。 ▎ 两种极端的观点 现在圈子里对这个问题，基本两派。 一派说：LLM懂一切，不需要本体了 理由是：GPT-4、Claude、Qwen这些大模型，训练数据里包含了大量的百科知识、领域术语、概念关系——你问它"采购申请和报销申请有什么区别"，它能答得头头是道； ▎ 我拿LLM试了试本体建模 去年底，我拿一个真实项目试了试——让GPT-4帮我设计一个"设备运维知识图谱"的本体。 4. 生成测试用例和示例数据 本体设计完了要测试，让LLM生成一些测试个体（individual）——这个挺好用的，能快速验证推理规则是不是按预期工作。 跟现有系统的集成设计 本体不是孤立存在的，它要跟你的数据库、API、工作流引擎对接——这个架构设计，LLM可以给建议，但最终方案必须懂你的人来做。 4.
14910编辑于 2026-09-09- 来自专栏本体研究院
本体技术视点 | 身份的五种思维模型（一）
我们提出五个不同的思维模型，这些模型来源于对技术人员和非专业人员在讨论身份时对话的观察。随后，我们将探究观察到的讨论和设计模式，这些模式皆由思维模型的交集产生。 最初的讨论提出了三种思维模型。此后，根据同行专家的反馈，纳入了第四和第五种思维模型。 我们期待收到有关此思维模型方法以及我们描述的五个思维模型的反馈和建议。 从观察中，我们确定了五个不同的身份思维模型，每个模型都有自己的框架，目的和定义性问题。这是身份的五个正交思维模型。 这些思维模型是自然而然的概念，源于人们对身份的需求。尽管可以教授这些模型，但我们的观察表明，这些模型更经常被争论和假定（国际标准中包含的“属性”思维模型除外）。
62520发布于 2020-07-31 本体驱动ERP｜大模型也会认错人：我是怎么用本体做实体消歧的
本体定义了 blocking key：名称前4字归一化 + 注册省份。先按这个分桶，只在桶内比对。 启示一：大模型是好的提取器，不是好的裁判。裁判必须是可审计的规则 + 本体定义的身份判据。本体提供 ground truth，大模型提供候选——分工清清楚楚。 而"定义概念和关系"恰恰是本体最擅长、大模型最不擅长的事。这俩不是替代关系——本体定规则、大模型提候选，合起来才是一个能上线、能审计、能回滚的企业级方案。 如果你也在做知识图谱落地、大模型 + 企业数据、或者任何"系统认人"的场景，实体消歧这道坎早晚要过。别信编辑距离，别让大模型当裁判，把"什么是同一个"写进本体里。 ■ 互动时间 1. 实体消歧你用的是规则、向量相似度、还是大模型？效果咋样？ 3. 如果让你给本体加一条"同名异实"防火墙规则，你会怎么写？ 评论区聊聊。
14110编辑于 2026-09-09- 来自专栏agent平台
《从知识库到本体驱动应用》第4招 本体模型 Onto-Model——把业务架构从 PPT 变成机器可以读取、程序可以校验的语义资产
于是我们开始引入本体，让模型从“画出来”变成“能校验、能追踪、能影响分析”。02、是什么本体不是新概念，在计算机里它是一套对业务世界对象、属性、关系、行为、规则、事件和参与者的显式描述。 比如我们要下线一个旧版供应商主数据，过去只能靠人肉搜索哪些系统、哪些模型用到了它。有了本体引用后，可以按ID查引用，迅速列出哪些订单、合同、规则引用了这个供应商。 但如果本体以YAML等结构化方式维护，后端可以自动扫描全部文件，检查重复ID、不存在的引用、循环继承、规则前后矛盾等。校验结果可以进入工程流水线，像单元测试一样把模型质量卡住。 YAML本体纳入版本库，每次提交自动跑Flask校验命令，发现悬空引用或规则冲突就阻止合并。这样本体模型不只是静态文档，而是一个可演进、可测试的工程资产。需要说明，YAML只是载体，不是本体本身。 真正有用的本体模型不是画在架构图里，而是能够被唯一标识、跨文件引用、关系追踪、影响分析和自动校验。定义节点与引用节点的分离，是实现这一切的基础。
20821编辑于 2026-09-01 对本体论实践的再思考-AI大模型下要抛弃传统的本体实践思路
最基础的模型加载和推理流程： 1.加载TBox的抽象本体模型（OWL类，属性，关系） 2.基于场景问题筛选数据加载ABox（RDF三元组） 3.加载规则（OWL+SWRL+SHACL） 4.执行推理 其次 、 还有就是类似Neo4j的属性图数据库。属性图本身不支持原生的 OWL/SWRL 推理，需要借助中间件。这种模式下OWL+RDF会转化为图模型导入到Neo4j，后续的推理更多基于图遍历进行推理。 传统本体建模标准是否适合AI用？ 包括我在谈本体建模和本体模型的时候提到另外一个重要观点。就是构建的本体模型应该是一套更加适合AI大模型理解的业务语义模型。 另一种是类似 Neo4j 的属性图数据库。 属性图本身不支持原生的 OWL/SWRL 推理，需要借助中间件——这种模式下，OWL+RDF 会先转化为图模型导入到 Neo4j，后续推理更多是基于图遍历来做。
1K10编辑于 2026-06-15- 来自专栏本体研究院
本体技术视点 | 身份的五种思维模型（二）
，为什么要建立身份的思维模型 Part 2 介绍五种关于身份的思维模型 Part 3 五种身份思维模型的交集和推荐做法 上一章节我们讲到，思维模型是真实、假设或虚构情况的心理学表示。 通过理解五种思维模型，我们可以更好地进行身份系统的讨论和工程设计。本期我们将带来五种思维模型的主要特征和具体解释。 ---- 五种思维模型 每个思维模型对“身份”识别、记住和响应的方式都不相同。 02 展示思维模型 展示思维模型将身份视为我们将自己展示给社会的方式。供应商关系管理、以用户为中心的身份以及自主身份背后都是这种思维模型。 是指每个对象选择让外界认识自己的方式吗？ ? 要建造一个系统，属性思维模型是最简单的一种模型，部分原因在于，属性思维模型是唯一一个有国际标准提供正式定义的思维模型。 04 关系思维模型 在关系思维模型中，身份产生于与他人的互动和与他人的关系。 这一思维模型包含一些可见的物理特征，比如一个“身高至少达到这么高”才能坐过山车的测试就基于这种模型。
81330发布于 2020-08-07 - 来自专栏本体研究院
本体技术视点 | 央行数字货币模型的简单认识
虽然英国央行还没有决定是否发行 CBDC，但我们还可以从中看一看他们对 CBDC 设计原则、可能平台模型等的一些认识。 英国央行CBDC的假想模型 英国央行的讨论文件中给出了一个假想的基于分层架构的平台模型。分层架构可以促进竞争、创新和扩展。 在这个模型中，所有 CBDC 支付都实时结算。支付完成后，交易将不可撤销，钱也会直接进入收款人的账户中。 基本支付、商业销售点支付、离线支付、打包支付、微支付、可编程性等不同类型的支付都是这个模型支持的支付功能。 ? 03 叠加服务 在该模型中，核心账本拥有相对简单的功能，因此支付接口提供商可以开发叠加服务以提供额外功能。
1K20发布于 2020-04-28 - 来自专栏用户2133719的专栏
本体入门（二）：OWL 本体构建指南f
2 构建一个 OWL 本体 本章节以创建一个披萨本体为例，介绍如何通过 protoge 构建一个 OWL 本体。 2.1 创建本体 File -> New 新建一个本体，修改其 IRI（每个本体唯一）： ? 以 OWL 形式保存为 "pizza.owl"： ? 在 Annotation 中可以添加评论： ? 注意：上面的限制只表明该类需要以 hasTopping 关系连接 4 个 CheeseTopping 个体，并不代表不能连接其他 Topping 个体，我们需要通过普遍性限制（only ）加以约束： ? 4 开放世界推理 下面我们将创建一个 VegetarianPizza 类的互补类 NonVegetarianPizza，以此进一步展示开放世界推理。 x) [3, 4, 5](?x) Built-In Atom 事先定义好的规则，支持用户自定义： Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?
7.3K42发布于 2020-08-16
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号