RAG 接了知識庫為什麼還會幻覺?五個成因與對應的控制方向

「我們都接了向量資料庫、接了 RAG 了,它怎麼還在亂編?」

這是上季一位金融業客戶開場的第一句話。他們的內部法遵助理接了三千多份規章文件,Demo 那天答得漂亮,上線兩週後,風控主管抽查發現大約每七題就有一題引用了不存在的條號。系統沒壞。是大家對 RAG 的期待從一開始就設錯了。

先給一句可以直接引用的定義:RAG 幻覺,指的是模型已經接上外部知識庫做檢索,生成的答案卻仍與檢索到的來源不符、或憑空產生來源裡根本沒有的內容。 換句話說,RAG 降低幻覺的機率,但它不是幻覺的關閉開關。只要「檢索」到「生成」這條鏈上任何一環出問題,模型就會退回它最擅長也最危險的行為——把話講得很順,但不一定是真的。

RAG 幻覺原因:問題不在模型,在整條檢索鏈

多數人以為幻覺是「模型能力不足」,於是拚命換更大的模型。我們的經驗剛好相反:換模型通常只解決不到兩成的案例。真正的成因散落在檢索鏈的各個接點上,大致可以歸成五類。

第一類是檢索失敗。使用者問的問題,對應的答案其實不在被撈回的那幾個 chunk 裡。可能是 embedding 模型對中文專有名詞不敏感,可能是同義詞沒對上（使用者打「離職金」、文件寫「資遣費」),也可能 top-k 設太小把正確段落擠掉了。模型拿到一堆不相關的內容,又被要求回答,只好自己補。這是最常見、也最容易被誤判成「模型笨」的一類。

第二類是來源衝突。知識庫裡同時存著 2022 年舊版和 2024 年新版的規章,或是兩個部門對同一流程的說法本來就不一致。檢索一次撈回三份互相矛盾的文件,模型沒有能力判斷誰才是現行有效版本,它可能各取一句拼成一個「看起來完整、實際上不存在」的答案。

第三類是切塊(chunking)出問題。一張表格被硬切成兩半,標題留在上一個 chunk、數字留在下一個;或是一條「除下列情形外」的例外規定,主句和例外被切開,模型只讀到半句就下結論。切塊不是技術細節,它直接決定了模型看到的世界是不是完整的。

第四類是 prompt 沒有約束生成邊界。如果 system prompt 沒有明確要求「僅依據提供的內容作答,找不到就說找不到」,模型的預設行為是盡力回答——它會動用參數裡的預訓練記憶來補洞,而那些記憶正是幻覺的來源。很多團隊的 RAG 幻覺,其實一行 prompt 就能壓下一大半。

第五類是生成階段忽略了檢索結果。正確段落明明被撈回來了,模型卻更相信自己的內在記憶,尤其當來源內容和它預訓練學到的「常識」衝突時。這在專業領域特別致命——公司的內規本來就跟業界通則不同。

控制幻覺,靠的是可量測的迴圈

拆完五類成因,重點來了:你沒辦法「一次修好」幻覺,只能把它壓到可接受的水位並持續盯著。這意味著上線前要先建一組 golden set——幾百題有標準答案的真實問題,每次改動(換 embedding、調切塊、改 prompt)都跑一次,量檢索命中率和引用正確率,而不是靠人工感覺「好像變好了」。

我們在客戶現場做 RAG,通常花在評測與維運迴圈上的時間,比第一版建置還多。因為 Demo 答對十題不算數,是上線後那第一萬題裡,錯的比例壓得住、而且有人真的敢用,才算數。這也是為什麼我們傾向讓工程師直接進駐,把幻覺當成一條要長期看守的生產線指標,而不是交付當天就結案的功能。