ProvenanceGuard: 基于MCP的LLM代理的源感知事实性验证

# ProvenanceGuard：面向MCP大语言模型智能体的源感知事实性验证

**来源：** https://arxiv.org/html/2606.18037

**作者：**  
Ander Alvarez<[email protected]> (https://arxiv.org/html/2606.18037v1/mailto:[email protected])  
Multiverse Computing, Parque Cientifico y Tecnológico de Gipuzkoa, Paseo de Miramón, 170, 20014 Donostia / San Sebastián, Spain  

Santhiya Rajan<[email protected]> (https://arxiv.org/html/2606.18037v1/mailto:[email protected])  
Multiverse Computing, Parque Cientifico y Tecnológico de Gipuzkoa, Paseo de Miramón, 170, 20014 Donostia / San Sebastián, Spain  

Samuel Mugel<[email protected]> (https://arxiv.org/html/2606.18037v1/mailto:[email protected])  
Multiverse Computing, Centre for Social Innovation, 192 Spadina Avenue Suite 509, Toronto, ON M5T 2C2, Canada  

Román Orús<[email protected]> (https://arxiv.org/html/2606.18037v1/mailto:[email protected])  
Multiverse Computing, Parque Cientifico y Tecnológico de Gipuzkoa, Paseo de Miramón, 170, 20014 Donostia / San Sebastián, Spain  
Donostia International Physics Center, Paseo Manuel de Lardizabal 4, E-20018 San Sebastián, Spain  
Ikerbasque Foundation for Science, Maria Diaz de Haro 3, E-48013 Bilbao, Spain  

###### 摘要

许多使用工具的LLM智能体通过模型上下文协议（MCP）从异构证据源（包括搜索结果、API、数据库、临床记录、处方工具以及通过工具服务器暴露的其他外部系统）生成答案。现有的事实性和忠实度指标通常在证据汇总后评估答案是否得到可用上下文的支持。但这种抽象忽略了一个重要的、与来源相关的失败模式：某个声明可能在证据库的某处得到支持，但却被错误地归因到了另一个来源。我们将这种失败称为跨源混淆。我们提出ProvenanceGuard，这是一个用于MCP基础答案的源感知验证器。ProvenanceGuard是经校准的Router+NLI系统：它消费带有稳定工具ID、源ID和原始工具输出的捕获MCP轨迹；将答案分解为原子声明；将声明路由到特定来源的证据；通过NLI和基于注意力的令牌对齐代理检查支持情况；并单独比较声明的陈述归因与路由来源。它返回每个声明的来源判定结果以及答案级别的允许/阻止决策，并且可以在重新验证前调用类似RARR（检索增强答案修订）的修复来修正被阻止的答案。我们在一个冻结的前瞻性语料库（包含281条捕获的医学领域MCP智能体轨迹）上进行评估。一个包含266条轨迹的声明判定子集产生了2,325个LLM辅助的声明标签，按轨迹划分为训练集、验证集和保留测试集；随后由人类专家验证361个保留标签，并使用完整的281条轨迹语料库进行答案级别的修复评估。在包含40条轨迹、361个声明的保留数据划分上，ProvenanceGuard在260个符合来源条件的声明上达到了0.802的阻止F1值和0.858的源准确率。在同一数据包上，无源意识的声明/证据基线分别达到：MiniCheck 0.783 F1，RAGAS Faithfulness 0.758，AlignScore 0.662，SummaC-ZS 0.436，但这些方法均不输出声明到来源的ID映射。在一个更困难的多源判定基准上，ProvenanceGuard在来自锁定测试问题的冻结提取声明上达到了0.846的阻止F1值，而来源加关系准确率降至0.229，这表明在语义上接近的候选来源中，精确的来源归属仍然困难。在整个轨迹集上，修复与重新验证循环解决了所有173个被阻止的答案，尽管有144个需要保守回退而非实质性重写；在重建的多源测试轨迹上，一次全新的答案级修复重跑解决了所有59个最初被阻止的答案，出现两次终端回退。在50个针对冻结捕获MCP证据生成的、具有临床框架的混淆探测样本中，ProvenanceGuard检测到了所有50个故意注入的来源归属交换，且没有保留错误的归属。这些结果表明，来源归属是基于MCP的智能体事实性验证中的一个独立评估维度。

**关键词：** 源感知事实性验证，数据来源，模型上下文协议，工具使用LLM智能体，检索增强修订，自然语言推理

## I 引言

使用模型上下文协议（MCP）的LLM智能体越来越多地操作多个外部工具，而不是单一的检索段落。它们通过MCP服务器调用工具，检查结构化记录，组合多个输出，并通常生成混合了源基础事实、通用背景知识和安全免责声明的答案。一个医疗智能体可能将PubMed摘要与患者的FHIR记录结合，而企业智能体可能将CRM条目、账单记录和支持工单结合。在此类设置中，事实性验证不仅要评估声明在可用证据中的某处是否得到支持，还要评估答案是否将声明归因于正确的来源。

考虑一个断言：“根据患者的病历，恩格列净降低了死亡率终点。”该死亡率声明可能得到临床试验摘要的支持，但患者的病历中可能没有。一个无源意识的验证器将病历和摘要合并，可以把该声明标记为“支持”。而源感知验证器应该拒绝该归因，因为证据来源不正确。

```
答案中的声明：“恩格列净降低了死亡率终点。”
答案中的陈述来源：患者病历

患者病历
诊断、用药
同一个患者，错误来源

文献摘要
死亡率估计
正确的支持来源

PubMed元数据
标题、期刊、年份
同一主题，部分来源

FHIR实验室数据
患者数值
同一病历族，无支持

无源意识支持：
合并证据：已支持

源感知判定：
支持是，归因阻止

路由支持
陈述归因
同一声明可以在某处被支持，但归因到错误来源
```

图1：为什么源感知事实性比无源意识支持更严格？一个声明可以被一个MCP来源支持，而答案却将其归因于另一个。无源意识评分看到合并证据中的支持；ProvenanceGuard分别检查支持来源是否匹配陈述或隐含的归因。

冻结的281条捕获智能体轨迹语料库本身并未估计这种失败模式的自然发生频率：捕获的随机轨迹包含单来源家族输出，或PubMed搜索加元数据输出（这些都停留在文献家族内）。因此，我们通过一个针对性的50例源混淆探测集（基于冻结的捕获MCP证据）来评估跨源混淆，每个探测样本包含一个故意的归属交换。这种区分很重要，因为许多事实性系统是为摘要一致性或检索忠实度设计的。它们通常针对上下文评分支持，而不是声明到来源的所有权。此类分数对于无支持的捏造是有用的，但对于其答案带有隐含或明确数据来源声明的MCP基础智能体来说是不够的。

本文做出四项贡献：
1.  我们为MCP基础答案形式化了来源归属事实性：验证器必须评估每个声明的支持和来源所有权。
2.  我们提出ProvenanceGuard，一个经校准的源感知Router+NLI验证器，它将答案分解为声明，从原始工具输出中保留稳定的MCP工具ID和源ID，将声明路由到特定来源的证据，并检测跨源混淆。
3.  我们报告了一个冻结的捕获医学领域智能体基准，由281条捕获的MCP智能体轨迹、一个包含2,325个LLM辅助标签的266条轨迹声明子集，以及一个包含完整MCP工具输出和人类专家审查标签的40条轨迹保留数据包组成。
4.  我们比较了ProvenanceGuard与MiniCheck、RAGAS Faithfulness、AlignScore和SummaC-ZS在同一保留声明数据包上的表现，同时在全量捕获轨迹和针对性源混淆探测样本上单独评估了RARR风格的修复。

核心主张仅限于MCP基础答案中的来源归属事实性；我们不声称解决了开放领域事实性检测、临床安全验证或参数知识修正等问题。

## II 相关工作

我们的工作处于支持验证、来源归属和工具基础智能体评估的交汇点。我们根据每项工作所保留的证据对象类型来组织先前工作。

#### 细粒度支持验证。
事实一致性系统，如FActScore、MiniCheck、SummaC、AlignScore和VeriScore，评估生成的声明是否得到证据支持[14 (https://arxiv.org/html/2606.18037#bib.bib1),19 (https://arxiv.org/html/2606.18037#bib.bib2),13 (https://arxiv.org/html/2606.18037#bib.bib3),23 (https://arxiv.org/html/2606.18037#bib.bib4),18 (https://arxiv.org/html/2606.18037#bib.bib11)]。细粒度工作将生成文本分解到句子以下级别：依存弧蕴含将错误定位在依存弧上[8 (https://arxiv.org/html/2606.18037#bib.bib15)]，QASemConsistency将谓词-论元命题表达为问答对[2 (https://arxiv.org/html/2606.18037#bib.bib16)]，PrefixNLI研究生成前缀上的蕴含[9 (https://arxiv.org/html/2606.18037#bib.bib19)]。这些方法启发声明级检查，但通常不保留声明到MCP来源的ID映射。因此，它们与二进制的允许/阻止决策相关，但不是来源归属指标（如Top-1源准确率、recall@k、平均倒数排名或来源集Jaccard）的直接基线。

#### RAG忠实度与归因生成。
RAG评估框架（如RAGAS）询问答案陈述是否忠实于检索到的上下文[3 (https://arxiv.org/html/2606.18037#bib.bib5)]。其他工作研究带引文和归因的答案生成：ALCE评估LLM生成答案的引文质量[7 (https://arxiv.org/html/2606.18037#bib.bib6)]；AttributedQA形式化了归因问答[1 (https://arxiv.org/html/2606.18037#bib.bib7)]；AutoAIS自动化了AIS风格的归因判断[22 (https://arxiv.org/html/2606.18037#bib.bib9),16 (https://arxiv.org/html/2606.18037#bib.bib8)]；TRUE整合了跨摘要、对话、释义和验证的事实一致性数据集[11 (https://arxiv.org/html/2606.18037#bib.bib10)]。最近的归因工作通过LAQuer[10 (https://arxiv.org/html/2606.18037#bib.bib17)]将证据定位到用户选择的跨度，或将生成分解为可执行的归因程序[21 (https://arxiv.org/html/2606.18037#bib.bib18)]。这些方法在动机上接近，但对合并上下文或引用上下文的忠实度并不等同于来源所有权。一个声明可以被一个检索来源支持，同时被错误地归因到另一个。ALCE[7 (https://arxiv.org/html/2606.18037#bib.bib6)]评估LLM生成的引文是否指向正确的支持段落，这是与来源归属最接近的现有任务。然而，ALCE在单个检索集合内以段落或块级别操作，而MCP轨迹暴露了稳定的工具级来源ID，需要路由步骤来确定哪个工具输出负责给定的声明。因此，我们的工作可以看作是将引文风格归因扩展到工具来源层。

#### 多源系统中的工具与来源归属。
随着RAG系统演变为使用工具的智能体，归属必须追踪哪个工具输出提供了证据。原子信息流模型将工具输出、LLM调用和最终响应建模为通过编排图的原子信息流[5 (https://arxiv.org/html/2606.18037#bib.bib20)]。FaithfulRAG专注于事实级别上检索证据与参数知识之间的冲突[24 (https://arxiv.org/html/2606.18037#bib.bib21)]，而Answering with Faithfulness将答案生成与忠实度预测相结合[4 (https://arxiv.org/html/2606.18037#bib.bib22)]。我们的设置不同，因为MCP轨迹暴露了稳定的工具和来源标识符。我们不推断潜在信息流或解决参数知识冲突；我们验证答案的陈述或隐含归因是否与路由到的MCP来源匹配。

#### 事后修订与训练型验证器。
RARR[6 (https://arxiv.org/html/2606.18037#bib.bib12)]获取生成的段落，研究证据，并修正无支持的声明，同时保持原始风格和结构。在我们的设置中，RARR风格的修复在源感知阻止之后进行评估：验证器拒绝答案，修复尝试生成一个基于来源的修订或保守回退，然后同一验证器重新检查修订后的答案。基于训练的方法在生成或检测时提高一致性，包括使用文本蕴含反馈的强化学习[17 (https://arxiv.org/html/2606.18037#bib.bib13)]、FactCC的合成不一致分类器[12 (https://arxiv.org/html/2606.18037#bib.bib14)]以及RAGulator用于基础生成的轻量级上下文外检测器[15 (https://arxiv.org/html/2606.18037#bib.bib23)]。这些方法与ProvenanceGuard互补，后者作为对黑盒MCP智能体输出的独立事后检查运行。对于校准，替代方案包括Platt缩放、保序回归和共形预测；我们采用随机森林校准器，因为它能处理经过简单独热编码和数值缩放后的表格验证器特征。

#### 工具使用与智能体轨迹。
工具使用评估通常研究智能体是否调用正确的工具、完成任务并产生有效的最终答案。我们的关注点更窄：在智能体产生答案且工具轨迹可用后，验证器能否决定每个声明是否得到答案引用或暗示的来源支持？一个相关的MCP社区提案已经识别出类似的差距：针对MCP服务器提议的验证能力[20 (https://arxiv.org/html/2606.18037#bib.bib24)]要求带有置信度分数的结构化判定，这镜像了我们允许/阻止/不可用的决策空间。我们的工作为MCP轨迹设置提供了该验证层的具体实现。

## III ProvenanceGuard

```
用户查询
MCP智能体核心
草稿答案
工具调用和服务器
带来源的轨迹
答案+轨迹包
原子声明分解
来源路由
NLI支持检查
校准评分
归因检查
答案门控
验证输出
阻止
RARR风格修复候选
```

图2：顺序源感知验证流水线。智能体核心调用MCP工具并产生草稿答案；ProvenanceGuard消费答案和捕获的带来源工具轨迹，将答案分解为声明，将声明路由到MCP证据，通过NLI、令牌对齐和校准估计支持，单独检查归因，并将被阻止的答案发送到修复和重新验证。

ProvenanceGuard在保留来源的模型上下文协议（MCP）轨迹中验证归因。目标不是证明某个来源在临床或科学上是正确的。目标更窄：当智能体答案做出事实性声明时，ProvenanceGuard询问该声明是否得到了它应该归因的来源的支持，以及答案是否将声明分配给了正确的MCP来源对象。这个框架在数据敏感领域尤为重要，因为离线验证器可以花费更多计算来获取可靠的来源归属，而不是优化交互式延迟。