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

来源：https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source

工具使用型LLM智能体现在不再仅从单个检索段落中读取信息。通过模型上下文协议（MCP）(https://modelcontextprotocol.io/)，智能体可以调用搜索工具、检查结构化的患者或账户记录、查询数据库并提取元数据，然后将所有这些信息编织成一个答案。这使得通常的事实性问题变得比表面看起来更加微妙。大多数用于检查LLM答案的系统，从RAGAS忠实度(https://github.com/explodinggradients/ragas)到MiniCheck、AlignScore和SummaC等细粒度检查器，都在证据汇集后询问某个主张是否得到可用证据的支持。在其常规形式中，它们不会告诉我们哪个MCP工具输出支持每个主张，或者该来源是否是答案中指明的来源。

我们的最新论文 ProvenanceGuard: 面向基于MCP的LLM智能体的源感知事实验证（可在此处阅读：Hugging Face (https://huggingface.co/blog/MultiverseComputingCAI/%5BHF-PAPER-LINK%5D)，或arXiv (https://arxiv.org/abs/2606.18037)）正是针对这一缺口。我们关注的失败模式是我们称之为“跨来源混淆”的情况：一个主张在证据的某处是真实的，但却被归因于错误的来源。一个来源盲的验证器可能会通过它，因为该事实在证据池中确实存在。而一个源感知的验证器则不应如此。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#the-problem-supported-somewhere-is-not-the-same-as-supported-by-the-right-source问题：在某处得到支持，不等于得到了正确来源的支持

考虑一个客服智能体回答：“根据账户记录，此计划包含30天退款窗口。” 退款窗口可能完全真实，但它陈述在一份政策文档中，而不是答案指向的账户记录中。将两者汇集在一起，该主张看起来是得到支持的。将它们分开来看，归因就是错误的。在数据敏感的场景中，错误的归因可能与错误的事实一样有害。相同的模式也出现在临床智能体中，一个从患者历史工具中提取的、针对特定患者的药物细节，一旦答案将其呈现为医学文献中的发现，就会产生误导。

图表对比了来源盲的汇集支持与源感知验证，使用了一个退款窗口主张，该主张由政策文档支持但被归因于账户记录。(https://cdn-uploads.huggingface.co/production/uploads/668e37fd9c9aa124a3c867e8/svnUpzhFgTpLqOF_bRDHl.png)

一个主张可以由一个MCP来源支持，而答案却将其归因于另一个来源。来源盲的评分在汇集证据中看到支持并放行；ProvenanceGuard则单独检查支持来源是否与答案陈述或暗示的来源匹配。来源：论文图1。

这就是为什么忠实度评分虽然有用，但对于MCP智能体来说还不够。一个答案承载着来源信息，有时是明确的（“根据账户记录”），有时是隐含的。ProvenanceGuard保持了主张与来源之间的这种连接，使其可供检查。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#what-provenanceguard-doesProvenanceGuard的功能

ProvenanceGuard是一个后生成验证层，位于黑盒MCP智能体之上。它在智能体产生答案后运行，并且从不将证据合并为一个匿名的上下文。相反，它在整个管道中保留来源标识。它读取捕获的MCP跟踪记录，包括工具输出及其来源ID，而无需重新训练智能体。然后它按顺序执行五件事：将答案分解为具体主张、为每个主张找到最相关的来源、检查该来源是否实际支持该主张、将来源与答案命名或暗示的来源进行比较，最后发出每个主张的来源判定以及全局的、答案级别的允许或阻止决策。

流程图显示智能体产生草稿答案和跟踪记录，然后ProvenanceGuard分解主张、路由到来源、通过NLI检查支持、校准、检查归因，并允许答案或将其发送进行修复。(https://cdn-uploads.huggingface.co/production/uploads/668e37fd9c9aa124a3c867e8/nDchWzRhBSmscjaa8w5G5.png)

验证流程。来源标识在分解、路由、支持评分、归因检查和修复过程中被保留，而不是被汇集。被阻止的答案可以经过RARR风格的修复并重新验证。来源：论文图2。

一些设计选择值得指出。对于我们论文中的实验，我们使用了本地模型，以便捕获的跟踪记录可以在受控的离线设置中处理：MiniLM (https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2) 有助于找到相关来源，DeBERTa NLI验证器模型 (https://huggingface.co/MoritzLaurer/DeBERTa-v3-base-mnli-fever-anli) 检查该来源是否支持该主张，本地语言模型帮助将答案分解为主张。验证器还仔细检查字面值：一个数字、日期或标识符如果不在来源中，就不能仅仅因为句子听起来合理而通过。校准决策步骤将这些信号结合起来。如果答案被阻止，RARR (https://arxiv.org/abs/2210.08726) 风格的修复步骤可以尝试基于来源的修订或安全回退，然后验证器会再次检查。

这些命名的模型是我们评估的设置，而不是ProvenanceGuard的要求。相同的主张、来源和决策步骤可以适配到团队更喜欢云服务的托管模型；新的设置需要自己的测试和校准。我们报告的结果来自本地配置。其保守的决策策略适合数据敏感的审查场景，在这些场景中，确保来源正确比产生尽可能快的答案更重要。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#results结果

我们在一个使用过患者记录、研究文章和其他工具的医疗智能体的答案上测试了ProvenanceGuard。这给了我们281条真实的跟踪记录供研究。医学是一个有用的测试领域，因为来自患者记录的事实和来自一般研究的事实不能被视为相同的来源。当智能体保留其工具输出和来源ID的记录时，该方法也可以用于其他领域。在主要测试中，人类专家检查了从用于开发系统的数据中留出的40个答案中的361个主张。

最直接的结果是：专家表示139个主张不应通过，ProvenanceGuard捕捉到了138个。它放过了一个。它还阻止了67个专家认为得到支持的主张，将它们送去审查或修复。这反映了我们测试的保守设置：它宁愿对一些得到支持的主张进行二次检查，也不愿让未得到支持的主张通过。对于有可识别来源的主张，在此测试中，它也有大约86%的时间选择了正确的来源。

我们还对相同的主张运行了其他四种支持检查器。ProvenanceGuard在论文的衡量标准上得分最高，该标准衡量系统在阻止应被阻止的主张的同时避免不必要阻止的能力。此比较中的其他检查器没有告诉我们哪个工具输出支持每个主张。ProvenanceGuard记录了这种连接，因此审查员可以看到为每个主张检查的来源及其产生的决策。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#checking-claims-when-sources-look-similar当来源看起来相似时检查主张

在一个更困难的、涉及多个相似来源的独立测试中，ProvenanceGuard在决定阻止哪些主张时得分为0.846 F1，但在50.3%的主张中正确识别了确切来源。区分相似来源仍然是一个重要的改进领域。

我们还运行了一个专注于错误归因的受控测试：我们在50个案例中更改了命名的来源，同时保持支持证据完整。ProvenanceGuard捕捉到了所有50个交换。这表明它可以检测到明显的来源错误，而更困难的测试则表明在众多可能来源中进行选择的挑战。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#repairing-blocked-answers修复被阻止的答案

只有当对被阻止的答案有处理措施时，阻止才有用。通过连接到RARR风格的修复循环，完整的跟踪运行解决了所有173个被阻止的答案，尽管其中144个最终以回退文本结束，而不是实质性的重写，这是系统选择避免生成一个无法验证的答案，而不是制造一个答案。在重建的多来源测试跟踪中，一次新的修复运行解决了所有59个最初被阻止的答案，仅有两个最终回退。作为离线关卡，其开销很小，在报告的本地配置中大约每个答案半秒，而NLI和路由调用本身仅需几十毫秒。

https://huggingface.co/blog/MultiverseComputingCAI/getting-the-source-right-not-just-the-fact-source#why-this-fits-multiverse-computing为何适用于Multiverse Computing

随着智能体从单段落RAG转向多工具MCP设置，一个事实实际来自哪个来源的问题，不再是一个脚注，而成为事实性含义的一部分。ProvenanceGuard使这种来源连接逐主张可见。对于Multiverse Computing而言，这意味着一种在需要时保持敏感跟踪记录受控环境的同时检查现有智能体的方法。医疗研究是一个用例；相同的方法可以适配到任何智能体跟踪保留其工具和来源的地方。

这种适配已经在NVIDIA NVFlow (https://github.com/NVIDIA/nvflow/pull/9)中可见，该系统为其金融智能体合并了一个可选的基于来源的验证阶段。它根据智能体检索到的SEC摘录检查完成的答案，并在不改变原始生成或训练数据的情况下保存单独的决定。NVFlow的贡献使用了ProvenanceGuard的源感知验证方法；上文讨论的修复循环属于更广泛的研究系统。

ProvenanceGuard还在UC Berkeley的2026年智能体AI峰会上以海报形式展示(https://github.com/aalvsz/provenanceguard/blob/main/poster/ProvenanceGuard_Agentic_AI_Summit_2026_Berkeley.pdf)。

想要完整的技术细节，包括路由和NLI推导、校准消融、多来源压力切片以及完整的结果表格吗？请在Hugging Face (https://huggingface.co/papers/2606.18037)上阅读完整论文，或与我们团队联系，讨论将源感知验证应用于您自己的智能体。