Getting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents

正确引用来源，而不仅仅是事实：面向MCP代理的源感知验证

返回文章列表

[0

团队

]

文章

2026年9月29日发布

[-1

点赞

16

[

• +10

Antonio Tiene

AntonioTN

关注

MultiverseComputingCAI

Ander Alvarez Sanz

ander-alvarez

Oliver Wirjadi

oliverwirjadi

Alessandro Genuardi

AlexDGenu

使用工具的LLM代理不再仅依赖单一检索段落。通过模型上下文协议（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在决定拦截哪些主张时F1得分为0.846，但仅在50.3%的主张中正确识别了具体来源。区分相似来源仍然是重要的改进方向。

我们还进行了针对错误归因的受控测试：在50个案例中修改了命名来源，同时保留支持证据。ProvenanceGuard成功检测到所有50次修改。这表明其能够识别明确的来源错误，而更复杂的测试则展示了在众多合理来源中选择的挑战性。

修复被拦截的回答

拦截只有在能对被拦截回答进行处理时才有价值。通过与RARR风格的修复循环集成，完整追踪运行解决了所有173个被拦截回答，尽管其中144个最终采用了后备文本而非实质性重写，这表明系统选择避免不可验证的回答而非制造虚假回答。在重建的多来源测试追踪中，新的修复运行仅用两次终端后备文本就解决了所有59个初始被拦截回答。作为离线网关，其开销较小，在报告的本地配置中每个回答约需0.5秒，NLI和路由调用本身仅需几十毫秒。

为什么这适合Multiverse Computing

当代理从单段落RAG转向多工具MCP架构时，事实实际来源的判定问题不再只是附注，而是事实性的核心组成部分。ProvenanceGuard通过逐条主张展示来源关联，使这一问题变得可视化。对Multiverse Computing而言，这意味着可以检查现有代理，同时在需要时在受控环境中保留敏感追踪。医学研究是一个应用场景；相同方法可适应任何代理追踪保留其工具和来源的场景。

这种适配已在NVIDIA NVFlow中体现，其为金融代理集成了可选的接地验证阶段。它将代理生成的回答与从SEC获取的摘录进行比对，并保存独立决策而不改变原始运行或训练数据。NVFlow的贡献采用了ProvenanceGuard的来源感知验证方法；上述修复循环属于更广泛的研究系统。

ProvenanceGuard也作为海报在加州大学伯克利分校举办的Agentic AI Summit 2026上展示。

想要完整的技术细节，包括路由和NLI推导、校准消融实验、多源压力切片以及完整的结果表格？请阅读Hugging Face上的完整论文，或联系我们的团队讨论如何将源感知验证应用到您的代理系统中。

本文提到的模型 2

本文提到的论文 1

更多该作者的文章

像物理学家一样修剪LLM：块移除作为Ising优化问题

33

2026年9月21日

为了谁的安全？拒绝主题的正确子集，而非整个主题

31

2026年9月8日

社区

Nomad-link-id

2天前

[1

[2

对MCP代理而言，关键的故障模式比“幻觉”更隐蔽：某个事实出现在聚合工具输出中，但被错误归因于其他来源。

在这种情况下，源盲保真度仍可能显示为绿色——该事实确实存在于结果中。源感知验证是功能升级：在声明分解、支持检查和归因检查过程中保留工具/源ID，然后通过逐声明的源判定结果进行允许或阻止，这些判定结果可供审查者实际检查。

对部署MCP的团队的实际建议：当您的评估显示“有依据”时，这是否意味着由任意工具输出支持，还是由答案中明确命名的源支持？这两种情况对应不同的发布门禁。在多工具设置中，第二种方式能在人类信任引用前捕捉跨源混淆问题。

查看翻译

• 1 条回复

·

文章作者

您好，感谢您的评论。您准确抓住了问题核心。对于ProvenanceGuard来说，当声明被标记为“有依据”时，意味着它确实由答案中明确命名或暗示的源支持。仅在其他工具输出中找到该事实是不够的。以退款窗口示例，政策确实支持该事实，但答案却归因于账户记录，因此我们会标记这种不匹配并展示源判定结果。

mghwaz

•

2天前编辑

我简要阅读了论文，但没有发现与更便宜的LLM代理进行源感知判断的对比。这是我目前对论文的理解：

• LLM调用多个工具并使用其输出生成答案，答案中可能包含多个声明
• 某个声明可能由一个或多个工具输出支持，但被错误归因于其他来源
• 基本上将答案拆分为声明，并使用嵌入向量为每个声明找到可能的支持源
• 使用NLI和随机森林检查选定源是否支持声明
• 同时检查响应中声明是否被正确归因

看起来（2-5）步骤如果拥有执行代理，可以通过基础提示在生命周期中完成。如果没有，也可以通过Harness中的钩子作为插件实现。您对此有任何对比数据吗？本质上，这些随机森林和工程实现的投入成本，与对轨迹+答案进行第二次LLM调用相比如何？

• 2 条回复

然而，我们部分动机源于引入LLM裁判本身可能导致不一致的裁决或混淆来源（这正是我们试图捕捉的错误类型）。因此，第二次LLM调用可能引入新的错误。ProvenanceGuard通过显式来源追踪和校准支持检查，减少对另一项生成判断的依赖。您建议的比较确实是一项有用的进一步研究，可用于量化准确率、延迟和成本方面的收益。

展开1条回复

编辑

预览

通过拖拽、粘贴或点击此处上传图片、音频和视频

点击此处上传图片

评论

· 注册或登录以发表评论

• +4