W3D5 学习手册 1.总览2.测试集3.Case字段4.检索指标5.生成指标 6.引用7.拒答8.RAGAS9.LangSmith10.实战 11.报告12.坑达标①达标②自测速记

FDE W3D5 学习手册 · RAG 评测

W3 Day5 · A 级(必须掌握,面试核心)· 4h · 学完能讲透"RAG 评测的核心指标、50 条测试集怎么建、一个 Case 怎么设计、拒答准确率怎么测"

本日定位:W3D4 讲了 Query 优化与可靠性机制,W3D5 讲"怎么用指标和数据证明 RAG 真的好用"。这是把作品一从"能跑"变成"可量化、可交付"的关键,也是面试深挖点。
学完能回答:① RAG 评测的核心指标(检索类 + 生成类)分别衡量什么;② 一个 Case 的完整字段设计和拒答准确率怎么测。
使用方法:通读原理 → 重点看「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W3D5-评测题.md》。选中不熟的词可标注(左下★重要 / 右下📌待查)。
参考资源:B站 RAG 评估(LangSmith+RAGAS)BV1aZ421W7DB;B站 2025 最全 RAG 教程(含 RAGAS)BV1D37GzLEe5;RAGAS 官方文档 docs.ragas.io;RAGAS GitHub(explodinggradients/ragas)。

一、RAG 评测总览:测什么、为什么测

RAG 系统由"检索"和"生成"两段组成,评测也分两层:检索质量(召回对不对、排得合不合理)和生成质量(答得忠不忠实、相不相关、引用准不准、该拒是否拒)。只测最终答案会掩盖"检索就错了"的根因,所以必须分层评测。

检索层:Hit Rate@K / Recall@K / Precision@K / MRR / nDCG@K 生成层:Faithfulness / Answer Relevancy / 引用准确率 / 拒答准确率
层级关注点不测会怎样
检索层是否召回相关文档、排序质量生成再强也"巧妇难为无米之炊"
生成层忠实、相关、引用、拒答召回对了也照样幻觉/答非所问
RAG 评测分两层:检索层看"召回对不对、排得好不好"(Hit Rate/Recall/Precision/MRR/nDCG);生成层看"答得忠不忠实、相不相关、引用准不准、该拒没拒"(Faithfulness/Answer Relevancy/引用准确率/拒答准确率)。
在保险知识库项目里,我们建了 50 条测试集,分检索层和生成层两套指标看板。一次迭代把 Faithfulness 从 0.82 提到 0.94,靠的不是调 prompt,而是修了检索——这正说明分层评测让你"知道该改哪"。

二、测试集建设:把评测集扩充到 50 个 Cases

2.1 为什么要 50 条、怎么来

太少不具统计意义,太多标注成本高。W3D5 目标 50 个 Case

2.2 为什么要"人工抽检"而非全人工

全人工 50 条成本高、周期长;完全模型生成又易同质化、漏边界。折中:模型批量生成骨架,人工只做"抽检 + 修正 + 补边界 case",既扩量又保底质量,还覆盖拒答/越权/长尾等难例。

2.3 分布设计

类型占比建议说明
事实问答~40%条款/比例/时效等可定位答案
多跳/复合~20%需多文档推理
应拒答~15%知识库无依据 / 越权 / 违规
模糊/歧义~15%需澄清或落具体意图
边界/长尾~10%极端输入、对抗样本
测试集 50 条 = 20 条人工 Golden(金标准)+ 30 条模型辅助生成人工抽检(扩量保底)。分布要覆盖事实/多跳/应拒答/模糊/边界,不能只测"好答的"。
① 模型生成的 case 容易"长得都像"——要在抽检时特意补拒答、越权、长尾难例,否则评测集偏科,线上照样翻车。② 每个 case 必须固定 document_version,知识库更新后老 case 要重标,否则指标不可比。③ 别把"模型生成 case 时的答案"直接当标准答案——它也可能错,需人工确认关键 points。

三、一个 Case 的完整字段设计

每个 Case 是一行结构化记录,既是评测输入也是评判依据:

字段含义示例(特药理赔)
case_id唯一编号C0001
question用户问题(可含画像上下文)"百万医疗下奥希替尼能报多少?"
question_type问题类型(事实/多跳/拒答/模糊…)fact / multi_hop / refuse / ambiguous
expected_document_ids期望召回的文档 id 列表[doc_特药目录, doc_报销比例条款]
expected_chunk_ids期望命中的 chunk id 列表[chunk_xxx_12, chunk_yyy_03]
answer_key_points答案关键得分点(用于生成评判)["在特药目录内","报销比例 80%","有免赔额 1 万"]
should_refuse是否应拒答false / true
allowed_roles允许回答的角色/权限[policy_holder, agent](排除未授权)
document_version知识库版本,保证可复现v2026.07
字段设计原则:expected_document_ids / expected_chunk_ids 给检索层判分用;answer_key_points 给生成层判分用;should_refuse + allowed_roles 给"拒答/越权"专门测;document_version 保证知识库变更后指标可比、可溯源。
一个 Case 字段 = case_id / question / question_type / expected_document_ids / expected_chunk_ids / answer_key_points / should_refuse / allowed_roles / document_version。前两个管检索判分,key_points 管生成判分,refuse+roles 管安全,version 管可复现。
① expected_chunk_ids 要精确到 chunk 而非整篇文档,否则"召回了文档但找错段落"测不出来。② allowed_roles 容易被忽略,但它是"防止知识库越权"的评测抓手,面试常问。③ document_version 不固定会导致同一条 case 不同时间得分漂移,指标失效。

四、检索类指标:Hit Rate@K / Recall@K / Precision@K

4.1 Hit Rate@K(命中率)

在 top-K 召回里,至少命中一个相关文档的 query 占比。衡量"检索能不能把对的文档捞上来"。

HitRate@K = (命中≥1相关文档的 query 数) / 总 query 数

4.2 Recall@K(召回率)

top-K 中相关文档占全部相关文档的比例。衡量"相关文档漏没漏"。

Recall@K = |相关∩topK| / |全部相关文档|

4.3 Precision@K(精确率)

top-K 中相关文档占 top-K 总数的比例。衡量"捞上来的是不是都对"。

Precision@K = |相关∩topK| / K
指标问的问题保险场景解读
Hit Rate@K有没有捞到对的?至少把特药目录那篇召回了没
Recall@K相关的是不是都捞到了?所有涉及奥希替尼的条款是否都在 topK
Precision@K捞上来的对不对?topK 里多少是真相关的,噪声多不多
Hit Rate@K = "至少命中一个相关的 query 占比"(有没有捞到);Recall@K = "相关文档被捞到比例"(漏没漏);Precision@K = "捞上来的里相关的比例"(噪声多不多)。三者一起看检索质量。
① 一个 query 可能"相关文档很多",Recall@K 会被 K 限制——K 越大 Recall 越高,所以必须固定 K 再横向比。② Hit Rate 只看"有没有",掩盖"只捞到一个但漏了关键那个",所以还要看 Recall。③ 这些指标依赖 expected_document_ids / chunk_ids 标注得准,标注错指标全错。

五、生成类指标:Faithfulness / Answer Relevancy

5.1 Faithfulness(忠实度)

答案是否完全基于检索到的上下文,没有编造、没有超出上下文的断言。这是"防幻觉"的核心指标。

Faithfulness = 答案中被上下文支持的表述 / 答案全部表述

5.2 Answer Relevancy(答案相关性)

答案是否切题、回答了问题本身,不管对错,先看"有没有答到点上"。

指标测的是坏的例子
Faithfulness答案有没有编上下文没写比例,答案硬说"报销 90%"
Answer Relevancy答案切不切题问比例,答了一堆流程
Faithfulness = "答案是否完全基于检索上下文、没编造"(防幻觉核心);Answer Relevancy = "答案是否切题、答到点上"(不管对错先看切不切题)。两指标互补:一个管"真不真",一个管"对不对题"。
① Faithfulness 高 ≠ 答案对——可能"忠实于错误/无关上下文",所以必须配合 Answer Relevancy 和检索指标。② 用 LLM 当裁判(LLM-as-judge)有偏见(偏好长答案、自评偏高),要校准、必要时人工抽检纠偏。③ Faithfulness 评测本身依赖检索上下文传入正确,检索错了它也会"忠实于错误上下文"。

六、引用准确率(Citation Accuracy)

答案中每条结论对应的引用(chunk_id)是否真实存在且真支持该结论。是 Faithfulness 在"可审计"维度的延伸。

维度判定
引用存在性引用的 chunk_id 在知识库中真实存在(无虚构 id)
引用正确性该 chunk 内容确实支持对应 claim(无张冠李戴)
引用完整性关键结论都有引用,而非仅部分挂来源
保险场景引用错 = 审计事故。我们的做法:生成时答案 JSON 强制 citations:[{claim, chunk_id}];评测时脚本先校验 id 存在,再用 LLM 判"该 chunk 是否支持该 claim",引用准确率 = 正确引用数 / 总引用数。
引用准确率 = 引用真实存在 + 真支持该结论 + 关键结论都挂了来源。是 Faithfulness 的可审计延伸;保险场景直接关系到合规,必须可回溯、可复核。

七、拒答准确率(Refusal Accuracy)

7.1 为什么单独测

RAG 的"安全底线"是不知道就说不知道。拒答准确率衡量系统对"应拒答"样本的识别能力,与 Faithfulness 互补——前者防"乱答",后者防"硬编"。

7.2 怎么测

在测试集中标 should_refuse=true 的 case 上计算:

拒答精确率 = 正确拒答数 / 系统判定拒答的总数 拒答召回率 = 正确拒答数 / 应拒答总数(should_refuse=true) 拒答 F1 = 2·P·R / (P+R)
判定口径:不能只看"是否含拒答话术",还要确认"没在拒答里夹带答案/越权信息"。allowed_roles 也在此校验——无权限角色提问应拒。
拒答准确率在 should_refuse=true 的 case 上算精确率/召回率/F1:精确率看"拒的是不是都该拒"(防误答幻觉),召回率看"该拒的是不是都拒了"(防漏答)。两者要一起看。
① 只报"拒答率"没意义——要同时看精确率和召回率,否则系统"一律拒答"精确率虚高但召回崩。② 拒答判定别只靠关键词("我不知道"),要结合 should_refuse 字段 + 语义。③ allowed_roles 越权拒答要单独统计,它是"防知识库越权"的评测证据。

八、RAGAS 框架(检索 + 生成一体化评测)

8.1 是什么

RAGAS(GitHub: explodinggradients/ragas,文档 docs.ragas.io)是开源的 RAG 评测框架,提供无需/少需人工标注的指标:

8.2 怎么用(思路)

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall
import datasets

# 每条样本: question, contexts(检索结果), answer, reference(可选)
dataset = datasets.Dataset.from_dict({
    "question": [...], "contexts": [[...]], "answer": [...],
    "reference": [...]   # 有 golden 时可算 answer_correctness
})
results = evaluate(dataset, metrics=[faithfulness, answer_relevancy,
                                     context_precision, context_recall])
print(results)

8.3 局限

RAGAS 是开源 RAG 评测框架,提供 faithfulness / answer_relevancy / context_precision / context_recall 等指标,很多用 LLM 当裁判、少人工标注。适合快速建基线,但中文领域要校准,且裁判有偏需人工抽检。

九、LangSmith 评测实践(可观测 + 数据集)

LangSmith 提供数据集(Dataset)+ 线上追踪(Tracing)+ 在线评测。思路:

LangSmith vs RAGAS 定位:RAGAS 偏"指标算法库",LangSmith 偏"实验平台 + 可观测 + 数据集管理"。实际常组合:RAGAS 指标 + LangSmith 跑数据与看 Trace(B站 BV1aZ421W7DB 有实操演示)。
LangSmith = 数据集 + 追踪 + 在线评测平台。把 50 case 建成 Dataset,写 evaluator 跑各指标,每条留 Trace 定位"检索/生成哪步错",每次改动做回归对比。常和 RAGAS 指标组合用。

十、医疗保险实战:特药理赔评测集

示例 Case(C0012,多跳):

case_id: C0012
question: "投保人有重疾险和百万医疗,确诊肺癌用奥希替尼,两份各自报多少、有先后吗?"
question_type: multi_hop
expected_document_ids: [doc_重疾条款, doc_百万医疗条款, doc_补偿关系说明]
expected_chunk_ids: [chunk_重疾_肺癌给付, chunk_医疗_靶向报销, chunk_补偿_顺序]
answer_key_points: ["重疾按保额给付","医疗报销靶向药比例80%","医疗补偿重疾已付部分","无重复超额"]
should_refuse: false
allowed_roles: [policy_holder, agent]
document_version: v2026.07

评测执行:检索层看该 3 个 chunk 是否进 topK(Recall@K / Hit Rate);生成层看答案是否覆盖 4 个 key_points(Answer Relevancy/Correctness)、是否忠实(Faithfulness)、引用是否指向正确 chunk(引用准确率)。

我们 50 条里专门放 8 条 should_refuse=true(如无该城市异地细则、越权查他人保单),用来盯拒答准确率;放 5 条 allowed_roles 越权 case 盯"防越权拒答"。这两条是保险合规的生死线,必须进评测集。

十一、评测报告怎么写、怎么迭代

11.1 报告结构

11.2 迭代闭环

跑评测 → 看分层指标 → 定位短板子集 → 改检索/Query/生成 → 回归对比 → 补 bad case 进集
评测报告 = 概览 + 分层指标 + 分类型细分 + 典型 bad case + 结论。迭代闭环:跑分→看短板子集→改对应环节→回归对比→把 bad case 补回测试集,让集子越测越硬。

十二、常见坑与排查清单

十三、面试达标线①:核心指标分别衡量什么

类别指标衡量什么
检索Hit Rate@KtopK 里是否至少命中一个相关文档(有没有捞到)
Recall@K / Precision@K相关文档漏没漏 / 捞上来的对不对(噪声)
MRR / nDCG@K第一个相关项排多前 / 排序质量(位置加权)
生成Faithfulness答案是否基于上下文、有无编造(防幻觉)
Answer Relevancy答案是否切题、答到点上
引用准确率引用真实存在且真支持结论(可审计)
拒答准确率应拒答的是否正确拒(防乱答/越权)
核心话术:检索类指标管"召回对不对、排得好不好"(Hit/Recall/Precision 看覆盖与噪声,MRR/nDCG 看排序位置);生成类指标管"答得忠实不忠实、切不切题、引用准不准、该拒没拒"(Faithfulness/Relevancy/引用/拒答)。必须分层看。

十四、面试达标线②:Case 字段设计 + 拒答准确率怎么测

14.1 一个 Case 的完整字段

case_id / question / question_type / expected_document_ids / expected_chunk_ids / answer_key_points / should_refuse / allowed_roles / document_version

14.2 拒答准确率怎么测

  1. 在测试集标 should_refuse=true 的 case(含越权 allowed_roles 不符)。
  2. 系统输出 should_refuse 判定 + 理由。
  3. 计算:精确率 = 正确拒答 / 系统拒答总数(防误答幻觉);召回率 = 正确拒答 / 应拒答总数(防漏答);F1 综合。
  4. 单独统计 allowed_roles 越权拒答,作为"防知识库越权"证据。
Case 九字段覆盖"检索判分 + 生成判分 + 安全拒答 + 可复现";拒答准确率在 should_refuse=true 子集上算精确率/召回率/F1,并单独看 allowed_roles 越权拒答——两者都达标才算"拒答可靠"。

十五、W3D5 自测清单

十六、高频面试题速记卡

Q:RAG 评测为什么要分检索层和生成层?
只测最终答案会掩盖"检索就错了"的根因。检索层看召回/排序,生成层看忠实/相关/引用/拒答,分层才能定位该改哪。
Q:Hit Rate@K 和 Recall@K 有什么不同?
Hit Rate@K 看"topK 里是否至少命中一个相关"(有没有捞到);Recall@K 看"全部相关文档被捞到的比例"(漏没漏)。一个看有无,一个看覆盖。
Q:Faithfulness 和 Answer Relevancy 区别?
Faithfulness=答案是否基于上下文、没编造(防幻觉);Answer Relevancy=答案是否切题(不管对错先看答到点上)。要一起看。
Q:一个 Case 有哪些字段?
case_id/question/question_type/expected_document_ids/expected_chunk_ids/answer_key_points/should_refuse/allowed_roles/document_version。前两个管检索判分,key_points 管生成,refuse+roles 管安全,version 管可复现。
Q:拒答准确率怎么测?
在 should_refuse=true 子集算精确率(拒的是否都该拒,防幻觉)和召回率(该拒是否都拒,防漏答),F1 综合;并单独看 allowed_roles 越权拒答。
Q:为什么"一律拒答"不行?
那样拒答精确率虚高但召回率崩(漏答),用户问啥都拒体验差且业务损失。必须同时看精确率和召回率。
Q:RAGAS 和 LangSmith 什么关系?
RAGAS 是指标算法库(faithfulness 等,少人工标注);LangSmith 是实验平台(数据集+Trace+在线评测)。常组合:RAGAS 指标 + LangSmith 跑数据看 Trace。
Q:LLM 当裁判有什么坑?
有偏见(偏好长答案、自评偏高),要人工抽检校准,尤其 Faithfulness;且裁判依赖检索上下文传入正确。
Q:document_version 字段有什么用?
固定知识库版本,保证同一条 case 不同时间得分可比、可溯源;知识库更新后老 case 需重标,否则指标漂移失效。
Q:expected_chunk_ids 为什么要标到 chunk 级?
标到文档级会漏掉"召回了文档但找错段落"的问题,chunk 级才能精确判检索质量与引用准确性。
FDE W3D5 学习手册 · RAG 评测(面试级)· 配合《FDE-W3D5-评测题.md》自测
📌 待查★ 重要