RAG 幻覺 vs. 檢索失敗：一個診斷框架

使用者向你的 RAG 系統提問。答案是錯的。然後呢？

這就是大多數團隊犯同樣錯誤的時刻：他們假設問題出在 LLM 上，然後開始調整 prompt。他們添加諸如「僅使用提供的上下文」或「如果答案不在上下文中就說不知道」之類的指令。有時這有幫助。但往往沒有效果，因為真正的問題從來不是 LLM——而是檢索流水線向它輸入了錯誤或缺失的上下文。

RAG 系統的錯誤輸出有兩種根本不同的根因，針對一種的修復對另一種毫無作用。幻覺是生成問題：LLM 擁有正確的上下文但在回答中編造或扭曲了資訊。檢索失敗是流水線問題：LLM 從一開始就沒有收到正確的上下文，因此它要麼編造內容、引用不相關的段落，要麼給出不完整的回答。

誤診根因意味著在錯誤的修復上浪費時間。本文提供了一個結構化的框架來區分這兩種問題。

兩種失敗模式

檢索失敗

檢索流水線沒有找到包含答案的文件或片段。LLM 收到的上下文是不相關的、部分相關的或空的——然後它盡力作答。

檢索失敗發生在 LLM 的上游。嵌入模型、分塊策略、向量庫查詢、中繼資料篩選器或重排序步驟未能識別正確的內容。LLM 運作正常——它只是使用了錯誤的輸入。

LLM 幻覺

檢索流水線提供了正確的上下文。LLM 收到了包含答案的相關文件。但生成的回應與提供的上下文相矛盾、扭曲或編造了上下文中不存在的資訊。

幻覺發生在檢索的下游。流水線完成了它的工作。LLM 沒有忠實地呈現它收到的內容。

為什麼這種區分很重要

檢索失敗的修復是流水線工作：調整分塊大小、改進嵌入、修復中繼資料篩選器、添加重排序、修復索引損壞。再多的 prompt 工程也無法修復一個檢索不到正確文件的流水線。

幻覺的修復是生成工作：改進 prompt、使用結構化輸出格式、添加引用要求、切換到更強的模型，或實施針對來源上下文的生成後事實核查。

用錯誤的修復方法會浪費時間，甚至可能讓情況更糟。對一個存在檢索失敗的系統添加「僅從上下文中回答」的指令，只會導致它拒絕回答——上下文中沒有包含答案，所以指令按設計運作了，但使用者體驗卻下降了。

診斷流程圖

按照以下順序來診斷 RAG 系統的錯誤輸出是檢索問題還是幻覺問題。

步驟 1：擷取檢索到的上下文。

在診斷任何問題之前，你需要看到 LLM 實際收到了什麼。記錄或顯示檢索流水線為該查詢返回的片段。如果你的系統不暴露這些資訊，那這就是首先要修復的——你無法診斷你無法觀察到的東西。

步驟 2：檢索到的上下文是否包含正確答案？

自己閱讀檢索到的片段。正確回答該查詢所需的資訊是否存在於上下文中？

如果否：這是檢索失敗。繼續閱讀下方的檢索診斷部分。
如果是：繼續步驟 3。

步驟 3：LLM 的回應是否忠實地代表了檢索到的上下文？

將 LLM 的回答與檢索到的上下文進行對比。回應是否準確反映了上下文中的內容，還是它在矛盾、修飾或編造？

如果回應矛盾或添加了上下文中沒有的資訊：這是幻覺。繼續閱讀幻覺診斷部分。
如果回應準確但不完整：可能是兩者之一——上下文可能包含完整答案但 LLM 遺漏了部分（遺漏性幻覺），或者上下文本身不完整（部分檢索失敗）。檢查來源文件是否包含未被檢索到的資訊。

步驟 4：失敗是一致的還是間歇性的？

多次執行相同的查詢（temperature 大於 0 時）。

如果答案以相同方式持續錯誤：更可能是檢索失敗（每次都檢索到相同的錯誤上下文）。
如果答案在正確和錯誤之間變化：更可能是幻覺（LLM 在使用上下文時具有非確定性）。

症狀對比表

症狀	檢索失敗	LLM 幻覺
答案自信但錯誤	常見——LLM 從不相關上下文中虛構	常見——LLM 在有正確上下文的情況下仍然編造
答案說「我不知道」但應該知道	可能——正確上下文未被檢索到	不太可能——LLM 在上下文中有答案但選擇不使用（罕見）
答案引用了真實文件但引用了錯誤的部分	可能——從正確文件中檢索了錯誤的片段	可能——LLM 在上下文內部錯誤歸因
答案引用了不存在的文件	不太可能——檢索返回真實文件	可能——LLM 編造了引用
答案包含錯誤的具體數字或日期	檢查上下文——如果數字不在檢索到的片段中，是檢索失敗	如果數字在上下文中但 LLM 改變了它們，是幻覺
答案部分正確、部分編造	可能——檢索到了一些相關上下文，但缺少一些	可能——LLM 將真實上下文與編造內容混合
相同查詢返回不同的錯誤答案	不太可能——檢索是確定性的	可能——非確定性生成
問題在流水線更改後突然出現	可能——索引、嵌入或分塊更改破壞了檢索	不太可能——除非模型或 prompt 被更改
問題影響特定主題但不影響其他主題	可能——那些文件未被索引，或分塊將它們碎片化了	不太可能——幻覺通常不是特定於主題的

診斷檢索失敗

一旦你確認正確的上下文未被檢索到，就要縮小檢索流水線中失敗發生的位置。

檢查 1：來源文件是否在索引中？

透過中繼資料（檔案名稱、文件 ID）直接在向量庫中查詢該文件。如果文件不在索引中，則它要麼從未被索引，要麼因索引損壞而遺失。這是擷取或索引完整性問題，不是檢索問題。

檢查 2：相關片段是否在索引中？

文件可能已被索引，但回答查詢的特定段落可能以碎片化答案的方式被分割到了多個片段中。檢索來源文件的所有片段，並檢查是否有任何單個片段包含完整答案。如果答案跨越兩個或更多片段，你的分塊策略需要調整——更大的片段、更多的重疊或語義分塊。

檢查 3：嵌入是否擷取了語義關係？

為查詢和應該被檢索到的片段生成嵌入。計算它們的餘弦相似度。如果儘管片段與查詢在語義上相關但相似度很低，則嵌入模型未能擷取該關係。這在嵌入模型未經訓練的領域特定詞彙上會發生。考慮使用領域特定的嵌入模型或查詢擴展。

檢查 4：中繼資料篩選器是否過於嚴格？

如果你的檢索流水線使用中繼資料篩選器（日期範圍、文件類型、部門），請驗證篩選器是否在排除正確的文件。這是檢索失敗的一個出人意料的常見原因——一個在設定時正確的篩選器隨著新文件以不同中繼資料模式到達而變得過時。

檢查 5：重排序器是否在降低正確片段的排名？

如果你在初始檢索後使用重排序步驟，重排序器可能將正確片段的得分評為低於不相關片段。檢查重排序前的結果，看正確片段是否最初被檢索到但隨後被降級。

診斷 LLM 幻覺

當上下文正確但 LLM 輸出錯誤時，調查以下因素。

上下文視窗溢出： 如果檢索到的上下文很長，LLM 可能會遺漏上下文中間部分的資訊。這就是「迷失在中間」現象。嘗試將相關片段放在上下文的最前面，看答案是否改善。

矛盾的上下文： 如果多個檢索到的片段包含不同或矛盾的資訊，LLM 可能會錯誤地合併它們或選擇錯誤的那個。檢查檢索到的片段之間是否一致。

Prompt 指令衝突： 系統 prompt 可能包含與忠實使用上下文相衝突的指令。諸如「盡量有幫助並提供全面的答案」之類的指令可能會鼓勵 LLM 用其參數化知識來補充上下文，從而導致編造。

模型能力限制： 一些模型在忠實的上下文錨定方面比其他模型更好。如果在 prompt 最佳化後幻覺仍然存在，考慮切換到具有更強指令遵循和上下文錨定能力的模型。

修復正確的問題

一旦你診斷出了根因，就應用有針對性的修復。

針對檢索失敗：

重新索引缺失的文件
調整分塊大小和重疊
切換到適合領域的嵌入模型
放寬過於嚴格的中繼資料篩選器
添加查詢擴展或混合搜尋（關鍵詞加語義）
實施重排序步驟或調優現有的

針對 LLM 幻覺：

添加明確的錨定指令：「僅使用提供的上下文中的資訊」
要求行內引用：強制 LLM 引用特定片段
使用結構化輸出格式來約束回應
減少上下文長度以避免「迷失在中間」效應
實施生成後驗證：將回應中的陳述與來源上下文進行核對
降低 temperature 以減少回應變異數

Ertas 的定位

這整個診斷框架的基本前提是可觀測性。你需要看到檢索到的上下文，而不僅僅是最終答案。你需要追蹤查詢通過檢索流水線的路徑——從嵌入到向量搜尋到重排序到上下文組裝——並查看每個階段發生了什麼。

Ertas Data Suite 將 RAG 檢索流水線建構為畫布上的視覺化、基於節點的工作流。流水線中的每個節點——Query Embedder、Vector Search、Context Assembler、API Response——都是可獨立觀測的。當一個查詢產生了錯誤結果時，你可以檢查每個節點的輸出，準確地看到流水線在哪裡失敗了：嵌入是否擷取了查詢意圖？向量搜尋是否返回了正確的片段？上下文組裝器是否正確地格式化了它們？

這就是「RAG 系統給出了錯誤答案」（死胡同）和「向量搜尋返回了 5 個片段，沒有一個來自正確的文件，因為中繼資料篩選器排除了一月之後上傳的文件」（可操作的診斷）之間的區別。可觀測的流水線將除錯從猜測變為工程。

關鍵要點

RAG 系統的錯誤輸出不是一個單一的問題。它要麼是檢索失敗（LLM 從未獲得正確的上下文），要麼是幻覺（LLM 擁有正確的上下文但沒有忠實地使用它）。診斷過程從檢查檢索到的上下文開始——一切都從那裡展開。

建構你的 RAG 系統時，將可觀測性作為一等要求，而不是事後補充。記錄每個查詢的檢索上下文。維護帶有已知正確答案的測試查詢。當出現問題時，先診斷再修復——花五分鐘確認根因將節省數天調優錯誤元件的時間。