第 14 章・應用場景篇

設備維護：故障診斷助手（RAG）

工廠裡最寶貴的常是老師傅腦中的排障經驗，卻也最難傳承——他一請假，機台跳警報就沒人會處理。這一章我們把維修手冊變成一個會「查書再回答」的診斷助手：操作員描述故障，它從知識庫找出對應的排查步驟，還會提醒安全規範。這是本篇第一個用到知識庫 RAG 的場景。

業界痛點
設備維護的知識高度依賴老師傅的個人經驗與一本厚厚的維修手冊。現場一跳警報，新人不知從何查起、翻手冊找半天；老師傅不在就只能停機等待。更棘手的是安全——排查主軸、伺服若沒先上鎖掛牌（LOTO）就動手，是會出人命的。經驗無法規模化、查詢沒有效率、安全規範靠人記，這三件事疊在一起，就是設備稼動率的隱形殺手。

本章目標

解決什麼: 把維修手冊變成隨問隨答的診斷助手，讓任何一位操作員都能快速、安全地初步排障
用到的技術: 第 3 章的知識庫（RAG）＋第 8 章的聊天流（Chatflow）：開始 → 知識檢索 → LLM → 直接回覆
難度: ★★★★☆　第一次讓 AI「查你自己的文件」再回答，答案有憑有據、可溯源

✨ 成果搶先看

先看做完長什麼樣——這樣你就知道自己在往哪裡前進。跟著本章做，你也能生出下面這個結果：

① 使用者在聊天視窗輸入
💬 「X 軸移動時跳出過負載警報 ALM-522，加工中途停了，我該檢查什麼？」

↓　AI 處理，產出 ↓

故障診斷：ALM-522 X 軸伺服過負載

可能故障方向

此警報通常與下列因素有關：

導軌潤滑不足或滑軌卡滯
切削負荷過大、進給速度（F值）設定過高
鐵屑堆積在導軌或滾珠螺桿
伺服馬達或驅動器異常

建議排查步驟（由簡到繁）

1. 清潔檢查

清除導軌與滾珠螺桿上的鐵屑堆積
確認自動潤滑系統是否正常作動、油量是否充足

2. 程式參數檢查

檢視目前加工程式的進給率（F值）設定
若設定過高，適度調降後重新試跑

3. 手動測試

以手動模式慢速移動 X 軸
注意是否有異音、震動或卡點現象

這是實際問診結果：AI 依維修手冊（RAG）給出由簡到繁的排查步驟，並提醒安全事項。（完整更長，下載 DSL 自己跑就看得到全部）

👇 在 Dify 裡實際執行、長這樣

成果搶先看 — 成品操作員報一個警報代碼，系統依維修手冊給出由簡到繁的排查步驟與 LOTO 安全提醒，並標明引用來源。

效益速覽（估算）

省時間

翻手冊 20 分→即時

隨問隨答

省人力

老師傅經驗規模化

新人也能安全排障

創造價值

可溯源

安全規範每次主動提醒

⬇ 把這個工作流帶走，直接用
不想從頭做？下載本章的 DSL 檔，到你的 Dify「工作室 → 匯入 DSL 檔案」上傳，就能一鍵複製這個範例、改成自己的。

下載 DSL 檔

14.1為什麼一定要 RAG，而不是把手冊塞進提示詞？

你可能想：把手冊全文貼進提示詞不就好了？兩個問題：手冊可能上百頁，塞不進、也貴；更重要的是，你要 AI 只根據手冊回答，不能自由發揮——設備排障不容它「憑感覺」。RAG（檢索增強生成）正是解方：先從知識庫「檢索」出跟問題最相關的段落，再讓 LLM「只根據這些段落」作答，答案還能標出引用來源，可稽核。

14.2第一步：建立設備維修知識庫

建立知識庫左側「知識庫」→「建立知識庫」→ 上傳維修手冊（本例是一份 CNC 加工中心常見故障排除手冊，含 ALM-401 主軸過熱、ALM-522 伺服過負載、ALM-310 換刀失敗與保養週期）。
選擇索引方式本機示範用「經濟」模式（關鍵字索引，不需 embedding 模型、快又省）；正式環境若追求語意檢索精度，改用「高品質」模式配 embedding 模型（見第 3 章）。
等待索引完成文件解析、分段、建索引後即可被檢索。

設備維修知識庫的文件清單頁 — **圖 14-1**建好的「設備維修知識庫」。左側可看到「經濟 · 倒排索引」的索引方式，維修手冊已完成解析。這個知識庫將被下一步的聊天流引用。

14.3第二步：用聊天流串起檢索與回答

診斷是一來一往的對話（操作員可能追問），所以用聊天流（Chatflow）而非工作流。整條流程四個節點：

聊天流畫布：開始 → 知識檢索 → LLM → 直接回覆 — **圖 14-2**聊天流結構：開始收下使用者問題 → **知識檢索**拿問題去查設備維修知識庫 → **LLM** 只根據查到的段落作答 → **直接回覆**把答案吐回對話。

知識檢索節點把它的查詢變數接到 sys.query（使用者的提問），並勾選要查的知識庫「設備維修知識庫」。
LLM 節點開啟「上下文」，把知識檢索的 result 餵進去；系統提示詞用 {{#context#}} 引用檢索結果，並下令「只根據參考資料回答，查無此故障就說通報設備課，不要捏造」，再要求涉及主軸/伺服/拆解時務必提醒 LOTO 上鎖掛牌。

知識檢索節點設定，已選定設備維修知識庫 — **圖 14-3**知識檢索節點的設定。查詢變數綁 `sys.query`、已掛上「設備維修知識庫」。這一步就是 RAG 的「檢索」環節——先找對段落，LLM 才答得準。

接著設定 LLM 節點——這是 RAG 的「生成」環節。兩個關鍵設定：「上下文」欄位把知識檢索節點的 result 餵進來；系統提示詞用 {{#context#}} 引用檢索到的段落，並下令「只根據參考資料回答、查無資料就說通報設備課」，再加上 LOTO 安全提醒的規則。

LLM 節點設定：上下文接知識檢索結果，提示詞用 context — **圖 14-3b　LLM 節點**LLM 節點的「上下文」接知識檢索的 `result`，系統提示詞以 `{{#context#}}` 引用檢索段落並約束「只根據參考資料回答」——這就是 RAG 讓答案有憑有據、可溯源的核心。

14.4實戰對話：一句警報，一套排查

發布後，讓操作員問一句真實的現場狀況：「X 軸移動時跳出過負載警報 ALM-522，加工中途停了，我該檢查什麼？」

診斷回覆：排查步驟、LOTO 安全提醒與引用來源 — **圖 14-4**助手先判斷故障方向，再依手冊給出**由簡到繁的排查步驟**（清潔導軌鐵屑 → 檢查進給率 → 手動慢速移動 → 仍報警才通報），並用 ⚠️ 強調涉及伺服時「勿自行拆機、執行 LOTO 上鎖掛牌」。最下方的「引用設備維修知識庫.txt」證明這段回答確實來自手冊，不是模型瞎編。

帶來的改變
老師傅的排障邏輯與手冊知識，變成 24 小時在線、任何人都能查的助手；新人面對警報不再手足無措；安全規範（LOTO）每次都被主動提醒，而不是靠人記得。答案可溯源到手冊段落，出了問題查得到依據。

進階做法
可在 LLM 前加一個第 6 章的「問題分類器」：先判斷是「設備故障」還是「保養排程」還是「閒聊」，故障走知識檢索、閒聊走一般回答。這就是客服／診斷型 Chatflow 的標準架構，把第 3、6、8 章全串起來。

輸出、發布與使用：把成果交付出去

做好的應用要能發布、分享給別人用才有價值。以下是這個應用的輸出設定與發布／使用畫面：

**發佈選單**做好後按右上「發佈 → 發布更新」即上線；選單還提供『運行』獨立網頁、『訪問 API』、『嵌入網站』與『工作流程作為工具』等交付方式——這就是把應用分享給別人使用的入口。

14.5本章回顧

要 AI「只根據你的文件」回答且可稽核，就用 RAG，而不是把文件塞進提示詞。
知識庫（檢索）＋聊天流（開始 → 知識檢索 → LLM → 直接回覆）是最通用的內部知識問答骨架。
設備場景的關鍵加值：把安全規範（LOTO）與「查無資料就通報、不捏造」寫進提示詞。
回覆附引用來源，讓答案可溯源、可信任——這是內部知識應用能否落地的關鍵。