使用工具的 LLM 代理不再僅從單一檢索段落中讀取資訊。透過模型上下文協定（Model Context Protocol, MCP），代理可以呼叫搜尋工具、檢查結構化的病患或帳戶記錄、查詢資料庫並提取中繼資料，然後將所有這些資訊整合到一個答案中。這使得常見的事實性問題變得比表面上更為複雜。

大多數用於檢查 LLM 答案的系統，從 RAGAS 的忠實度到 MiniCheck、AlignScore 和 SummaC 等細粒度檢查器，都只在證據匯集後，詢問某個聲明是否得到現有證據的支持。它們通常不會指出哪個 MCP 工具輸出支持了每個聲明，也無法判斷這是否就是答案所提及的來源。

我們最新的論文《ProvenanceGuard：針對基於 MCP 的 LLM 代理的來源感知事實性驗證》（可在 Hugging Face 或 arXiv 上閱讀），旨在解決這個問題。我們關注的失敗模式稱為「跨來源混淆」：即聲明在證據中某處是真實的，但卻歸因於錯誤的來源。

來源盲驗證器可能會通過這種情況，因為事實確實存在於證據池中。然而，一個來源感知驗證器則不應如此。

問題：得到某處支持，不等於得到正確來源的支持

想像一個客服代理回答：「根據帳戶記錄，此方案包含 30 天退款期。」退款期可能是真實存在的，但它可能記載於政策文件中，而非答案所指的帳戶記錄中。如果將兩者混為一談，該聲明似乎得到了支持。

但若將它們分開，歸因就是錯誤的；在資料敏感的環境中，錯誤的歸因可能與錯誤的事實一樣具有破壞性。同樣的模式也出現在臨床代理中，當從病患病史工具中獲取的特定藥物細節，被答案呈現為醫學文獻中的發現時，就會產生誤導。

一個聲明可能由某個 MCP 來源支持，但答案卻將其歸因於另一個來源。來源盲評分器會在匯集的證據中看到支持並通過它；ProvenanceGuard 則會單獨檢查支持來源是否與答案所陳述或暗示的來源相符。來源：論文圖 1。

這就是為什麼忠實度分數儘管有用，但對於 MCP 代理來說仍不足夠。答案帶有出處，有時是明確的（例如「根據帳戶記錄」），有時則是隱含的。ProvenanceGuard 保留了聲明與來源之間的這種連結，以便進行檢查。

ProvenanceGuard 的運作方式

ProvenanceGuard 是一個生成後驗證層，位於黑箱 MCP 代理之上。它在代理產生答案後運行，從不將證據合併為一個匿名上下文。相反地，它將來源身份貫穿整個驗證流程。

它讀取捕獲的 MCP 追蹤，包括工具輸出及其來源 ID，而無需重新訓練代理。然後它依序執行五個步驟：將答案分解為具體聲明、找到與每個聲明最相關的來源、檢查該來源是否實際支持該聲明、將該來源與答案所提及或暗示的來源進行比較，最後發出每個聲明的來源判斷以及一個全局的、答案層級的允許或阻止決定。

驗證流程。來源身份透過分解、路由、支持度評分、歸因檢查和修復等步驟得以保留，而非被匯集。被阻止的答案可以透過 RARR 風格的修復並重新驗證。來源：論文圖 2。

有幾個設計選擇值得一提。在我們論文的實驗中，我們使用了本地模型，以便在受控的離線環境中處理捕獲的追蹤：MiniLM 協助找到相關來源，DeBERTa NLI 驗證模型檢查該來源是否支持聲明，而本地語言模型則協助將答案分解為聲明。

驗證器還會仔細檢查字面值：來源中不存在的數字、日期或識別符號不能僅因為句子聽起來合理就通過。一個經過校準的決策步驟會結合這些訊號。如果答案被阻止，RARR 風格的修復步驟可以嘗試基於來源的修訂或安全回退，然後驗證器會再次檢查。

這些提及的模型是我們評估的設定，並非 ProvenanceGuard 的必要條件。相同的聲明、來源和決策步驟可以應用於團隊偏好雲端服務的託管模型；新的設定將需要自己的測試和校準。

我們報告的結果來自本地配置。其保守的決策策略適用於資料敏感的審查，在這種情況下，確保來源正確比產生最快答案更為重要。

實驗結果

我們使用一個醫療代理的答案測試了 ProvenanceGuard，該代理使用了病患記錄、研究文章和其他工具。這提供了 281 個真實追蹤供我們研究。醫學是一個有用的測試領域，因為來自病患記錄的事實與來自一般研究的事實不能被視為相同的來源。

當代理保留其工具輸出和來源 ID 的記錄時，該方法也可用於其他領域。在主要測試中，人類專家檢查了從用於開發系統的資料中抽取的 40 個答案中的 361 個聲明。

最直接的結果是：專家認為 139 個聲明不應通過，而 ProvenanceGuard 捕獲了其中 138 個，僅放過一個。它還攔截了 67 個專家認為有支持的聲明，將它們送去審查或修復。

這反映了我們測試的謹慎設定：它傾向於對一些有支持的聲明進行二次檢查，而不是讓無支持的聲明通過。對於具有可識別來源的聲明，它在本次測試中約有 86% 的時間選對了正確的來源。

我們在相同的聲明上運行了其他四個支持檢查器。ProvenanceGuard 在論文衡量系統捕捉應被阻止的聲明同時避免不必要阻止的指標上得分最高。

在這次比較中，其他檢查器沒有告訴我們哪個工具輸出支持了每個聲明。ProvenanceGuard 記錄了這種連結，因此審查者可以看到每個聲明所檢查的來源及其產生的決定。

驗證器、拒絕/阻止 F1 分數、是否發出聲明到來源 ID

ProvenanceGuard (我們開發的)、0.802、是

MiniCheck、0.783、否

RAGAS Faithfulness、0.758、否

AlignScore、0.662、否

SummaC-ZS、0.436、否

在相同的保留聲明包上的二元支持指標。ProvenanceGuard 在阻止方面與來源盲基準持平或超越，同時也產生了每個聲明的來源判斷。來源：論文摘要和表 III。

當來源相似時檢查聲明

在一個單獨的、更困難的測試中，面對幾個相似的來源，ProvenanceGuard 在決定阻止哪些聲明方面獲得了 0.846 的 F1 分數，但在 50.3% 的聲明中正確識別了確切來源。區分相似來源仍然是重要的改進領域。

我們還進行了一項針對錯誤歸因的受控測試：在 50 個案例中，我們更改了指定的來源，同時保持支持證據不變。ProvenanceGuard 捕獲了所有 50 個錯誤歸因。

這表明它能夠檢測到明確的來源錯誤，而較困難的測試則顯示了在眾多看似合理的來源中進行選擇的挑戰。

修復被阻止的答案

阻止答案只有在能夠對其進行處理時才有意義。連接到 RARR 風格的修復迴圈後，完整追蹤運行解決了所有 173 個被阻止的答案，儘管其中 144 個以回退文本而非實質性重寫告終。這表示系統選擇避免提供無法驗證的答案，而不是憑空捏造。

在重建的多來源測試追蹤上，一次新的修復運行解決了所有 59 個最初被阻止的答案，僅有兩個最終回退。作為離線閘道，其開銷適中，在報告的本地配置中，每個答案大約需要半秒，而 NLI 和路由呼叫本身僅需數十毫秒。

為何這符合 Multiverse Computing

隨著代理從單一通道 RAG 轉向多工具 MCP 設定，一個事實究竟來自哪個來源的問題不再是附註，而是構成事實性意義的一部分。ProvenanceGuard 讓這種來源連結逐聲明地可見。

對於 Multiverse Computing 而言，這意味著一種在需要時，於受控環境中檢查現有代理並保留敏感追蹤的方法。醫療研究是一個應用案例；只要代理的追蹤保留其工具和來源，同樣的方法就可以適用於其他領域。

這種適應性已在 NVIDIA NVFlow 中體現，它為其金融代理整合了一個可選的基礎驗證階段。它根據代理檢索到的 SEC 摘錄檢查完成的答案，並保存獨立的決策，而無需更改原始部署或訓練資料。

NVFlow 的貢獻採用了 ProvenanceGuard 的來源感知驗證方法；上面討論的修復迴圈則屬於更廣泛的研究系統。

ProvenanceGuard 也曾在加州大學柏克萊分校舉行的 2026 年 Agentic AI 峰會上以海報形式發表。

想了解完整的技術細節，包括路由和 NLI 推導、校準消融實驗、多來源壓力測試切片以及完整的結果表格嗎？請在 Hugging Face 上閱讀完整論文，或聯繫我們的團隊，討論如何將來源感知驗證應用於您的代理。