📰 重點摘要
ProvenanceGuard 論文提出一種名為「來源感知事實驗證」(Source-Aware Factuality Verification)的方法,專門解決基於 MCP(Model Context Protocol)架構的大型語言模型代理人在引用資料來源時常見的錯誤,稱為「跨來源混淆」(cross-source conflation)。這種錯誤指的是:某個說法在證據池中確實存在且為真,但代理人卻把它歸因到錯誤的來源工具上。傳統的「來源盲」(source-blind)驗證方法只檢查該說法是否能在整個證據池中找到支持,只要存在就判定通過,因此無法抓出這類歸因錯誤。論文舉例說明,客服代理人若回答「根據帳戶紀錄,此方案享有30天退款期」,但這項退款規則其實寫在政策文件裡而非帳戶紀錄中,若把兩個來源的證據混在一起看待,這個說法會被誤判為有憑有據;但若分開檢視,就能發現歸因錯誤。在醫療場景中,類似狀況會讓病患個人用藥紀錄被誤引用成醫學文獻中的研究發現,可能造成誤導。ProvenanceGuard 是一套在代理人產生答案後才介入的驗證層,不需要重新訓練模型,直接讀取被記錄下來的 MCP 追蹤紀錄(包含工具輸出與各自的來源 ID)。其運作流程依序為五步驟:將答案拆解為具體主張、為每個主張找出最相關的來源、檢查該來源是否真的支持此主張、比對此來源與答案中明示或暗示的來源是否一致,最後產出「逐條主張的來源判定」以及整體答案層級的「允許/封鎖」決策。若答案被封鎖,還可透過 RARR 風格的修復機制重新生成並再次驗證。詳細實驗設計與資料請見原文連結。
💬 JudyAI Lab 觀點
ProvenanceGuard指出的問題很直觀:AI代理人查資料時,答案本身可能是對的,但引用來源卻可能牽錯了物件,這種錯誤在人工檢查中特別容易被忽略。
這對AI builder群體的啟發在於,驗證機制的設計思維需要更精細。過去「來源盲」的驗證方式只確認某個說法能否在整體證據池中找到支援,卻沒有檢查說法跟它「聲稱的來源」是否真的對得上號,這在MCP架構下多工具、多來源並行運作時特別危險。ProvenanceGuard採用答案產生後才介入的驗證層,把答案拆解成具體主張、逐一比對來源,不需要重新訓練模型就能補上這個漏洞,這種「事後稽核」而非「訓練時修正」的設計思路,值得在建構任何多來源代理人系統時參考。
若你的系統會整合多個資料來源作答,建議檢查目前的驗證邏輯是否只看「有沒有支援」,而漏了「支援的是不是同一個來源」。
📅 原文資訊
- 發布時間:2026-09-29T13:07
- 來源原文:https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source