工程和建築團隊的無代碼資料標記

工程量清單師看著工程量清單的一個行項目——「供應和安裝 150mm 直徑 HDPE 管道，PN10，包括所有配件、挖溝至 1.2m 深度、墊層、回填和恢復，完整」——立即知道這是一個捆綁材料、勞動力、土方工程和恢復的複合費率。他們知道 PN10 壓力等級意味著這是供水管線，而不是排水管線。他們知道 1.2m 深度表明它在霜線以下但在典型下水道深度以上。

ML 工程師讀到同樣的行項目，看到的是文字。

建築 AI——無論是成本估算、規範解析、圖紙解讀還是項目風險評估——依賴於正好存在於工程師、工程量清單師、項目經理和現場監督人員頭腦中的領域知識。將這種知識轉化為訓練資料集是一個挑戰。

為什麼建築資料標記特別困難

建築和工程資料具有使其對沒有行業經驗的任何人都難以標記的特性。

非標準術語因地區、公司和項目而異。 「BOQ」在任何地方都意思相同，但其中的行項目差異很大。一家公司的「不可預見地質條件的暫定金額」是另一家公司的「應急費——地質技術風險」。英國的「日工費率」在美國是「T&M 費率」。構建分類模型的 ML 工程師沒有標準化這種變化的框架。

縮寫密集且依賴上下文。 「RC」可能是鋼筋混凝土、運行費用或資源中心。「GF」在建築圖紙中是地面樓層，但在土方工程規範中是一般填充。「PC」在估算中是主要費用，但在結構設計中是預製混凝土。正確的解釋需要知道文件類型和部分。

視覺資料需要空間推理。 建築圖紙用線重、線型、剖面線圖案、尺寸、注釋和空間關係來編碼信息。結構工程師讀取橫截面並理解特定的剖面線圖案表示在特定保護層深度有鋼筋的澆築混凝土。ML 工程師看到幾何形狀。標記圖紙元素用於目標檢測模型需要每一步的領域專業知識。

數量有隱含的約束。 工程量清單中「100m³ 的 C30/37 混凝土用於基礎」的條目攜帶隱含信息：混凝土等級意味著結構用途，基礎規範意味著特定的澆築要求，100m³ 大約是 230 噸——這是一個重要的澆築，意味著泵送交付和可能的分階段施工。標記這個條目的複雜性水平、資源需求或風險概況需要沒有任何 Google 搜索能提供的建築知識。

規範解讀需要經驗。 建築規範使用術語——「應」、「宜」、「可」——具有特定的合同含義。「混凝土在 28 天時應達到最低抗壓強度 30 N/mm²」是一個帶有測試和合規意義的硬性要求。ML 工程師可能無法將其與一般描述區分開來。

當前狀態：工程師無法訪問工具

儘管具備生產高質量標記的知識，建築專業人員幾乎完全被排除在 ML 標注工具之外。

典型建築專業人員的技術環境看起來像這樣：Microsoft Office、項目管理軟件（Primavera、Microsoft Project）、成本估算工具（CostX、Bluebeam）、BIM 軟件（Revit、Tekla）和 CAD 工具（AutoCAD）。他們的計算舒適區是帶有視覺界面的桌面應用程式。

標注工具需要不同的技能集。設置 Label Studio 需要 Docker。Prodigy 需要 Python 和 pip。雲端平台需要上傳可能是專有的資料——項目圖紙、投標文件、成本資料——到外部服務器。

大多數建築公司將投標資料、成本資料庫和項目文件視為高度機密的商業信息。將此資料上傳到雲端標注平台引起了超越 IT 安全的競爭顧慮——訪問你的歷史投標資料的競爭對手獲得了直接的商業優勢。

結果：建築 AI 的開發在標記循環中沒有建築專業人員。ML 工程師標記他們不理解的 BOQ 項目，分類他們無法解讀的圖紙元素，以及他們不了解合同意義的規範條款。

建築團隊需要什麼

我們與從一級承包商到專業分包商的工程和建築團隊合作過。他們對標記工具的要求集中在五個方面。

桌面安裝，零 IT 依賴。 建築 IT 團隊專注於 BIM 服務器、項目管理平台和現場連接。他們沒有部署 Docker 容器或維護自托管 Web 應用程式的能力或專業知識。標記工具必須像 CostX 或 Bluebeam 一樣安裝——下載安裝程序，運行它，完成。

本地資料處理。 投標文件、成本資料和項目圖紙是商業敏感的。它們不能上傳到雲端平台。工具必須與存儲在本地或公司文件服務器上的文件一起工作，沒有外部資料傳輸。

支持建築資料格式。 工程量清單以 Excel 和 CSV 形式出現。規範以 PDF 和 DOCX 形式出現。圖紙以 PDF、DWG 和圖像格式出現。工具應該直接打開這些格式，而不需要轉換為專業的標注格式。

視覺標記界面。 工程量清單師、項目經理和工程師習慣於視覺工具。他們點擊、拖動、高亮和注釋。使用這些交互模式的標記界面將被採用。需要輸入 JSON 或從代碼風格下拉菜單中選擇的界面將不會。

建築相關的標記類型。 使用行業術語創建標記方案的能力——交易類別（CSI MasterFormat 部門）、費用類型（材料、勞動力、設備、分包商）、風險水平（低、中、高）、規範類型（規定性的、性能的、專有的）——而不需要將它們映射到通用的 ML 詞彙。

建築標記的實際工作流程

以下是當工具障礙被消除時，建築領域專家如何可以為 AI 訓練資料做出貢獻。

工程量清單分類。 工程量清單師在標記工具中打開一個工程量清單。對於每個行項目，他們分配交易類別、費用類型、複雜性評級和任何標誌（複合費率、暫定金額、主要費用）。資深工程量清單師每小時可以標記 80-120 個行項目——比必須研究每個項目的 ML 工程師快大約 4 倍。

規範解析。 合同經理審閱規範部分並按類型（性能要求、規定性要求、參考標準、行政要求）、適用性（所有交易、特定交易）和合規驗證方法（測試、檢查、文件記錄）標記它們。這種標記需要了解規範如何與合同條件交互——這種知識只存在於有經驗的建築專業人員中。

圖紙元素分類。 結構工程師審閱結構圖紙並標記元素——柱、梁、樓板、基礎、鋼筋細節——以及從圖紙注釋中提取的結構屬性。服務工程師對 MEP 圖紙做同樣的事。每個專家比通才更快、更準確地標記他們的領域。

風險評估標記。 項目經理審閱項目文件——RFI、變更令、延誤通知——並按風險類別、嚴重性和可能結果標記它們。這種標記需要了解項目動態、合同機制和建築實踐，這些是任何 ML 模型都無法從文字中學習的。

規模機會

一個中等規模的建築公司有 20-50 名可以為標記做出貢獻的工程師、工程量清單師和項目經理。如果每個人每週貢獻 30 分鐘——這是個小要求——公司每月生產 2,000-5,000 個標記範例。

這足以在單個季度內為工程量清單分析、規範解析或文件分類構建有意義的分類模型。沒有領域專家參與，同樣的資料集將需要 ML 團隊 6-12 個月才能生產，標記質量更低。

建築行業生成大量結構化和半結構化資料——工程量清單、規範、RFI、報批、日報、變更令——這些資料幾乎完全未標記。標記它的知識存在於成千上萬的有經驗的專業人員中。障礙是工具。

消除障礙

Ertas Data Suite 正是為這個用例構建的。它是一個原生桌面應用程式，安裝起來像任何其他工程軟件。建築專業人員將它指向他們的本地文件——Excel 工程量清單、PDF 規範、圖紙圖像——並通過視覺界面進行標記。沒有 Python，沒有 Docker，沒有雲端上傳。

標記方案使用團隊使用的任何術語以視覺方式配置。導出生成 AI 團隊直接使用的標準 ML 訓練格式。領域專家從不見代碼。ML 工程師從不必解讀他們不理解的建築術語。

結果是在建築知識上訓練的建築 AI——這是構建建築專業人員實際上會信任的模型的唯一方法。