ProvenanceGuard：为MCP代理构建源认知验证层

ProvenanceGuard：为 MCP 代理构建源认知验证层

随着大型语言模型（LLM）代理从单一检索增强生成（RAG）转向通过 Model Context Protocol (MCP) 调用多工具环境，事实核查的复杂性显著增加。代理现在能够整合搜索工具、结构化记录、数据库查询及元数据等多源信息。然而，现有的验证系统如 RAGAS faithfulness、MiniCheck、AlignScore 和 SummaC 主要关注声明是否得到“汇总证据”的支持，却往往忽略了来源归因的准确性。

Multiverse Computing 团队近期发布的论文《ProvenanceGuard:基于 MCP 的 LLM 代理人源认真事实验证》指出了一种名为“交叉来源混淆”的失败模式：即事实本身存在于证据池中，但被错误地归因于某个特定来源。传统的源盲验证器可能允许此类答案通过，因为事实确实存在；而具备源感知能力的验证器则应将其拦截。

核心问题：支持不等于正确归因

在数据敏感场景中，错误的归因可能与错误的事实同样有害。例如，客户服务代理回答“根据账户记录，该计划包含 30 天退款窗口”，若该政策实际源自政策文件而非账户记录，尽管事实准确，但归因错误。类似情况也出现在医疗领域，患者特定的药物细节可能被误引自医学文献而非患者病史工具。

上图展示了源盲评分与 ProvenanceGuard 的区别：前者仅检查综合证据是否支持声明，后者则单独验证支持来源是否与答案中明确或暗示的来源一致。

ProvenanceGuard 的工作机制

ProvenanceGuard 作为一个后置验证层，运行在黑盒 MCP 代理之上，无需重新训练代理即可工作。它读取捕获的 MCP 痕迹（包括工具输出及其源 ID），并通过以下五个步骤处理答案：

1. 将答案分解为具体的独立声明。
2. 找到与每个声明最相关的来源。
3. 检查该来源是否实际支持该声明。
4. 将该来源与答案命名或暗示的来源进行比对。
5. 发布每项声明的来源判决及全局答案级别的允许或阻止决定。

该流程保留了源标识，避免了证据聚合带来的匿名化问题。对于被阻止的答案，系统可结合 RARR 式修复步骤尝试基于源的修改或提供安全备用方案，随后再次验证。

在技术实现上，研究团队使用了本地模型组合以确保证据处理的受控性：MiniLM 用于定位相关来源，DeBERTa NLI 用于验证支持关系，本地语言模型辅助声明分解。验证过程还严格检查字面值（数字、日期、标识符），防止仅凭语义合理性通过验证。这种保守策略适用于对数据敏感度要求高于响应速度的场景。

实验结果与性能评估

研究团队在医疗代理场景下进行了测试，涉及患者记录、研究文章等多种工具，共收集了 281 个真实痕迹。人类专家对其中 40 个答案中的 361 个声明进行了审查。

结果显示，专家判定 139 个声明不应通过，ProvenanceGuard 成功识别了其中的 138 个，仅漏过 1 个。此外，系统将 67 个被认为已获支持的声明提交至进一步审查或修复，体现了其谨慎的设计倾向。对于具有可识别来源的声明，ProvenanceGuard 在约 86% 的情况下选择了正确的来源。

在上述基准测试中，ProvenanceGuard 在封锁决策上的 F1 分数最高，且是唯一能提供每个声明具体来源裁决的系统。

挑战与局限性

在针对多个相似来源的更严格测试中，ProvenanceGuard 获得了 0.846 的 F1 分数来决定是否阻止声明，但在精确识别确切来源方面的准确率降至 50.3%。这表明区分高度相似的来源仍是需要改进的关键领域。

然而，在专门针对错误归因的控制测试中（50 个案例交换来源），ProvenanceGuard 成功检测出了所有 50 个明显的源错误。

修复循环与应用前景

为了提升实用性，ProvenanceGuard 集成了修复循环。在完整追踪运行中，系统解决了所有 173 个被阻止的答案，其中 144 个通过备用文本结束，以避免生成无法验证的内容。在多源测试轨道上，新的修复运行解决了所有 59 个最初被阻止的答案，仅有两个终端回退。作为离线网关，其开销较小，在报告的本地配置中每次响应耗时约半秒，NLI 和路由调用仅需几十毫秒。

该方法已在 NVIDIA NVFlow 中得到应用，为其财务代理合并了可选的接地验证阶段，检查完成的答案与 SEC 摘录的一致性，同时保留单独的决策记录而不改变原始部署。

目前，ProvenanceGuard 的技术细节已在 Hugging Face 和 arXiv 公开，并在 2026 年加州大学伯克利分校举行的 Agentic AI 峰会上作为海报展示。