規則引擎沒有失效，只是無法承擔所有判斷
設備告警通常從明確條件開始：溫度高於門檻、壓力持續異常、通訊中斷，或感測值在指定時間內沒有更新。這類規則容易解釋、執行速度快，也能通過安全與稽核要求。對停機保護、法規限制及人員安全相關事件，確定性的規則仍應是第一道防線，不適合交給生成式 AI 自由判斷。
問題出現在事件量與設備關係變得複雜之後。同一個上游故障可能讓多台下游設備同時告警；維修模式可能產生大量預期中的異常；感測器漂移則會讓規則反覆觸發，卻沒有真正的設備故障。工程師需要的不只是「哪條規則成立」，而是這批事件是否屬於同一個事故、哪個最可能是根因，以及現在應先處理什麼。這正是 AI 較適合介入的判斷層。
先定義 AI 的工作邊界，再談模型
實務上，我們會把告警流程拆成三層。第一層是規則與邊緣控制，負責即時偵測及必要的安全動作；第二層是事件關聯與 AI 分流，整合時間序列、設備拓撲、工單及維修狀態；第三層才是人員確認與執行。這種分層讓 AI 可以處理模糊脈絡，又不會越過既有控制系統的安全責任。
AI 的輸出也不應只是一段看似合理的文字，而應是能被系統使用與稽核的結構化結果。至少要包含事件群組、建議優先級、可能原因、引用證據、仍缺少的資訊，以及下一個安全動作。模型信心不足或資料不完整時，結果應明確標示需要人工確認，而不是勉強給出單一答案。
- 保留硬規則：停機聯鎖、安全門檻、法規要求與不可逆操作仍由確定性邏輯負責。
- 交給 AI 輔助：重複告警合併、事故摘要、根因候選排序、SOP 搜尋及處置建議。
- 限制自動執行：初期只建立工單、通知或補充資訊，不直接修改 PLC、設備參數或控制命令。
- 提供降級路徑：模型、向量資料庫或外部服務不可用時，系統必須回到原本的規則與通知流程。
資料脈絡比提示詞更重要
要讓 AI 做出可靠的分流，單一告警文字通常不夠。事件層至少需要統一設備識別碼、事件時間、來源系統、告警代碼、嚴重度、確認狀態與品質標記。接著再依時間窗口補上前後感測值、近期設定變更、設備階層、上下游關係、維修模式及未結工單。若不同系統對同一台設備使用不同名稱，應先建立主資料對照，而不是期待模型自行猜測。
維修手冊、標準作業程序與歷史工單可透過 RAG 提供額外知識，但檢索結果必須保留版本、適用機型及來源。舊版手冊或不同廠牌的相似說明，可能比沒有資料更危險。對時間序列資料，也不宜把大量原始點位直接塞進模型；較穩定的方式是先由程式計算趨勢、持續時間、變化率、缺值與事件序列，再讓模型解讀這些可驗證的特徵。
還要區分「沒有資料」與「數值正常」。感測器離線、資料延遲或單位轉換錯誤，都可能造成錯誤結論。每次 AI 判斷都應附帶資料新鮮度、缺漏狀態與來源，讓值班人員知道結論建立在哪些證據上，也方便事後重播與調查。
以分階段上線驗證營運價值
第一階段適合採影子模式：AI 讀取真實事件並產生判斷，但不影響現行通知。團隊將結果與值班紀錄、工單結論及工程師回饋比對，特別檢查錯誤降級、漏掉高風險事件、引用不相干文件，以及把資料缺失誤判為設備正常等情況。評估時不要只看模型回答是否流暢，而要看事件是否正確分群、證據是否可追溯，以及建議動作是否安全。
第二階段可讓系統在告警介面提供摘要、根因候選與 SOP 連結，由人員接受、修改或拒絕。這些操作應成為可追蹤的回饋資料，但不能未經審查就自動拿去訓練。只有在特定場景長期穩定、錯誤成本可控且有清楚回復機制時，才考慮自動建立或指派工單等低風險動作。
最後，模型版本、提示設定、檢索內容與決策結果都需要留存。設備配置會改變，SOP 會更新，告警分布也會隨季節、產線與維修狀態變動，因此上線並不是終點。好的 AI 告警系統不是取代工程師，而是把分散的訊號整理成有證據、可質疑、能安全退回人工流程的判斷；若涉及多套 IoT、ERP、CRM 或維運系統，整合團隊的主要價值也正在於把這些責任邊界落實成可運作的架構。