Back to blog
    建築和工程 AI 的人在迴路:工地安全、結構分析和工程量清單提取
    human-in-the-loopconstruction-aiengineering-aisite-safetyai-governance

    建築和工程 AI 的人在迴路:工地安全、結構分析和工程量清單提取

    建築 AI 發展迅速——工地安全攝影機、結構分析工具、工程量清單提取。以下是在工地和設計辦公室中有意義的人類監督的樣子。

    EErtas Team·

    建築 AI 正在成熟。不是在原型意義上——而是在部署、生產、人們依賴它的意義上。檢測個人防護裝備違規和危險接近重型設備的工地安全攝影機。協助載重計算和失效模式識別的結構分析工具。能夠從圖紙中提取數量並在數小時而非數週內生成工程量清單草稿的 AI。模擬延誤風險的進度 AI。讀取合約並提取相關條款的索賠分析 AI。

    這些工具都能創造價值。如果人類監督層設計不正確,它們也都會帶來責任、安全風險或職業責任風險。

    建築 AI 有通用企業 AI 框架無法完全解決的特定 HITL 要求。以下是這些要求是什麼以及如何滿足它們。

    為何建築 AI 有獨特的 HITL 要求

    三個因素使建築 AI 區別於大多數其他企業 AI 情境。

    生命安全影響。 部署在活躍建築工地上的 AI 在一個不正確的決定可能導致死亡的環境中運作。一個未能標記墜落危險的工地安全系統,或者產生如此多誤報以至於主管停止審查警報的系統,不是中性的技術。其失敗的後果具有物理維度。

    合約和職業責任。 結構分析、工程量測量和合約分析都產生具有法律和財務後果的輸出。提交給招標的工程量清單中的錯誤在授標後無法糾正。不正確的載重計算可能成為職業責任索賠。簽署這些輸出的人員承擔的職業責任不能委託給 AI 系統。

    領域專業知識差距。 了解 AI 輸出是否正確的工程師、工程量測量師和安全管理人員不是 ML 工程師。他們無法評估模型——他們只能評估輸出。這使 HITL 設計尤為重要:人類檢查點必須定位在專家正在審查他們實際上可以評估的事物的地方。

    使用案例 1:工地安全 AI

    建築工地上的計算機視覺系統通常標記個人防護裝備不合規(缺少安全帽、高能見度背心、安全靴)、人員危險接近設備機械、墜落危險條件和未授權區域進入。

    HITL 設計:AI 標記一個事件。訓練有素的安全主管在採取任何行動之前審查標記。AI 不會自主發出警告、升級事件或記錄違規——它為人工審查提供候選事項。

    這個設計解決了兩種不同的風險。

    第一個是假陰性:AI 遺漏了它本應捕獲的事物。這種風險的人類監督模型是工地安全巡查。AI 是那次巡查的增強,而非替代。完全依賴攝影機 AI 並消除實地安全檢查的工地誤解了 AI 在做什麼。它是第二雙眼睛,而非第一雙的替代品。

    第二個是假陽性:AI 標記實際上不是安全事件的事物。誤報率是一個帶反饋迴路的設計約束。誤報太多,主管就停止審查警報。一旦 HITL 審查停止成為真實的,它就停止成為監督。如果你的工地安全 AI 每班生成 200 個警報,而主管有時間審查 20 個,你的 HITL 流程涵蓋了被標記事件的 10%。這不是有意義的檢查。誤報率管理與檢測率同樣重要——可以說更重要,因為誤報率決定了人工審查步驟是否保持真實。

    使用案例 2:結構分析 AI

    協助有限元素分析、規範合規性檢查和失效模式識別的 AI 工具正在成為結構工程工作流程的一部分。它們可以比手動分析更快地處理載重組合、按規範要求檢查構件尺寸,並標記潛在的失效模式。

    HITL 設計:AI 產生報告。持牌結構工程師審查報告、驗證輸入、評估結論並認證分析。工程師的職業印章放在輸出上——而非 AI 的。

    這主要不是技術選擇。而是職業和法律選擇。負責工程師對結構設計承擔法定責任。這個責任不能委託給軟體。AI 改變的是吞吐量:工程師可以在相同時間內審查更多設計、檢查更多組合,並覆蓋更多條件。但審查不能壓縮到有意義的閾值以下。無法解釋 AI 報告中任何特定結論的工程師——因為他們處理得太快以至於無法理解它——並不是在提供有意義的監督;他們在提供簽名。

    實際 HITL 要求:AI 報告必須以允許高效但真實審查的格式呈現。如果 AI 的推理是不透明的——如果它是一個在不顯示其工作的情況下產生通過/失敗結果的黑箱——工程師就無法驗證它。輸出格式中的可解釋性是 HITL 要求,而非可選功能。

    使用案例 3:工程量清單提取和工程量測量

    對於大型建築項目,工程量清單從數百張圖紙和規範文件中生成。手動流程耗時且容易出錯。能夠讀取圖紙、解釋標注並提取尺寸和數量以生成工程量清單草稿的 AI 是一個實質性的生產力工具。

    HITL 設計:AI 從源文件中提取數量 → 工程量測量師審查提取的數量與源文件 → QS 在工程量清單提交招標前批准。

    招標工程量清單中錯誤的後果要麼是失去招標(如果錯誤使出價缺乏競爭力),要麼是損害利潤的低估(如果錯誤使出價以不可行的價格獲勝)。兩者在授標後都不可恢復。提交前的人工驗證是不可協商的。

    工程量清單 AI 的特定 HITL 要求:輸出必須可追溯到其來源。每個提取的數量應鏈接回提取它的圖紙和標注。這允許 QS 高效驗證——不是通過從頭重新測量每個項目,而是通過抽查對源的提取,高值或高不確定性項目可能完全覆蓋。產生沒有來源歸屬的工程量清單的 AI 沒有給 QS 任何可審查的東西——它與有意義的監督不相容。

    使用案例 4:建築合約索賠 AI

    分析合約文件、識別相關條款並協助索賠準備的 AI 工具,在延誤索賠、變更索賠和爭議解決常見的行業中有真實應用。

    HITL 設計:AI 起草分析 → 合約管理員或法律顧問審查和修訂 → 人類簽署任何採取的索賠立場。

    原因很簡單:索賠分析文件可能最終進入爭議解決、仲裁或調解。簽署它的人需要能夠站在其中的每一個聲明後面。如果 AI 產生了審查員只是粗略瀏覽的分析,審查員無法做到這一點。提交前審查不是可選的;對於可能被對方和爭議小組仔細審查的文件,這是最低可行標準。

    資料主權維度

    建築文件——圖紙、規範、工程量清單、合約、分包商報價——具有競爭敏感性。它們包含定價策略、設計決定和商業立場,如果暴露,會為競爭對手和對方提供優勢。

    將這些文件發送到雲端 AI 服務會造成保密風險。雲端提供商的服務條款可能允許對提交的資料進行訓練。文件可能被提供商員工訪問。跨境雲端處理會引發司法管轄問題。

    本地 AI 處理解決了這個問題。在自己基礎設施上處理文件資料的建築公司——在沒有任何材料離開建築物的情況下攝取、清理、標注和匯出訓練資料——與將圖紙上傳到雲端服務的公司有根本不同的風險態勢。

    EU AI Act 維度

    建築工地安全中使用的 AI 系統,根據 EU AI Act 附錄 III,可能具有高風險資格,該附錄涵蓋機械和關鍵基礎設施的安全組件。如果你的工地安全 AI 具有資格,第 14 條人類監督要求適用——包括具體義務:

    • 在操作期間啟用人類監督
    • 確保自然人能夠理解 AI 系統的能力和限制
    • 確保自然人可以干預或中斷 AI 系統

    這些不是有抱負的要求。它們是法律義務。在歐盟情境中部署,沒有記錄的 HITL 程序、沒有真正的人工審查能力和沒有干預機制的工地安全 AI 是不合規的——無論模型有多準確。

    從一開始就設計 HITL 比在系統已部署後為滿足監管要求而對其進行改造更容易。

    有關基礎 HITL 概念,請參閱什麼是人在迴路 AI。有關受監管行業需要不同 AI 基礎設施的內容,請參閱受監管行業需要不同的 AI 基礎設施。有關管理非結構化建築文件上的 AI,請參閱建築 AI 和非結構化文件


    預約與 Ertas 的探索通話 →

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading