# 答案正確，還不夠：RAG 的來源驗收

作者：Ian
發布：2026-10-06
更新：2026-10-06
實作紀錄期間：2026-10-01
正式網址：https://ianinfra.com/knowledge/rag-source-provenance/

在一次多來源 RAG 整合中，我遇到一個比「查不到」更難發現的問題：系統能回答問題，卻沒有查到我以為它查過的來源。

底層已接入筆記與議題追蹤系統，但其中一個 MCP 入口仍然只查筆記。因為筆記裡早已整理過議題內容，模型常常能產生看似正確的答案。這讓入口漏接的問題藏了下來。

## 看起來答對，為什麼仍然失敗？

原始議題與整理筆記，可能描述同一件事，卻有不同的更新時間與證據地位。整理筆記可能省略後續留言，也可能保留已被取代的決策。

如果問題明確要求查原始系統，而實際只命中轉述筆記，即使答案文字剛好相同，也不能算這條整合路徑通過驗收。更不能把原始資料與它的摘要，算成兩份獨立證據。

> 答案正確，與來源路由正確，是兩個需要分開驗收的維度。

## 我怎麼把問題查清楚

首先檢查入口回傳的搜尋範圍，再沿著路由追到實際來源。這次確認的是入口沒有走到既有的聯合檢索，而非原始資料未同步或索引不存在。

接上來源後，第一次回應是授權不足。這表示請求開始走到新的來源邊界，但還不能算讀取成功。完成對應授權後，再用來源類型與原始片段確認，才證明整條路徑真的接通。

這個過程讓我把驗證拆成三件事：路徑有沒有走到、權限有沒有允許、資料有沒有真的讀回來。

## 把來源寫進 Golden Case

我開始讓固定回歸案例同時描述「應該答什麼」與「應該從哪裡取得證據」。對需要原始來源的題目，至少檢查：

- 實際入口與檢索模式，是否符合這次查詢的目的。
- 命中的來源類型，是否包含指定的原始系統。
- 原始片段或留言，是否真的支持回答中的關鍵敘述。
- 只有整理筆記命中時，是否明確標示限制，而非假裝已讀取原始來源。
- 不同入口是否各自通過相同案例，而非共用一次後端測試結果。

例如同一題經由網頁、訊息入口與 MCP 查詢，就應保留各自的來源紀錄。底層服務同名，不代表每個入口都接到相同能力。

## 路由可以判斷失誤，但範圍不能失守

後續修正中，我把來源偏好與硬性限制分開。一般模糊問題可以在證據不足時，有限度補查另一個已授權來源；明確要求「只查這個來源」的問題，則要保留原範圍。

這裡的取捨是：讓路由先降低搜尋成本，再由證據決定是否足夠回答。同時限制補查次數，避免失敗後無限擴張搜尋，也不能跨越權限邊界。

## 這次經驗的適用範圍

這篇記錄的是一次入口整合與驗收方法的修正，不是所有入口、所有題目都已完成驗收的宣告。當時仍有入口待補跑固定案例，補查帶來的額外模型成本也尚未完整量化。

對我而言，最值得留下的做法是：當答案看起來合理，仍然要能回答「這一次，到底讀了哪份資料？」

延伸閱讀：[RAG 變快了多少？先說清楚量的是哪一段。](/knowledge/rag-latency-evidence/)