在前面的章節已有分別介紹YOLO和PaddleOCR如何將辨識結果轉換為定位資料，今天我們再次來回顧與整理，這兩種AI所生成的結果在BIM資料流中的角色。

18.1. 數據流架構概念

　　在實務中，業界通常為搶時程，往往在細部設計尚未完全完成時就同步送審，甚至現場已先開工。之後進入長時間的改圖循環，從送審回覆、現場變更到完工為止，圖面不斷更新。
　　傳統 BIM 流程中，2D 圖紙設計與建模通常為分離的，這種反覆修改意味著需不斷人工輸入與修正模型。但若藉由AI 輔助 BIM ，則可由 2D 圖直接生成 3D 並快速套入標準化屬性，以減少建模與修改的時間成本。以下是我認為傳統與 AI 結合的資料流差異：

18.1.1. 傳統 BIM 資料流

各專業設計師/工程師繪製 2D CAD 圖
        ↓
人工輸入建置 BIM 模型與構件屬性
        ↓
送審 / 施工圖產出
        ↓
現場變更（人工回改 BIM 模型 + 2D 圖）
        ↓
重複上述流程直到完工

18.1.2. AI 結合 BIM 資料流

2D 圖面
├── YOLO 偵測結果
│     ├── 物件類別（如門、窗、柱）
│     ├── 邊界框座標（比例座標 → 圖紙像素座標 → 實際尺寸）
│     └── 置信度
│
├── PaddleOCR 偵測結果
│     ├── 文字內容（尺寸、材料、房間名稱等）
│     ├── 文字框四點座標
│     ├── 中心點座標
│     └── 置信度
│
└── AI → BIM 轉換引擎
      ├── 幾何定位（由 YOLO + OCR 座標生成 3D 幾何）
      ├── 屬性賦值（由 OCR 文字對應 BIM 屬性欄位）
      ├── IFC / BIM 模型輸出
      └── 回饋修改（更新 2D 圖 → AI 再轉 3D）

18.2. BIM 資料交換常見問題

　　由於不同軟體對於自家商業利益考量，雖然名義上支援 IFC 開放格式，但各家使用的資料格式與屬性命名規則仍有差異，導致直接匯出或匯入時，容易出現：

18.2.1. 資訊遺失

• 構件屬性不見（例如材料、尺寸、編號消失）
• 幾何變形或無法編輯
• 關聯關係（如樓層、系統）被斷開

18.2.2. 軟體相容性差

　　以目前台灣建築產業市佔率最高的某BIM軟體為例，雖然功能完整，但在模型建置介面與軟體價格上並不友善。但由於使用者基數龐大，專案方與協作單位幾乎全面採用，導致「不使用就難以加入專案」的情況。即便使用者知道它在資料交換上的侷限，卻也只能接受。

18.3. 結語

　　我曾在Day16介紹OpenBIM跨軟體的益處，若想突破跨平台協作的限制，IFC 或許是現階段的解方之一，能減少不同軟體間的資訊遺失與重工。
　　而 AI 的介入，更有機會在「讀取 2D 資料 → 生成 3D BIM」的流程中，繞過部分封閉格式的限制，為業界帶來更多彈性與效率。
　　下一篇，繼續來探討AI辨識結果轉換為IFC開放格式的方法，明天見。