AI应用园地（3）｜ AI可推理的本体与华望方案

在复杂产品设计、装备研制与系统工程的领域中，专业化的知识以非结构性文档的形式存在并高度依赖个人经验，这些文档无法成为AI能自动开展推断的知识库。尽管将知识进行数字化有很多可选的格式，例如Excel、JSON、XMI等，但它们本质上解决的是数据交换。数据层可以换存储、换接口、换系统甚至换技术栈，但逻辑骨架的本身需要稳定。而这正是本体构建要解决的核心问题。

●  本体—逻辑约束的骨架

本体（Ontology）是一个领域的形式化的概念系统，不限于定义一个领域“有什么”，还规定该领域内的概念之间“必须满足什么逻辑约束”，从而使得计算机能根据这些约束开展逻辑推断。尽管数据的格式会被迭代、会被淘汰，但本体的逻辑骨架本身是稳定的。数据层可以换存储、换接口、换系统，但只要本体的骨架不变，知识的结构和计算机进行的推理就不会变化。因此，本体概念的核心价值在于：

• 遗产化：知识不会随着人的离开而丧失，将遗留并固化在项目中；

• 可复用：一份本体可被设计工具、仿真软件、检索系统同时使用，无需重复建模；

• 可推理：计算机可自动推断文档里没直接写出来、但逻辑必然成立的知识；

• 一致性：同一个概念在任何一个工具里只有一个标准定义，不因文档而异。

图1  本体论-介绍的示意图

●  本体的详细介绍

一个可被推理的本体由三个逻辑层级构成，每一层级负责一类定义，构件按层级归属，三个层级之间互相关联。

图2  三层-概览的示意图

TBox（术语层）：定义概念和规则

TBox 回答“这个领域有什么”和“它们必须满足什么”。它包含“类与类上的约束”：

图3  术语盒（TBox）的示意图

RBox（关系层）：定义关系及其逻辑约束

RBox 定义的是本体中的属性及其逻辑约束。属性分两类，即：对象属性表达概念之间的连接，数据属性表达概念自身的数值参数。

对象属性（Object Property） 是本体中将不同类连接起来的桥梁。TBox 定义了“领域有什么概念”，对象属性则定义了“概念之间怎么连接”。每个对象属性在 OWL 中都有正式的定义：定义域（Domain）规定关系的起点类，值域（Range）规定关系的终点类，方向语义由此确定。

对象属性还存在逆属性，例如“发动机由推力室组成”与“推力室是发动机部件”互为逆关系，两者可在计算机上自动转换。

数据属性（Data Property）描述类自身的量化参数，它连接类与具体数值，例如“推力室的设计室压” “推进剂物质的分子量”“ 发动机的燃烧时长”。

数据属性不涉及类与类之间的关系，它描述的是“一个类含有什么参数”。

此外，属性公理（Property Axiom）定义了关系（和数值参数）必须服从的逻辑规律：

没有属性公理的 RBox 只是一张关系图。只有属性公理的存在，计算机才能自动推断结构链条、检测关系冲突、判断方向是否一致。

图4  关系盒（RBox）的示意图

ABox（断言层）：存放事实

ABox 回答“实例的状态是什么”。它的内容包括：

计算机在 ABox 上运行一致性检查：如果实例违反了 TBox 或 RBox 中定义的约束，实例就能被标记出来。

图5  断言盒（ABox）的示意图

三个层级的配合机制

以上三个层级不是各自独立的，一个完整的推理通常需要三个层级同时参与。例如，检查“某台发动机的工作方式同时为挤压式和涡轮泵式”，计算机需要使用 TBox 中的不相交并集约束条件来认定这是违规，需要 RBox 中的关系定义来理解“工作方式”这个属性的含义，需要 ABox 中的事实来判断该实例是否同时被赋予了这两个值。

TBox 定义规则，RBox 定义约束关系，ABox 存放事实。计算机在 TBox 上验证模型是否自洽，在 RBox 上检查语义关系是否一致，在 ABox 上做实例去开展违规检测。该三层结构才是本体能真正开展推理而不是简单进行查询的根本原因。

图6  三层-协作的示意图

●  本体技术实现的华望方案

传统的本体构建需要领域专家和本体工程师花几个月完成手工建模，后续模型维护的成本更高。华望系统科技已经实现了输入自然语言或文档（文本、Markdown、HTML、PDF）后，计算机自动输出可推理的 OWL2 本体。

华望的技术实现采用的是中间模型（IM）的方式，即：大语言模型（LLM）把文档语义抽取成为中间模型，再从中间模型分别渲染成两种表达—系统工程师能读能改的SysML 文本，计算机能理解的OWL 本体。该技术路线可以避免不可控的由 LLM 直接生成 OWL的方式，也不会出现强行解析自然语言而产生的无法理解。

目前，华望方案支撑的 OWL2 本体包括子类继承、不相交并集、属性约束、唯一键、SWRL 规则等约束。

图7 技术-实现的示意图

●  示范案例：由火箭发动机教材自动生成工程本体

以下是采用华望自主研发的AI工具，由文本自动生成工程本体的实例。将一本液体火箭发动机教材前两章的清洗文本（约 14 万字，覆盖总体设计和主要子系统）作为输入，经AI工具自动处理后，输出了覆盖五大子系统（推力室、供应系统、推进剂、总装组件、控制架构）的本体，包含约 40 个类、70 个数据属性、27 个对象属性。

片段一：子类继承。教材中描述氧化剂、燃料都属于推进剂物质，AI工具自动生成一个中间模型，再渲染出如下 SysML 中间稿（工程师版本）：

item def Oxidizer :> PropellantSubstance;

item def Fuel :> PropellantSubstance;

计算机推理出的 OWL本体表达：Oxidizer rdfs:subClassOf PropellantSubstance。计算机由此推断—凡推进剂的物质属性（分子量、沸点、密度）将由氧化剂和燃料自动继承，无需人工标注。

片段二：不相交并集。发动机工作方式—挤压式和涡轮泵式，二者互斥。AI工具检测该语义后生成：

disjointUnion FeedSystemCategory = PressurizedSystem | TurbopumpSystem; 最终映射为 owl:disjointUnionOf。AI工具不仅知道有哪几类，还知道一个实例不可能同时属于两个互斥类别。普通标签只标明“是什么”，不相交并集还规定“不可能同时是什么”。

片段三：唯一键。 如何区分两台不同的发动机？AI工具推理出型号和用途的组合可作为发动机的唯一识别方式：key LiquidRocketEngine(engineDesignation, intendedUse); 最终映射为 owl:hasKey。如果两个发动机实例的型号和用途都相同，它们就是相同个体。唯一键是在数据集成与跨系统比对时的核心能力。

以上三个片段不是人工挑选出来的，而是AI工具从教材中自动抽取、生成、映射生成的。14 万字的教材最终成为了一份结构完整、约束严谨、可被计算机使用的工程本体。

图8  本体案例的示意图

●  本体的不可替代性

在上述案例之后，一个疑问自然而然会出现：以上信息用其他格式保存不行吗？答案是：不行！这不是存储容量的问题，而是能力的问题。对于Excel 和 JSON 格式， 数据含有字段名和值，计算机能读出每个字段但却无法理解字段之间的语义关系。例如，一个 JSON 里同时写有“氧化剂”和“推进剂”，计算机不知道前者是后者的子类，更推理不出“氧化剂继承推进剂的所有属性”。

尽管XMI格式能描述模型的结构形状—类、属性、关系，但不携带逻辑公理，不能表达“互斥”“ 属性传递”“ 两个字段组成个体唯一标识”。它解决的是模型交换却不是知识推理。

OWL2本体把信息写进文件，使得计算机能读到、能验证、能据此推断。这不是在已有格式上加一个标签层，而是在数据之外多出一套逻辑层。本体文件让计算机能自动完成子类推断、互斥检测、一致性验证，而这些能力是文档检索做不到的，也是模型交换无法实现的。

图9  为什么需要本体论的示意图

在工程实践层面上，这意味着其他存储格式做不到：知识不再绑定个人，变成组织可拥有的数字资产；设计、仿真、测试系统采用同一套术语和逻辑约束；计算机可推断出没有直接写出来的信息。人走了知识留下了，系统变了信息还能重用，数据还能自动做一致性检查，而这些能力正是本体不可替代的核心价值。