AI 幻覺怎麼管？用客服知識庫追到錯誤發生的位置

AI 幻覺可能來自資料過期、檢索漏掉關鍵條款，或回答超出證據。以客服退款為例，逐一核對政策版本、命中文段、回答內容與轉接紀錄，才能判斷該修哪個環節。

專題編輯：Derek Chou｜AI 技術與架構編輯

客服機器人回答「七天內可退款」時，主管需要能追到這句話引用的政策版本。以下用虛構的退款流程，把錯誤定位到資料、檢索、生成或人工接手，讓每次修正都能重跑同一批案例。

從錯誤輸出辨認幻覺

NIST 在生成式 AI 風險管理框架中以 confabulation 描述系統產生並自信呈現錯誤內容的現象，也涵蓋偏離輸入或與同一脈絡先前敘述矛盾的內容［1］。若工作要求是寫虛構故事，創作本身屬於任務的一部分。

為什麼流暢的回答可能是錯的

語言模型的生成目標與外界真實性的驗證不是同一個機制。它可以接續出合理句子，卻沒有自動取得最新檔案或真正比對資料庫的保證。語句自信、格式完整、附上看似正式的引用，都無法單獨證明主張正確。

把錯誤分成五種

可以區分外部事實錯誤、來源憑空生成、摘要扭曲、數字／單位誤算、遵循指令失敗。分開標記的好處，是可以對症修正：算術交給計算器，資料時效交給權威來源，摘要交給逐段回查，權限問題交給應用層控制。

案例：採購比較報告

採購同仁請 AI 比較供應商合約，模型卻把草案條款當成已簽版本。這不是語句好壞問題，而是來源版本與權威排序失效。應固定文件 ID、發布日、合同狀態，回答時附條款位置；找不到條款就回答「未提供資料」，不自行補足。

退款回覆錯在哪一層

假設新版政策僅適用官網訂單，而且問答引用的是舊版經銷商條款。若新版檔案未入庫，由政策管理者修正；若已入庫但檢索沒找到，由工程團隊查版本和通路篩選；若找對條款仍答錯，檢查答案是否省略適用條件與缺資料時的轉接規則。

RAG 上線後仍要驗證回答

RAG 先檢索材料，再用材料生成回覆。RAGTruth 的研究顯示，實際生成答案仍可能出現檢索資料無法支持或相互矛盾的內容［2］。測試時分開記錄兩件事：是否找到有效政策，以及回覆裡每項關鍵條件是否都能由該政策支持。

引用存在不代表引用支持主張

真正的引用查核要看引用文獻是否存在、是否能存取、原文是否真的有那項說法、年份與數據是否一致。只有把 URL 放在段落尾端，可能讓不正確說法看起來更可信。可把每項重大主張對應到特定段落與頁碼，並標示直接證據或合理推論。

建立 Golden Dataset

從高頻業務問題與高損害問題選代表性題目，附正確答案、可接受的替代答案、來源版本和拒答條件。納入正常、缺資料、過期、互相矛盾、含惡意文字等樣本。避免測試資料只涵蓋簡單正例，否則正式上線時錯誤無從察覺。

讓指標對得上責任人

檢索命中率以有已知適用條款的題目為分母，回答支持率以已抽取的可查證主張為分母，兩個比例不能互換。另記錄在應轉人工的案例中，有多少真的收到承辦回執。政策、工程、客服各自有可跟進的修正項目。

從提示詞到治理

提示詞可以要求引用、缺資料時拒答，但更穩定的做法是加入資料白名單、版本檢核、程式化計算、權限限制與人工審核。工具呼叫與模型回答都要有日誌，讓事件發生後能追查「哪份資料、哪個版本、誰核准、做了何種操作」。

上線前的情境測試

規劃正常問題、資料缺漏、政策變更、引用不符、數字矛盾、日期跨期及極端問題七組測試。每組預先寫好預期答案與拒答標準。若關鍵情境未通過，應限制功能而非只在介面增加免責文字。

管理者的決策原則

AI 應被安排在可以查證、有明確責任、錯誤可逆的流程；不可把「有回答」當成「已完成」。高風險場景應有清楚的資料責任人、更新 SLA、測試紀錄、異常停用與人工接手流程。

讀者下一步

選一條客服政策，請政策負責人各寫一題正常案、一題資料不足案和一題跨版本案。每題先存有效條款與預期處置，再分別記錄回答、證據位置及人工轉接結果。

查證來源

1. NIST AI 600-1，生成式 AI 風險管理框架（2024）。
2. Niu 等人，RAGTruth（ACL 2024）。

本文由 AI 輔助整理。案例為教學用的虛構情境。