RAG 幻覺 hallucination 怎麼控制?企業級的六層防線與落地做法

RAG 幻覺控制,指的是在檢索增強生成 (Retrieval-Augmented Generation) 系統裡,用一整套工程手段確保模型只根據檢索到的可靠資料作答、對查不到的問題誠實拒答,並讓每一句話都能追溯到來源——而不是靠一句 prompt 叫它「不要亂講」。

我先講一個現場。某金融客戶的內部知識問答上線一個月,合規部門抓到一次回答:系統言之鑿鑿地引用了一條「2023 年修訂的作業辦法」,格式完整、語氣專業,唯一的問題是那條辦法不存在。工程師回去查 log,才發現檢索根本沒命中相關文件,模型是憑語感自己補的。這不是模型壞掉,是系統少了防線。

為什麼一句 prompt 救不了你

很多團隊控制幻覺的方法,是在 system prompt 裡加一句「只根據提供的資料回答,不確定就說不知道」。這句話有用,但它是六道防線裡最弱、最靠後的一道。模型是機率產生器,當檢索給的上下文模糊、衝突、或根本沒命中時,它填空的本能會壓過那句叮嚀。真正能把幻覺壓到可上線的水準,靠的是把「防止它亂講」拆解成獨立、可各自量測的環節。

我們在客戶現場落地時,習慣用六層防線來盤點一套 RAG 系統。哪一層漏了,就從哪一層補。

前四層是即時的,後兩層決定你能不能睡好

檢索品質是地基。八成的幻覺其實源自檢索沒命中——模型拿到不相干的段落,只好編。我們幾乎每個案子都會先做一輪 retrieval evaluation,量 recall@k,先確認「答案該有的文件到底有沒有被撈進來」,再談生成。切 chunk 時別用固定字數硬切,那會把一句話劈成兩半;沿標題、段落等語意邊界切,rerank 的命中率會明顯提升。

引用強制與答案驗證是我認為最被低估的兩層。強制模型標來源,不只是給使用者看,更是給你的後處理程式一個可驗證的錨點:你可以用程式檢查它引用的 chunk id 是否真的在檢索結果裡,對不上就攔下來。再上一層,用一個獨立的 grounding check——把「答案句」和「來源段落」丟給另一個模型或 NLI 模型判斷是否蘊含。這一步會攔掉大量「來源存在、但被過度延伸解讀」的軟性幻覺,也就是最難用肉眼抓的那種。

拒答機制聽起來簡單,卻是採用率的分水嶺。多數團隊不敢讓系統說「我不知道」,怕顯得無能。但在金融、醫療這種場景,一次自信的錯答造成的信任崩塌,遠比十次誠實拒答嚴重。我們會給模型一條明確的 abstain 路徑:當上下文把關的分數過低、或驗證沒通過時,回一句「目前查無相關規範,建議聯絡合規窗口」,並把這次 query 記進待補知識清單。

沒有評測,前五層都是玄學

最後一層——評測與維運——是把前面五層從「感覺有效」變成「數字上守得住」的關鍵。上線前,你需要一組帶標準答案的評測集,量幻覺率、引用準確率、拒答率;上線後,這幾個指標要進監控面板,每次改 prompt、換模型、更新知識庫都跑一次回歸測試。我們踩過的雷是:某次為了讓回答更完整而放寬了引用約束,離線看起來更「聰明」,線上幻覺率卻悄悄漲了。沒有那組指標,你根本不會發現。

幻覺控制不是一個開關,是六層各自可量測、可回歸的工程。這也是我們在客戶現場做 RAG 時最花力氣的地方——不是把 demo 調得漂亮,而是把這六層一層層架起來、接上監控,讓它上線三個月後還守得住,而且真的有人敢用它的答案做決策。