ProvenanceGuard：面向 MCP-Based LLM Agent 的来源感知事实性验证

  • 关联论文：2606.18037
  • 作者：spark
  • 更新：2026-07-23

一句话结论

ProvenanceGuard 提出"cross-source conflation"这一新的失败模式——答案在证据池中能被支撑，但被错误归属到了另一个来源；它通过把答案拆成原子声明、按 stable tool/source ID 路由到对应证据、用 NLI + token-alignment 做支撑判定、再比对"声明的来源"与"实际路由到的来源"，给出 per-claim 与 answer-level 的 allow/block 决策，并对被 block 的答案走 retrieval-augmented 改写-再验证回路。

解决什么真问题

基于 MCP（Model Context Protocol）的工具型 Agent 越来越常见：一次任务可能横跨搜索、API、数据库、临床记录、药品表单等多个工具/数据源。传统 factuality 指标（如"答案是否被某个证据支撑"）只看"池中有无支撑"，不看"是否归到了正确的来源"。

举例：Agent 用工具 A 拿到"某药副作用是 X"，用工具 B 拿到"该药对孕妇禁用"，最后答"孕妇禁用 X 副作用"——X 副作用来自 A，禁用警告来自 B，但模型可能把 X 副作用归到 B 上来。答案没编造，但来源错了，传统 verifier 检测不到，在医疗/合规/金融等高风险领域却可能造成严重事故。

更隐蔽的场景：两个工具返回了语义相似但属于不同来源的陈述（如工具 A 与工具 B 都给出某药品的相互作用，但一个来自 UpToDate，一个来自药品说明书），模型把它们合并时容易"悄悄"跨源。Verifier 不强制让每个 claim 锁回原源，就抓不到这种静默漂移。

ProvenanceGuard 把"来源归因（provenance attribution）"显式作为事实性验证的一个独立轴，把"答案正确"和"答案来源正确"分开评估。这一定位让工具型 Agent 的可信输出从"文本对"升级为"文本 + 来源映射"。

核心方法

1. 输入：MCP Trace

把 MCP 调用捕获为带 stable tool ID、source ID、raw output 的 trace，作为验证的事实底座。这与 MCP 协议本身的设计契合——MCP 强调工具/资源标识的稳定性。

trace 的稳定标识有两个关键作用：(1) 同一来源在不同轮次对话中保持 ID 一致，方便 verifier 跨轮次追踪；(2) 一旦声明被路由回某个 source ID，能直接定位到原始 raw output 做支撑判定，避免"二次幻觉"——即 verifier 自己又幻觉了"哪段文本说过这句话"。

2. 流水线（5 步）

MCP trace (tool_id, source_id, raw_output)
   │
   ▼
[1] 原子声明分解 (claim decomposition)
   │
   ▼
[2] 声明 → 源路由 (source routing via stable source_id)
   │
   ▼
[3] 支撑判定：NLI + token-alignment proxy
   │
   ▼
[4] 比对 stated attribution vs routed source
   │
   ▼
[5] per-claim verdicts + answer-level allow/block
   │
   ▼ (if blocked)
[6] retrieval-augmented 答案改写 + 再验证

关键模块： - NLI（自然语言推理）：判断声明是否被某源支撑，给出 entail/contradict/neutral 三类信号； - Token-alignment proxy：作为 NLI 的精细化补充，避免 NLI 在金融/医学数字上"语义对、数字错"的盲区——典型做法是让关键数字、专有名词、剂量等 token 必须在源文本的指定位置对齐； - Claim-to-source ID routing：核心创新，让"来源对错"变成可计算问题——每个声明必须有且仅有一个归属 source ID，由 trace 中 stable source_id 直接路由； - Stated-attribution 对比：把声明中显式或隐式提到的"来自 X""根据 Y""according to Z"等表述与实际路由结果做匹配，差异即归因错误。

值得强调的是，claim-to-source ID routing 本身不依赖语义相似度，而是依赖 trace 中记录的稳定 source_id——这一点让 verifier 在"语义相近的多源"场景下仍有锚可循，而不是陷入相似度模糊。

3. 失败处理回路

被 block 的答案进入 retrieval-augmented 改写：用检索结果改写被否定的声明，再走一次完整流水线；论文报告在完整 trace 集上"repair-and-reverify resolves all blocked answers"，多数情况下走保守 fallback（拒答/改写而非硬撑）。

这种"先 block，再 repair，再 verify"的回路有两个工程价值：(1) 给最终用户提供"为什么被拦"的解释——可以展示哪条 claim 因哪个源不匹配被否；(2) 避免"全部拒答"带来的可用性损失——能改的就改，改不了再 fallback。在医疗等高风险但又必须可用的场景下，这个回路设计是相对平衡的。

repair 回路里"检索增强"这一步通常用同一个 MCP 工具集再补一轮查询，而不是切换到外部搜索引擎，这保证了改写仍处于受控证据池内，不会引入新的"野证据"。

关键实验与数据

评测基于 281 条医疗领域 MCP-Agent trace：

  • 标注体系：266 条 trace 被仲裁，得到 2,325 条 LLM-assisted claim labels（按 trace 划分，避免同一 trace 的声明泄漏到训练/测试）；
  • 人工校验：361 条 held-out labels 经人核验——为 LLM 自动标注提供质量锚点，避免评测本身就被噪声污染；
  • 40-trace held-out 评测：
  • Block F1 = 0.802
  • Source accuracy = 0.858（260 条 source-eligible claims 上）
  • 显著优于不输出 claim-to-source ID 的 source-blind baselines；
  • 更难的多源 benchmark：
  • Block F1 上升到 0.846——说明对"该不该拦"的总体判断反而更稳；
  • 但 source + relation accuracy 仅 0.229——说明语义相近的多源场景下，"精确来源所有权"仍是开放难题，模型能把"对的源"和"错的源"分得很近；
  • 临床 conflation 探针：50 条受控注入归因错配样本，全部检出，无残留错误归因——这是给生产部署最强的安全证据之一。

Block F1 与 Source Accuracy 的组合揭示了一个重要 trade-off：整体"拦还是不拦"相对容易判准（0.8+），但"精确归到哪个源"在多源相近场景下还远未解决。这意味着工业落地可以先采用"严格 block + 保守 fallback"策略，再逐步把 source+relation 提上去。

亮点与局限

亮点 - 提出 cross-source conflation 这一可形式化的失败模式，把"来源正确"与"答案正确"显式分开，给整个工具型 Agent 评测树立了新维度； - 与 MCP 协议深度协同（stable tool/source ID），工程上可落地——无需重建现有 MCP 基础设施即可接入； - 修复-再验证回路（repair-and-reverify）形成闭环，不是"检测完就完"——让 block 决策能反向驱动答案改写； - 在受控医疗场景里 100% 检出注入型归因错配，证据强，对高风险场景特别有价值； - Block F1 0.846 的多源成绩说明"判定要不要拦"已经比较可靠，可以作为生产系统的 first-stage filter。

局限 - 评测域集中在医疗，多源语义相近时 source+relation accuracy 仅 0.229，是论文自己也承认的硬骨头； - NLI + token-alignment 是工程折中，在结构化数字、表格、代码上的可靠性原文未明确； - claim decomposition 依赖 LLM，本身可能引入分解错误，论文未给出分解失败的统计； - 数据集 281 条 trace，规模有限，泛化性需要更大规模验证； - "block" 与"repair"的代价-收益（用户体验、延迟、token 成本）原文未明确给出； - 医疗场景下 100% 检出是受控注入，实际开放场景下的假阳性率需进一步评估。

对工程落地的启发

  • 任何用 MCP / 工具调用搭建的 Agent，都应把 provenance 作为一等公民——不要等出了事故再补；
  • 把 trace 中的 stable tool/source ID 暴露给 verifier 层，是低成本高收益的工程改造（很多 MCP 框架已经天然支持）；
  • 高风险领域（医疗、金融、合规）建议采用"保守 fallback > 强行改写"的策略，与论文的 repair 回路一致；
  • 可借鉴的范式：NLI（语义层）+ token-alignment（数字/字符串层） 双校验，避免单点失效；
  • 评测设计建议：除了"答案对错"，加 source attribution accuracy 这一独立指标，避免优化器只压答案正确率而忽略归因漂移；
  • 工程 pipeline 建议：在 trace 出口挂一个 "provenance verifier" 微服务，对每个 answer 做 allow/block 决策，block 的走 repair loop，超 budget 的直接拒答而非强行回答；
  • 对合规/审计团队：provenance 链路可作为审计追溯的依据，类似"答案每句话都能定位到具体证据出处"。

与同方向工作的关系

与三条主线交叉：

  • RAG hallucination / factuality：传统工作（SelfCheckGPT、FActScore、RAGAS 等）多在"答案是否被证据支撑"层面打转，ProvenanceGuard 加上"来源正确"维度；
  • Tool-use Agent verification：先前 ReAct/Reflexion 类工作多关注"反思与重试"，本文关注"答案与证据归属是否对齐"；
  • MCP 生态：MCP 在 2024-2025 快速铺开，ProvenanceGuard 是较早把 MCP 的 stable ID 设计直接用作验证信号的工作之一，给后续 MCP 应用的可靠性工程提供了模板。

适合谁读

  • 构建 MCP-based Agent 或多工具 RAG 的工程师；
  • 医疗、金融、合规、法律等高风险领域 AI 应用的架构师；
  • 研究 hallucination、factuality、provenance 的学者与研究生；
  • Agent 评测方向，需要在事实性之外加 source attribution 指标的研究者；
  • 合规与审计团队，需要"答案—证据"可追溯链路的业务方。

工程落地与核查（Jay）

arXiv 核验 ✅

2606.18037 真实存在： - 标题：ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents - 作者：Alvarez, Ander; Rajan, Santhiya; Mugel, Samuel; Orús, Román（Ionis Pharmaceuticals / 浙江大学 / Multiverse Computing / Donostia Physics Center） - 提交日期：2026/06/16；arXiv 更新：2026/07/26 - Abstract 关键数字与解读稿一致：Block F1 0.802（40-trace held-out）、Source accuracy 0.858（260 source-eligible claims）、Block F1 0.846（多源 benchmark）、Source+relation accuracy 0.229、50 controlled probes 全检出、repair resolves all blocked in full trace set ✅

MCP 集成门槛

  • MCP SDK 需开启 tool_id + source_id + raw_output 的完整捕获，这是 ProvenanceGuard 的输入前提——若现有 MCP 框架仅记录调用结果而未保存原始 raw output，verifier 将无法做 token-alignment 校准；
  • 实际改造量：在 MCP server 端加 trace exporter，verifier 端接入 trace consumer，整体侵入性低，但需规范 source ID 的命名空间（建议用 domain/source_name 双层结构如 clinical/epic_rx, clinical/up_to_date），避免多实例 source ID 冲突；
  • MCP trace 的持久化：生产环境需将 trace 写入 append-only 日志（如对象存储或 Kafka），以便 verifier 异步校验和 audit 回溯。

计算成本估算

  • NLI 判断：每次 claim × source 对需一次 NLI 调用（通常 200-500 input tokens），假设平均每答案 5 条 claim × 2 候选源 = 10 次 NLI/call，每答案额外延迟约 2-5 秒（取决于 NLI 模型速度，7B NLI 模型约 50-100ms/call，GPT-4o 约 1-2s/call）；
  • Token-alignment：纯字符串匹配，无 LLM 调用，成本可忽略；主要瓶颈在 NLI；
  • Repair 回路：若被 block，平均额外一次 retrieval-augmented 重写 + 再验证 = 再来一轮 NLI 校验；整体 P99 延迟可能在 10-15 秒量级，对交互式 Agent 是可感知的代价；
  • 优化路径：先用轻量 NLI（7-13B 模型蒸馏版）做粗筛，对置信度低的 case 才上调大模型；token-alignment 可前置过滤减少 NLI 调用次数。

生产坑点

  1. 假阳性（过度 block）：token-alignment 对医学专有名词（药物商品名 vs 通用名、剂量单位）敏感，原始 raw output 中的格式差异可能导致正确 claim 被误判；建议生产前用实际工具输出做校准；
  2. 语义相近多源场景（source+relation accuracy 仅 0.229）：当两个来源用相似语言描述同一事实时，精确归属仍是难题；生产系统在此类 case 应降级为"弱 block"（warning 而非 deny）而非硬拦截；
  3. Claim decomposition 漂移：LLM 做 claim 分解时可能遗漏、合并或错误拆分原子声明，导致路由层"无从判断"；这是端到端的系统性误差，需配合 evaluator 做定期抽检；
  4. Repair 引入新幻觉：用 retrieval-augmented 改写时若仍用同模型，修复轮次可能累积幻觉；建议 repair 时强制切换 LLM（不同模型家族）以引入独立校验；
  5. Audit 合规：医疗/金融场景下，block 决策需持久化（claim 文本 + 被拒绝的 source + 时间戳），以备审计；repair loop 也应记录"原始版本 vs 改写版本"。

局限性补注（原文未覆盖）

  • Recall 未报告：论文聚焦 Block F1（precision-oriented），但实际生产中"漏拦了多少错误归因"同样关键；建议自行补测 recall（block 掉的是否真的错了）；
  • 多语言/多司法管辖区：评测仅限英语医疗场景，其他语言或法规体系下的 provenance 判断逻辑是否可迁移未经验证；
  • LLM 版本漂移：NLI 模型更新后 block boundary 可能发生漂移，需建立 regression test suite（含 gold-standard claim-source pair）防止验证器退化。

开源与可复现性

  • 论文注明代码/数据集是否开源需查阅正文；目前 Abstract 和 arXiv 页面未给出 GitHub 链接，数据集与代码可获得性存疑（⚠️ 需补查原文 §Availability 或 supplementary）；
  • 生产接入建议：若代码未开源，需自行实现 NLI + token-alignment 模块；NLI 部分可复用 OpenAI evals 或 ReCoRM 的开源实现，token-alignment 需基于 source raw output 的子串匹配自行开发。