AI agent 证据来源与可信度分层：引用、过期、冲突和人工复核怎么做

很多 AI agent 项目都会说自己“基于检索和工具结果回答”。但只要系统开始接触多个来源，真正难的问题就不再是“有没有证据”，而是“这条证据从哪来、是不是最新、跟别的来源冲不冲突、冲突时该信谁”。

如果这些问题都没被显式建模，所谓 evidence 很容易退化成“拼接出来的上下文”，一旦结果错了，团队只能模糊地说“模型引用了旧数据”或者“检索命中了不准的片段”。

建议先结合 AI agent Artifact 设计、AI agent 缓存与失效策略、AI agent Run Ledger 审计模型 和 AI agent 人工审批控制台设计 一起看。

先给结论：evidence 不只要存内容，还要存 provenance

没有这些元信息，证据就只是“看起来像引用的文本”。

一、Provenance 先回答“这条证据到底来自哪里”

更稳的 evidence envelope 通常至少包含：

{
  "evidenceId": "e_123",
  "sourceType": "document",
  "sourceId": "policy_v4",
  "retrievedAt": "2026-05-10T10:00:00Z",
  "version": "v4",
  "permissionScope": "team_finance"
}

这不是为了“多存点字段”，而是为了后续系统能回答：这条依据现在还可不可以用。

进一步做审计和缓存收口时，evidence envelope 最好再带完整性与时效快照：

{
  "sourceChecksum": "sha256:abc123",
  "freshnessTtlMs": 3600000,
  "trustBand": "medium",
  "retrievalDecisionId": "rd_18"
}

这样系统不只是知道“证据来自哪里”，还能判断这条证据是基于哪次检索决策进入当前 run，以及它在什么时间窗内仍然有效。

二、可信度不等于相关度，trust score 要单独建模

检索相关，并不一定代表可信。很多时候，一条证据相关性很高，但来源过旧、权限不匹配，或者只是低可靠渠道。一个更有用的 trust score 通常会同时考虑：

• 来源权威性
• 时效性
• 权限匹配度
• 与其他证据的一致性

可以先用规则型评分起步：

重点不是分数绝对精确，而是系统能稳定地区分“可依赖”和“仅供参考”。

算完分数以后，最好不要直接把连续值丢给模型自己解释，而是先映射成 trust band：

这样 trust score 才不只是分析字段，而会真正影响系统接下来的控制动作。

三、Freshness 是证据系统里最容易被忽略的一层

证据不一定会失效，但系统至少要知道什么情况下它可能失效：

• 文档版本更新
• 业务状态变化
• 权限边界变化
• 缓存 token 变化

这也是为什么 evidence provenance 应该和 AI agent 缓存与失效策略 连接，而不是孤立存在。

四、冲突证据不要让模型自己拍板，系统要先做 conflict class

更健康的做法，是先把冲突分成几类：

如果系统把所有冲突都丢给模型“自己综合判断”，最终得到的只会是难以复盘的黑盒结论。

五、高风险结论最好带 evidence packet，而不是只带最终摘要

当证据会进入审批台或审计链路时，系统最好输出一个 review-ready packet：

{
  "primaryEvidence": ["e_123", "e_124"],
  "supportingEvidence": ["e_201"],
  "conflicts": ["e_310"],
  "trustLevel": "medium",
  "reviewRecommended": true
}

这样人工接手时看到的不是一段模糊结论，而是一份已经整理好的证据包。

更稳的一步，是把 trust band 与 review trigger 直接绑定：

否则 evidence packet 虽然很完整，但系统仍然不知道什么时候该停下来交给人。

六、上线后要看“证据链质量”，而不是只看检索命中率

建议至少记录：

如果命中率很高，但 stale evidence 也很高，说明系统只是更快地拿到了旧答案。

七、失败案例：制度文档更新后，Agent 还在引用旧版本条款

某个审批 agent 的检索命中率一直很好，但上线后仍频繁给出过时结论。复盘发现新旧制度文档都能检到，系统也没有保存 version 和 retrievedAt，模型只能自己“看起来选一条更像的”。

修复后，团队为 evidence 增加 provenance、freshness 和 trust score，并把“新旧版本冲突”直接升级为人工复核，错误率才明显下降。

八、Evidence Provenance 与可信度 Checklist

• 每条 evidence 是否带 sourceId、version、retrievedAt 和 permissionScope
• trust score 是否独立于相关度建模
• sourceChecksum、freshnessTtlMs 和 retrievalDecisionId 是否可追溯
• 系统是否显式识别 freshness 失效条件
• trust score 是否映射成 high / medium / low / blocked 等明确分层
• 冲突证据是否先分类，而不是全部交给模型拍板
• 高风险场景是否输出 review-ready evidence packet
• trust band 是否直接驱动继续、复核或阻断动作
• 是否监控 stale hit、conflict escalation 和 trust band 结果差异
• 审计时能否回到原始证据而不是只看摘要

结语

AI agent 的 evidence 体系，真正难的不是“多找几条依据”，而是让系统知道哪条依据来自哪里、现在还值不值得信，以及冲突时谁该做最后判断。只有 provenance、freshness 和 trust score 同时存在，证据链才真正可控。

延伸阅读：

• AI agent Artifact 设计
• AI agent 缓存与失效策略
• AI agent Run Ledger 审计模型
• AI agent 人工审批控制台设计