Appearance
怎么判断检索真的变好了：Retrieval 与 RAG Evaluation
前置：Agent 什么时候该检索：Pre-Retrieval、Retrieval Tool 与 Failure Modes
为每个 query 标记 relevant docs/chunks，计算 Recall@K、MRR/nDCG，并单独统计 ACL/filter 失败。如果 RAG 只读取前 3 个 chunk，排名质量比 top-100 总 recall 更关键；若 reranker 有大候选池，第一阶段更重 recall。
Retrieval Evaluation
Retrieval Eval 只评价“候选有没有找对、排对”，使用带 relevant document/chunk 标注的数据集，把 Retriever 从生成模型中解耦。数据集应包含精确术语、长尾、时间/权限 filter 等容易暴露检索弱点的 slice。
Recall / Precision / MRR / nDCG 基础
Recall@K 看需要的证据是否进入候选集；Precision@K 看 top-K 中有多少真正相关；MRR 强调首个相关结果的位置；nDCG 适合多级相关性并评价整体排序。指标选择要匹配消费方式：只要证据进入较大 candidate set 的 reranker 更关注 recall，用户直接看前几条结果则更看重前排质量。
RAG End-to-End Evaluation
End-to-End RAG Eval 从最终回答反查 evidence 使用质量：回答是否被实际检索证据支持、citation 是否指向正确版本、是否在无证据处扩写，以及最终 task 是否成功。它与 Retrieval Eval 必须同时保留——前者回答“证据有没有用对”，后者回答“证据有没有找对”；只看最终文字会让强模型掩盖 Retriever 的回归。
Eval Dataset 必须包含“容易失败”的切片
不要只采随机正常 query。应覆盖：同义改写、关键词精确匹配、时间新鲜度、权限 filter、长文档跨 chunk、多个近似候选、无答案 query。每次改 chunking/embedding/rerank 时按 slice 比较，才能知道优化到底修了哪类问题、又伤了哪类问题。
一次 Retrieval Eval 应该怎么拆
不要拿“最终回答正确率”直接替代 Retrieval Eval。假设有 100 个真实问题，每个问题都标注了能够支持答案的文档或 chunk。可以先只测 Retriever：
text
query: "resume 后为什么重复执行支付工具"
relevant chunks:
- checkpoint-boundary.md#pending-writes
- idempotency.md#external-side-effect
retrieved top-5:
1. checkpoint-boundary ... relevant
2. retry-budget ... partial
3. payment-api ... irrelevant
4. idempotency ... relevant
5. observability ... irrelevant这时可以计算 Recall@K、MRR、nDCG 等检索指标；然后再把同一批结果喂给生成阶段，单独测 grounded answer quality。这样当最终答案变差时，你能区分：
text
没有把证据检索出来 → retrieval problem
证据检索到了但模型没用好 → generation/context problem
引用了错误或过期证据 → grounding/freshness problem对 Agentic Retrieval 还应记录 是否本来就不该搜、搜了几次、query 是否被无效重写。否则一个“最终答对但搜索 12 次”的 Agent 会在普通 end-to-end accuracy 中被误判为优秀。
自测
- Recall@10 上升但最终答案准确率不变，说明优化可能停在哪一层？为什么不能用一个指标代表整个 RAG？
- 给一组带 relevant labels 的查询，Recall@K、MRR、nDCG 分别更强调什么，哪一种最能反映首个正确证据排名？