Agent Evidence Admissibility

区分“已经检索到的证据”和“被当前 configuration/policy 允许用于决策的证据”，防止来源、版本或事实类型不合规的 evidence 非法关闭关键 EvidenceGap。

#type / concept #status / growing #tech / ai #tech / architecture #tech / security #resource / agent

[!info] related notes

Agent Evidence Admissibility

一句话定义

Evidence Admissibility 指一条已经被系统获取到的 Evidence，是否满足当前 Agent Configuration 与业务 Policy 的来源、版本、事实类型和用途约束，从而有资格参与本次决策。

最重要的区分是：

retrieved evidence
≠
admissible evidence
≠
proof that a gap is resolved

[!important] 记忆方式 “搜到了”只是执行事实；“能不能拿来判”是治理事实。

为什么需要这一层

假设 Agent 为 critical gap G3 搜到了 E8：

G3 = critical external_knowledge gap
A2 retrieves E8
LLM says: E8 resolves G3

但当前 configuration C9 的 evidence policy 只批准特定来源或版本，而 E8 不在允许范围内。

此时系统应该记录：

E8 = retrieved ✅
E8 = semantically relevant ✅ / maybe
E8 = admissible ❌
G3 = unresolved

即使模型对 E8 非常满意，也不能用它穿透 policy。

为什么“证据质量高”仍不等于“当前可采纳”

Admissibility 经常被误解成“这篇资料是不是权威”。

其实它问的是更具体的问题：

在这一次特定决策、这一个特定 configuration、这一个特定 evidence policy 下，这条 Evidence 有没有资格被使用？

一篇医学指南可以非常高质量，但仍可能因为以下原因不可采纳：

source revision 不在当前批准列表
jurisdiction 不适用
已经 superseded / withdrawn
不属于当前 replay snapshot
只能支持 general knowledge，不能支持 user fact
不是本轮实际 acquisition 得到的证据
与当前 Gap 类型不兼容

所以：

Evidence Quality
≠
Evidence Admissibility

质量是输入之一；可采纳性是 policy 结果。

Evidence 的决策生命周期

可以把一条 Evidence 理解成经过多道门：

Retrieved
  ↓
Identity Validated
  ↓
Source / Version Policy Validated
  ↓
Fact-Type Compatible
  ↓
Associated With Accepted Gap
  ↓
Semantically Relevant
  ↓
Admissible For This Decision
  ↓
May Support Gap Resolution

这里每一步回答不同问题。

Retrieved

工具确实返回了这条数据。

Identity Validated

系统能确认：

  • evidence ID 是真实的；
  • source key/version 可追踪；
  • 它属于本次实际 acquisition，而不是模型编造的 ID。

Source / Version Policy Validated

当前 configuration 是否允许：

  • 这个知识源；
  • 这个 source version；
  • 这个 corpus/index revision；
  • 这个证据等级。

Fact-Type Compatible

这条 Evidence 是否能回答当前 gap 类型？

典型硬边界：

外部医学知识
不能证明
“这个用户本人确实存在某症状”

也就是：

external knowledge ≠ user fact

Semantically Relevant

证据内容是否真的回答了 gap，而不只是关键词相似。

这一步可能需要结构化 validator 或 LLM semantic judgment。

Admissible

前面的身份、来源、版本、事实类型和用途条件全部满足后，这条 Evidence 才有资格进入业务决策。

把 Admissibility 拆成“硬门”和“语义门”更容易理解

有些条件可以 100% deterministic：

Evidence ID 是否存在
是否属于本轮 run
source revision 是否批准
source status 是否 reviewed/published
Gap kind 是否允许这个 source type
是否跨 run / 跨 snapshot

另一些条件需要语义判断：

这段 Evidence 是否真正回答了 Gap？
是否只是同主题但无关？
是否支持、部分支持、反驳？

因此可以分：

Layer 1 — Deterministic Admissibility
        ↓
Layer 2 — Semantic Relevance / Support
        ↓
Gap Resolution

不要反过来先问 LLM：

“这篇文章看起来能用吗？”

再让它顺便决定 source/version/run identity 是否合法。

机器已经知道的事实，应由机器直接验证。

user_fact 来源是最典型的 Fact-Type Compatibility 问题

假设用户只说：

“我右肩痛。”

RAG 搜到：

“某类神经根问题常伴随拇指麻木。”

这条 Evidence 可以被用于：

external_knowledge:
“如果存在拇指麻木，会增加某候选解释的合理性。”

但不能被用于：

user_fact:
“这个用户存在拇指麻木。”

即使它：

  • 来源权威；
  • 版本正确；
  • 语义相关；

也仍然对 user_information Gap 类型不兼容。

这是一类特别重要的 admissibility rule，因为它不是“模型判断错了”，而是证据在 epistemic role 上根本无权证明该事实。

Admissible 不等于 Gap 必然 RESOLVED

一条证据合法可用，仍可能：

  • 支持力度不够；
  • 只回答 gap 的一部分；
  • 与另一条 admissible evidence 冲突；
  • 让不确定性下降，但不足以关闭 critical gap。

因此：

admissible evidence
→ can participate in resolution

not

admissible evidence
→ gap automatically resolved

一个“部分支持”的例子

Gap：

G9:
“这个干预的频率和停止条件是否都有充分支持？”

Evidence E31：

支持每周 3 次
但完全没提疼痛加重时是否停止

则：

E31 admissible = true
frequency supported = true
stop condition supported = false
G9 = partial / unresolved

这也是为什么后面的 Grounding / Faithfulness 要评估 material claim，而不是只看是否存在一条“相关证据”。

冲突 Evidence 怎么办

可能出现：

E31 admissible
→ supports A

E32 admissible
→ contradicts A

这不代表 Admissibility 层失败。

相反，它说明系统得到了合法但冲突的知识。

后续需要：

  • conflict policy；
  • source hierarchy；
  • freshness / recency；
  • evidence strength；
  • human review；
  • 保持 Gap unresolved。

重要的是不要因为系统“想要一个确定答案”，就把不喜欢的 admissible evidence 静默丢掉。

被拒绝的 Evidence 要不要删除？

不要。

如果 E8 实际被工具返回，它就是一次真实的 execution fact。正确做法是把它保留在：

  • DecisionTrace；
  • EvidenceAttempt；
  • Execution Provenance；
  • rejection / inadmissibility reason。

例如：

Attempt A2
├─ returned = E8@v4
├─ semantic_relevance = true
├─ admissible = false
└─ rejection_reason = source_version_not_approved_by_C9

这样以后才能回答：

“为什么明明搜到了 E8，系统仍然 ABSTAIN？”

如果把 E8 删除，审计时反而看不见真正发生过什么。

Rejection Reason 应该结构化，而不是一段日志文本

可以考虑稳定 reason code：

unknown_evidence_id
not_observed_in_this_run
cross_run_reference
source_not_approved
source_version_not_approved
source_status_not_allowed
fact_type_incompatible
wrong_gap_binding
snapshot_mismatch
semantic_irrelevance

这样可以：

  • 统计最常见 rejection；
  • 构建 eval slice；
  • 在 DecisionTrace 中解释；
  • 区分检索质量问题和 policy 问题。

如果所有错误都只写：

“evidence invalid”

后续很难知道是检索没命中、来源没批准，还是模型引用了另一个 run 的 evidence。

Cross-run Evidence 为什么必须 deterministic 拦截

假设：

Run A retrieved E31
Run B 没有检索 E31

模型或缓存 bug 却在 Run B 输出：

supporting_evidence_ids = ["E31"]

如果系统只检查：

数据库里存在 E31

就可能错误通过。

真正应验证：

E31 ∈ Run B observed evidence set ?

如果不是：

admissible = false
reason = not_observed_in_this_run

这是 runtime 可以精确确定的事实，不应该交给 LLM Judge。

Evidence Policy 是 Configuration 的一部分

允许哪些 Evidence 参与决策，本身会改变 Agent 行为。

例如：

C9
→ evidence-policy-v2
→ E8 不可采纳
→ G3 unresolved
→ ABSTAIN

C12
→ evidence-policy-v3
→ E8 source/version 被批准
→ 可能关闭 G3

因此 Evidence Policy 发生行为性变化时，应该产生新的 Agent Configuration identity，并重新 qualification，而不是在某次 production run 临时放宽。

为什么“更新知识库”也可能是行为变化

即使 prompt/model 完全没变，如果系统允许使用的 corpus snapshot 改了：

KB snapshot S12
→ S13

某些 query 可能开始检索到新的 Evidence，最终改变 decision。

所以对高治理场景，需要区分：

Knowledge content lifecycle
vs
Agent configuration policy
vs
Execution observed evidence

不一定每次知识库新增一篇文章都要生成新的整个 Agent Configuration，但如果 qualification/replay 要严格复现行为，至少要能追踪：

本轮使用的 knowledge snapshot/index/source version

否则 historical replay 会偷偷用今天的知识回答昨天的问题。

与 SafetyEnvelope / DecisionAuthority 的关系

Evidence Admissibility 发生在 authority 之前：

Evidence Retrieved
  ↓
Admissibility Validation
  ↓
Gap State
  ↓
Runtime Facts
  ↓
SafetyEnvelope
  ↓
DecisionAuthority

如果 critical gap 因证据不可采纳而仍然 unresolved，那么 HIGH confidence 不能覆盖这个事实。

Authority 不应该直接消费“retrieved count”

错误的 policy fact：

retrieved_evidence_count = 5
→ evidence sufficient

更合理：

unresolved_critical_gap_count = 1

因为“搜了多少”是 mechanism fact，“关键不确定性是否被合法解决”才是业务 authority 更关心的事实。

Historical Replay 为什么依赖 Evidence 版本

Historical Replay 想恢复的是“当时系统实际知道什么”。因此如果历史 D100 使用：

E17@v3

今天知识库已经是：

E17@v8

就不能偷偷用 v8 替换 v3，然后声称是在复现历史。

Evidence identity、source version 和必要 snapshot 是 epistemic provenance 的一部分。

Historical Replay 的三种 Evidence Fidelity

可以把 replay fidelity 分层：

Level 1 · Exact snapshot

保存当时 Evidence excerpt/content/version

最接近原始世界。

Level 2 · Version-resolvable

保存 source_id + version
今天仍能取回完全相同版本

也可以高保真 replay。

Level 3 · Current substitute

历史版本找不到
只能拿 current version

这时必须标记：

replay fidelity degraded

不能把它包装成 exact historical replay。

与 Grounding 的关系

Admissibility 回答：

“这条 Evidence 有资格进入判断吗？”

Grounding 回答：

“这条 admissible Evidence 是否真的支持某个 material claim？”

例如：

E31 admissible = true

但 Treatment claim：

“每天 10 组 × 100 次”

Evidence 只支持动作名称，不支持剂量。

所以：

Admissibility passed
≠
Grounding passed

这两个概念不要合并成一个“evidence valid”。

测试 Evidence Admissibility 应覆盖什么

Deterministic negative cases

unknown evidence id
cross-run evidence
wrong version
unapproved source
unpublished source
wrong gap binding
external evidence used as user fact

Semantic cases

same topic but not answering gap
partial answer
contradictory evidence

Replay cases

historical version available
historical version unavailable
current version differs

Contract property

不管模型 confidence 多高：

inadmissible evidence
→ 不得关闭 critical gap

一个完整 BodySense 例子

Gap G5
kind = external_knowledge
question = “某动作在神经症状加重时的 stop condition 是什么？”
critical = true

检索：

A1 returns E20@v2
A1 returns E21@v7

Policy：

E20@v2
source = reviewed guideline
version approved
→ admissible

E21@v7
source = draft user-generated note
status = unpublished
→ inadmissible

语义检查：

E20 只说一般 dosage
没有回答 stop condition

最终：

retrieved = 2
admissible = 1
gap resolved = false
criticalGapCount = 1
DecisionAuthority → ABSTAIN / ESCALATE

这条链非常清楚地说明：

“搜到两条”
并不能推出
“已经有足够证据”

自测题

  1. 为什么高质量 Evidence 仍可能在当前 case 不可采纳？
  2. retrieved、admissible、resolved 分别是哪一层事实？
  3. 为什么 external knowledge 不能用于关闭 user-information gap？
  4. Cross-run evidence 为什么必须在 deterministic 层拦截？
  5. 为什么被拒绝的 Evidence 仍应该留在 trace？
  6. Evidence Policy 改变为什么可能触发新的 configuration qualification？
  7. Knowledge snapshot 和 Agent Configuration 有什么区别？
  8. Admissibility 与 Grounding 为什么不能合并？
  9. historical replay 如果只能拿到 current evidence version 应该怎么标记？
  10. 为什么 Authority 更应该消费 unresolved_critical_gap_count，而不是 retrieved_evidence_count？

常见误解

  • 搜到就是能用：retrieval 是 mechanism，admissibility 是 policy。
  • 内容看起来很权威就能用：还要满足当前 configuration 的 source/version/用途约束。
  • 不可采纳证据应该从 trace 删除：相反，它应保留为真实 execution history，并记录拒绝原因。
  • 模型认为相关就等于 gap resolved：semantic relevance 只是必要条件之一，不是最终 authority。
  • Evidence 只要在数据库存在就能引用：必须属于当前 run 的 observed/approved evidence set。
  • Admissibility 通过就代表 Treatment faithful：还需要 material-claim grounding。
创建于 2026/8/22 更新于 2026/8/23