身為工廠現場主管，每天最關心的就是：

• 昨天發生了什麼異常？（診斷）
• 今天可能有什麼風險？（預測）

本篇先專注於異常診斷，也是工廠每天最痛的事：

找出異常背後的「真正根因」（Root Cause）。 

因為若沒有找到根因，所有的改善都只是治標，而非治本。

一、為什麼現場最難的不是找異常，而是找原因？

在連接器端子壓接現場，或是 CNC、射出成型工廠，我們常看到：

• 壓接壓力曲線長得不一樣，但不知道差在哪
• 品檢抓到端子瑕疵，但追不到源頭
• 老師傅說得出原因，但說不出理論
• 班長、品保、設備三方互相推諉

這是因為：

大家可以「看到」異常，卻無法「找到」根因。

「根因」之所以這麼難找到，是因為兩大難點：

1. 多對多的迷宮

工業世界不像程式那樣簡單：if Error=501 then Network Fail。

物理世界是錯綜複雜的。

❖　一個數據徵兆（Signature），可能對應多個原因

以端子壓接為例，以下原因都有可能導致「峰值壓力降低」這個數據徵兆：

• 缺芯
• 線徑偏細
• 端子材質偏軟
• 壓接高度跑掉

❖　一個原因，可能會產生多個數據徵兆

同樣以端子壓接為例，「模具偏心」這個原因可能同時導致：

• 曲線左右不對稱
• 出現高頻摩擦音
• 成品出現毛邊

結論：單看某個數據「點」，永遠找不到真相「面」。

2. 動態的演化

異常/故障並不是靜態的，它會「長大」、會「變化」，

同一個異常/故障在不同階段，有著不同的數據徵兆。

❖　以 CNC 主軸軸承為例：

• 早期（潛伏期）：振動診斷無法偵測，必須依賴超音波檢測
• 中期（發展期）：振動 RMS 顯著上升、頻譜圖出現軸承特徵頻率
• 晚期（爆發期）：溫度飆升、負載電流異常、噪音明顯

❖　以端子壓接為例：

• 模具刃口的磨損從「曲線面積微幅增加」→「毛邊變大」→「峰值壓力劇變」一路長大、變化。

這是一個動態的過程。

• 如果 AI 只學會晚期的數據徵兆，那它永遠只能當「驗屍官」。
• 真正的診斷，必須能看懂 整段 時序的數據徵兆 演化。

二、診斷的基礎：還原現場的數據徵兆

診斷環節的基礎，就是第二篇所談的數據徵兆，

我們得先把感測器原始數據，翻譯成：

• 壓力曲線尾端是否變鈍？
• 聲紋頻譜是否有尖峰？
• 行程是否輕微漂移？

備註：為了說明，以形容詞呈現；實際上應該是一個或一群數據與基準。

三、診斷的核心：依靠「三核驅動」來推理

AI 透過三種知識庫協同運作（三核驅動），

破解上文說的「多對多」與「動態演化」難點：

1. 規則庫（Rule-based）：硬性物理限制與經驗法則

將設備手冊的規格（Spec）、物理極限（Hard Limits）

以及老師傅的經驗，轉化為明確的 IF-THEN 邏輯。

• 應用：判定是否違反物理安全邊界、設備相容性或SOP規範。
• 舉例：端子壓接

IF 行程誤差 > 0.02mm THEN 判定為感測器鬆動或滑塊異常。

• 工具：Rule Engine（如 Drools）。

2. 機理模型（Mechanism Model）：物理／化學專家的公式

把物理／化學現象變成可運算的指標，降低多對多的歧義。

• 應用：利用物理／化學公式計算，區分異常屬性。
• 舉例：端子壓接的「做功」計算

❖　若 峰值壓力不變 但 曲線面積（積分）顯著增加

　→ 推論：模具刃口鈍化（阻力變大）。

• 舉例：CNC的 FFT 分析

❖　特徵頻率在 1X（轉速頻率）→ 推論：轉子不平衡

❖　特徵頻率在 BPFO（外圈頻率）→ 推論：軸承損壞

• 工具：Python（SciPy ／ NumPy）、Matlab

3. 案例庫（Case DB）：KM 

用相似度比對過去相似的故障案例，特別用來應對「動態演化」。

• 應用：這條曲線跟三個月前那次「斷刀/崩模」前的徵兆有 90% 相似。
• 舉例：端子壓接

❖　比對發現目前的聲紋特徵，與歷史資料庫中標記為「絕緣皮咬入」（Insulation Crimp Issue）的案例高度相似。

• 工具：向量資料庫（Vector DB，如 Milvus、Qdrant）。

四、AI 實作架構：Agentic Workflow（代理工作流）

這三種知識庫該如何實作？

不能只靠 LLM（它是文科生），

也不能只靠 Python（它是理科生）。

現在新技術架構是 AI Agent（智能體）工作流，

組成一個「數位智能團隊」，針對每一台端子壓接機的異常進行診斷：

Step 1：鑑識科（Python 算力層）－對應第二篇洞察的理性運算（萃取數據徵兆）

• 外部程式從原始壓力數據中萃取數據徵兆。
• 產出（示意）：

{ "峰值": "450N (偏低)", "面積": "12.5 (正常)", "波形": "左側塌陷" }

Step 2：檔案室（檢索層）－對應規則庫+案例庫

• Agent 拿著數據徵兆去詢問：

❖　問規則庫：「有無觸發停機警報？」

→ 無，但在下限邊緣

❖　問案例庫：「以前發生過這種波形嗎？」

→ 答：有，半年前發生兩次，當時原因是「線材導體缺芯」

【備註】：

歷史案例 #20240512

徵兆：峰值低、左側塌陷

原因：導體缺芯

維修對策：調整剝皮機刀片深度，重新剝皮後恢復正常。

Step 3：柯南（LLM 推理層）

• 這時，團隊的指揮官－編排者（Orchestrator）登場。

它是 AI Agent 的中控大腦，

負責將Step 1：鑑識科（Python）找到的數據徵兆，

與Step 2：檔案室（KM）所查到的案例，

組裝成最終的Prompt（示意）：

「你是一台資深壓接機顧問。

　目前數據：峰值偏低但面積正常，波形左側塌陷。

　歷史案例強烈指向『線材導體缺芯』。請綜合判斷。」

• LLM 進行最終推理：

「綜合判斷：波形左側塌陷且峰值低，符合『導體量不足』特徵。

　極高機率為導體缺芯。建議檢查線材剝皮段是否斷絲。」

這就是 AI Agent，串聯了 理性運算、歷史記憶 與 語意推理，

完成了人類專家可能需要數小時才能完成的診斷。

五、技術迷思：為什麼光靠 RAG（讀手冊）無法做診斷？

很多人問：

「把維修手冊丟進 RAG（檢索增強生成），LLM 不就會診斷了嗎？」

答案是：不行。

原因很簡單：

• RAG 讀的是文字，不懂訊號

它讀不懂壓力曲線的斜率變化，也看不懂振動頻譜。

• RAG 不會算

數據徵兆需要計算（如積分、頻率轉換），這是 LLM 的弱項。

• RAG 缺乏動態

文件是靜態的，但異常的演化是動態的。

簡單來說：

• RAG 讓 AI 讀懂了「書」（手冊），
• 但機理模型讓 AI 看懂了「病」（數據）。

唯有將「讀書的 LLM」與「看病的演算法」結合，

才能產出真正有血有肉、有憑有據的工業診斷報告。

六、場景：《廠長的一天》昨日異常的真相

場景回到工廠，早上8:30。廠長打開 iPad，系統顯示「昨日異常診斷日報」。

• 事件：5 號端子壓接機，昨日下午14:00起，良率波動。
• 診斷過程：

❖　看到數據徵兆：壓力曲線尾端面積逐漸增大，且伴隨微幅高頻噪音。

❖　比對案例庫：與之前的「模具疲勞」案例相似度92%。

❖　推理規則庫與機理模型：雖然未達停機標準，但積分計算顯示阻力異常上升。

• 根因推論：模具刃口磨損（Confidence: 87%）。
• 行動建議：建議中午休息時進行磨修，無需更換整組模具。

廠長點點頭，按下「派工單」。

從發現問題到鎖定原因，只花了30秒。

這就是診斷的價值。

七、診斷KPI：成敗論英雄

企業如何評估診斷是否成功？

•  準確性

找出來的根因，被現場驗證為真的比率，這項指標最關鍵。

• 時效性

從異常發生到找到根因，是3天還是30秒？

• 可行動性

給出來的是「模稜兩可的猜測」，還是「具體的根因」？

八、結語：從「知道痛」到「知道為何痛」

五環的前三環：

1.  取數：讓設備能開口說話，數據蒐集l（感知層）
2.  洞察：快速偵測早期問題，防微杜漸l（認知層）
3.  診斷：重建現場找出病灶，治本解決l（歸因層）

掌握了過去數據與現在情況，工廠終於有了底氣。

下一篇，我們將挑戰廠長每天最焦慮的首要事情：

今天、明天、下週，我的產線將會發生什麼事？（風險）

這就是第四環：預測（Prediction）。

讓工廠從「事後反應」，正式跨越到「事前準備」的新紀元。