檢索增強系統給出的答案不理想時，模型可能是最後一個該被責怪的元件。原始資料也許根本沒有進入脈絡。
梳理 RAG 的故障鏈
典型的 RAG 流程會匯入文件、切分文字片段、新增後設資料、建立表示索引、檢索候選內容，再讓模型據此回答。各階段的失敗表現不同：匯入的資料過時、切分破壞語義、排序不佳、脈絡被截斷，或者生成內容缺乏依據。
保留一條將查詢、文件版本、檢索出的文字片段、分數、過濾條件、最終脈絡和回答關聯起來的執行軌跡。沒有這條鏈，看似合理的回答可能掩蓋故障檢索器，錯誤的回答也可能引發無意義的提示詞修改。
用已標註的問題衡量檢索效果
構建已知支援文件的問題。先衡量必需的來源是否出現在靠前的結果中；如果順序重要，再使用排序指標。Microsoft 的 RAG 評估器指南將文件檢索指標與檢索脈絡的文字品質判斷分開；這種區分很有用，因為相關性標籤能支援更精確的診斷。
把過濾規則和許可權作為一等測試物件。檢索器即使找到了相關文件，只要該文件未經授權，就算回答正確也屬於失敗。測試集中還應包含重複頁面、過時版本、表格，以及需要綜合多個文字片段證據的問題。
從相互獨立的維度判斷答案
依據充分性考察斷言是否侷限於提供的脈絡；相關性考察回答是否切中問題；完整性考察是否覆蓋關鍵的預期資訊。這些維度可能各自變化：謹慎的回答可能有據可依卻不完整，流暢的回答則可能相關卻缺乏支援。
在高影響場景中，為具體斷言附上引用，並核實每處引用確實支援相鄰的陳述。如果讀者無法判斷哪個段落支援哪個結論，只在文末列出來源還不夠。
測試邊界情況
提出語料庫無法回答的問題，要求系統明確說明侷限，而不是臨時編造回答。加入嵌入檢索文件的提示詞注入、相互衝突的版本、拼寫錯誤、不同表述以及時效性問題。評估系統是否識別來源的權威性與日期，而不是將每個文字片段一視同仁。
當使用者使用一種語言提問、語料庫使用另一種語言時，應按語言單獨測試。跨語言檢索可能在生成之前就失敗，而流暢的回答可能掩蓋這一遺漏。
將診斷結果轉化為改進
如果召回率低，檢查資料匯入、文字片段邊界、後設資料、嵌入表示和查詢改寫。如果檢索到的證據很好，但回答的依據充分性差，就調整生成約定和引用要求。如果回答有據可依卻不完整，則重新檢查脈絡組裝和多文件覆蓋情況。
用固定的測試集和新的保留測試集比較改動。這既避免針對熟悉的問題過度最佳化，也保留檢驗真實泛化能力的途徑。
如何付諸實踐
先選取一個與「RAG 評估：先測試檢索，再歸咎於模型」相關、邊界清晰的工作流程。改動系統之前，用一頁文件紀錄基線：目前的完成時間、品質檢查項、常見失敗類別、升級處理路徑和結果負責人。選取有代表性的樣本，而不是隻挑最乾淨的案例。納入普通案例、困難的邊緣案例，以及至少一個正確做法是停止或請求更多資訊的案例。
在允許候選方案取代現有流程前，先讓兩者並行執行。成功和失敗的輸出都要檢查，因為錯誤率下降仍可能掩蓋新的高影響失敗。紀錄每次測試使用的準確設定，並保留足以讓其他稽核人員復現結果的材料。試點結束時，依據事先商定的閾值決定擴大應用、修改方案還是停止，而不是事後憑一次最出色的演示作判斷。
向供應商或內部團隊提出的問題
詢問核心主張有哪些證據支撐、證據基於哪個系統版本和資料版本，以及排除了哪些條件。要求提供與你的部署場景相符的語言、輸入型別和風險類別的測試結果。詢問變更如何通知、迴歸問題如何發現，以及客戶如何匯出事故覆盤所需的紀錄。
還要問清：當置信度低、依賴項故障或請求超出支援範圍時，系統會如何處理。可靠的產品應有明確的失敗狀態，而不是僅僅給出更像樣的回答。責任歸屬同樣重要：明確誰能暫停流程、誰批准例外，以及重大錯誤流入正式環境後由誰通知受影響的使用者。
實用檢查清單
- 選擇模型或工具前，先明確使用者任務以及真正需要防範的失敗。
- 維護一個來自真實工作的、小規模且有版本紀錄的測試集，納入棘手案例和對抗性案例。
- 每次執行都紀錄模型、提示詞、工具、檢索設定、資料版本、延遲和成本。
- 不可逆、高影響或對外可見的操作必須經過人員確認。
- 按類別覆盤失敗，不要只看單一平均分，並將迴歸案例加入測試集。
Meydo Journal 延伸閱讀
原始資料
- 檢索增強生成評估器 — Microsoft Learn
