ProvenanceGuard：面向 MCP 代理的来源感知事实性核查

把握正确的来源，而不仅是事实：面向 MCP 智能体的来源感知验证

智能体可以调用搜索工具，检查结构化的患者或账户记录，查数据库，拉元数据，然后把这些东西织成一个回答。这让通常意义上的「事实性」问题比表面看起来更微妙。从 RAGAS faithfulness（忠实度）到 MiniCheck、AlignScore、SummaC 这些细粒度核查器，大多数检验大语言模型回答的系统都问同一个问题。证据汇集到一起之后，一条陈述能不能被可用证据支撑？这些系统在通常形态下既不会告诉我们是哪一份 MCP（Model Context Protocol，模型上下文协议）工具输出支撑了某条陈述，也不会告诉我们那份输出是不是回答所声称的来源。

我们最新的论文 *ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents*（ProvenanceGuard：面向基于 MCP 的大语言模型智能体的来源感知事实性验证）正瞄准这一缺口。论文可在 Hugging Face 或预印本 arXiv 上阅读。我们关心的失败模式有个名字，叫 cross-source conflation（跨来源混淆）。它指的是，一条陈述在证据里确实为真，却归因到了错误的来源。来源盲（source-blind）的核查器可能放它通过，因为事实确实存在于证据池里。来源感知（source-aware）的核查器则不应放行。

问题：得到某处支持，不等于得到正确来源的支持

试想一个客服智能体这样回答：「根据账户记录，本套餐包含 30 天退款窗口。」退款窗口本身完全真实，但出现在政策文档里，而不是回答所指向的账户记录中。把两份证据汇集起来看，这条陈述看似得到了支撑。分开来看，归因便是错的。在数据敏感的场景下，错误的归因和错误的事实一样有破坏性。同样的模式也出现在临床智能体里。患者特异性用药细节从患者历史工具里来，回答一旦把它说成医学文献的发现，就成了误导。

一条陈述可能由一个 MCP 来源支撑，但回答却把它归因到另一个来源。来源盲的评分在汇集后的证据中看到支撑便放行。ProvenanceGuard 则单独检查支撑来源是不是回答陈述或暗示的那个。来源：论文图 1。

faithfulness 评分虽然有用，但放到 MCP 智能体身上就不够了。回答里承载着 provenance（来源归属），有时显式（「根据账户记录」），有时隐式。ProvenanceGuard 把陈述与来源之间的连接保留下来，方便审查。

ProvenanceGuard 的工作方式

ProvenanceGuard 是一层 post-generation（后生成）验证层，架在黑盒 MCP 智能体上面。它在智能体产出回答之后运行，从不把证据合并成单一的匿名上下文，而是把来源标识一路带下去。它读取捕获到的 MCP trace（追踪记录），包括工具输出及其来源 ID，无需重新训练智能体。然后按顺序做五件事。先把回答拆成具体陈述，再为每条陈述找到最相关的来源，然后核查该来源是否真的支撑它，接着把这一来源和回答所陈述或暗示的来源做比对，最后给出每条陈述的来源 verdict（判定），以及 answer-level（回答级）的整体放行或拦截决策。

验证流程。来源标识贯穿分解、路由、支持打分、归因核查与修复各环节，不会被合并。被拦截的回答可以走 RARR 风格的修复环节，再次被验证。来源：论文图 2。

几处设计选择值得说说。论文实验里，我们用本地模型，方便在可控的离线环境里处理捕获到的追踪记录。MiniLM 用来定位相关来源，基于 DeBERTa 的 NLI（Natural Language Inference，自然语言推理）核查模型判断来源是否支撑该陈述，本地语言模型帮忙把回答拆成陈述。核查器还会严格比对字面值。源里没有的数字、日期或标识符，不能仅凭句子听起来合理就放行。校准后的决策步骤把这些信号合在一起。回答被拦截后，RARR 风格的修复步骤会尝试基于来源的改写或安全兜底，核查器再检查一遍。

上述模型是评估时用的，并非 ProvenanceGuard 的硬性要求。同样的「陈述—来源—决策」流程可以换成团队更偏好的云端托管模型，不过新配置得单独测试和校准。我们报告的结果来自本地配置。它偏保守的决策策略适合数据敏感场景，比起尽快给出回答，把来源做对更重要。

结果

我们在某个医疗智能体的回答上测试 ProvenanceGuard。这个智能体用过患者记录、研究论文等工具，我们由此拿到 281 条真实追踪记录。医疗是很好的测试场景，因为患者记录里的事实和一般研究里的事实不能当作同一个来源。该方法也能用在其他领域，只要智能体保留其工具输出与来源 ID 的记录。主测试里，人类专家检查了 361 条陈述，来自 40 个回答。这些回答都是从开发系统的数据里预留出来的。

最直接的结果是这样的。专家认为不应放行的 139 条陈述里，ProvenanceGuard 拦下了 138 条，放过了 1 条。它还把 67 条专家判定为有支撑的陈述保留下来，送去复核或修复。这反映的是测试里的偏保守设定，宁可对部分本可放行的陈述多看一眼，也不让无支撑的陈述漏过。对于具有可识别来源的陈述，它在这项测试里正确选择来源的概率约为 86%。

我们在同样的陈述上跑了另外四个支撑度核查器做对比。ProvenanceGuard 在论文衡量「系统能在避免不必要拦截的同时尽量拦截应拦截陈述」的指标上得分最高。参与对比的其他核查器没法告诉我们每条陈述由哪一份工具输出支撑。ProvenanceGuard 记下了这个连接，审查者能看到每条陈述核查过的来源以及产生的决策。

| 核查器 | Reject/block F1 | 是否输出 claim-to-source 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 条以 fallback text（兜底文本）收尾，没做实质性改写。这是系统在选择避免给出不可验证的回答，而不是硬编一个。在重建的多来源测试追踪上，一轮新的修复运行处理完了全部 59 条最初被拦截的回答，仅 2 条以兜底收尾。作为离线闸门，它的开销不大。报告的本地配置下，每条回答约半秒，其中 NLI 和路由调用本身在数十毫秒量级。

与 Multiverse Computing 的契合之处

智能体从单文档 RAG（Retrieval-Augmented Generation，检索增强生成）走向多工具 MCP 架构，「某条事实究竟来自哪个来源」已不再是注脚，而是「事实性」含义本身的一部分。ProvenanceGuard 让这条来源连接逐条陈述地可见。对 Multiverse Computing 来说，这等于拿到了一种方式，可以在需要时把敏感追踪记录保留在受控环境里，对现有智能体进行核查。医疗研究是一个用例。只要智能体的追踪记录保留了其工具与来源，同一方法便能适配其他场景。

这种适配已在 NVIDIA NVFlow 里落地，它为金融智能体合入了一个可选的 grounding-verification 阶段。它把完成的回答与智能体检索到的 SEC（U.S. Securities and Exchange Commission，美国证券交易委员会）摘录做核对，单独存下决策，不动原始 rollout 或训练数据。NVFlow 的贡献采用了 ProvenanceGuard 的来源感知验证方法。上文讨论的修复回路则属于更广的研究系统。

ProvenanceGuard 还以海报形式在 UC Berkeley 举办的 Agentic AI Summit 2026 上展示过。

想看完整的技术细节，包括路由与 NLI 的推导、校准消融实验、多来源压力切片以及完整的结果表格，请阅读全文