检索与回答评估

学习目标

读完本课你能把「答得好不好」拆成三个可独立判定的问题——检索命中了吗、引用支持吗、答案一致吗——并且能用分层结果定位失败发生在哪一环，而不是拿着一个总分干瞪眼。

问题场景

总分 80% 的评估报告看起来不错，但你没法回答老板的追问：「那 20% 错在哪？」是资料根本搜不到？搜到了但引用错了？还是引用没错、模型自己跑偏了？三种原因对应三种修法（改索引、改引用生成、改提示），总分把它们搅在一起，修哪个都靠猜。分层评估的意义就是让每一环自己报数。

核心解释

对着 A31 的评估集，每一层独立判定（样例里都写好了期望）：

第一层：检索评估——期望的片段进没进 top-k？判定输入是检索命中列表，输出 hit/miss。它不关心答案长什么样。

第二层：引用评估——回答附带的引用，是否指向期望片段？引用内容是否支持结论（A22 的核对流程自动化）？它不关心语言质量。

第三层：答案评估——回答是否表达了期望行为：该说的说了吗（must_state）、该承认没有的承认了吗（must_admit_missing）、不该编的没编吗（must_not_invent）？

// 分层评估的骨架：每层独立打分，失败层级决定下一步查什么
async function evalCase(c: EvalCase) {
  const retrieved = await searchDocuments(c.question);
  const retrieval = c.expect.retrieve
    ? judgeRetrieval(retrieved, c.expect.retrieve)   // 命中的片段里有期望文档/标题吗
    : null;

  const answer = await generate(c.question, retrieved); // 用与线上一致的管道生成
  const citation = c.expect.citation?.required
    ? judgeCitation(answer.refs, answer.claims)      // 引用存在且支持结论（A22 核对）
    : null;

  const answerEval = judgeAnswer(answer.text, c.expect.answer); // must_state / must_admit_missing

  return { id: c.id, retrieval, citation, answerEval };
}

失败定位的推理表——这是分层评估的真正产出：

retrieval	citation	answer	结论
miss	-	差	检索层问题：改切分/索引/查询改写（A19/A21/A23）
hit	无引用或引用错	差	引用链问题：服务端引用生成或核对（A22）
hit	引用支持	编造了引用外内容	生成层问题：改提示或加约束（A18/A28）
hit	引用支持	一致	通过

如何验证评估器可信：故意注入一个坏检索（把某样例的查询词改到零命中），跑一遍，确认报告显示的是「retrieval miss」而不是笼统的「失败」——分层结果能还原你人为制造的故障，评估器才算可用。

示例拆解

一份分层报告的样子（数字会说话）：

{
  "run": "2026-10-26 prompt-v3",
  "cases": 10,
  "layers": {
    "retrieval": { "pass": 8, "miss": 2 },
    "citation":  { "pass": 7, "unsupported": 1 },
    "answer":    { "pass": 7, "admit_missing_ok": 1, "invented": 1 }
  },
  "locate": "invented 的那例对应 case-edge（口语问题）：retrieval 命中但答案编了引用外内容 → 生成层，查提示约束"
}

关键点：

• 总分是给老板看的，分层是给你修用的：同一份 run，报告页放三层通过率，行动页放失败定位表。
• answer 层的「invented」检查是安全指标：答案里出现引用范围外的具体事实（数字、规则）就要标红——它对应 A18 的编造风险，是三层里唯一涉及「信任」的判定。
• 判定器允许用模型，但要留人工抽查：must_state 这类判定用关键词可自动化；「引用是否支持结论」语义判定可交给模型，但每次改动后抽 3-5 条人工复核，防评估器自己漂移。
• 每层判定只用自己需要的信息：检索判定别偷看答案，答案判定别只看引用——层间隔离，定位才准。

动手任务

1. 为 A31 写的 6 条样例跑一次手工分层评估：每条标出三层结果，画成一张「retrieval / citation / answer」三列表。
2. 找出你表格里至少一处失败，用本课的推理表定位到「哪一层、对应改什么」，写成一句话行动项。
3. 设计「评估器自检」：故意构造一个必然检索失败的样例（查询词与资料完全无关），验证分层报告能把它标成 retrieval miss 而不是 answer 失败。

常见错误

• 只算一个总分：80% 听起来及格，但检索 miss 和答案编造混在一起，改进无从下手。
• 三层全用一次「感觉不错」代替：没有独立判定，分层形同虚设。每层要有明确的判定输入与规则。
• 检索评估用「搜到东西」当通过：搜到 5 条不等于期望片段在其中。判定的必须是「期望的文档/标题出现在命中里」。
• 答案评估只看对没对，不查编造：must_not_invent 被跳过，编造风险在报告里隐身——最危险的漏检。

检查与复盘

自查清单：

• 能说出三层的判定输入与输出，以及层间为什么隔离
• 能用推理表把任意失败组合映射到「改哪一层」
• 能设计评估器自检（人为故障 → 分层报告还原）

参考资料

• OpenAI 文档：API Reference - Evals —— 多指标评估的官方数据结构
• RAGAS 文档 —— RAG 分层评估（检索/引用/答案）的成熟指标体系
• 下一课 A33 给系统加最后一道保险：改了之后，回归跑一遍。