其次注意,本体模型作用是提供更加完整的上下文给AI大模型用于推理,整个推理能力是AI推理。 再次明确我前面分析的本体案例和演示原型,本体模型仅仅作为给AI大模型推理用的上下文就是一种最佳方式。整个问题已经转换为了如何解决大数据量下的上下文溢出问题。 AI 基于需求生成本体模型(M1对象/M2行为/M3规则/M4场景/M_Metric指标) → 知识图谱动态演进 → 字段级数据库映射 阶段三:预设场景执行 三个场景(经营异常/GMV分析 文件——M1 对象模型(17 个实体 + 完整关系)、M2 行为模型(10 个分析行为)、M3 规则模型(业务口径 + 数据质量规则)、M4 场景模型(3 个分析场景)、M_Metric 指标模型(30 项目采用 Python Flask + React + TypeScript + SQLite + ECharts + D3.js + DeepSeek 技术栈,以"本体模型作为数据库与 AI 之间的业务语义中间层
今天继续分享合同管理本体模型定义。在前面我谈到了一个核心的方法思路,就是首先是通过自然语言,基于对象、行为、规则三个维度构建了本体模型的元模型 Markdown 文件。 然后再和 AI 大模型交互,让大模型基于文本文件来输出完整的符合 OWL 本体建模语言标准的 OWL 完整模型文件。这个本身也给我们后续构建本体模型给出一种新的参考思路。 基于 OWL 语义的本体模型拓扑架构 本模型采用 W3C 的 OWL (Web Ontology Language) 标准,旨在构建一个以 cm:Contract 为核心、高度向外辐射的拓扑架构。 业务支撑:SPARQL 查询模板与应用场景 本体模型为前端应用提供了超越传统 SQL 的查询效能。 结论:本体模型对合同管理的核心价值 综上所述,本合同管理本体模型通过显式的类层级、严密的基数约束以及智能的 SWRL 规则,为企业提供了一个标准化、关联化、透明化的语义底座。
你如果没有这种场景和需求,那么你构建本体干啥?引入大模型干啥?如果你构建的方法能够解决抽象建模,业务语义精确化表达和知识网络,闭环回路构建。那么这个模型是否叫本体模型也无关紧要。 那么好了,问题又来了,既然传统的APS分析推理已经可以做,为何还要进入本体建模和AI大模型来做同样的事情? 本体和AI的结合 最后一个点,还是要谈下本体论,本体建模和AI大模型结合的事情。 更多的方法都是通过AI辅助来构建本体,而这个本体模型本质还是用传统的OWL2模型+SWRL等规则语义,那么你后续推理自然也是演绎推理,这个虽然有价值但是并不是最核心价值的地方。 那么本体和AI如何结合? 又回到这个关键的问题上面。我一再强调的观点就是,本体模型提供给AI完整的精确的业务语义上下文,而基于场景的分析推理完全交给AI大模型。 但是在这种实践的过程中我们看到关键点在于这个上下文不仅仅是抽象的本体模型,还包括基于场景问题解决的时候动态拉取的实例数据,如果我们不分阶段把这些东西全部投喂给AI大模型,AI大模型实际是无法解决的,超过了
今天继续聊本体论建模。 因为最近写本体论方面的文章比较多,包括前面也分享了一个基于已经有的本体元模型,通过AI编程的方式输出一个可视化的本体语义知识网络图谱。 主要特性: ✓ 符合 W3C 标准 ✓ 可定制的用户界面 ✓ 可视化支持 ✓ 本体重构支持 ✓ 推理机直接接口 ✓ 高度可插拔架构 ✓ 与 WebProtégé 跨平台兼容 在下载安装了这个桌面端的本体建模工具后 3. 接着第3个关键问题,我一直理解事件定义在本体模型中相对重要。 注意前面的建模并没有去实现本体模型的可视化。
四、V3:场景模型与主体模型——面向业务的编排接着在引入了领域建模以后,后面又做了一个很重要的变化,就是引入了场景模型(ScenarioModel)和主体模型(ActorModel)。 M7只与M1(对象模型)和M2(行为模型)发生直接关系,不直接引用M3(规则)、ME(事件)、M4(场景)、M5(主体)或M6(流程)。 我们来汇总一下:编号模型名称核心职责层级M1对象模型实体、属性、关系、约束L1领域对象层M2行为模型原子行为方法、触发条件、前后置约束L2原子能力层M3规则模型跨对象/跨行为的业务决策规则L3解耦决策层 ME事件模型业务事件、生产者/订阅者、事件链路L3解耦决策层M4场景模型跨对象事件协同的业务语义链L4编排协同层M5主体模型参与者、角色、权限边界横切层M6流程模型端到端协同流+审批流L4编排协同层M7 L3解耦决策层:ME事件模型+M3规则模型。有了领域服务层上面,你涉及到场景业务的协同,那怎么样去做相应的解耦?就会有相关的事件模型和规则模型。L4编排协同层:M6流程模型+M4场景模型。
进入大模型时代,这个前提发生了根本变化。当本体的消费者从 DL 推理机变成大语言模型(LLM)时,评价一套本体好坏的标准、它应当承载什么、以及它应当长什么样,都要重新回答。 更关键的是 2017 年成为 W3C 标准的 SHACL——它提供的恰恰是封闭世界的约束校验,能做跨对象约束,配上 SHACL-SPARQL 还能做跨属性的算术和时间比较。 可我真正想做的,是把本体喂给大语言模型,让它来理解和使用。这是两个完全不同的消费者。 后来我发现,这个判断和学界正在发生的一个转向是吻合的:知识工程的重心,正从"用大模型去做本体工程",转向"为大模型服务的本体";在这个新阶段,大家更看重事实覆盖、可扩展、好维护,而不再死磕逻辑上的语义完备性 参考与延伸 W3C: RDF 1.1(2014)、OWL 2 Web Ontology Language(2009)、*Shapes Constraint Language (SHACL)*(2017)
今天继续结合这套企业架构材料,来看下如何基于企业架构来构建本体模型。 这四类正好对应到本体建模的四个核心元模型。 具体怎么做的呢? 我手上有一份《本体建模规范》(v1.0,八个模型那一套,里面把对象、行为、规则、场景的 YAML Schema 都规定好了)。 这条链路在 TOGAF 文档里是有的,但都是规划层面的;现在我用本体模型把它落实到了具体的对象和行为上,可以直接被系统读、被规则卡、被跨域穿透。 这三步做完之后我最大的感受是:规划文档再厚,没有本体模型托底,它还是浮的——落到系统里的时候照样会断链、会扯皮、会口径不一对不齐。本体模型其实不是规划之外的东西,它是规划真正"落地"的那一层。
腾讯混元 Hy3 大模型以 2950 亿的总参数量,进入了超大参数模型行列。 不过 Hy3 并非传统的全参数稠密模型。 用户可通过对应订阅方案继续使用 四、Hy3 与其他模型的对比 CodeBuddy 国内版内置了多款 2026 年最新旗舰大模型,用户可在对话界面一键切换,包括混元 Hy3、DeepSeek V4、Kimi 选 MiniMax-M3 的场景:需要原生多模态能力(图像/视频理解、电脑操作)的 Agent 任务。M3 是国内首个齐备这些要素的开源模型。 五、Hy3限免活动 根据官方公告,Hy3 限时免费调用活动已延长至 2026 年 8 月 31 日。在此期间,CodeBuddy 用户可以免费使用 Hy3 模型进行文本类任务。 限免活动结束后,Hy3 将作为常规模型纳入 CodeBuddy 的模型矩阵,用户可通过对应的订阅方案继续使用。 六、开始体验 Hy3 目前 Hy3 已在 CodeBuddy 平台上线并开放免费体验。
本文旨在介绍本体的基本概念和通用构建方法。 1 为什么构建本体? 实际应用中,构建一个本体包括: 定义本体中的概念 将概念进行分层,确定超类与子类关系 定义概念的属性以及对这些属性的值的限制 为实例填充这些属性值 3 本体构建方法 下面介绍一种可行的构建本体的方法。 我们要用这个本体来干什么? 本体中的信息应该为何种类型的问题提供答案? 谁将来使用并维护本体? 在确定了本体的基本范围后,一种确定本体具体范围的方法是,列出一系列本体应该能够回答的问题,这些问题被称为 competency questions,其专注于本体所涉及的领域,但也不用过于具体,我们将用这些问题来对已完成的本体进行测试 第二步 考虑重用现有的本体 在从头开始构建本体之前,最好先调研是否有相关的本体已经被构建出来了。我们可以基于这些本体进行进一步的改进和扩展。
同样,对于本体模型,如果脱离场景和应用,那么本体模型本身没有体现存在的意义,或者说了为了本体而本体。在我的本体建模规范里面,我将场景问题和本体模型的映射,放到了场景模型定义中。 但是场景模型按道理不属于狭义的本体建模范畴,但是场景模型解决了一个关键点,就是本体模型存在的意义和价值问题。场景模型让本体模型的价值得以体现。 存在的本质如何定义,如何抽象,如果这是本体论研究的范畴。那么这个本体模型究竟应该如何形成?我们的建模方法论是如何的?包括这个本体模型形成后,如何应用这个本体模型去解决问题,去分析和推理。 所以本体模型本身也不是重点,重点是你如何基于业务形成本体模型,同时确保整个本体模型是正确的。包括你如何基于场景问题应用本体模型,去发挥本体模型的价值。这个才是重点。 方法论+本体模型才能够真正发挥本体应用的价值。那么AI大模型公共知识库里面有无方法论?
它把业务系统拆成几个相互引用但职责清楚的模型:M1对象模型描述业务中有哪些核心对象、属性和关系;M2行为模型描述这些对象能执行哪些操作;M3规则模型描述校验、计算、推导和风控等可复用规则;ME事件模型描述业务状态变化后触发的事件及订阅关系 这样后续模型生成出现问题时,可以回到需求来源定位原因。 2. 本体模型引擎 本体模型引擎负责把需求文档转成本体模型,并管理模型的生命周期。它既要支持自动生成初始模型,也要支持人工调整和版本管理。 模型变更时,还要能分析影响范围,例如删除合同金额字段,会影响哪些规则、报表、接口和分析场景。 3. 应用生成引擎 应用生成引擎负责把本体模型变成可运行应用。 它根据M1对象模型生成数据库结构和领域对象,根据M2行为模型生成接口和服务骨架,根据M3规则模型生成校验与计算逻辑,根据M4场景模型生成流程编排,根据M5主体模型生成权限配置。 加入需求引擎和应用生成引擎,支持从一句话需求到需求文档、从需求文档到本体模型、从本体模型到可运行应用。
七模型定本体:LLMGateway的To-Be语义与迁移差异映射换完包名只是换壳,本体不定,后面十五境全要返工。 M3是规则层,管的是什么允许、什么禁止:Key明文只显示一次、模型ACL、重试白名单、预算封顶、隐私字段脱敏、配置快照。规则不产生新名词,它约束M1和M2的行为。 本体非文档乃是约束器先慢后不返一字定乾坤04、架构展开代码语言:TXTAI代码解释[输入]Demo的类/表/API清单(As-Is)|v[模块]七模型分层容器(M1/M2/M3/M5/M6/M7/MU) →不等于,换骨只改了名字,语义仍是Demo的单上游单租户本体Q2→先钉本体还是先写代码?→先钉本体,并且让本体可执行;不可执行的本体等于没有Q3→本体错了会在第几境爆发? 这三个问题一旦变成构建期必须通过的检查,本体就不再是会后纪要里的几行字。这一境交付的其实不是映射表,而是一条判断准则:任何不能被追溯回七模型的设计,都是还没想清楚的设计。
今天继续聊本体论和AI大模型,今天核心的主题就是本体论究竟解决了什么问题,带来什么核心的业务价值。 因此固化当前的场景虽然也可以用本体,但是从来不是本体真正的重点,真正的重点是真正理解了完整的本体模型的业务语义,真正能够做到出现新场景下的举一反三。这样才能够充分发挥AI大模型+本体的价值。 提供这个完整语义最佳的方式就是本体模型。所以原来我们只谈本体给AI大模型提供了丰富的,精确的业务语义还是没有直达最本质的东西。核心是AI要能够替代关键人员的思考过程。 这些往往就是需要本体模型+AI辅助的关键点。 所以如果你看我前面文章,我其实对经典本体论不太感冒。AI时代只有本体模型+AI大模型两者充分结合才能够真正发挥巨大的价值。 一个是最下面的Foundry+AIP的本体建模底座和AI分析推理底座的沉淀。还有一个就是面向垂直行业或者说是垂直业务的本体模型经验沉淀。而真正更加重要的我认为反而是中间层内容逻辑的沉淀。
原因就是本体建模,本体模型应用都需要底层有一个强大的Harness能力支撑。比如一个20页的原始需求,生成的软件需求存文本可能都超过10M,生成的本体模型也基本这个量级。 这些指导书真正实现了场景到本体模型之间的关键映射,脱离了这些指导书实际本体模型没法真正发挥最大的作用。这个平台我为何没有大量发布给大家下载试用? 所以拿到本体论平台也是一样的道理。本体论平台提供了Harness底座和本体模型最终的沉淀能力。但是里面的关键是将业务目标和需求转换为本体模型的能力,基于业务目标去应用本体模型分析推理的能力。 如何更好的理解本体模型,如何基于不同的业务目标和需求去构建适合自己的本体模型并落地应用,如何让本体模型发挥传统UML模型,数据模型,AI大模型无法发挥出来的更大作用,这个才是我们需要考虑的问题。 对于本体模型一样的道理,本体模型作用不是仅仅类似企业架构抽象企业实际业务,而是要真正解决业务问题的。或者说类似Palantir的理念,本体模型是真正衔接业务和数据,打通OLTP和OLAP的关键桥梁。
今天我把这个问题摊开来说——大模型时代,本体建模到底还值不值得学,LLM能不能替代本体工程师,我实测下来的结论是怎样的。 ▎ 两种极端的观点 现在圈子里对这个问题,基本两派。 一派说:LLM懂一切,不需要本体了 理由是:GPT-4、Claude、Qwen这些大模型,训练数据里包含了大量的百科知识、领域术语、概念关系——你问它"采购申请和报销申请有什么区别",它能答得头头是道; 3. 跟现有系统的集成设计 本体不是孤立存在的,它要跟你的数据库、API、工作流引擎对接——这个架构设计,LLM可以给建议,但最终方案必须懂你的人来做。 4. 3. 工程落地能力——本体设计完了怎么验证、怎么部署、怎么跟现有系统集成? 这3个能力,LLM辅助得了,但替代不了。 ▎ 给不同人的建议 如果你是企业架构师/数据工程师:本体建模值得学,而且建议学"实战导向"——别先啃W3C规范,先拿一个真实场景(比如你们公司的主数据)建一个本体,遇到问题再查。
github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/offline-use-cases.pdf 本主题的系列视点总共分为3个章节 : Part 1 什么是身份和思维模型,为什么要建立身份的思维模型 Part 2 介绍五种关于身份的思维模型 Part 3 五种身份思维模型的交集和推荐做法 01 摘 要 无论是数字身份系统还是非数字系统的工程师 本文作者在 W3C、IETF、KantaraInitiative 和 ISO 等的身份相关标准工作中发挥了领导作用。 从观察中,我们确定了五个不同的身份思维模型,每个模型都有自己的框架,目的和定义性问题。这是身份的五个正交思维模型。 这些思维模型是自然而然的概念,源于人们对身份的需求。尽管可以教授这些模型,但我们的观察表明,这些模型更经常被争论和假定(国际标准中包含的“属性”思维模型除外)。
启示一:大模型是好的提取器,不是好的裁判。裁判必须是可审计的规则 + 本体定义的身份判据。本体提供 ground truth,大模型提供候选——分工清清楚楚。 踩坑 3:信用代码字段有脏数据。有的录了全角字符,有的少一位,有的带了空格——直接相等判断全失效。加了归一化清洗层(去全角、去空格、补位校验)才稳。 而"定义概念和关系"恰恰是本体最擅长、大模型最不擅长的事。这俩不是替代关系——本体定规则、大模型提候选,合起来才是一个能上线、能审计、能回滚的企业级方案。 如果你也在做知识图谱落地、大模型 + 企业数据、或者任何"系统认人"的场景,实体消歧这道坎早晚要过。别信编辑距离,别让大模型当裁判,把"什么是同一个"写进本体里。 ■ 互动时间 1. 实体消歧你用的是规则、向量相似度、还是大模型?效果咋样? 3. 如果让你给本体加一条"同名异实"防火墙规则,你会怎么写? 评论区聊聊。
论文地址: http://arxiv.org/pdf/1904.03820v3.pdf 代码: 公众号回复:08030258682 来源: 纽约大学, 卡耐基梅隆大学 论文名称:Real-time Soft ,但它们的本体感知一直是一个挑战。 换句话说,几乎没有一种方法可以用内部传感器来测量和建模软体的高维3D形状。我们提出了一个框架,使用嵌入相机测量高分辨率3D形状的软体的实时情况。 摄像头捕捉到软体内部的视觉模式,卷积神经网络(CNN)产生代表变形状态的潜在代码,然后可以使用另一个神经网络重建软体的3D形状。 我们相信,该方法可以应用于软机器人和人-机器人交互的本体感觉形状感知。 主要框架及实验结果 ? ? ? 声明:文章来自于网络,仅用于学习分享,版权归原作者所有,侵权请联系删除。
最基础的模型加载和推理流程: 1.加载TBox的抽象本体模型(OWL类,属性,关系) 2.基于场景问题筛选数据加载ABox(RDF三元组) 3.加载规则(OWL+SWRL+SHACL) 4.执行推理 其次 虽然上面这个基于传统本体论和知识图谱的思路构建本体模型并进行推理的思路流程没有任何问题。但是AI大模型在里面起到什么作用? 传统本体建模标准是否适合AI用? 包括我在谈本体建模和本体模型的时候提到另外一个重要观点。就是构建的本体模型应该是一套更加适合AI大模型理解的业务语义模型。 其次就是我一直谈到的这种本体模型定义中缺少了关键的场景模型定义(可以理解了算法模型,是提前预设的行为规则的组合),本体建模是为场景问题服务,缺少了场景模型定义,整个本体模型缺少了关键的牵引。 也就是基于场景问题,我们基于Tbox本体模型定义,动态拉取数据出来后,可以直接投喂给大模型,让大模型展开后续的动态推理。而不是一定要用传统的本体模型中的推理引擎和推理机进行推理。
//github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/mental-models.pdf 本主题的系列视点总共分为3个章节 : Part 1 什么是身份和思维模型,为什么要建立身份的思维模型 Part 2 介绍五种关于身份的思维模型 Part 3 五种身份思维模型的交集和推荐做法 上一章节我们讲到,思维模型是真实、假设或虚构情况的心理学表示 通过理解五种思维模型,我们可以更好地进行身份系统的讨论和工程设计。本期我们将带来五种思维模型的主要特征和具体解释。 ---- 五种思维模型 每个思维模型对“身份”识别、记住和响应的方式都不相同。 02 展示思维模型 展示思维模型将身份视为我们将自己展示给社会的方式。供应商关系管理、以用户为中心的身份以及自主身份背后都是这种思维模型。 是指每个对象选择让外界认识自己的方式吗? ? 要建造一个系统,属性思维模型是最简单的一种模型,部分原因在于,属性思维模型是唯一一个有国际标准提供正式定义的思维模型。 04 关系思维模型 在关系思维模型中,身份产生于与他人的互动和与他人的关系。