深圳大学丁志坤教授与广州大学袁红平教授研究论文丨让建筑模型“开口说话”:大语言模型*轻量本体,重塑BIM数据交互新范式

BIM在工程全生命周期管理中发挥着不可替代的作用，但其数据交互面临双重困境。

痛点一：数据冗余严重。IFC转本体（IFCOWL）是当前主流的语义化路径，但全量转换导致文件急剧膨胀。如表1所示，五个典型模型的IFCOWL文件体积是原IFC文件的3至10倍不等，大规模项目中甚至因内存溢出而无法打开。

表1 IFC与IFCOWL数据体量对比

痛点二：交互门槛过高。现有BIM数据查询大多依赖静态人机交互（SHDI）：每次数据需求变更，用户都必须手动介入，直接编写SQL或SPARQL查询语句，不仅效率低下，还对专业技能要求极高。这使得BIM数据的使用权实际上被锁定在少数技术专家手中。

本研究提出的框架将整个BIM数据交互过程拆解为四个相互衔接的阶段（图1）：

图1 基于LLM与本体的动态BIM数据交互框架总览

用户用自然语言描述数据需求（如“我需要一个能在Omniverse平台流畅加载的轻量结构模型”），LLM对其进行语义解析，输出结构化数据需求（数据范围、精度等级、输出格式等）。

本研究设计了包含五要素的提示词模板（图4）：任务描述（Task）、知识注入（Knowledge）、操作指令（Instruction）、答案映射（Answer Mapping）、输出格式（Response Format）。LLM输出结构化JSON后，先经用户确认，再进入下游任务，确保语义准确性（图5）。

本研究选用本地部署的Qwen2.5-14B模型（单卡NVIDIA RTX 4090），兼顾中文语义理解优势、数据隐私安全和低运营成本。

图4 提示词模板设计

图5 语义分析交互逻辑

针对隐含语义（如"结构模型"并不直接对应任何IFC类名），系统向LLM注入外部规则（如“柱、梁、板、墙为本项目结构构件”），引导其生成覆盖四类构件的UNION查询语句。对于复杂语义歧义，则保留领域专家介入通道，实现"自动纠错+人工兜底"的双保险机制（图6）。

图6 SPARQL生成交互逻辑

研究以一栋12,600平方米、共7层（含地下室）、涵盖20,933个建筑构件的图书馆为案例，系统测试了框架各环节的实际表现。

▌数据压缩效果（图7）

原始IFC文件160MB，经全量RDF转换后膨胀至1,393 MB（增幅870.6%），且因Java堆内存溢出根本无法在Protégé中打开；而本框架的轻量部分转换结果仅14MB（为原文件的8.75%），1秒内即可完成加载。

图7 全量转换vs.轻量转换对比

▌语义交互过程（图8）

用户以自然语言提出"提取可在Omniverse流畅加载的轻量结构模型"需求，系统经两轮语义对话确认需求，再通过一轮SPARQL生成（含人工修正UNION子句语法），完成全流程。全程平均2.3轮交互，专家介入率33.3%，大幅低于传统全程手动操作。

图8 语义分析与数据检索处理过程

▌几何简化效果（图9）

对提取的结构构件执行C级几何简化后：

图9 元数据提取与处理流程及几何简化效果对比

本研究的核心贡献可归纳为两点：

一是提出了面向任务的IFC语义轻量化映射范式——不再盲目追求全量语义转换，而是仅保留高频查询所需的层级结构与核心关系，将本体文件体积压缩至原IFC的8.75%，彻底解决了IFCOWL的冗余问题。

二是构建了“语义分析→本体约束→SPARQL执行”的端到端动态交互流水线——用LLM的生成能力替代专家手工编写查询语句，以外部规则库保障领域适配性，以自动纠错+人工兜底保障执行可靠性，真正实现了从自然语言到工程数据的全链路贯通。

未来，研究团队计划在以下方向深化研究：开发自动化提示词生成算法，提升系统对多样用户输入的泛化能力；建立标准化性能基准测试体系，涵盖不同规模模型的查询延迟与系统吞吐量；进一步向设施运维和数字孪生场景延伸，探索该框架在多平台数据集成与低成本运维支持中的应用潜力。

本研究得到深圳市自然科学基金稳定支持计划（项目编号：20220810160221001）的资助。