面向工程和建筑团队的无代码数据标注

一位工程量测量师看到工程量清单中的一个条目——"供应并安装 150mm 直径 HDPE 管道，PN10，包括所有配件、1.2m 深度沟槽开挖、垫层、回填和恢复，完整"——立刻知道这是一个捆绑了材料、人工、土方工程和恢复的综合费率。他们知道 PN10 压力等级意味着这是供水管线，不是排水管。他们知道 1.2m 深度表明在冻结线以下但高于典型污水管深度。

ML 工程师读同一条目看到的是文本。

建筑 AI——无论是用于成本估算、规格说明解析、图纸解读还是项目风险评估——取决于正是那种存在于工程师、工程量测量师、项目经理和现场主管头脑中的领域知识。将这些知识纳入训练数据集是挑战所在。

为什么建筑数据特别难以标注

建筑和工程数据具有使其抵抗非行业人员标注的特征。

非标准术语因地区、公司和项目而异。 "BOQ「到处含义相同，但其中的行项目差异巨大。一家公司的」不可预见地质条件暂定金额「是另一家的」岩土风险应急费"。

缩写密集且依赖上下文。 "RC「可能指钢筋混凝土、运行成本或资源中心。」GF"在建筑图中是底层但在土方工程规格中是一般填料。

视觉数据需要空间推理。 建筑图纸在线宽、线型、填充图案、尺寸、注释和空间关系中编码信息。

数量有隐含约束。 工程量清单中"100m3 C30/37 混凝土用于基础"的条目承载着隐含信息。

当前状态：工程师无法使用这些工具

尽管拥有产生高质量标签的知识，建筑专业人员几乎完全被排除在 ML 标注工具之外。

典型的建筑专业人员技术环境包括：Microsoft Office、项目管理软件、成本估算工具、BIM 软件和 CAD 工具。他们的计算舒适区是带有可视界面的桌面应用。

标注工具需要完全不同的技能。设置 Label Studio 需要 Docker。Prodigy 需要 Python 和 pip。云平台需要上传可能专有的数据。

大多数建筑公司将投标数据、成本数据库和项目文件视为高度机密的商业信息。

结果：建筑 AI 开发在没有建筑专业人员参与标注环节的情况下进行。

建筑团队的需求

我们与从一级承包商到专业分包商的工程和建筑团队合作过。他们对标注工具的需求汇集在五点：

零 IT 依赖的桌面安装。 标注工具必须像 CostX 或 Bluebeam 一样安装——下载安装程序，运行，完成。

本地数据处理。 投标文件和成本数据是商业敏感的。不能上传到云平台。

支持建筑数据格式。 BOQ 来自 Excel 和 CSV。规格说明来自 PDF 和 DOCX。图纸来自 PDF、DWG 和图像格式。

可视化标注界面。 QS 专业人员习惯于可视化工具。点击、拖拽、高亮和注释。

建筑相关的标签类型。 使用建筑术语创建标签 schema 的能力。

建筑标注的实际工作流

BOQ 分类。 工程量测量师在标注工具中打开工程量清单。对每个行项目分配工种类别、成本类型、复杂度评级。高级 QS 每小时可标注 80-120 个行项目——大约是 ML 工程师的 4 倍。

规格说明解析。 合同管理员审查规格说明章节并按类型标注。

图纸元素分类。 结构工程师审查结构图并标注元素。服务工程师对 MEP 图纸做同样的事。

风险评估标注。 项目经理审查项目文件并按风险类别、严重性和可能结果标注。

规模机会

一家中型建筑公司有 20-50 名工程师、QS 专业人员和项目经理可以参与标注。如果每人每周贡献 30 分钟——一个小要求——该公司每月可产出 2,000-5,000 个标注示例。

这足以在单个季度内构建有意义的分类模型。没有领域专家参与，同样的数据集 ML 团队需要 6-12 个月才能完成，且标签质量更低。

消除障碍

Ertas Data Suite 正是为此用例而构建的。它是一个原生桌面应用，安装起来像任何其他工程软件。建筑专业人员将其指向本地文件——Excel BOQ、PDF 规格说明、图纸图像——并通过可视界面标注。没有 Python，没有 Docker，没有云上传。

标注 schema 使用团队使用的任何术语进行可视化配置。导出产生 AI 团队直接消费的标准 ML 训练格式。领域专家永远不会看到一行代码。ML 工程师永远不必解读他们不理解的建筑术语。

结果是在建筑知识上训练的建筑 AI——这是构建建筑专业人员会真正信任的模型的唯一方式。