据 Hugging Face 博客9月29日介绍，最新论文提出 ProvenanceGuard，一种面向基于 MCP 的大语言模型智能体的来源感知事实核查方法，重点处理“事实为真、来源归属错误”的跨源混淆。来源盲核查器可能因该事实存在于整体证据中而放行，来源感知核查器则不应如此。
博客用客服智能体说明问题。智能体回答“根据账户记录，该套餐包含30天退款窗口”，退款窗口可能真实存在，但写在政策文档而非账户记录中。合并材料看，主张似乎有支持；分开检查，来源归属就是错的。在数据敏感场景，错误归属可能与错误事实同样有害。临床智能体也有类似情况：患者病史工具中的用药细节，一旦被说成来自医学文献，就会产生误导。
ProvenanceGuard 的出发点是，一条主张可能由某个 MCP 来源支持，而答案将其归因于另一个来源。来源盲评分在合并证据中看到支持便放行；ProvenanceGuard 单独检查支持来源是否与答案明确或暗示的来源一致。博客称，忠实度分数虽然有用，但对 MCP 智能体并不足够，因为答案带有来源信息，有时明说，有时隐含。ProvenanceGuard 要让主张与来源之间的连接可供检查。
该方法是一个生成后验证层，位于黑盒 MCP 智能体之上。它在答案生成后运行，不把证据压缩为一个匿名上下文，而是让来源身份贯穿流程。它读取捕获的 MCP 轨迹，包括工具输出及来源 ID，无需重新训练智能体。随后按顺序把答案拆成具体主张，为每条主张找到最相关的来源，检查该来源是否支持它，比较该来源与答案点名或暗示的来源，最后给出逐条主张的来源判定和答案层面的允许或阻止决定。被阻止的答案可通过 RARR 式修复再验证。
论文实验使用本地模型，MiniLM 帮助找到相关来源，DeBERTa NLI 验证模型检查来源是否支持主张，本地语言模型帮助拆分主张。验证器还严格检查字面值，数字、日期或标识符若不在来源中，不能仅因句子听起来合理而通过。若答案被阻止，RARR 式修复步骤可尝试基于来源的改写或安全回退，再由验证器复查。博客指出，这些具名模型是论文评估设置，并非 ProvenanceGuard 的硬性要求；同样步骤可适配云端托管模型，但新设置需要自行测试和校准。报告结果来自本地配置，其保守决策策略适合数据敏感审查。
测试使用医学智能体的答案，这些答案调用了患者记录、研究文章等工具，共得到281条真实轨迹。患者记录中的事实与一般研究中的事实不能视为同一来源，因此医学适合检验该方法；论文称，只要智能体保留工具输出和来源 ID 记录，方法也可用于其他领域。主测试中，人类专家检查了从开发数据中留出的40个答案里的361条主张。专家认为其中139条不应通过，ProvenanceGuard 拦截了138条，放行1条；同时，它把专家认为有支持的67条主张拦下，送交审查或修复。这反映其谨慎设置：宁可让部分有支持的主张接受二次检查，也不让无支持主张通过。对于有可识别来源的主张，该测试中选对来源的比例约为86%。论文还报告，在同一批主张上测试了另外四个支持检查器，ProvenanceGuard 在衡量系统拦截应被阻止主张的指标上得分最高。