Back to blog
    constructionengineeringdata-extractionenterprise-aiboq

    為 AI 提取工程圖紙和 BOQ 資料

    標準 OCR 為什麼無法處理工程圖紙和 BOQ 文件,以及如何建立一條提取管線,產出結構化的 AI 訓練資料。

    Edward Xi Yang

    工程圖紙和工程量清單是每個建築項目的密集、信息豐富的支柱。它們包含花費多年領域專業知識產生的規格、尺寸、數量、材料和成本結構。從機器學習的角度來看,它們也是最難解析的一些文件。

    如果您試圖為建築行業構建特定領域的 AI——估算模型、規格搜索系統、合規檢查器——第一個障礙不是模型。而是從文件中獲取訓練資料。

    本指南恰恰涵蓋這個問題:是什麼使工程圖紙和 BOQ 文件難以處理、如何處理提取,以及最終可用的訓練數據集實際上是什麼樣子的。

    為什麼工程圖紙會破壞標準 OCR

    標準 OCR 引擎——Tesseract、AWS Textract 或 Adobe 內部的 OCR 層——是在連續散文文本上訓練的。它期望單詞排列成行,行排列成段落,段落排列在有可預測邊距的頁面上。

    工程圖紙違反了所有這些假設。

    符號密集的內容。 結構和土木工程圖紙使用幾十個專業符號:焊接類型、截面指示器、鋼筋棒標注、標高標記、坡度箭頭。標準 OCR 模型對這些沒有訓練資料。它要麼跳過它們,要麼因為符號干擾字符分割而誤讀相鄰文本。

    多佈局頁面。 單個 A1 圖紙可能在左上角包含平面圖,在右下角包含截面切割,在右下角包含標題欄,在右邊距包含修訂歷史,以及在任何有空間的地方散佈的一般說明。OCR 引擎無法推斷任何閱讀順序。它將以錯誤的順序連接這些區域的內容,產生沒有語義連貫性的文本。

    標注層。 CAD 匯出的 PDF 包含維度、鍵注和引線,它們位於主繪圖幾何圖形的單獨層中。當展平為光柵化 PDF 時,這些成為重疊元素。文本識別在重疊或接觸其他元素的文本上失敗。

    比例依賴的細節。 在 1:500 的現場平面圖上,建築輪廓很粗,標注稀疏。在 1:10 的細節圖上,相同的區域充滿了材料標注、尺寸字符串和參考氣泡。單個 PDF 項目文件可以同時包含兩者,沒有固定的 OCR 分辨率同時對兩者都有效。

    後果:從工程圖紙中的通用 OCR 提取產生嘈雜、亂序的文本,缺少標注和混亂的尺寸字符串。該輸出在沒有大量——通常是不切實際的——手動糾正的情況下無法用於 AI 訓練。

    為什麼 BOQ 文件不同(也很難)

    工程量清單位於另一端。它們不是視覺文件;它們是高度結構化的表格資料。但它們的結構方式特定於建築行業,大多數資料提取工具處理得很差。

    典型的 BOQ 組織為多級編號層次結構:部門、節、項目。每個行項目都有項目代碼、可能跨多行的描述、數量、計量單位、費率和延伸金額。描述欄位是領域知識所在——它編碼了材料規格、工作方法、適用標準和對圖紙編號的任何引用。

    BOQ 特有的提取挑戰:

    混合 PDF 格式。 BOQ 通常從工程量軟體(CostX、CANDY、Buildsoft)生成,匯出為包含嵌入文本和光柵化表格混合的 PDF。表格結構在屏幕上可能看起來完美,但在 PDF 中以任意 X-Y 坐標處的一系列斷開文本片段表示,沒有提取工具可以偵測的底層表格對象。

    多頁項目描述。 複雜的 BOQ 項目——例如,具有特定外加劑要求和對項目特定規格參考的後張緊板的結構混凝土——可能有跨三四行的描述。頁面中斷在描述中間打斷項目。按頁處理的提取工具將錯誤地分割這些項目。

    延續表。 BOQ 表格通常跨頁延續,每頁頂部重複列標題。天真的表格提取將重複的標題合併為資料行,破壞結構。

    數量和單位標準化。 BOQ 中的單位沒有標準化。"m3"、"M3"、"CUM"、"cum"和"Cum"都意味著立方米。項目數量根據生成文件的地區和軟體以"1,234.50"、"1234.5"和"1,234·50"的形式出現。提取管線必須標準化這些,而不改變值。

    提取管線

    建築文件的實際管線需要對圖紙文件和 BOQ 文件分別處理,最後有一個合併步驟。

    第一階段:文件分類。 在處理之前,每個文件需要分類:這是圖紙、BOQ、規格部分、檢查報告還是其他什麼?處理邏輯在類型之間差異顯著,應用錯誤的提取器會產生垃圾輸出。分類可以是基於規則的(文件命名約定、頁面尺寸、標題欄的存在)或對於模糊案例的基於模型的。

    第二階段:圖紙提取。 對於圖紙,管線必須在區域而不是整頁上操作。標題欄、一般說明和平面圖區域分別處理。區域偵測可以使用標準標題欄位置的模板匹配,或對非標準圖紙的佈局分割模型。在每個區域內,OCR 以適當的分辨率運行,符號偵測作為單獨的過程運行——輸出結構化記錄如 {type: "weld_symbol", subtype: "fillet", size_mm: 6, location: "beam_flange_connection"} 而不是試圖將符號轉換為文本。

    第三階段:BOQ 提取。 對於 BOQ 文件,管線專注於表格結構重建。這需要從文本片段的 X 坐標分佈偵測列邊界,使用縮進和編號模式將延續行與其父項目關聯,將數量和單位標準化為規範形式,以及從描述文本中提取圖紙引用。

    第四階段:交叉引用連結。 圖紙標注引用項目代碼;BOQ 項目引用圖紙編號。連結這些創建了更豐富的訓練資料。當與顯示構件幾何圖形和連接細節的圖紙相連接時,「結構鋼,等級 S275,熱浸鍍鋅」的行項目作為訓練資料更有用。

    第五階段:品質評分。 每個提取的記錄根據 OCR 置信度、表格結構完整性和交叉引用解析率獲得置信度分數。低置信度記錄被標記為人工審查,而不是直接傳遞到訓練數據集。

    結構化輸出看起來像什麼

    提取後,BOQ 行項目應該是具有以下欄位的結構化記錄:

    {
      "item_code": "03.04.12",
      "description": "Reinforced concrete, grade C35/45, in columns above ground floor, including formwork, vibration and curing",
      "quantity": 127.5,
      "unit": "m3",
      "unit_rate": null,
      "drawing_refs": ["S-201", "S-202", "D-C-04"],
      "spec_refs": ["Clause 5.4.2"],
      "section": "Structural Concrete",
      "division": "Substructure"
    }

    圖紙標注記錄看起來不同:

    {
      "drawing_number": "S-201",
      "zone": "section_cut_AA",
      "element_type": "column",
      "annotation_type": "reinforcement_callout",
      "text": "8T25 + links T10@200 c/c",
      "parsed": {
        "main_bars": {"count": 8, "dia_mm": 25, "grade": "T"},
        "links": {"dia_mm": 10, "spacing_mm": 200}
      }
    }

    這種結構水平使資料對 AI 訓練有用。從 PDF 中抓取的非結構化文本產生一個可以討論建築的語言模型。結構化、標注的記錄產生一個可以推理特定項目、數量和規格的模型。

    此資料支持的 AI 使用案例

    估算模型微調。 在完成項目的結構化 BOQ 資料上訓練的模型可以為新項目建議費率和數量,捕獲異常值並提高估算一致性。微調的 JSONL 格式自然地從 description + context → rate 配對映射。

    規格搜索(RAG)。 分塊的 BOQ 項目和規格條款,嵌入並存儲在向量索引中,允許工程師查詢「哪個規格適用於外牆預製混凝土?」並從項目自己的規格文件中檢索相關條款——而不是通用網路內容。

    合規檢查。 在圖紙標注及其相應規格要求上訓練的模型可以標記圖紙細節似乎偏離項目規格的情況——或 BOQ 項目引用不存在的圖紙的情況。

    歷史估算檢索。 處理足夠多的項目後,RAG 系統可以回答「過去三年在這種類型、這個地區的項目中,地下室牆壁防水的費率是多少?」使用公司自己的歷史資料。

    為什麼這必須在本地進行

    擁有大型項目檔案的建築公司無法將這些檔案發送到雲端 API 進行處理。這些文件包含商業敏感的數量、費率和規格。一些司法管轄區——包括巴基斯坦的 PPIA——要求對外部傳輸進行資料處理批准,獲得該批准可能需要一年多。

    更實際地說:量是問題所在。700GB 的項目文件檔案不是您通過 API 運行的批處理作業。它需要一個在本地運行、增量處理文件並在會話之間維護狀態的管線,這樣中斷的作業可以在不重新處理所有內容的情況下恢復。

    提取管線應完全在本地機器上運行。OCR、表格偵測、符號識別、品質評分——所有這些必須在沒有任何互聯網依賴的情況下操作。輸出——結構化 JSONL 記錄和分塊文本——是下游使用的內容。

    入門

    最小可行方法:

    1. 按類型分類代表性的文件檔案樣本(圖紙、BOQ、規格、報告)
    2. 從 BOQ 文件開始——它們以最少的歧義產生最多的結構化資料
    3. 按區域而不是按頁處理圖紙
    4. 為自動接受與人工審查建立品質閾值
    5. 在匯出到 JSONL 之前構建 BOQ 項目和圖紙編號之間的交叉引用連結

    目標不是每個文件的完美提取。而是足夠大且足夠乾淨的訓練數據集以有用。對於大多數建築 AI 使用案例,50,000 個帶圖紙交叉引用的結構化 BOQ 行項目數據集是有意義的起點。


    相關閱讀

    就本文向 AI 提問

    Custom models for the work you send to frontier APIs.

    A free audit finds the tasks worth training on. You own the model, and it runs Ertas-managed, in your cloud, or on-premise.

    Keep reading