一名項目經理問 AI 助手：「這項變更是否已經獲批？」

系統很快回答：「根據會議紀錄，顧問已同意相關方案，可按計劃施工。」

答案引用的會議紀錄確實存在，但同一段文字的下一句寫着：「費用及工期影響仍待承建商提交資料後另行確認。」

AI 沒有完全捏造內容。

它只是把一個有條件、分層次的決定，壓縮成了一句看似明確的批准。

工程 AI 最危險的錯誤，經常不是離譜答案，而是九成合理、足以讓人停止查證的答案。

第一種：問題沒有指定項目、合約或版本

「消防要求是甚麼？」「這部設備是否符合規格？」「付款期限是多少？」

這些問題看似清楚，對工程 AI 而言卻可能缺少最重要的範圍。

不同項目、合約包、設備和文件版本可以有不同要求。若系統搜尋整個企業資料庫，它可能找到另一個項目的相似內容，或者使用一份已被取代的文件。

聊天介面的便利，很容易令人忘記搜尋必須有邊界。

較可靠的助手應在回答前確認 project、discipline、package、document status 和 revision。若使用者沒有提供，系統可以根據目前頁面或登入環境自動限制；仍然不清楚時，應先追問，而不是猜測。

一個工程問題若沒有範圍，通常不應直接得到一個確定答案。

第二種：AI 找到舊文件，但不知道它已經失效

語意搜尋會優先找到內容最相似的文件，不一定是最新或有效文件。

舊圖紙、rejected submission、superseded method statement 和早期合約草稿，往往仍然保留在資料庫中。它們的文字可能比最新版本更完整，反而更容易被模型檢索。

所以，RAG 系統不能只依靠向量相似度。

在搜尋內容前，應先利用 metadata 排除錯誤狀態，或者明確比較版本關係。答案中亦應顯示文件狀態和 revision，而不是只顯示檔案名稱。

如果系統無法確認哪一份為最新批准版本，最安全的輸出不是自行選擇，而是列出衝突並要求文件控制人員核實。

第三種：多份文件都有道理，但它們互相矛盾

工程項目中的矛盾並不罕見。

圖紙與規格不同、顧問回覆與會議紀錄理解不同、合約要求與現場指示未完全一致。人類工程師會辨認這是一個需要澄清的問題，AI 卻可能把多份內容合併成一個流暢答案。

這種「綜合」可能把矛盾消失掉。

成熟的助手應該把 evidence comparison 視為獨立步驟。當兩份高權威文件存在不同要求，系統要展示差異、來源、版本和日期，而不是自動選擇一方。

Agentic RAG 的概念，正是把問題拆成多個任務：先理解問題、規劃搜尋、取得證據、比較內容，再由另一個步驟檢查答案是否真正被證據支持。

但流程變得更複雜，並不代表一定更準確。每一個 agent 都可能犯錯，因此中間結果需要被記錄和評估，而不是只看最後一句話。

第四種：文字答得對，卻沒有讀懂圖紙和表格

工程資料不是純文字世界。

設備規格可能在 schedule 表內，尺寸和位置在圖紙中，測試結果以曲線呈現，缺陷則由相片和標註說明。AI 若只讀取抽出的文字，可能看見所有詞語，卻失去它們的空間和結構關係。

例如一個數字「1200」若失去欄位標題，可能是長度、流量、重量或設備編號；一段 general note 可能只適用於某一區域，但文字抽取後看起來像全圖要求。

多模態模型可以直接處理頁面和影像，但亦可能看錯細字、圖例、表格欄位和複雜圖紙。

因此，AI 助手不應因為支援圖片上載，便被視為已能可靠閱讀所有工程圖紙。高風險答案應指出來源類型，並讓人打開原頁確認。

第五種：資料庫沒有答案，模型卻補上一個合理答案

大型語言模型的本質是生成最可能的文字。

當檢索沒有找到足夠資料時，它仍然可能利用一般知識、相似項目或語言模式補全答案。結果讀起來合理，卻不是來自企業正式紀錄。

工程 AI 助手必須有 abstention 能力。

當證據不足、來源權威不夠、文件互相矛盾或問題超出系統範圍時，它應明確回答：

「目前未找到足夠項目證據，不能確認。」

這不是系統失敗，而是安全功能。

如果企業以「回答了多少問題」衡量 AI 使用率，系統會被鼓勵不斷作答。較成熟的衡量方式，是有證據支持的答案比例、引用正確率、錯誤拒答和應拒未拒的情況。

一個可信答案，至少要帶着四樣東西

工程 AI 的答案不應只提供文字結論。

使用者至少需要看到：

它搜尋了哪一個項目與範圍；引用了哪些文件、版本和頁碼；答案中哪些部分直接來自證據；以及系統對結果有多大信心或存在甚麼限制。

若答案涉及合約、設計、法規、安全或正式批准，還應顯示是否需要指定角色覆核。

這樣的介面可能比一般聊天機械人複雜，但它更接近工程決策真正需要的形式。

一個答案愈重要，系統就愈不應只要求使用者「相信 AI」。

Agentic AI 不代表可以把整個項目交給它

智能代理可以把任務拆解、呼叫不同工具、檢查文件、草擬電郵和建立 action。

這對項目行政和資料整理很有潛力，但當 agent 具備寫入系統、通知外部人員或改變工作狀態的權限時，風險亦同步增加。

較安全的做法是按行動風險分級。

搜尋和草擬可以較自動；發出正式通知、改變批准狀態、更新成本或承諾工期，則應要求人工確認。系統要保留誰提出、AI 做了甚麼、誰批准以及最後寫入了甚麼的 audit trail。

工程 AI 治理的核心，不是禁止自動化，而是讓權限與後果相稱。

可由哪一個 pilot 開始？

先建立一個只回答低風險、可驗證問題的助手，例如：

「找出指定項目中某份文件的最新批准版本和批核狀態。」

限定資料範圍，要求每次顯示文件編號、revision、status 和來源頁面，找不到時必須拒答。由文件控制和項目團隊建立一組已知答案作測試，記錄錯誤檢索、錯誤引用和錯誤拒答。

不要一開始便讓它解釋所有技術、合約和安全問題。

工程 AI 助手最成熟的表現，不是它看起來無所不知，而是它清楚知道自己的證據、邊界和甚麼時候必須把決定交回人。