第二部分:从第一性原理思考本体论在运维中的价值 要理解本体论为什么对智能运维这么重要,得回到运维的第一性原理。 这一点对智能体尤其重要——没有本体论时,Agent 面对的是一堆零散的工具 API;有本体论时,Agent 面对的是对象上的受控动作。 第四部分:本体论与 AI 原生——为什么智能体离不开本体论 最近一年讨论本体论的人突然多了起来,这背后有一个最直接的推手:AI 原生(AI-Native)。 4.5 本体论与智能体的四种协同模式 理解了 AI 原生的全局,再回到具体的运维智能体,本体论与 Agent 的协同就清晰了。 模式一:本体作为智能体的"世界模型" 智能体通过本体查询来感知系统状态,而不是直接访问原始数据。 比如告警触发后,Agent 不是去 grep 日志,而是问本体:"这个告警关联的服务是什么?
一 报告导读 本文报告主要介绍了对通用智能本体的设想和研究工作,从通用智能本体可迁移性、可扩展性、可群智性三大基本特性进行解读,元操作流的解析、与计算机的类比与学习、人类行为理解知识引擎、动作元操作学习等方面介绍了目前的研究进展 回国前在斯坦福大学人工智能实验室博士后工作。获得国家青年千人计划。 三 报告内容 让我们来看一下当前人类研制的各类机器,服务于各种行业各种情况,而人是通用的智能本题,任何场景都可以做很通用的事情。 ? 我们在思考,作为一个通用智能本体需要什么样的特性呢? 第一是具有迁移性,也就是说面对不同的任务我们用一个本体就可以了,不用专门设计各种本体。另外本体可以打成好几个模块,模块可以独立升级,最后还有群治性,支持增长和支持共享,这是本体的基本特性。 ? 通用智能本体是一个很大的话题,但是具体怎么做?首先,任何人的操作都可以解析成元操作,意思就是不可分割的操作,比如说抓取、插拔等等,这在机器人领域有一定的定义。
本文旨在介绍本体的基本概念和通用构建方法。 1 为什么构建本体? 我们要用这个本体来干什么? 本体中的信息应该为何种类型的问题提供答案? 谁将来使用并维护本体? 在确定了本体的基本范围后,一种确定本体具体范围的方法是,列出一系列本体应该能够回答的问题,这些问题被称为 competency questions,其专注于本体所涉及的领域,但也不用过于具体,我们将用这些问题来对已完成的本体进行测试 第二步 考虑重用现有的本体 在从头开始构建本体之前,最好先调研是否有相关的本体已经被构建出来了。我们可以基于这些本体进行进一步的改进和扩展。 7 结语 本文简单介绍了如何构建一个本体,最重要的信息是:任何领域都没有单一的正确本体。构建本体是一个创造性的过程,本体的质量只能通过实际应用来评价。
商业智能软件可以收集、管理、分析和转化企业中现有的数据,使这些数据成为可用的信息。让企业更轻松地获取洞察力,帮助企业做出明智的经营决策。 商业智能软件辅助操作层的决策,也可以辅助战术层和战略层的决策。为了将数据转化为知识,商业智能软件涉及咨询服务、应用和信息技术的充分利用。其基本体系结构包括数据仓库、统计分析、数据挖掘三个部分。 作为国内商业智能软件中的佼佼者,亿信ABI可连接包括关系型数据库,分布式数据库,文件数据源,接口数据源等多种类型的数据源,并支持跨源跨库的分析。 内置了分类分析,关联分析,回归分析,聚类分析,时间序列预测等多种预测挖掘算法,全程可视化,拖拽操作即可轻松掌握数据挖掘,并提供了科学的模型评估方法,根据评估结果智能的推荐最佳模型。
本体智能合约目前使用 NeoVM 虚拟机,开发者可以使用他们所熟悉的语言,例如 C# 和 Python 等去编写智能合约,而无需再去学习一种新的语言,这极大地降低了智能合约开发的入门门槛。 02 跨合约调用攻击 本期,我们讲解在本体上开发智能合约时可能遇到的一种漏洞攻击,即跨合约调用攻击。 通过此种方式,我们就能很好地防范智能合约被跨合约调用攻击。 04 后记 本期列举了本体智能合约开发者在进行智能合约开发时可能遇到的一种攻击类型,这种类型的智能合约攻击比较隐晦。 如果开发者对智能合约本身不是特别的了解,可能很难预知并防范这种漏洞攻击。在之后的技术视点中,我们将会展示更多的漏洞攻击类型,帮助本体智能合约开发者更好地避免合约开发中可能存在的漏洞。 同时,本体智能合约开发者可以使用本体智能合约集成开发环境 SmartX 中深度集成的高度自动化智能合约形式化验证平台 VaaS-ONT 来“一键式”精确定位到有风险的代码位置,迅速找出原因,有效验证智能合约或区块链应用的常规安全漏洞
——题记 01 引言 在上一期中,我们介绍了一种在本体上开发智能合约时可能遇到的安全威胁,即跨合约调用攻击。相信大家对如何防范这种智能合约漏洞攻击有了一定的了解。 本期中我们将介绍在本体上开发智能合约时可能遇到的另一种安全威胁以及相关防范措施。 通过这种方式,智能合约开发者可以防范恶意用户利用该漏洞攻击合约的情况发生。 04 后记 以上,我们讲解了在本体上开发智能合约时可能遇到的第二种安全威胁,并给出了相关解决方案。 我们还将继续介绍另外的智能合约安全威胁,方便大家了解如何在本体上开发更加安全的智能合约。 本体智能合约开发者可以使用本体智能合约集成开发环境 SmartX 中深度集成的高度自动化智能合约形式化验证平台 VaaS-ONT 来“一键式”精确定位到有风险的代码位置,迅速找出原因,有效验证智能合约或区块链应用的常规安全漏洞
01 导语 在上一期的技术视点中,我们介绍了合约原生 API,讲述了如何利用智能合约进行ONT / ONG 转账。本期我们将讨论如何通过 Upgrade API 来进行合约升级。 在这之前,小伙伴们可以在本体智能合约开发工具 SmartX 中新建一个合约,跟着我们进行操作。跟以前的 API 讲解一样,在文章最后我们将给出这次讲解的视频示例。 03 结论 本次技术视点中我们介绍了本体区块链的 Upgrade API,开发者可以用来进行合约升级。 下一期我们将介绍本体 Python 智能合约语法的 Static & Dynamic Call API,讲述如何在 Python 智能合约中进行静态调用和动态调用。
——题记 01 引言 在上面两期中,我们介绍了在本体上开发智能合约可能会遇到的两种安全威胁:跨合约调用攻击和强制交易失败攻击,并针对这两种安全威胁给出了相应的解决方案。 同时,社区开发者如果在本体上进行智能合约开发时遇到其它的安全威胁,可以和我们一起探讨,一起共同打造更加安全的智能合约体系。 这一期将介绍开发智能合约过程中可能遇到的另外一种安全威胁:存储注入攻击。 在详细介绍这种安全威胁前,我们先介绍下本体的智能合约持久化存储接口 : def Put(context, key, value) 该接口主要包含下列三个参数: 1. context - 当前智能合约的运行的上下文环境 04 后记 以上我们讲解了第三种在本体上开发智能合约时可能遇到的安全威胁,并给出了相关解决方案。 另外,本体智能合约开发者可以使用本体智能合约集成开发环境 SmartX 中深度集成的高度自动化智能合约形式化验证平台 VaaS-ONT 来“一键式”精确定位到有风险的代码位置,迅速找出原因,有效验证智能合约或区块链应用的常规安全漏洞
同时,社区开发者如果在本体上进行智能合约开发时遇到其它的安全威胁,可以和我们一起探讨,一起打造更加安全的智能合约体系。 本期我们将介绍在智能合约开发中更常见的一种安全漏洞及其解决方案——边界攻击。 在介绍这种攻击之前,我们需要先注意这一点:本体智能合约支持正数与负数的数学运算。 04 总结 以上是我们讲解的第四种在本体上开发智能合约的漏洞,并附带了解决方案。 至此,我们的智能合约安全与漏洞分析就告一段落,在之后的开发中如果我们发现另外的智能合约漏洞,我们会再以案例讲解的形式公布给大家,希望大家可以和我们共同打造本体上更加安全的智能合约。 以下哪个选项不是对本体智能合约的正确描述? A. 本体区块链合约体系不存在向上溢出或向下溢出问题 B. 本体智能合约不支持正数与负数的数学运算 C. 支持的最大值为2^255 D.
1 OWL 本体简介 OWL 是由 W3C 开发的一种本体描述语言,按照表达性可以被分为三类: OWL-Lite:可表达性最低 OWL-DL:可表达性中等(本指南使用) OWL-Full:可表达性最高 OWL 本体的组件与 Protege 框架下的本体组件相对应,包括: Individuals:对应 Instances Properties:对应 Slots Classes:对应 Classes 1.1 2 构建一个 OWL 本体 本章节以创建一个披萨本体为例,介绍如何通过 protoge 构建一个 OWL 本体。 2.1 创建本体 File -> New 新建一个本体,修改其 IRI(每个本体唯一): ? 以 OWL 形式保存为 "pizza.owl": ? 在 Annotation 中可以添加评论: ? 断言本体(手工创建)和推理本体如下图所示: ? 2.12 值分割 本章节我们将介绍值分割(Value Partitions),它并不是 OWL 的特性,而是一种本体构建中的设计模式。
01 导语 上一期我们介绍了本体 Python 智能合约的合约执行 API,本期我们将讨论如何通过 Native API 来进行本体原生合约调用。 原生合约调用最典型的功能就是合约转账,这也是整个智能合约最核心的部分。Native API 只有1个 API。 在这之前,小伙伴们可以在本体智能合约开发工具 SmartX 中新建一个合约,跟着我们进行操作。跟以前的API讲解一样,在文章最后我们将给出这次讲解的所有源代码以及视频讲解。 目前,本体可供使用的原生合约有六个。 原生合约调用最典型的功能就是合约转账,这也是整个智能合约最核心的部分。在下一期技术视点中,我们将介绍 Upgrade API,探讨如何在本体智能合约中进行合约升级。
传统智能体的"表面智能",已经满足不了企业精细化管理的需求。本体智能体(Ontology-Driven Agent),正是为破解这个痛点而来。一、为什么"会聊天"的 AI,做不好企业的事? 二、什么是本体智能体?本体智能体(Ontology-Driven Agent),核心是在大模型与企业业务数据、规则之间,搭建一套标准化的"业务语义本体"。 它的本质,是让 AI 从「通用对话者」升级为「专业业务执行者」——传统智能体的核心是"执行指令",本体智能体的核心是"理解业务"。 本体智能体把规则与执行解耦:业务人员只需在本体里直接更新规则,智能体就能快速适配。这完美匹配了企业政策频繁调整的现实——改的是"手册",不是"大脑"。 七、关键认知:本体智能体不是"装个软件"最后,有一个认知必须点明:本体智能体的价值,终究取决于它承载的业务知识深度。
01 导语 在前两期的本体技术视点中,我们介绍了跨合约静态调用与动态调用,讲述了如何使用 RegisterAppCall API 与 DynamicAppCall API 跨合约调用其他合约的函数。 本期将进入本体 Python 智能合约语法专辑的终极篇,探讨如何使用合约执行引擎 API,即 ExecutionEngine API。 它包含了3个 API,用法如下: 本期语法难度较大,堪比 Python 智能合约界的九阴真经,学成了你就厉害了! 下面我们具体讲述一下 ExecutionEngine API 的使用方法。 在这之前,小伙伴们可以在本体智能合约开发工具 SmartX 中新建一个合约,跟着我们进行操作。同样,在文章最后我们将给出这次讲解的所有源代码以及视频讲解。 我们准备两个智能合约,合约 A 与合约 B,假定合约 A 来调用合约 B 的功能函数。
今天完整分享下最近通过AI编程实现的一个基于本体模型+AI大模型驱动的端到端AI智能体交付平台。包括需求分析,整体设计,核心功能实现。供大家参考。 该平台以本体模型(Ontology Model)作为中间表示层,打通了从原始业务需求到可运行AI智能体的完整链路:需求探索 → 本体建模 → 可视化验证 → 能力代码生成 → 技能封装 → Agent动态发布 我们选择本体作为AI智能体工厂的核心中间表示,基于以下关键判断: 语义完备性:本体不仅描述"有什么数据"(对象),还描述"能做什么"(行为)、"为什么这样做"(规则)、"在什么情况下触发"(事件+场景) Code-Chat(智能体商店) — 负责"运行"智能体。 四、总结与展望 4.1 核心价值回顾 本文介绍的"本体+AI驱动的AI智能体工厂"平台,通过以下三个核心设计决策,实现了从需求到智能体的半自动化交付: 第一,以本体模型作为"通用中间语言"。
这大半年,本体论实在是太火了。我自己也在公众号和视频号里聊了很多期,从西方哲学的本体论,到 Palantir 的本体,到对象行为规则建模,再到本体驱动 AI 原生应用。 不是否定本体论,而是想认真地划一划它的边界:本体论到底适合解决什么问题,又有哪些场景根本不该硬上本体。讲清楚边界,本体论才不会沦为一个空洞的口号。 大量的本体论滥用,恰恰是混淆了这两件事。要么是拿本体去抢"算法早就固定好了"的活,画蛇添足;要么是指望本体模型本身能直接产出"精确结果",缘木求鱼。 这一类就滑到了右下象限,恰恰需要本体加大模型。所以合规检查要拆成"规则可枚举"和"需语义裁量"两半看,不能一刀切。 例子二:智能问数、ChatBI 场景。 但它的核心,仍然是本体模型驱动 AI 编程、输出精确的源代码,它暂时并没有实现 Palantir 那种数据分析模式下真正的智能推理能力。
今天接着聊本体论方面的内容。因为前面我在聊本体论的时候,更多的是在讲如何构建一个本体,如何进行抽象建模,实现对象、行为、规则三者之间的一个融合统一。 你只有了解了这个问题,你才能够知道:我们为什么要去做本体模型?或者是通过本体论的思想解决什么问题? 所以这个时候我们再来回到本体论。 这个是本体论带来的巨大的一个价值。 所以说本体论,在当前的情况下面,它有可能是依托在我传统已有业务系统、已有主数据或者是数据中台产品上面的本体论的建模。 这个是本体论最最核心的一个价值。 好了,把这个理解完了以后,我们再回来想另外一个关键问题。 就是我在讲本体论的时候,我为什么没有特别强调是Palantir的本体论? 那如果我一开始就应用的本体论的思想,那我这个时候的模型就不会分OLTP和OLAP都各自构建一套模型,而是构建一套融合的本体模型。
图片来源于网络 今天我们延续去中心化身份的话题,结合本体汽车解决方案概念视频中的案例展示,分析当去中心化身份应用于汽车行业会带来怎样创新的场景。 首先观看一个小短片 ? 0 1 启程 便捷面部识别登录,随时随地智能启程 ? Daphne 通过自己的去中心化身份(ONT ID)刷脸登录,进入驾驶室。 与此同时,通过汽车保险和维修公司数据的接入与打通,系统能够对汽车零部件进行自动监测,判断出哪里需要检修,智能化地完成相关的维修流程,实现对汽车生命周期的智能管理。 ? 图片来源于网络 区块链技术能够使以上问题迎刃而解,伴随着本体汽车解决方案的发布,本体团队也在积极推动这一进程。 本体信用分 B. 车辆生命周期管理 C. 路权申请 D. ONT/ONG 闪兑功能 将答案私信后台,前三名答对的同学将得到本体书包一个。
图片来源于网络 视频回顾 https://v.qq.com/x/page/v31421ve7oj.html 视频中演示了 Daphne 驾驶应用本体解决方案的汽车,使用面部识别功能启程,使用数字资产支付 ,用大数据分析突发路况,通过本体信用分判断是否共享,发起路权申请避开拥堵,在应用内完成云端理赔,实现车辆生命周期的系统管理。 应用案例 本体区块链解决方案已被一家领先的德国汽车企业用于付款结算、车辆识别和数据共享等关键环节。 ? ? 同时,本体支持用户、车辆和第三方之间的身份认证和数据协作。 通过本体信任框架和自主权数据存储部署一系列密码算法来保护用户身份和数据隐私安全。每个数据共享操作都需要授权,并通过授权协议和密码算法来实现选择性共享。 本体信用分 B. 车辆生命周期管理 C. 路权申请 D. ONT/ONG 闪兑功能
谢谢!
今天继续聊本体论建模。 因为最近写本体论方面的文章比较多,包括前面也分享了一个基于已经有的本体元模型,通过AI编程的方式输出一个可视化的本体语义知识网络图谱。 当然这个仅仅是简单的可视化展示的示范,还是有不少朋友问当前有无一些开源的本体论建模工具可以参考。最近也查找了不少资料,找了一个斯坦福大学开源的本体建模工具。 提供重构操作,包括本体合并、在本体间移动公理、批量重命名多个实体等。 也就是我需要构建一个合同的语义本体,能够完全支撑我后续合同管理需求的实现。所以需要你仔细分析我的需求来构建这个本体。 所以你已有的数据库设计经验完全可以平移过来理解本体建模,只是 OWL 在语义表达上比数据库更强一层。 当然,本体建模另外一个核心还是规则。