企業導入 LLM 客服機器人，如何避免「答非所問」

「直接接上一個大語言模型」聽起來很簡單，實際上線後最常見的抱怨卻是：機器人講得很流暢，但答案是錯的、答非所問，或是一本正經地編造出根本不存在的規則。問題通常不在模型本身，而在導入時漏掉的幾個環節。

LLM 客服機器人跟傳統關鍵字機器人最大的差異，是它「看起來」什麼都答得出來——這既是優點也是風險。傳統機器人答不出來會直接顯示「找不到相關結果」，使用者知道要換個問法或找真人；但 LLM 機器人即使資訊不足，也可能用流暢的語氣生成一個聽起來合理、實際上錯誤的答案，使用者反而更難察覺。以下是我們在導入專案中，最常需要提醒客戶提前規劃的幾件事。

01知識庫的品質決定回答品質

模型再強，也只能根據你提供的知識庫回答問題。如果知識庫內容過期、格式混亂、同一個問題在不同文件裡有互相矛盾的答案，模型會如實反映這些問題——甚至在資訊不足時自行「腦補」出聽起來合理但不存在的規則。上線前，先把知識庫內容盤點過一輪：淘汰過期資訊、統一同一問題的答案版本、把口語化的常見問法也對應進去，這件事比急著挑模型更重要，也是多數導入專案裡最花時間、但報酬率最高的一步。

02明確定義機器人「不知道」時該怎麼做

一個常被忽略的設計決策是：當知識庫裡真的找不到答案時，機器人該老實說「不確定，幫你轉真人」，還是根據語言能力硬湊一個聽起來合理的回答？後者正是「一本正經胡說八道」的來源。上線前要明確要求系統在信心不足時承認不知道，而不是靠語言流暢度掩蓋內容上的空白。實務上可以透過限制機器人只能根據檢索到的知識庫內容回答（而不是憑訓練時學到的一般知識回答），大幅降低這種風險。

03設計清楚的人工轉接時機

不是所有問題都適合、或應該讓機器人處理，例如客訴、退款爭議、涉及個資或法律責任的問題。導入前要先定義哪些情境要主動轉真人、觸發轉接的條件是什麼（連續追問次數、特定關鍵字、使用者明確要求、情緒偵測到不滿），並確保轉接時對話紀錄完整帶過去，客戶不用重講一次。設計良好的轉接機制，會讓使用者感覺是「順暢地被接手」，而不是「被機器人擋在門外」。

04用真實對話紀錄測試，而不是假設情境

內部測試時常常用「乾淨」的標準問句去驗證機器人，但真實客戶的問法往往口語、跳躍、一句話夾雜多個問題，甚至帶著錯字或方言用語。上線前應該用過去真實的客服對話紀錄（去識別化後）做測試，才能看出機器人在真實語境下的表現，而不是在理想情境下的表現。這一步也能提前發現知識庫遺漏的常見問題型態，比正式上線後才被使用者發現要划算得多。

05上線後要持續監控「答非所問」的案例

機器人上線不是專案的終點。應該建立機制追蹤：哪些問題被使用者重複問、哪些對話被轉真人、哪些回答被使用者標示為沒有幫助。這些資料是持續改善知識庫與提示設計的依據，沒有這層監控，機器人的表現只會隨著客戶問題型態改變而慢慢變差，卻沒有人發現，直到某天累積成一波客訴才被注意到。

LLM 客服機器人真正的門檻，不是「要不要用大模型」，而是知識庫整理、邊界設計與上線後的維運機制是否到位。這些工作沒有捷徑，但做好了之後，機器人才會是真的在幫客戶解決問題，而不是另一層讓客戶更挫折的介面。

常見問題