建築 AI：將 700GB 非結構化項目文件轉化為領域專屬模型

大多數建築公司已經擁有構建強大 AI 系統的原材料。它存放在某個共享硬碟中——十年的項目文件、PDF、圖紙、檢測報告、工程量清單、施工進度照片和 RFI，逐個項目積累，組織得恰好足以手動查找東西。

挑戰不在於資料匱乏。而是相反：資料豐富、充滿領域知識，但以目前形式幾乎完全無法被 AI 系統使用。

本指南涵蓋如何解決這一轉換問題：建築 AI 實際需要什麼、資料為何難以處理、完整的處理管道是什麼樣的，以及最終得到什麼。

問題的範圍

一家有十到十五年項目歷史的中型建築公司，通常會有 200GB 到 1TB 的項目文件。運營了三十年的公司，或管理了大型土木基礎設施項目的公司，可能擁有更多。

在這個存檔中，文件類型是異質的：

圖紙：建築、結構、機電、土木、排水——從 CAD 匯出的 PDF，從簡單平面圖到複雜 3D 剖面圖不等
工程量清單（BOQ）：從工程量測算軟體生成的表格成本文件
規範：Word 或 PDF 中的技術規範部分，每個項目通常有數百頁
檢測和測試報告：結構化表格和自由文字敘述，通常包含照片
RFI 和往來函件：問答鏈、現場指示、變更令
BIM 匯出：IFC 文件、COBie 試算表、碰撞檢測報告
施工進度照片：命名不一致的 JPEG，通常是竣工條件的唯一記錄

建築 AI 從業者明確指出的關鍵見解：「問題不在於微調，而在於清理和準備多樣化的資料。」模型是容易的部分。資料是困難的部分。

哪些建築 AI 用例真正有價值

在處理任何單一文件之前，值得明確您試圖構建哪些 AI 模型。資料管道設計取決於下游用例。

成本估算模型。 在歷史 BOQ 資料上訓練的模型——項目描述、數量、費率、項目類型、地點和日期——可以為新的估算項目建議費率，對照歷史範圍標記異常值，並提高整個團隊估算的一致性。這需要來自已完成項目的結構化、標準化 BOQ 資料。

文件搜索（RAG）。 對公司規範庫、項目規範和技術標準的檢索增強生成系統，允許工程師用自然語言查詢存檔。「A 類項目地面樓柱混凝土的規定最低抗壓強度是多少？」從相關文件中檢索相關條款。這需要帶有良好元資料的乾淨、分塊文字。

檢測分析。 在檢測報告資料上訓練的模型——缺陷類型、位置、嚴重程度、補救措施、項目階段——可以對新的檢測發現進行分類、建議補救措施，並標記與下游問題相關的模式。這需要從檢測表格提取結構化資料，加上缺陷術語的 NER 標注。

圖紙搜索和協調。 理解圖紙內容的系統——不只是文件名——可以回答「查找顯示 RC 柱與鋼樑連接的所有細節」，通過理解圖紙內容而不是依賴文件命名慣例。這需要在標注圖紙內容上訓練的模型。

每種用例需要稍有不同的資料準備方法。單一存檔可能為多個用例生成資料集，但處理應按用例規劃，而非泛泛運行。

為什麼雲端工具被排除在外

大多數資料團隊面對大型文件存檔時的第一反應是通過雲端 API 運行它。AWS Textract、Azure Document Intelligence、Google Document AI——這些都是有能力的工具。問題不在於技術。

問題在於資料治理。

建築項目文件包含商業敏感資訊：數量、費率、分包商價格和代表競爭情報的規範。它們也可能包含現場工人、分包商和客戶的個人資訊。將這些資料發送到雲端 API 意味著它離開了公司的環境。根據司法管轄區，這可能需要資料處理協議、隱私影響評估或明確同意。

在某些司法管轄區，在合理的時間框架內根本不可能。例如，巴基斯坦 PPIA 下的資料處理批准過程，跨境資料傳輸可能需要超過一年。等待這一批准的公司無法開始構建其 AI 能力。

實際後果：處理管道必須在本地運行。OCR、表格提取、版面分析、標注、品質評分——一切都必須在公司控制的硬體上進行，不向外部服務發出網絡調用。

建築資料的完整管道

建築資料準備管道有五個階段。這些不是快速的順序過程；每個階段在大型存檔上都可能需要大量時間。

第 1 階段：攝取和分類。 存檔中的每個文件都被攝取並按文件類型分類。這不是可選的——圖紙的處理邏輯與 BOQ 或規範部分的處理邏輯完全不同。分類使用文件元資料（命名慣例、目錄結構）、頁面版面分析和內容抽樣的組合。輸出：存檔中每個文件的分類清單，帶有估計的處理複雜度。

第 2 階段：提取。 每種文件類型使用適合類型的邏輯處理。圖紙通過基於區域的 OCR 和符號檢測及標注解析。BOQ 通過表格重建、行項解析和單位標準化。規範通過部分分段和條款提取。檢測報告通過表格欄位提取和自由文字解析。此階段計算密集，大型存檔需要整晚或整個週末運行。

第 3 階段：清理。 提取的資料被去重複（同一個 BOQ 可能以三個版本存在——初版、修訂版 A、修訂版 B），標記不一致，並分配品質分數。低於品質閾值的記錄被標記供人工審查，而不是傳遞到下一階段。

第 4 階段：標注。 特別是對於訓練資料，提取的記錄需要標籤。對於估算模型，這是來自已完成項目的費率資料。對於 NER 模型，這是由領域專家（工程量測量師、現場工程師）應用的實體標籤。對於分類模型，這是應用於檢測發現的類別標籤。此階段需要領域專家參與——而不是 ML 工程師。

第 5 階段：匯出。 標注的清理資料以下游系統所需的格式匯出：微調語言模型的 JSONL、RAG 索引的分塊文字帶元資料、傳統分析的 CSV，或資料庫攝取的結構化記錄。

完成的建築訓練資料集看起來是什麼樣的

在管道結束時，您應該擁有：

對於 RAG 知識庫：50,000 到 200,000 個文字塊，每塊 300-800 tokens，帶有文件類型、項目類型、日期、部分標題和源文件的元資料欄位。這些塊是乾淨的、正確排序的，沒有 OCR 偽影。

對於微調資料集（估算）：30,000 到 100,000 個結構化記錄，每條記錄代表一個 BOQ 行項，包含其描述、單位、數量背景和費率——按項目日期和地點標準化。JSONL 格式，每行一條記錄。

對於微調資料集（檢測 NER）：來自檢測報告的 5,000 到 20,000 個標注句子，帶有缺陷類型、位置、嚴重程度和補救措施的實體標籤。JSONL 格式，帶有 token 級別跨度標注。

這些在一般 AI 標準下並不是巨大的資料集。GPT 規模的模型在數兆 tokens 上訓練。但特定領域的微調所需的資料遠少於一般預訓練。在同類型項目的 50,000 個結構化 BOQ 記錄上微調的建築估算模型，在建築特定任務上可以顯著優於通用模型。

預期的時間表和工作量

時間表取決於存檔大小、文件品質以及目標用例的複雜性。

對於 700GB 混合建築文件存檔：

攝取和分類：1-2 天算力時間，加上 2-3 天人工審查以驗證分類品質並修復系統性錯誤
提取：5-10 天算力時間（很大程度上取決於需要 OCR 的光柵化 PDF 的比例）
清理：3-5 天算力時間，加上領域專家對標記記錄的審查
標注：這是可變的。對於費率已存在於文件中的 BOQ 資料，標注是自動的。對於檢測報告的 NER 標注，預計有 10,000 個標注句子的資料集需要 2-4 週的領域專家時間
匯出和驗證：1-2 天

從 700GB 存檔獲得首個可用資料集的總經過時間：6-10 週，假設領域專家的可用性不是瓶頸。

瓶頸幾乎總是標注階段。領域專家——工程量測量師、現場工程師、檢測員——不能全職進行資料標記。圍繞他們的可用性進行規劃，並設計不需要 Python 或終端訪問的標注界面，對於保持合理時間表至關重要。

您現在可以做什麼

第一步不是處理。而是清點庫存。

在運行任何工具之前，了解您擁有什麼：多少文件、什麼類型、什麼日期範圍、哪些項目。一個簡單的清單——按類型統計文件數量、按文件類型統計總大小、項目元資料——告訴您提取工作將集中在哪裡，以及哪些用例與您擁有的資料可行。

大多數建築公司發現他們的 BOQ 存檔是最容易處理的起點。資料是結構化的（或接近結構化），用例高價值（估算），而且因為費率資料通常已存在於文件中，標注負擔更低。

從那裡開始。處理 BOQ，匯出 JSONL，並在小樣本上測試微調的估算模型。第一個結果，即使不完美，在建立組織認同方面比任何數量的規劃文件都更有用。

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →