从ProvenanceGuard理解多源RAG的claim-to-source验证
内容提要
ProvenanceGuard面向多工具Agent，在生成答案后读取工具轨迹，将回答拆分为声明并逐条验证来源，可允许、阻断或修复。医学测试中，系统拦截了139条应拦声明中的138条，但相似来源精确匹配率仅50.3%。文章强调多源RAG应保留来源ID，区分事实正确与出处正确，并提供Python示例检查声明是否由声称来源支持。
延伸解读
保守拦截的代价与边界
ProvenanceGuard在医学测试中拦下139条应拦声明中的138条，但同时也将67条专家认为有支持的声明送去复核。这说明系统偏保守，高拦截率不等于判断完美。实际部署时需权衡漏拦与误拦：在医疗、金融等高风险场景，保守可能更安全，但会增加人工复核成本；在低风险场景，过度拦截可能影响效率。
相似来源下的精确匹配挑战
在相似来源压力测试中，系统精确找对来源的比例仅50.3%。这意味着当多个来源包含相似内容时，仅靠关键词或简单匹配容易混淆。文章建议保留来源ID并区分事实正确与出处正确，但相似来源的精确归因仍是难点。开发者需注意，来源感知验证不能完全依赖表面文本重叠，可能需要更细粒度的来源特征。
来源感知验证的适用与不适用
该方法适合医疗、金融、客服、合规研究等需要解释依据来源的多工具工作流，也可作为发布门禁。但它不能解决知识库污染、恶意工具输出和权限越界问题。来源感知不是内容可信、授权合法和数据新鲜的替代品。开发者应明确其边界，避免将其视为万能方案。
从数据结构开始的可追溯证据链
文章强调，多源RAG的下一个基础设施不是更长上下文，而是可追溯的证据链。开发者应从数据结构改起：每段工具输出带不可变来源ID、采集时间和权限域；每个回答声明保存候选证据与判定，而非只留最终文本。这有助于实现声明到来源的精确映射，提升系统可解释性和可审计性。
Q&A
ProvenanceGuard 是什么？它主要解决什么问题？
ProvenanceGuard 是 Multiverse Computing 团队提出的一个系统，面向通过 MCP 调用多个工具的 Agent。它在答案生成后读取完整工具轨迹，将回答拆分成声明，并逐条验证每个声明是否真的由它声称的来源支持，最后允许、阻断或进入修复。它主要解决多源 RAG 中“事实正确但出处错误”的问题。
ProvenanceGuard 在医学场景测试中的表现如何？
在医学场景测试中，包含 281 条真实轨迹，留出的 40 个回答、361 个声明中，专家认为 139 条不该通过，系统拦下了 138 条；同时把 67 条专家认为有支持的声明送去复核。相似来源压力测试中，精确找对来源的比例只有 50.3%。
多源 RAG 中为什么需要保留来源身份？
因为真实 Agent 的来源不只是文档，还可能是数据库记录、搜索结果、API 返回和用户私密数据，这些来源的权限、时效和可信等级并不相同。如果先把所有工具输出拼成匿名上下文，再只问句子是否有支持，就会丢失来源身份，无法判断回答明示或暗示的来源是否与支持来源一致。
如何用 Python 检查一个声明是否由它声称的来源支持？
文章提供了一个教学版 Python 示例：定义 sources 字典（来源 ID 到文本）和 claims 列表（每个声明包含 text 和 named_source）。通过 tokens 函数提取关键词，support_score 函数计算声明与来源的关键词重叠度，并对数字进行精确匹配。然后对每个声明，按支持分数对来源排序，取最高分来源，如果与 named_source 一致则 ALLOW，否则 BLOCK。
使用来源感知验证时有哪些常见误区？
常见误区包括：认为有 URL 就有证据（链接可能只与主题相关，并不支持具体数字）；把所有工具结果合并后做一次“忠实度”评分（会丢失来源身份）；把来源匹配当成真实性证明（原始来源本身也可能过期或错误）；见到 138/139 就认为可以无人审核（论文同时出现保守误拦与相似来源识别下降）。
ProvenanceGuard 适合哪些场景？不适合哪些场景？
它适合医疗、金融、客服、合规研究等需要解释“依据来自哪里”的多工具工作流，也适合把引用检查变成发布门禁。不适合只靠这一层解决知识库污染、恶意工具输出和权限越界；来源感知不是内容可信、授权合法和数据新鲜的替代品。
