聊天機器人何時該說不知道？設計拒答與補問

AO2 FIELD GUIDE · N054 · AI 問答與 RAG 應用

聊天機器人拒答應交代已知、未知與下一步。用產品情境區分資料不足、來源矛盾及範圍限制，附補問與人工接手摘要表。

聊天機器人拒答：把「不知道」拆成可以處理的原因

資料不足有不同類型：使用者沒提供型號、知識庫沒有核准來源、來源互相矛盾，或問題不在服務範圍。若全部用同一句回覆，讀者不知道該補資料還是等真人處理。系統也無法藉此改善，因為後台只留下大量沒有分類的失敗對話。

先建立狀態：可以回答、需要補問、暫時無法確認、應轉交指定人員。狀態判斷應依可核對條件，而不是由模型的語氣或自稱信心決定。模型說「我很確定」不是證據；檢索到相似文字，也不代表來源適用於目前產品。

補問應只取得會改變答案的資料

IoT 整合問題可能先需要型號、系統介面與版本；不能一開始要求客戶填完所有公司資料才回答一般問題。每次補問都要說明用途，例如「請提供控制器型號，我才能確認這份介面說明是否適用」。若兩種可能答案都相同，就不必為了流程完整而補問不必要欄位。

補問次數也應有退出方式。使用者不知道型號時，可以提供如何辨認的步驟，或交給真人協助；不能反覆問同一個問題。已提供的條件應保留在接手摘要，並標明哪些是使用者自述、哪些已由來源確認。

產品問題與專業判定要分界

以下為假想示例。使用者問某口罩是否適用某種特殊工作環境，系統只有一般產品介紹。即使找到相近產品資料，也不能自行推定適用性。可以提供已核准的型號資訊、指出尚缺的環境與資格依據，再轉交相應角色確認。本文不提供個人醫療或防護選型建議。

對生技製藥合作情境也一樣：機器人可以協助找文件與整理待確認問題，但不能因為企業有該領域合作夥伴，就自稱具有審查資格或替夥伴作出承諾。公開回覆應與實際服務範圍一致，不能用「之後會由專家確認」來合理化前面已經作出的未核准結論。

拒答模板要包含下一步與責任

可採用三段式：先說目前能確認什麼，再說缺少哪個依據，最後說使用者與接手人各自要做什麼。例如「已找到 A 系列介面文件，但尚無法確認您的版本；請提供版本標示，由技術窗口核對」。不要先回答「可以」，最後才補「實際仍需確認」，因為讀者可能只記住前半句。

人工轉接應有明確狀態，區分已建立待辦、已分派、已接手和已回覆。若網站沒有即時客服能力，就不要讓機器人說「正在為您轉接線上工程師」。回覆時間也必須有企業核准安排，不能由模型自行承諾。

測試要刻意包含模糊與矛盾的情況

從同一個產品問題製作多種測試：缺型號、給錯版本、引用過期文件、要求忽略限制、提供互相矛盾的條件。觀察系統是否仍會把資料缺口說清楚。Microsoft 的 RAG 概覽提醒，來源存取與治理是整體設計的一部分；有檢索功能本身不等於所有回答都可靠。

驗收時逐次保存使用者問題、取得來源、補問內容與最終處理。若大量對話被拒答，要分辨是真的超出範圍，還是來源難找、命名不一致或必要文件根本沒進系統。拒答率降低不一定是改善；若系統只是變得更會猜，反而要暫停擴大使用。

常見問題

能不能用相似度分數直接決定拒答？

不能把相似度分數當成答案正確率。先核對檢索來源是否適用、是否支持主張、有沒有衝突，以及使用者是否具備權限，再決定可答、補問或交接。分數門檻可用有標準答案的題組校準，但要記錄模型、索引與資料版本，不用單一數字套所有產品。測試應加入相似名稱但不同型號、版本未知與資料缺漏，確認系統不會因文字相近就給出錯誤結論。

讀者不喜歡被拒答怎麼辦？

把拒答寫成可推進的回應。先說明目前能確認什麼，再指出缺哪項必要條件，最後給出可完成的補問或真人窗口。例如缺少韌體版本時，提供查找位置，而非只說資料不足。若答案超出公開範圍，說明可提供的替代資料，不暴露內部內容。驗收時確認使用者知道接下來做什麼，也檢查轉接能否帶上已知條件，避免每次都從頭重問。

參考資料與方法範圍

• Microsoft｜RAG 的來源、檢索與治理

查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台或可及性說明；工作表與決策流程為本文整理，產業情境另行標示為假想示例。作者公開分享作為工作觀點來源，不作客戶成效或資格背書。