企業 AI 回答找不到依據：引用來源與拒答設計指南

文章目錄

• 1. 分清沒有來源和來源不一致
• 沒有來源：知識庫裡根本查無資料
• 來源不一致：多份文件互相矛盾
• 兩種狀況對企業的實際影響差異
• 2. 訂出可查證的引用欄位
• 必備欄位：文件名稱、版本、日期、段落定位
• 引用欄位表格範例
• 技術實作上的常見做法
• 3. 設計拒答與補問條件
• 拒答條件要寫成規則，不能靠模型「自己感覺」
• 補問設計：讓系統反問而不是亂猜
• 拒答訊息也要設計得有用，而不是一句「查無資料」
• 4. 用假設情境安排人工覆核
• 抽查比例該怎麼訂：高風險主題優先
• 覆核人員該檢查什麼：不只是「答案對不對」
• 覆核頻率隨導入階段調整
• 5. 記錄錯誤與資料更新責任
• 建立錯誤記錄表：不只是記錄，是要能追蹤
• 資料更新責任該落在哪個角色
• 定期檢核週期：別等客訴才想起來

AI 回答找不到依據時，正確做法是讓系統明確標示「查無來源」或「來源不一致」，而不是讓模型自行推測答案。許多中小企業在導入 AI 客服或內部知識庫問答系統後，發現最大的風險不是回答錯誤，而是回答得「太有自信」——明明知識庫裡沒有這份資料，系統卻還是生成一段看起來合理的文字。這種現象在技術上常被稱為 hallucination（幻覺，指模型生成看似合理但缺乏事實依據的內容）。對企業來說，這不是學術問題，而是會直接影響客戶信任與法遵風險的實務問題。

本文重點摘要

• AI 回答找不到依據時，系統該做的不是編答案，而是明確回報「查無來源」或「來源不一致」
• 可查證的引用欄位至少要包含文件名稱、版本、更新日期與原文段落，缺一都會讓覆核變得困難
• 拒答條件要寫成具體規則，而不是交給模型自行判斷「有沒有把握」
• 人工覆核不是備案，是 AI 導入初期的標準流程，抽查比例與對象都該事先訂好
• 錯誤記錄與資料更新責任若沒有指定窗口，知識庫會在半年內開始累積過期資訊

分清沒有來源和來源不一致

假設一家台中的機械零件製造商導入了內部 AI 知識庫問答系統，員工詢問某款產品的保固條件，系統給出一個聽起來很完整的答案。問題是，這個答案到底是「知識庫裡真的有這份保固文件」，還是「模型根據相似產品的描述推測出來的」？這兩種情況看起來結果一樣，但風險完全不同，企業必須先學會分辨。

沒有來源：知識庫裡根本查無資料

這是最單純的情況。使用者問的問題，在企業的知識庫、文件庫、SOP 裡完全找不到對應內容。這時候系統如果硬生出一個答案，等於是在編造。正確的設計是讓系統回傳「查無相關資料」，並引導使用者聯繫對應窗口，而不是用模型的通用知識「補一個看起來合理」的答案。

來源不一致：多份文件互相矛盾

這種情況更棘手。知識庫裡可能同時存在 2024 年版和 2026 年版的產品規格文件，兩份內容互相衝突，而系統沒有判斷新舊版本的機制，就隨機引用其中一份。來源不一致不是「沒資料」，而是「資料太多且互相矛盾」，處理方式完全不同——前者該拒答，後者該標示衝突並交由人工判斷採用哪一份。

兩種狀況對企業的實際影響差異

沒有來源的風險是「答案空洞但誠實」，客戶體驗打折但不致命。來源不一致的風險是「答案看似權威但可能誤導」，一旦客戶依據舊版規格下單或簽約，後續爭議處理成本會高出許多。企業在設計 AI 問答系統時，這兩種狀況必須分開記錄、分開統計，才能知道問題出在內容不足還是內容管理混亂。

AI 說「不知道」比說錯更值錢，因為錯誤的代價通常要事後才會出現。

訂出可查證的引用欄位

引用欄位設計得完不完整，直接決定了日後覆核的效率。很多企業導入 AI 知識庫時，只讓系統顯示「資料來源：產品手冊」，這種標註幾乎沒有查證價值——哪一本手冊？哪個版本？哪一頁？沒有這些細節，覆核人員得重新翻找整份文件，等於引用欄位形同虛設。

必備欄位：文件名稱、版本、日期、段落定位

一個可查證的引用欄位至少要有四項：文件名稱、版本號或發布日期、原文段落或頁碼、以及該文件的保管單位。這四項資訊讓任何一位覆核人員，不需要詢問原作答者，就能自行回溯到原始出處，確認 AI 的引用是否正確。

引用欄位表格範例

技術實作上的常見做法

在 RAG（Retrieval-Augmented Generation，檢索增強生成，指系統先從知識庫檢索相關文件片段，再交由語言模型生成回答的架構）架構中，這些欄位通常來自文件切割（chunking）階段所保留的 metadata（中繼資料）。企業導入 AI 知識庫時，若在文件前處理階段沒有把版本與日期標註清楚，後續再想補救，成本會高出許多。建議從文件上傳的第一天就建立命名規則與版本管理習慣。

引用欄位不是給 AI 看的，是給人看的。設計時要站在「半年後接手覆核的同事」角度，而不是工程師自己好用就好。

設計拒答與補問條件

企業 AI 系統該在什麼情況下主動說「我不確定」？這個問題如果沒有事先定義清楚，模型預設的行為通常偏向「盡量給答案」，因為多數語言模型的訓練目標本來就是生成流暢且有幫助的回應，而不是判斷自己是否該保持沉默。

拒答條件要寫成規則，不能靠模型「自己感覺」

常見的做法是設定信心門檻（confidence threshold），當檢索到的文件相似度分數低於某個數值時，系統自動回傳制式拒答訊息。但光靠相似度分數並不夠，還需要搭配規則，例如：若檢索結果少於某個數量、若命中的文件已超過設定的有效期限、若多份命中文件結論互相矛盾，都該觸發拒答或補問，而不是直接生成答案。

補問設計：讓系統反問而不是亂猜

假設客戶問「這個方案多久可以上線」，但沒有說明是哪一種方案，系統與其猜測，不如先反問「請問您指的是網站開發、SEO 優化，還是 AI 導入服務？」。補問機制能大幅降低錯誤回答的機率，同時讓使用者感受到系統的謹慎，而不是隨便亂答一通。

拒答訊息也要設計得有用，而不是一句「查無資料」

單純回覆「查無相關資料」對使用者幫助有限。較好的做法是拒答時同時提供「目前最接近的資訊是什麼」加上「建議聯繫的對應窗口」，讓拒答不等於斷線，而是導引到下一步。這種設計對導入 AI 客服的企業特別重要，因為客戶體驗的斷點，往往就發生在系統說不知道的那一刻。

讓 AI 學會反問，比讓它每次都給答案更接近真正的智慧。

用假設情境安排人工覆核

假設一家台中的連鎖零售品牌導入 AI 客服回答常見問題，上線初期團隊沒有安排任何人工抽查機制，認為系統測試階段已經「夠準」。三個月後才發現，系統對於「退換貨期限」的回答，引用的是一份已經被新規則取代的舊版 SOP，而這個錯誤在上線期間持續發生，直到有客戶提出爭議才被注意到。這類情境說明了一個通則：沒有持續覆核機制的 AI 系統，風險不會在上線當下出現，而是在累積一段時間後才爆發。

抽查比例該怎麼訂：高風險主題優先

人工覆核不可能、也不需要涵蓋所有對話紀錄。實務上較合理的做法，是依照主題風險分級：涉及金額、法律責任、保固條款的回答，抽查比例應明顯高於一般產品介紹類問題。企業可以先從每週抽查一定比例的高風險對話開始，再依據錯誤發生率動態調整。

覆核人員該檢查什麼：不只是「答案對不對」

覆核不應只看答案表面是否正確，還要檢查引用欄位是否完整、是否存在來源不一致卻被忽略的情況、拒答條件是否該觸發卻沒有觸發。這幾項加起來，才是完整的覆核範圍，單純檢查「答案看起來合理」反而容易漏掉系統性問題。

覆核頻率隨導入階段調整

試辦階段建議高頻率、近乎全量覆核，等系統穩定運作一段時間、錯誤率明顯下降後，再逐步調整為抽查制。這個節奏類似軟體上線後的監控強度調整——剛上線盯得緊，穩定後才放寬頻率，但絕對不能完全停止覆核。

人工覆核的目的不是抓 AI 的錯，是確認「拒答機制有沒有確實運作」。如果覆核時發現系統該拒答卻沒拒答，這比答錯一題更該優先處理。

記錄錯誤與資料更新責任

誰該負責更新知識庫？這個問題聽起來簡單，但多數企業在導入 AI 系統時根本沒有明確指定。結果就是知識庫上線半年後，沒有人知道哪些文件該更新、哪些錯誤已經修正過、哪些還懸而未決。

建立錯誤記錄表：不只是記錄，是要能追蹤

一份有效的錯誤記錄表至少要包含：發現日期、錯誤類型（沒有來源／來源不一致／拒答未觸發）、對應文件、負責更新的單位、更新完成日期。少了「負責單位」與「完成日期」兩欄，記錄表只是流水帳，無法真正驅動改善。

資料更新責任該落在哪個角色

常見的做法是由原始文件的擁有部門負責更新內容本身（例如品管部負責保固規範），而由系統維護方負責確認更新後的文件是否正確匯入知識庫並重新索引。這兩個責任容易混在一起，但其實是不同性質的工作，分清楚才不會互踢皮球。

定期檢核週期：別等客訴才想起來

建議企業在導入 AI 問答系統後，訂定固定週期（例如每季）全面檢視知識庫中的文件是否仍在有效期內，而不是被動等待錯誤記錄表累積到一定數量才處理。這個節奏可以參考企業既有的文件管理制度，搭配系統維護顧問的建議調整。

這套分工看似增加了管理負擔，但實際運作起來，比起事後處理客訴或法遵爭議，前期建立清楚的責任歸屬反而省力許多。根據維基百科對大型語言模型的說明模型本身並不具備區分真偽的內在機制，這也是為何外部治理設計（如引用欄位、拒答規則、人工覆核）必須由企業自行建立，不能期待模型自動具備這些能力。

導入 AI 問答系統前，先把治理設計談清楚

AI 導入的技術門檻正在下降，但引用來源、拒答機制與人工覆核的治理設計，才是決定系統能不能長期穩定運作的關鍵。歡迎與我們聊聊貴公司目前的知識庫現況與導入規劃，我們可以一起討論適合的治理架構與執行步驟。