从ProvenanceGuard理解多源RAG的claim-to-source验证

AI 说“根据账户记录，你有 30 天退款期”，这句话可能事实正确，引用却错了：30 天来自通用政策，账户记录里根本没有。读完本文，你会理解多源 RAG 为什么要保留来源身份，并能用一段 Python 检查“每个声明是否真的由它声称的来源支持”。

最新事件：事实正确，也可能没有通过验证

Multiverse Computing 团队 9 月 29 日介绍了 ProvenanceGuard。它面向通过 MCP（Model Context Protocol，模型上下文协议）调用多个工具的 Agent，在答案生成后读取完整工具轨迹，把回答拆成声明，再逐条寻找支持来源、检查证据和归因，最后允许、阻断或进入修复。

团队报告的医学场景测试包含 281 条真实轨迹；在留出的 40 个回答、361 个声明中，专家认为 139 条不该通过，系统拦下 138 条，同时也把 67 条专家认为有支持的声明送去复核。这个结果说明它偏保守，也说明“拦得多”不等于“判断完美”。相似来源压力测试里，精确找对来源的比例只有 50.3%，边界必须说清。

它解决什么问题

把多源 RAG 想成写论文：图书馆里确实有一句话，不代表你能把它脚注到任意一本书。类比的边界是，真实 Agent 的来源不只是文档，还可能是数据库记录、搜索结果、API 返回和用户私密数据；这些来源的权限、时效和可信等级并不相同。

去掉类比，来源感知验证是维护“声明—证据—来源标识”的映射，而不是先把所有工具输出拼成匿名上下文，再只问句子是否有支持。它要同时回答三个问题：声明是什么、哪份原始输出支持它、回答明示或暗示的来源是否与支持来源一致。

最小实践：抓住“事实对、出处错”

下面的教学版不用模型，只用关键词交集展示核心数据结构。生产系统应换成嵌入检索和自然语言推断（NLI），但仍要保留来源 ID。

import re

sources = {
    "account": "用户方案为专业版，账户状态正常。",
    "policy": "专业版购买后30天内可以申请退款。",
}
claims = [
    {"text": "用户是专业版", "named_source": "account"},
    {"text": "退款窗口是30天", "named_source": "account"},
]

def tokens(text):
    return set(re.findall(r"[\u4e00-\u9fff]+|\d+", text))

def support_score(claim, source):
    ct = tokens(claim)
    st = tokens(source)
    numbers_ok = re.findall(r"\d+", claim) == re.findall(r"\d+", source)
    overlap = len(ct & st) / max(1, len(ct))
    return overlap + (0.5 if numbers_ok else -1.0)

for item in claims:
    ranked = sorted(
        sources,
        key=lambda sid: support_score(item["text"], sources[sid]),
        reverse=True,
    )
    best = ranked[0]
    verdict = "ALLOW" if best == item["named_source"] else "BLOCK"
    print(item["text"], "support=", best, "verdict=", verdict)

assert support_score("退款窗口是30天", sources["policy"]) > 0
assert claims[1]["named_source"] != "policy"

无需第三方依赖，保存为 provenance_gate.py，运行 python provenance_gate.py。本次在 Python 3.9.6 实际运行，第二条声明被识别为应由 policy 支持，因此对错误标注的 account 归因执行阻断。它只验证流程，不复现论文模型与医学数据结果。