跳到主要内容

评测 — 你不能修你量不到的东西

这一章讲三件事: 「答错了」到底有哪几种错法(失败分类学); 每种错用什么指标(量化的度量口径)量出来——分检索一族与生成一族; 以及评测怎么从「跑一次报告」变成持续运转的工程机制。 书里那句话是本章的地基:「you can't fix what you can't measure」 ——没有度量框架,质量随规模悄悄退化而不自知。

1. 顶层全景:失败先分层,指标再分族​

一个 RAG 系统的输出,要过三道手:摄入、检索、生成。每一道都会独立地坏, 所以评测的第一步不是选指标,而是把「答错了」拆成三层失败1:

  摄入层:解析坏、内容旧 ──→ 库里就是坏的(garbage in)
  检索层:没检到(漏)、检错了(噪声) ──→ 模型拿不到对的材料
  生成层:幻觉、没用全、答非所问 ──→ 材料对了,话没说对

  图说:定位失败发生在哪一层,比知道「分数掉了」重要得多——
  三层的修法完全不同。本章主走查:「项目上线的最终审批步是什么?」
  那个查询,看它在三层各怎么死。

2. 核心原理(一):失败分类学​

检索层的两种死法​

书里一句台词值得贴在墙上:「如果你的检索召回率是 40%, 再多 prompt 工程也救不了你的 RAG 应用。」2

  • 没检到(低召回):答案明明在库里,检索没让它浮出来。模型被逼进死角: 要么承认找不到,要么更危险地退回参数里的旧印象编一个;
  • 检错了(低精度):检索器「吵」——检回的块不含答案。 例:问 GitHub 新仓库的安全协议,检回一堆 GitHub 功能介绍3。

主走查:一个查询的三种死法​

书里这个走查把三层失败串在了一个查询上4:

  查询:「项目上线的强制最终审批步是什么?风险评估表提交截止?」

  库里三块:
     块A = Stakeholder Sign-off(相关)
     块B = 截止 72 小时前提交 Compliance Portal(相关)
     块C = Team Celebration 午餐预算(噪声,只因含「project」「launch」被检回)

  检索层死法:检回了 A、漏掉 B、拉进 C
     │
     ▼ 生成层接着死:
     输出答对了 sign-off(用了 A)、承认不知道截止时间(B 没检到,
     模型诚实地说了不知道)、还夹带了庆祝午餐的信息(C 的噪声进了答案)

  后果:用户以为没有 deadline → 错过合规窗口。

生成层的三种死法​

检索对了,生成还可能坏5:

失败样子书例
faithfulness failure(忠实性失败=幻觉)答案与块矛盾或无块支撑块明写「deadline is July 31st」,模型答「early August」
context utilization failure(上下文利用失败)块都对,模型没全用(比如只看了头尾两块)问「风险+收益」,只答了收益——不是幻觉,但「危险地不完整」
answer relevance failure(答非所问)句句有据,但没回答核心问题问「现在推更新安全吗?」答「更新含功能 A、B、C」——把推断负担丢回给用户

一个要分清的区分:faithful incorrectness(忠于块但块本身错, 比如旧版 PDF)与 unfaithful incorrectness(答案在源数据里根本不存在)。 前者修摄入与版本管理,后者才是模型的锅6。

摄入层的死法最阴险​

摄入失败会制造「可靠假象」:系统看着正常运转,地基是坏的7。 两种典型:结构解析错(表格被拆成无意义的词串,表现为表重文档的 检索相关性系统性偏低);内容陈旧(旧文档没删没版本化,模型「自信地」 把一年前的政策当现况)。解法:给每个实体配唯一 ID + 版本号, 新版摄入时删掉旧版的全部块8。

3. 核心原理(二):检索指标族​

传统信息检索(IR)的指标大多需要 golden chunks——人工整理的 「哪些块相关、按相关度排序」的清单。它的死穴是:数据一变,清单就过时9。

逐个看,每个量什么(这些缩写出门会撞见,都得留名):

  • precision@k(精确率):top-k 里有多少真相关——量的是信噪比。 上下文窗口有限时,它直接决定你塞进模型的材料有多干净10;

  • recall@k(召回率):库里所有相关块,被找回了多少——量的是完整性11;

  • F1:前两者的调和平均(调和平均偏向较小的那个,两者同等重要时用)12;

  • MRR(mean reciprocal rank):第一个相关结果的名次取倒数,跨查询平均—— 「快速找到一个好答案就够」的任务(客服)适用13;

  • MAP:在每个相关项出现的位置算 precision 再平均—— 把相关项排得越靠后罚得越狠,适合「相关块有好几个」的场景14;

  • nDCG:支持分级相关度(0-3 分而不是相关/不相关二元), 拿「实际排序的得分」除以「理想排序的得分」。最灵活也最重, 是「gold standard」;top-3/5 的小应用上它是杀鸡用牛刀15。

UMBRELA:不要 golden chunks 的评法​

golden chunks 难造,于是有了 reference-free(免参考答案)路线。 UMBRELA 让裁判模型给每个检回的块打 0-3 分16:

  查询:「光合作用是什么?」

  块1(光合作用的定义)        → 3:专门回答此问
  块2(叶绿素的作用)          → 2:有答案的一部分,但埋在别的叙述里
  块3(线粒体产生 ATP)        → 0:无关

  图说:0=无关;1=相关但没答案;2=有答案但不清楚;3=专门答此问。

它与人工评估高度相关;原始分可以直接用,也可以当 precision/nDCG 的输入。 召回率没法这么算(要给全库每块打分不现实)——本质是把人工标注换成 机器计算的成本17。

4. 核心原理(三):生成指标族​

  • faithfulness(忠实度):答案里每句话都能从检索块直接验证—— RAG 的核心承诺,用 HHEM 或裁判模型测18;
  • context utilization(上下文利用):用 AutoNuggetizer:先让模型从 「查询+块」里拆出 nuggets(原子事实——最小的一条条事实点),标出 vital(好答案必含)与 ok(锦上添花),再看答案覆盖了多少19;
  • citation accuracy(引用准确):引文是否真支撑那句话20;
  • response consistency(一致性):同一查询跑多次,事实实质应稳定—— 金融/医疗/法务的可审计要求让它成为硬指标21;
  • answer accuracy:需要 golden answer(标准答案)的两个指标—— 答案相似度(BERTScore/ROUGE-L,与标准答案比对)与答案切题度。 注意第 2 节那个「答非所问」的例子:相似度指标查不出这种失败, 因为每句话都和有答案的文本很像22。

5. 核心原理(四):裁判模型的三类偏差​

LLM-as-a-judge 的最大优点是灵活:评分标准用自然语言写(rubric), 任何维度都能评——简洁、口吻、因果推理都行;拿两个答案比较(pairwise) 比单独打分(pointwise)更稳23。但它不是即插即用的,书里列了要防的东西24:

偏差表现
self-referential bias(自我偏好)裁判偏自己风格/语调的答案;礼貌工整但错误的「AI 腔」胜过直白准确;把长度当质量
overestimation(高估)系统性高估 LLM 输出、低估确定性(每次运行结果一样的)输出
随机不稳定同一输入不同运行不同分;温度 0、固定种子也不保险

缓解办法:用人工核对过的 golden test set(校准集)去校准裁判25。 它与人工评判的一致程度还高度依赖任务:创意摘要它是专家级,复杂数学推理它会崩。

6. 核心原理(五):评测作为工程机制​

四个框架一句话​

框架一句话
Open RAG Eval(Vectara + 滑铁卢大学)全 reference-free 指标(UMBRELA/AutoNuggetizer/HHEM/引用/一致性),只要查询清单就能跑26
Ragas以裁判模型为主,与 LangChain/LlamaIndex 集成好,能从文档合成测试集;缺点:低分难诊断、要人造 golden 数据集27
DeepEval把评测写成单元测试,和 pytest 集成,适合 CI/CD(持续集成/持续部署:代码改动自动构建、测试、发布的流水线)回归(防旧功能被新改动弄坏的)测试28
Amazon Bedrock全托管,含 responsible AI 评测;代价是 judge 运营成本与透明度29

离线:评测是一道门​

评测要深植 CI/CD:新组件部署前过「evaluation gate」。 书里给了 no-regression(不许倒退)政策的具体形态:忠实度与检索相关性 不低于阈值、且不低于上一版;P95 延迟增幅 ≤5%。 基准数据集要和代码一起版本化,并把困难的真实用户查询不断提升进测试集30。

在线:异步、抽样、A/B​

在线评测有两难:真实查询没有 golden 数据集;每条查询都跑裁判模型, 成本翻倍。解法31:

  • 异步管线:响应立刻给用户,后台 worker 记录 query/context/answer 做 out-of-band(带外,不占用户等待时间)评测;
  • 智能抽样:抽 5-10% 的交互,统计上足够看系统健康;
  • A/B 测试(把流量随机分给新旧两版对比效果)是金标准:新管线(challenger)与老管线(champion)分流对比;
  • 反馈飞轮(evaluation flywheel):自动异步打分 + 实时人工反馈(赞/踩), 抓线上退化,把高价值失败案例提升回离线 golden 数据集——离线在线连成环。

系统指标是一等公民​

答案完美但慢/常挂/贵 = 失败。按组件分解延迟找瓶颈;uptime 目标 99.9%+; 评测本身是第二层成本(裁判吃词元),也要有预算32。

人工反馈的四个用法​

赞/踩按钮背后是 User Satisfaction Rate(赞 ÷ (赞+踩)),作主 KPI。 四个用法:总体满意度;按主题分类(产品问题 95% 赞 vs 账单问题 60% 赞 → 账单知识库有病);相关性分析(低忠实度是否与踩强相关?是→自动指标可信); 失败分析(踩最多的交互找根因)33。

7. 作者的判断与证据​

  • 「先优化检索器、再动负责生成的 LLM」是作者的排序建议,论证(检索封顶)成立;
  • UMBRELA 与人工评估的高相关性有论文支撑(它来自作者机构与滑铁卢大学的 合作研究,利益相关但已发表);
  • judge 偏差引用了 Zheng et al. 等研究,属学术共识;
  • 抽样 5-10% 是经验值,不是统计推导。

8. 边界与局限​

  • 没有普适指标集:有的用例要高召回,有的要忠实度+低延迟——按目标选, 书里最后明说了这一点34;
  • reference-free 指标仍依赖裁判模型,裁判换了分数会漂—— 「evaluation drift」:分数变了不是 RAG 变了,是尺子动了。裁判也要版本化35;
  • 多模态评测本章没覆盖,在第 14 章;
  • agent 的评测(任务完成度、自主性)在第 13 章。

9. 可带走的​

  1. 先分层再选指标:摄入/检索/生成三层失败,修法互不通用;
  2. 检索 40% 召回时,别碰 prompt;
  3. 指标按需选:客服用 MRR,多相关块用 MAP,分级相关用 nDCG,没有 golden 用 UMBRELA;
  4. 相似度指标查不出「答非所问」——切题度要用裁判或 AutoNuggetizer;
  5. 裁判模型要校准、要版本化,防 evaluation drift;
  6. 评测进 CI/CD:no-regression 门(质量不降 + P95 增幅 ≤5%);
  7. 在线 = 异步 + 抽样 5-10% + A/B;人工反馈是飞轮另一半;
  8. 系统指标(延迟/uptime/成本)与质量指标同为一等公民。

10. 原文地图​

主题原书章原文位置
40% 召回台词Retrieval Failurestext/62-fm-retrieval-failures.txt:10(搜「40%」)
审批步走查Retrieval Failurestext/62-fm-retrieval-failures.txt:67(搜「Stakeholder Sign-off」)
生成三失败Generation Failurestext/63-fm-generation-failures.txt:17(搜「July 31」) · :41(搜「AutoNuggetizer」)
摄入失败、实体 IDFailures Due to Inadequate Data Ingestiontext/64-fm-failures-due-to-inadequate-data-ingestion.txt:32(搜「entity ID」)
可靠假象Summary of RAG Failurestext/65-fm-summary-of-rag-failures.txt:4(搜「reliability」)
judge 灵活性与偏差What Is LLM-as-a-Judge?text/66-fm-what-is-llm-as-a-judge.txt:7(搜「flexibility」) · :29(搜「self-referential」) · :20(搜「pairwise」)
golden chunksRetrieval Metricstext/68-fm-retrieval-metrics.txt:7(搜「golden」)
precision/recall/F1Retrieval Metricstext/68-fm-retrieval-metrics.txt:21(搜「precision@k」) · :37(搜「recall@k」) · :62(搜「F1」)
MRR/MAP/nDCGRetrieval Metricstext/68-fm-retrieval-metrics.txt:87(搜「MRR」) · :121(搜「MAP」) · :151(搜「nDCG」)
UMBRELA 与光合作用走查Retrieval Metricstext/68-fm-retrieval-metrics.txt:10(搜「UMBRELA」) · :277(搜「photosynthesis」)
生成指标族Generation Metricstext/69-fm-generation-metrics.txt:92(搜「faithfulness」) · :23(搜「citation」) · :101(搜「consistency」)
Open RAG EvalOpen RAG Evaltext/71-fm-open-rag-eval.txt:4(搜「reference-free」)
Ragas/DeepEval/Bedrock同名节text/72-fm-retrieval-augmented-generation-assessment.txt:4(搜「ragas」) · text/73-fm-deepeval.txt:7(搜「pytest」) · text/74-fm-amazon-bedrock.txt:7(搜「Claude」)
离线门Offline RAG Evaluationtext/76-fm-offline-rag-evaluation.txt:7(搜「no-regression」)
在线抽样、A/B、飞轮Online RAG Evaluationtext/77-fm-online-rag-evaluation.txt:27(搜「sampling」) · :30(搜「A/B」)
人工反馈四用法Amazon Bedrock(同文件内 Human Feedback 节)text/74-fm-amazon-bedrock.txt:39(搜「thumbs」)
evaluation driftUsing LLM-as-a-Judge in Productiontext/75-fm-using-llm-as-a-judge-in-production.txt:13(搜「drift」)

Footnotes​

  1. 出处:「Chapter 6. Evaluating Your RAG Application」第 39 段(text/61-ch06-chapter-6-evaluating-your-rag-application.txt:39,搜「component」)。 ↩

  2. 出处:「Retrieval Failures」第 10 段(text/62-fm-retrieval-failures.txt:10,搜「40%」)。召回率的定义见第 3 节。 ↩

  3. 出处:「Retrieval Failures」第 49 段(text/62-fm-retrieval-failures.txt:49,搜「irrelevant」)。 ↩

  4. 出处:「Retrieval Failures」第 62-96 段(text/62-fm-retrieval-failures.txt:67,搜「Stakeholder Sign-off」)。 ↩

  5. 出处:「Generation Failures」第 11-59 段(text/63-fm-generation-failures.txt:17,搜「July 31」)。 ↩

  6. 出处:「Generation Failures」第 23 段(text/63-fm-generation-failures.txt:23,搜「faithful incorrectness」)。 ↩

  7. 出处:「Summary of RAG Failures」第 4 段(text/65-fm-summary-of-rag-failures.txt:4,搜「reliability」)。 ↩

  8. 出处:「Failures Due to Inadequate Data Ingestion」第 26-34 段(text/64-fm-failures-due-to-inadequate-data-ingestion.txt:32,搜「entity ID」)。 ↩

  9. 出处:「Retrieval Metrics」第 7 段(text/68-fm-retrieval-metrics.txt:7,搜「golden」)。 ↩

  10. 出处:「Retrieval Metrics」第 21 段(text/68-fm-retrieval-metrics.txt:21,搜「precision@k」)。 ↩

  11. 出处:「Retrieval Metrics」第 37 段(text/68-fm-retrieval-metrics.txt:37,搜「recall@k」)。 ↩

  12. 出处:「Retrieval Metrics」第 62 段(text/68-fm-retrieval-metrics.txt:62,搜「F1」)。 ↩

  13. 出处:「Retrieval Metrics」第 87 段(text/68-fm-retrieval-metrics.txt:87,搜「MRR」)。 ↩

  14. 出处:「Retrieval Metrics」第 121 段(text/68-fm-retrieval-metrics.txt:121,搜「MAP」)。 ↩

  15. 出处:「Retrieval Metrics」第 151-186 段(text/68-fm-retrieval-metrics.txt:151,搜「nDCG」)。nDCG=normalized discounted cumulative gain;DCG 对排越后的相关项打的折扣越大,再拿理想排序的 DCG 归一。 ↩

  16. 出处:「Retrieval Metrics」第 197-238 段(text/68-fm-retrieval-metrics.txt:10,搜「UMBRELA」)与第 277-299 段(同文件,搜「photosynthesis」)。 ↩

  17. 出处:「Retrieval Metrics」第 7 段(text/68-fm-retrieval-metrics.txt:7,搜「recall」)。 ↩

  18. 出处:「Generation Metrics」第 92-104 段(text/69-fm-generation-metrics.txt:92,搜「faithfulness」)。 ↩

  19. 出处:「Generation Metrics」第 20-74 段(text/69-fm-generation-metrics.txt:28,搜「nuggets」)。 ↩

  20. 出处:「Generation Metrics」第 113 段(text/69-fm-generation-metrics.txt:113,搜「citation」)。 ↩

  21. 出处:「Generation Metrics」第 127-137 段(text/69-fm-generation-metrics.txt:101,搜「consistency」)。 ↩

  22. 出处:「Generation Metrics」第 86-92 段(text/69-fm-generation-metrics.txt:86,搜「answer similarity」)。 ↩

  23. 出处:「What Is LLM-as-a-Judge?」第 7 段(text/66-fm-what-is-llm-as-a-judge.txt:7,搜「flexibility」)与第 20 段(同文件,搜「pairwise」)。 ↩

  24. 出处:「What Is LLM-as-a-Judge?」第 26-32 段(text/66-fm-what-is-llm-as-a-judge.txt:29,搜「self-referential」)与第 50-100 段(同文件,搜「temperature」)。 ↩

  25. 出处:「What Is LLM-as-a-Judge?」第 100 段(text/66-fm-what-is-llm-as-a-judge.txt:100,搜「golden test set」)。 ↩

  26. 出处:「Open RAG Eval」第 4-14 段(text/71-fm-open-rag-eval.txt:4,搜「reference-free」)。 ↩

  27. 出处:「Retrieval-Augmented Generation Assessment」第 4-16 段(text/72-fm-retrieval-augmented-generation-assessment.txt:4,搜「ragas」)。补充(不在书里,依据我们的 frontier 书架):shelf=ai-frontier-reference/ragas 有该库的拆解,事实=docs/ragas 目录存在。 ↩

  28. 出处:「DeepEval」第 4-16 段(text/73-fm-deepeval.txt:7,搜「pytest」)。 ↩

  29. 出处:「Amazon Bedrock」第 4-22 段(text/74-fm-amazon-bedrock.txt:7,搜「Claude」)。 ↩

  30. 出处:「Offline RAG Evaluation」第 4-13 段(text/76-fm-offline-rag-evaluation.txt:7,搜「no-regression」)。 ↩

  31. 出处:「Online RAG Evaluation」第 24-30 段(text/77-fm-online-rag-evaluation.txt:27,搜「sampling」;:30,搜「A/B」)。 ↩

  32. 出处:「Latency and Throughput」第 4 段(text/78-fm-latency-and-throughput.txt:4,搜「P95」)与「Cost and Resource Efficiency」第 7 段(text/80-fm-cost-and-resource-efficiency.txt:7,搜「evaluation budget」)。 ↩

  33. 出处:「Amazon Bedrock」文件内 Human Feedback 节,第 39-129 段(text/74-fm-amazon-bedrock.txt:39,搜「thumbs」)。 ↩

  34. 出处:「Cost and Resource Efficiency」文件内结论节,第 21-77 段(text/80-fm-cost-and-resource-efficiency.txt:71,搜「strategic business lever」)。 ↩

  35. 出处:「Using LLM-as-a-Judge in Production」第 13 段(text/75-fm-using-llm-as-a-judge-in-production.txt:13,搜「drift」)。 ↩