RAG / 系統整合

答案正確,還不夠:RAG 的來源驗收

一次多入口整合的漏接,讓我重新定義 RAG 的驗收:除了答案,也要檢查實際來源、授權範圍與原始證據。

實作紀錄期間:2026-10-01

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

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

看起來答對,為什麼仍然失敗?

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

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

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

我怎麼把問題查清楚

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

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

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

把來源寫進 Golden Case

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

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

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

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

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

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

這次經驗的適用範圍

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

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

延伸閱讀:RAG 變快了多少?先說清楚量的是哪一段。