openBIM Talk | 从“词元接龙”到工程事实：谈大语言模型与语义网技术的融合

整理说明：本文根据在2026年8月openBIM Talk第二期的报告《大语言模型与语义网技术融合：基于openBIM，持续生长的工程知识系统》整理。

生成式人工智能已经能够理解自然语言、生成文本和图像，并在大量日常任务中展现出极强的可用性。但当它进入工程建设领域，问题并不只是“能否回答”，而是“回答所依据的事实是什么、能否复核、规则是否被遵守、项目事实发生变化后知识是否仍然有效”。

工程智能不应仅被理解为把文档交给大模型，再从中检索答案。工程世界需要一个能表达对象、关系、属性、规则和约束的知识底座。大语言模型可以承担理解、交互与生成的角色；语义网和本体则负责把工程事实组织为可计算、可推理、可追溯的知识系统。openBIM提供了描述建成环境事实的共同语言，因此可以成为这种工程知识系统的重要基础。

从概率生成到工程事实

当前生成式AI可概括为：从大量数据中挖掘规律，并估计“下一步什么更可能发生”。从传统机器学习、深度学习到大语言模型和扩散模型，技术路线虽有差异，但都离不开样本、统计相关性和概率预测。

在大语言模型中，输入会被切分为词元（token），模型据此预测后续词元。这样的机制使模型能够自然地续写、归纳和表达，却也意味着它并非天然拥有对现实世界事实的直接把握。以“蘑菇是否可食用”为例：模型可能给出听起来流畅、甚至十分自信的回答，但这种回答若缺少明确的事实来源、专业规则和验证机制，便可能造成危险。图像生成也有类似现象：模型能生成“猫坐在垫子上”的常见画面，也能生成“猫飞在天上”的非常规画面；生成质量不等于工程事实成立。

报告引用维特根斯坦的命题：“世界是事实的总和，而非事物的总和。”这句话被用来说明工程知识的关键不在于孤立地罗列对象，而在于表达对象之间真实存在的关系。例如，“猫”“垫子”都是对象；“猫在垫子上”才是一个可陈述、可判断的事实。工程领域同样如此。仅有构件名称、设备参数或文档片段，并不能形成可用的工程知识；构件与空间、系统、工序、责任、状态、规则之间的关系，才是工程事实能够被理解和验证的前提。

工程AI面对的不是单点问答，而是系统性问题

工程领域的AI挑战可归纳为准确性、稳定性和及时性。三项要求彼此关联：结果必须正确，才能用于工程决策；相同事实和规则下，结果必须可复现；项目发生设计变更、现场状态变化或数据更新时，系统又必须及时反映新的事实。

报告进一步把困难归结为四类原因。

• 第一，工程知识中包含大量非公开的专有知识。它们可能沉淀在企业制度、项目文件、专家经验和特定软件系统中，并不天然出现在公开训练数据里。

• 第二，工程事实具有动态性。设计、采购、施工、验收和运维过程持续改变对象的属性和关系。一个昨天正确的答案，在今天的项目状态下可能已经失效。

• 第三，工程场景对结果的精度、可靠性和可解释性要求很高。工程AI不能只追求“看起来合理”，还应能够减少幻觉，说明答案来自何处，并保持规则和结论的一致性。

• 第四，工程数据分散于多种载体和系统。CAD、BIM、文档、表格、传感器数据、ERP、CRM以及现场记录的粒度、格式和语义往往不同。把它们简单堆叠，不会自动形成可计算的工程知识。

因此，报告的判断是：工程AI首先是一个系统问题。模型能力是必要条件，但还需要处理事实更新、知识治理、规则表达、推理链路和结果约束。

技术要点： 工程AI不是通用问答的简单迁移，而是对专有知识、动态事实、可靠生成与多模态上下文融合的系统工程。

RAG、GraphRAG与动态语义网：它们各自解决什么

面对大模型不了解企业私有知识的问题，常见做法是训练、提示词工程和上下文工程。上下文工程非常关键，将外部知识以可控制的方式提供给模型，并避免把每一次知识变化都变成重新训练的任务。

向量RAG（检索增强生成，Retrieval-Augmented Generation）通常将文档切分为片段，生成嵌入向量，再根据相似度召回相关片段作为上下文。它适用于从大量非结构化材料中寻找语义相近的内容，但也有明确限制：片段化可能切断上下文，向量相似不等于工程关系成立；对于跨文档、多跳关系、逻辑约束和实时变化的项目事实，单纯依赖相似度检索并不充分。

技术要点： 相较于训练和微调，采用上下文工程并外接集成数据底座，成本更可控，也更能适应不同需求。

GraphRAG将实体和关系组织为图，能够支持多跳检索，例如从某个构件追溯到所属系统、空间、责任主体和关联规则。GraphRAG能够对复杂关联的改进，但图的构建、维护和查询成本较高；更重要的是，如果图只保存某一时刻的静态关系，它仍难以直接处理工程事实的持续变化。

语义网的重点不只是“再建一张图”，而是为对象、关系、属性和规则赋予明确、可共享的语义，并使系统能够在事实变化后按规则重新推理。语义网技术可视为连接“动态世界”和“可计算知识”的机制。

三层知识结构：事实、语义与应用

语义网可概括为三个相互衔接的层次。

底层是事实数据层。它记录可观察、可更新的工程事实，例如构件、空间、设备、传感器读数、文档、任务和状态。

中间是语义与逻辑层。它以本体定义概念和关系，以规则表达约束和推理条件，使不同来源的数据能够指向共同的概念体系。

上层是应用层。问答、检索、校核、预警、智能体和业务应用并不直接面对彼此割裂的原始数据，而是通过语义与逻辑层使用已经关联、可解释的知识。

技术要点： 语义与逻辑层是核心：它以统一语言描述事实，基于事实推理，并将验证后的结果送达到应用层。

以建筑围护系统、室外温度、空调系统和室内温度传感器为例。一个系统若只收集若干温度数值，很难判断它们的工程含义；当系统知道某传感器位于哪个建筑、哪个空间，空间处于何种围护条件下，又由哪个空调系统服务时，温度数据才会进入可以推理的情境。事实变化会触发关系和规则的重新计算，从而使“动态”成为知识系统的内在能力，而不是事后人工修订的负担。

本体和推理的价值还在于把隐含事实显式化。例如，系统已知两个传感器位于同一场地，便可根据定义推导出二者具有相同的场地归属。这样的推导链条由明确的语义和规则支持，能够被检查和说明，而不依赖模型临时“猜测”。在工程任务中，这意味着系统可以把部分回答从概率生成转为可验证的计算结果。

技术要点： 在本体推理体系下，隐含关系可以从隐性推导为显性；推理过程应严格、可控，并以明确的事实和规则约束模型输出。

组合式上下文增强：动态图数据与场景化算法

报告展示了一组同一领域34个离散数据集上的500轮横向对比测试。对比对象包括非结构化数据合并注入、向量RAG、静态图数据RAG、动态图数据RAG，以及“动态图数据加场景化算法”的组合。报告图表显示，在所列准确率和召回率指标中，动态图数据结合场景化算法的方案表现最高；同时，所使用的大语言模型能力仍会影响结果。

这组结果的意义不在于宣布某一技术可以取代模型，而在于说明：对工程场景而言，给模型提供结构化、动态、受规则约束的上下文，与仅提供非结构化片段或静态关系图，是不同层次的知识支持。模型负责理解问题和生成交互；语义数据、推理与场景算法负责把答案锚定在可识别的工程事实与规则上。

技术要点： 语义网动态推理与场景化算法的组合，在报告所展示的不同开源和闭源大语言模型对比中均呈现更优效果。

语义网为何在今天重新成为关键技术

互联网的发展可概括为几个阶段：Web 1.0解决信息发布与访问，Web 2.0强调互动和平台，Web 3.0曾承载语义化网络的愿景。报告认为，语义网的理念并非新近出现，W3C早已推动相关标准；石油化工等领域也曾以ISO 15926等标准探索跨组织、跨生命周期的信息互操作。

然而，本体开发、数据映射、知识治理和领域专家参与都需要长期投入。企业若没有形成共同的概念体系和维护机制，语义模型很难持续生长。大语言模型的发展为语义网带来了新的入口：自然语言可以降低知识获取、查询和交互的门槛；但它不能替代本体、事实和规则本身。

以Palantir等企业数据平台为例，说明企业智能系统通常需要把事实、对象、关系、行动和应用组织在同一知识底座上。这里的重点不是某一家公司的商业表现，而是架构启示：企业AI若要参与业务执行，就必须能识别业务对象、理解其状态、调用工具，并接受规则和约束的控制。

工程知识系统的治理任务

知识治理可归纳为四类工作。

• 第一，本体开发与集成。需要定义工程概念、实体类型、关系类型和属性类型，并将既有系统的数据映射到共同语义之下。

• 第二，项目事实的更新与查询。项目数据不应只在归档时汇总，而应随着设计、施工和运维事实变化而更新，使查询结果反映当前状态。

• 第三，业务规则的定制。许多关键知识来自规范、企业标准、工艺要求和专家经验。它们需要从自然语言、表格或经验判断中提炼为可执行、可审查的规则。

• 第四，结果约束与质量验证。系统输出不仅要“给出答案”，还应能够检查数据完整性、规则符合性、推理条件和输出边界。

这些工作共同构成工程AI的知识基础设施。大语言模型可以帮助用户提出问题、生成事实候选项、辅助本体映射和解释结果；但重要的工程判断应落在可追溯的事实、明确的规则和可复核的验证上。

技术要点： 每一个企业和项目都可能有自身的业务规则；规则能够驱动隐含事实的发现与自动推理，因而是知识治理不可缺少的一层。

以模块化钢结构连接节点为例：从本体到规则，再到IFC校核

以模块化钢结构连接节点为例说明实施路径。第一步是开发本体基础框架，明确实体类型、关系类型和属性类型。例如，螺栓组、插接件、梁、柱和连接节点可被定义为不同实体；“被螺栓连接”“插入于”等关系可以被形式化；宽度、高度、直径等属性也可具有明确的定义、单位和约束。

第二步是让知识系统接入业务事实。报告展示了通过自然语言交互生成或补充事实数据，并把BIM、ERP、CRM等来源纳入知识系统的方式。自然语言降低了使用门槛，但生成的内容仍须映射到受定义约束的实体、属性和关系，不能停留在无约束的文本层面。

第三步是把隐含的工程规则形式化。举例说明，若企业规则规定“连接板最小宽度等于梁宽度加三倍螺栓直径”，则可以将其写成可计算的约束。此时，系统不只是从资料中找一段相似文本，而是基于当前梁宽、螺栓直径和节点事实计算并校核连接板宽度。报告将这种方式概括为：在明确事实和规则范围内获得可解释、可复核的推理结果。

第四步是把规则用于IFC模型的合规性检查。报告展示了对IFC层级与本体类的映射，以及在模型中查询、校核构件及其属性的过程。用户可以用自然语言提出问题，例如检查门、墙、柱等对象的关系或属性是否符合既定要求；系统则需要将自然语言意图转化为对IFC事实、语义映射和检查规则的调用。

报告最后列示了3种大语言模型、5 400组消融试验的结果，用以说明结构化知识增强与模型能力需要共同考虑。技术路线并不是“只要有本体就不需要模型”，也不是“只要换一个大模型就不需要知识治理”；工程智能的可靠性来自模型能力、数据质量、语义结构、规则体系和验证机制的协同。

openBIM是工程知识的共同语言

openBIM是一套能够描述物理世界事实的开放共同语言。IFC并不只是一个文件交换格式；当它被映射进本体、与项目事实和业务规则结合时，便可以成为工程知识系统中可识别、可关联、可校核的一部分。

这也是提出“基于openBIM构建持续生长的工程知识系统”的原因。工程知识系统需要继承项目的事实，需要能够理解构件、空间、系统、过程和责任之间的关系，也需要能与跨软件、跨阶段、跨组织的数据持续连接。开放标准为这些关系提供了可共享的表达基础；语义网把表达基础提升为可推理的知识网络；大语言模型则使人可以通过自然语言进入这一网络。

技术要点： 工程智能需要一套共同的标准和语言体系来描述物理世界与工程事实；openBIM标准体系正承担这一共同语言的作用。

工程AI真正值得追问的问题，不是它是否会说工程语言，而是它能否立足于当前、明确、可验证的工程事实，在规则和约束之内完成查询、推理、校核和行动。对行业而言，这意味着高质量数据集、本体、规则和开放标准不是大模型时代之前的遗产，而是工程智能得以可靠进入实践的基础条件。

作者简介

张震，上海知元语链科技有限公司创始人兼 CEO，新西兰奥克兰大学博士、研究员。