[!info] related notes

• 所属 MOC: BodySense MOC
• BodySense L4: Python Async / RAG Engineering
• 运行时护栏: RAG Grounding / Faithfulness 校验 · Red Flag 检测器
• 质量门禁: [[ai-quality-gates|AI 质量门禁]], Agent 评估工程化
• 归因边界: Agent Failure Attribution, Evidence Admissibility
• 知识库: RAG 知识库设计
• Evidence: Targeted RAG 与 Evidence Provenance

AI 输出质量评估框架

本篇维护分层指标与诊断顺序；评测数据集、版本与发布流程见 agent-evaluation-engineering。BodySense 数字和病例用于说明方法，不是已部署系统的实测报告。

一句话理解

不要只问：

“最终答案对不对？”

而要问：

“正确知识是否存在、Retriever 是否找到了、Reranker 是否保留了、Evidence 是否真的交给模型、模型是否忠实使用、Citation 是否指对、最终答案是否相关且安全？”

这就是分层 Eval。

它的最大价值不是多算几个指标，而是让错误可以被归因到具体层，而不是所有失败最后都变成一句：

LLM 效果不好

为什么只评 Final Answer 不够

假设最终答案错误，可能发生的是完全不同的故障：

A. Knowledge Base 根本没有正确知识
B. Knowledge 有，但 Retriever 没召回
C. Retriever 召回了，但 Reranker 排掉了
D. 正确 Evidence 已进入 Context，但模型没有忠实使用
E. Claim 本身有支持，但 Citation 指错来源
F. Answer 有依据，但根本没有回答用户的问题
G. 内容相关且有依据，但违反 Safety / Decision policy

如果只保留：

final_answer = wrong

就不知道应该修：

• knowledge ingestion；
• embedding；
• hybrid retrieval；
• reranker；
• prompt/model；
• grounding evaluator；
• citation mapping；
• safety policy。

因此 Production Eval 的核心是：

从第一处可观察的 Contract Failure 开始调查，再用输入、版本与对照实验验证原因。

第一处被发现的违约不一定是唯一根因；多层问题可能同时存在，日志缺失也可能影响定位。

RAG / Agent Eval 的完整层次

Knowledge Base
     │
     ▼
1. Knowledge Coverage
     │
     ▼
Retriever
     │
2. Recall@K / candidate recall
     │
     ▼
Reranker
     │
3. Precision@K / MRR / NDCG
     │
     ▼
Normalized / Admissible Evidence
     │
4. Evidence delivery / provenance
     │
     ▼
LLM / Agent
     │
5. Faithfulness / Grounding
     │
     ▼
Answer / Decision
  ┌──┼─────────────┐
  ▼  ▼             ▼
6. Relevance   7. Citation   8. Safety/Correctness

这些层可以关联，但不能混成一个平均分。

Layer 1：Knowledge Coverage

先问：

正确答案需要的知识，知识库里到底有没有？

如果 Golden Evidence 是 E42，但知识库根本不存在 E42 等价内容，那么 Retriever 不可能凭空召回。

这属于：

Knowledge coverage failure

而不是 embedding failure。

因此离线数据集最好明确：

query
required fact / claim
relevant evidence IDs
risk stratum

评测应固定语料快照和访问权限：库中存在但当前用户无权访问的内容不能算作必须召回。缺少人工相关性标注也不能直接证明知识不存在。

Layer 2：Retriever Eval —— 优先看 Recall

Retriever 的主要职责是 Candidate Generation：

尽量别漏掉真正有价值的 Evidence。

Recall@K

Recall@K
= Top-K 中召回的已标注相关 evidence 数
  / 当前评测范围内已标注相关 evidence 总数

例：

Golden Evidence = {E17, E42}
Top-5 = {E17, E08, E91, E32, E75}

那么：

Recall@5 = 1 / 2 = 0.5

空相关集需单独作为 no-result case 处理，不能除以零；相关标注不完整时，Recall 只代表相对该标注集的覆盖率。相同 evidence ID 去重后计数。

为什么常看多个 K

Recall@5
Recall@10
Recall@30

可以帮助判断：

正确 Evidence 完全找不到？
还是能找到，但排名太靠后？

如果 E42：

Top-30 rank = 7
Top-5 missing

若 Top-30 确实传入下一层，说明 E42 已被召回；还需比较精排、权限过滤与上下文裁剪记录，才能确定最终 Top-5 为什么没有它。单看两个 K 的结果不能直接归因精排。

Layer 3：Reranker Eval —— 排序质量

Retriever 常先追求高 Recall，多捞一些 Candidate；Reranker 再负责把真正相关内容排到前面。

Precision@K

Precision@K
= Top-K 中 relevant result 数 / K

它问：

“我最终放进模型上下文的东西，大部分真的有用吗？”

MRR

MRR（Mean Reciprocal Rank）关注：

第一个正确结果排得有多靠前。

例如：

Query A: first relevant rank = 1 → 1/1
Query B: first relevant rank = 2 → 1/2
Query C: first relevant rank = 5 → 1/5

再取平均，得到 (1 + 0.5 + 0.2) / 3 ≈ 0.567。没有相关结果时 reciprocal rank 记 0；采用 MRR@K 时，还需固定截断范围。

NDCG

当相关度不是简单的“相关/不相关”，而有：

非常相关
比较相关
略相关
无关

NDCG 更适合评价整个排序是否把高价值结果排在前面。

Retriever 与 Reranker 必须分开测

假设：

Retriever Recall@30 = 98%
Reranker Recall@5 = 60%

这说明最终小集合丢失了一部分已标注相关证据，但还不能断定精排错误：K 从 30 减少到 5 本就限制容量。应比较相同最终 K 的未精排 baseline、候选集可达到的上限和关键证据保留率，并检查中间过滤。

如果只看最终 Top-5，就可能错误地去换 embedding model。

Failure Attribution：一个最重要的例子

Golden Evidence：

E42

运行结果：

Knowledge Base: E42 存在 ✅
Retriever Top-30: E42 rank #7 ✅
Reranker Top-5: E42 被淘汰 ❌
Agent: 没看到 E42，最终回答错误

若合同要求保留 E42，且排除权限变化、去重和后续裁剪，当前可定位的违约是 Reranking failure。这不证明模型没有独立问题：没有足够依据仍作确定结论，也可能同时违反 grounding / abstention 规则。

这就是分层 Eval 的价值：不要把下游表现错误归罪给没有违约的上游组件。

Layer 4：Evidence Delivery / Provenance

即使 Retriever/Reranker 都正确，还要确认：

正确 Evidence 是否真的进入了当前 Agent run？

要区分：

retrieved globally
!= observed in this run
!= admissible in this run

例如模型引用：

E42

如果 E42 未以检索结果、获准快照、缓存或其他受控路径绑定并交付给当前 run，却被当作本轮证据引用，这属于：

invalid provenance / cross-run contamination

证据 ID、版本、权限与交付记录可做 deterministic 校验；跨 run 缓存复用本身不违规，前提是重新验证并绑定当前使用范围。正文是否支持 claim 则是另一层语义判断。

Layer 5：Faithfulness / Grounding

Faithfulness 最通俗的理解：

模型有没有“按资料说话”。

它问的不是“现实世界里这句话是否碰巧正确”，而是：

当前输出中的 material claim，是否能被本轮允许使用的 Evidence 支持？

例如 Evidence：

疼痛加重时应停止动作 A

模型输出：

疼痛加重时继续动作 A

则：

Retriever ✅
Reranker ✅
Evidence delivery ✅
Faithfulness ❌

这时候应该优先调查：

• prompt grounding contract；
• conflicting evidence；
• context formatting；
• model reasoning；
• model capability；
• grounding evaluator。

而不是继续调 embedding。

Faithfulness 与 Correctness 不相同

假设 Evidence 没有提到 B，但模型凭参数知识说了 B，而 B 恰好在现实世界中是真的。

那么可能：

Correctness = true
Faithfulness = false

当合同要求该 claim 必须由指定证据支持时，这个区别很重要，系统需验证：

这个结论来自当前 Evidence

而不是“模型刚好知道”。

详见 RAG Grounding / Faithfulness 校验。

Layer 6：Answer Relevance

即使回答全部有依据，也可能答非所问。

例如用户问：

“我现在应该先观察什么？”

模型回答一大段：

“梨状肌的解剖位置是……”

内容可能完全 faithful，但：

Relevance 低

所以：

faithful
!= relevant

Layer 7：Citation Correctness 与 Completeness

Citation Correctness

问：

[1] 真的支持紧邻的 Claim 吗？

Citation Completeness

问：

所有应该引用的重要 Claim 都有来源吗？

因此：

citation exists
!= citation correct
!= claim grounded

漂亮的 Citation UI 只是透明度能力，不是 correctness proof。

Layer 8：Safety / Business Correctness

一个输出可以：

fully grounded ✅

但仍然因为当前用户状态或 red flag：

Safety blocked

因此：

Faithfulness
!= Safety
!= DecisionAuthority

这在 BodySense Diagnosis/Treatment 特别重要。

Golden Dataset 应该保存什么

最简单可以从：

from dataclasses import dataclass

@dataclass
class GoldenCase:
    query: str
    relevant_doc_ids: list[str]
    expected_answer: str | None = None
    expected_intent: str | None = None
    risk_stratum: str = "normal"
    critical_evidence_ids: list[str] | None = None

开始。

更成熟后可以增加：

• required facts / claims；
• expected evidence type；
• forbidden / contradicted claims；
• source/admissibility requirements；
• expected decision outcome；
• expected citation mapping。

数据来源

来源	优点	缺点
人工标注	可引入领域判断	成本高，仍需准则与一致性复核
历史真实对话	真实分布	需要脱敏/审核
LLM 辅助生成	扩量快	必须人工校验
Knowledge Unit 反向构造	覆盖知识库	Query 可能不自然

Risk-stratified Eval：不要只看平均数

BodySense 不能把所有 RAG query 混在一起算一个：

Recall@5 = 95%

因为可能实际是：

exercise recall = 99%
red-flag / contraindication recall = 70%

平均很好，但安全上不可接受。

因此 dataset 应分 slice：

definition
cause
self-check
exercise
contraindication
red flag
escalation knowledge

并对高风险 Evidence 使用更严格的 hard gate，例如：

critical evidence recall

具体阈值由 benchmark 与业务风险决定，原则是：

不同 Evidence 的漏召回成本不同。

组件升级时应该控制变量

换 Embedding Model

优先比较：

Recall@K
MRR / candidate ranking
latency
cost
critical evidence recall

不要只看最终 Diagnosis Accuracy，因为中间还有 Reranker、Prompt、Model 等变量。

换 Reranker

冻结 Retriever candidate set，比较：

Recall@final K
Precision@K
MRR / NDCG
critical evidence retention

换 Prompt / Model

冻结 Evidence set，比较：

Faithfulness
Answer relevance
Decision correctness
Safety behavior

这是组件对照评测。还需固定语料、权限、配置和 evaluator，考虑模型随机性；组件效果明确后再跑端到端回归，检查组件间交互。

离线 Eval 与运行时 Guardrail 的关系

维度	离线 Eval	运行时 Guardrail
时机	上线前 / 变更后	每次生产请求
目的	发现系统性退化	拦住单次危险/不合格输出
输入	Golden Dataset	当前 Run
结果	指标 + failure slices	单次 verdict / reason code
典型例子	Recall@K, MRR, Faithfulness rate	invalid provenance, unsupported claim

二者互补：

Offline Eval
→ 在指定数据集与门槛下提供上线资格证据，不证明所有请求都安全

Runtime Guardrail
→ 尝试拦截当前可检测的违约；判定与执行边界仍可能失败

一个最小 Eval Pipeline

for each GoldenCase:
    1. verify knowledge coverage
    2. run retriever → record candidate ranks
    3. run reranker → record final ranks
    4. record actual evidence delivered
    5. generate answer / decision
    6. evaluate faithfulness
    7. evaluate relevance / citation / safety
    8. store observed failure layers + reason codes + evidence gaps

最终报告不应该只给平均数，而应该同时有：

aggregate metrics
+
risk slices
+
failed cases
+
observed failures / attribution confidence
+
configuration identity

常见错误

“Final Answer 错了，所以换更强 LLM”

错误。先检查 Knowledge → Retriever → Reranker → Evidence Delivery → Faithfulness 的第一处违约。

“Retriever Top-30 找到了，但 Top-5 没有，所以 Embedding 差”

不一定。如果 Candidate 已经召回，优先查 Reranker。

“Faithfulness 高，所以 Answer 一定好”

错。它可能完全忠实地回答了一个与用户问题无关的内容。

“Citation 存在，所以 Grounded”

错。Citation 可能指错，也可能来源根本不支持 claim。

“平均 Recall 很高，所以可以上线”

错。必须看 critical/risk strata。

“运行时 checker 可以代替离线 eval”

错。一个负责系统性 qualification，一个负责单次 runtime guard。

自测题

1. Knowledge Coverage failure 与 Retriever failure 如何区分？
2. E42 在 Retriever Top-30 排第 7，但被 Reranker Top-5 淘汰，应该归因哪一层？
3. Retriever 为什么通常更偏 Recall，Reranker 为什么更偏 Precision/Ranking？
4. MRR 主要回答什么问题？
5. E42 已经进入 Agent Context，但 Agent 给出与它明确矛盾的 Claim，应优先看哪一层？
6. Faithfulness 与 Correctness 有什么区别？
7. Citation Correctness 与 Citation Completeness 有什么区别？
8. 为什么不能只看整个 Dataset 的平均 Recall？
9. 换 Embedding、换 Reranker、换 Prompt 时为什么应该评不同指标？
10. Offline Eval 与 Runtime Guardrail 各自解决什么？

最终心智

Knowledge exists?
→ Retriever found it?
→ Reranker kept it?
→ Runtime actually delivered it?
→ Evidence admissible?
→ Model followed it faithfully?
→ Answer relevant?
→ Citation correct?
→ Safety / Authority allows it?

生产级 Eval 的核心不是“分数越多越专业”，而是：每个指标对应一个明确组件职责，从可观察的违约定位调查范围，并明确证据不足与多因素归因的边界。