Normalized Evidence Boundary

把不同 Retrieval Backend 的 SearchResult 转换成统一 Evidence Contract 的标准化边界，使 Agent/Governance 与 pgvector、PubMed、PDF 等检索实现解耦；标准化只统一形状，不等于 Evidence 已经可信或可采纳。

#concept #growing #ai #architecture #agent #bodysense

[!info] related notes

所属 MOC: bodysense-moc

前置概念:

并列概念:

易混淆概念:

关系笔记: bodysense-targeted-rag-evidence-provenance

Normalized Evidence Boundary

一句话定义

Normalized Evidence Boundary 是 Retrieval Infrastructure 与 Agent / Governance 之间的一层标准化契约：

不同检索后端的原始结果
→ normalize
→ 统一 Evidence Contract
→ Agent / Policy / Eval

它解决的核心问题是：

上层业务应该依赖“证据是什么”，而不是依赖“某个搜索后端碰巧怎么返回数据”。

最通俗的理解

BodySense 今天可能从 KnowledgeLibrary.search() 得到：

SearchResult
├─ id
├─ title
├─ body_markdown
├─ similarity
├─ source_title
└─ clips

以后又可能接入 PubMed：

PubMedResult
├─ pmid
├─ abstract
├─ journal
└─ publication_date

再以后可能接入 PDF：

PdfChunk
├─ document_id
├─ page
├─ chunk_id
└─ text

如果 Diagnosis/Treatment 直接依赖这些结构，就会变成：

if source == "knowledge_library": ...
elif source == "pubmed": ...
elif source == "pdf": ...

检索层每加一个后端，上层业务都要跟着修改。

Normalized Evidence Boundary 则把它们统一成：

Evidence
├─ evidence_id
├─ source_type
├─ source_key
├─ source_revision
├─ locator
├─ excerpt / snapshot
├─ retrieval metadata
└─ policy metadata

于是上层只消费一个稳定 Evidence 语言。

SearchResult 与 Normalized Evidence 的职责不同

SearchResult

属于 Retrieval Backend / Infrastructure。

它回答：

“这次搜索后端返回了什么？”

字段通常围绕搜索实现：

vector similarity；
raw chunk；
database row ID；
backend-specific metadata；
clip/title/body；
ranking score。

换 pgvector、BM25、cross-encoder 或外部 API 后，这个结构完全可以变化。

Normalized Evidence

属于 Agent / Business Boundary。

它回答：

“上层系统现在观察到的是哪一条可追踪的证据候选？”

它更关心：

稳定 identity；
来源类型；
具体来源 key；
版本/revision；
当时观察到的内容；
为哪个 Gap 获取；
provenance；
policy-relevant metadata。

所以：

SearchResult
= retrieval implementation language

Evidence
= business / governance language

这本质上是 Adapter / Dependency Inversion

依赖方向应该是：

Agent / Governance
        │
        ▼
Evidence Contract
        ▲
        │ adapters
 ┌──────┼─────────┐
 ▼      ▼         ▼
pgvector PubMed   PDF

而不是：

Agent
├─ knows pgvector SearchResult
├─ knows PubMedResult
└─ knows PdfChunk

因此未来从：

vector-only retrieval

切换到：

BM25 + vector + reranker

主要修改 Retrieval Adapter / normalization，而不是重写 Diagnosis/Treatment 的业务逻辑。

Normalization 不等于“证据已经正确”

这是最重要的边界。

SearchResult
→ normalize
→ Evidence candidate

只说明：

数据已经被转换成统一格式。

不说明：

内容一定正确 ❌
来源一定可靠 ❌
当前版本允许使用 ❌
一定适用于当前用户 ❌
一定解决 EvidenceGap ❌

后面仍然需要：

Normalized Evidence
→ Provenance validation
→ Admissibility
→ Semantic support / Grounding
→ DecisionAuthority

所以一定记住：

normalized
!= admissible
!= sufficient
!= true

Identity、Locator、Revision、Snapshot 要分开

生产 Evidence 不应该只剩一个数据库 ID。

Source Identity

source_key = knowledge-unit:123

回答：

“是哪一个来源对象？”

Locator

例如：

page 57
video 03:14–05:28
chunk 8

回答：

“来源里的哪个位置？”

Revision / Version

revision = 7

回答：

“这个来源当时是哪一个版本？”

Snapshot / Hash

excerpt = 当时真正看到的内容
content_hash = ...

回答：

“当时系统到底看到了什么？”

因此：

locator
!= revision
!= snapshot

尤其不能拿“视频时间戳没变”去证明“知识内容版本没变”。

一个 BodySense 例子

KnowledgeLibrary 返回：

SearchResult
id = 123
title = 梨状肌相关表现
similarity = 0.88
body_markdown = ...
source_timestamp = 03:14–05:28
review_status = reviewed

Normalization 后可以形成：

Evidence
evidence_id = stable derived identity
source_type = knowledge_unit
source_key = knowledge-unit:123
source_revision = 7
locator = video:03:14–05:28
excerpt = ...当时观察内容...
retrieval_score = 0.88

上层 Agent 不需要知道底层 SQL 是：

pgvector cosine

还是未来变成：

BM25 + dense + cross encoder

它只认识 Evidence Contract。

为什么 Stable Evidence Identity 对 Replay 很重要

假设：

2026-08-23
unit #123 revision 7 = 内容 X

2026-10-01
unit #123 revision 8 = 内容 Y

如果历史 Analysis 只保存：

source_key = 123

未来重新查数据库可能拿到 Y，然后误以为当时模型看到的也是 Y。

所以 Evidence identity / provenance 应至少能 pin：

source identity
+
revision/version
+
必要 snapshot/hash

这样 Historical Replay 才不会被今天的知识偷偷改写。

Normalized Evidence 与 Citation 也不同

Evidence Contract 是系统内部的受治理事实载体。

Citation 更偏 UI / 用户解释：

标题
作者
URL
页码/时间戳

一个 Evidence 可以生成 Citation，但：

Evidence
!= Citation

因为 Evidence 还需要承载：

stable identity；
version；
provenance；
acquisition context；
policy metadata。

常见误区

“normalize_evidence() 就是验证 Evidence 正确”

错。Normalization 只做 contract mapping；验证可信度属于 provenance/admissibility/grounding。

“数据库 row ID 就是 Evidence ID”

不一定。Evidence 关注的是参与决策的来源与版本，不只是当前数据库中的一行。

“有统一 Pydantic Model 就已经解耦”

只有当上层不再依赖 backend-specific 字段/行为时，才真正实现解耦。

“Similarity 应该成为 Evidence 的核心真值”

Similarity 是 retrieval metadata，只说明“检索器认为相关”；它不等于 support 或 truth。

自测题

SearchResult 与 Normalized Evidence 分别属于哪一层？
为什么接入 PubMed/PDF 时不应该让 Diagnosis 增加一堆 if source == ...？
Normalization 为什么不等于 Admissibility？
source locator 与 source revision 有什么区别？
为什么 Historical Replay 最好 pin revision/snapshot？
Embedding similarity 为什么只是 retrieval metadata，而不是 Evidence truth？

最终心智

Retriever-specific result
→ Adapter / Normalization
→ Stable Evidence Contract
→ Provenance
→ Admissibility
→ Grounding
→ Decision

Normalized Evidence Boundary 的价值，本质上就是：底层 Retrieval 可以演进，上层 Agent/Governance 仍然只依赖一个稳定、可追踪的 Evidence 语言。