评测(上):题从哪来、谁来判、它判不了什么
这一章讲三件事: 为什么「试几个问题觉得还行」不算数、 拿什么题去试、以及谁来判卷、他判不了什么。
它在全书链条上的位置:它给前面十五章的每一处选择配一把尺子。 前面所有「该切多大」「该取几块」「该不该加这一招」, 依据都只是作者的经验;这一章开始有量。
1. 这一章讲什么
三句话:
- 书这一章的第一句话就把问题摆死了:「你无法改进你无法度量的东西。 没有评测,优化就成了猜。」——而前面十五章的每一处参数,你到现在都还是在猜;
- 这件事和「训练一个模型然后测它准不准」不是一回事, 而这个差别决定了题该从哪里来;
- 判卷可以交给模型,理由很具体而且站得住;但它有一块判不了的区域, 那块区域有名字,而且只能人来。
2. 顶层全景:一次评测要准备四样东西
① 一个具体的改动 "把每次取回的块数从 10 降到 3"
↓
② 一套题 从哪来?(第 5 节)—— 不是从数据里切,是改写真实查询
↓
③ 一个判卷的人或程序 谁来判?(第 6 节)—— 模型可以判一部分,人必须判另一部分
↓
④ 两三个指标 量什么?(第 4 节)—— 至少一个管检索、一个管生成
↓
结论:这次改动是变好了还是变坏了
图说:这一章管 ①②③④ 的准备工作,以及每一样的坑。
三个指标具体怎么算,第 17 章讲 。
3. 先看现象:为什么「试几个问题觉得还行」不算数
这一节先讲清一个差别,因为后面「题从哪来」全建立在它上面。
书的地基句是这一段1:
传统机器学习里,你训练模型从带标签的数据里学到模式,再测它能不能推广到没见过的样本。 而这类系统不学习——它只检索和生成。基础模型已经能跨任务泛化了。 问题不在于模型有没有学到模式,而在于它有没有检索到对的信息、有没有生成有用的答案。
这段话里有两个词要就地交代。基础模型指的是那种先用海量通用文本训练一遍、 然后不必再改就能拿来干很多种活的大模型——本书从头到尾在调用的就是这种。 泛化指的是「在没见过的例子上还灵不灵」:传统做法要专门测这一点, 而基础模型这一关已经在它自己的训练阶段过掉了。
这段话的实际后果有三条(这个归类是我们做的):
| 传统做法 | 这里 |
|---|---|
| 把带标签的数据切成训练集和测试集 | 没有训练,所以没有「训练集」可切 |
| 测「见没见过」——测试题不能在训练数据里出现过 | 测「找没找到」——测试题不能逐字出现在你的知识库里,但答案必须在 |
| 一个模型,一个准确率 | 好几个可以各自独立坏掉的部件,每个都要有自己的数 |
书举了一个反例说明「题出错了会怎样」2: 拿哲学问题去问一个只懂足球规则的系统,得到的评测结果毫无意义。
4. 你的系统有几个可以各自坏掉的部件
这一节回答「量什么」,而它的答案取决于你的系统长什么样。
书那个跑例
书用了一个时装电商的例子,这一章后面全靠它3:
一个给用户提供穿搭建议的问答机器人,它连着两个完全不同的数据源:
① 支撑网店的 SQL 库 —— 结构化的应用数据:用户、商品、库存、订单
② 一个向量库 —— 时尚博客的文本片段
于是这套系统有四个部件,而且**每一个都可能独立地出错**:
部件 A 决定这次该查哪个源
部件 B 把用户的话转成一条 SQL 查询
部件 C 在向量库里按意思检索
部件 D 把取回的材料变成最终答案
图说:书自己的话是"每个部件都可能独立失败,
所以每一部分都需要评测指标,才找得到瓶颈"。
注意 A 就是第 10 章那个"选源",B 是让模型写查询语句(第 18 章会讲它的三种失效)。
好消息:检索那一半的尺子是现成的
书给了一句让人松口气的话4: 检索这一步在概念上和传统的搜索引擎、分类系统很像, 所以精确率、召回率这些成熟指标可以直接拿来用。
这两个名字先各给一句,第 17 章再展开:精确率问「捞上来的这些里,有几成是有用的」; 召回率(第 11 章那个)问「本该捞上来的里,捞回了几成」。一个怕脏,一个怕漏。
这就是为什么第 11 章那个「召回率」你已经见过了——它本来就是搜索领域的老词。
选指标之前,先看你手上有什么标注数据
这是这一节最实用的一张表。书说得很明确:你手上有什么,决定了你能可靠地量哪一部分5:
| 你手上有 | 能量什么 |
|---|---|
| 参考问题 + 正确答案 | 端到端地量:答案和标准答案有多像、让模型给正确性打分 |
| 标注过的检索数据(问题 + 这个问题应该检索到哪几块) | 量检索:取回的块里有多少是该取的、该取的取回了几成 |
| 两样都没有 | 量生成本身的内在质量:答案有没有守住材料、有没有回应问题、连不连贯 |
注意第三行——那正是绝大多数人的处境,而这本书把重点全放在了第三行。 第 17 章那三个指标,全都属于「两样都没有也能算」的那一类。
一条纪律:选两三个,而且要覆盖不同部件
书给的这条纪律很重要6:
不管你处在哪一种情况,都要选一小组、平衡的指标——通常两三个——覆盖流水线的不同部分。 多数情况下,这意味着至少一个检索指标 + 一个生成指标。 这能防止你优化了一个部件,却在悄悄地让另一个变差。
「悄悄地」这三个字是关键。 举个具体的: 你把取回的块数从 3 加到 10,检索那一头的数肯定变好(该找到的更可能被找到); 但材料一多一杂,模型更容易从中挑错重点,生成那一头会变差。 只盯一个数,你会以为自己改进了。(这个例子是我们编的;那条纪律是书里的。)
5. 承重词一:合成测试数据 —— 它保证什么、保证不了什么
这一章第一个承重词。一句话先给结论:合成测试数据就是「让模型自己出题」—— 从库里随机取几块文字,让模型照着它们编出「能用这几块回答的问题」和答案。
做法
书的做法只有两步7:
① 从向量库里随机取文本块(可以一块,也可以几块拼在一起当上下文)
② 让模型照着这些块生成问题和答案
跑例用的是一份公开数据集,里面有约 3 200 条百科文本片段。
提示词里那三条要求值得照抄8:
| 要求 | 为什么 |
|---|---|
| 直接、聚焦,针对上下文里某个具体的事实 | 含糊的问题判不了对错 |
| 写成用户会输进搜索框的那种自然查询 | 否则出的题和真实用法不是一回事 |
| 独立于上下文——不许出现「根据这段文字」「在上文中」 | 出现这类说法,题就只能配着那段材料看,拿去搜完全没意义 |
它保证了什么
书说得很明确9:
模型生成的问题一定能从知识库里答出来,因为它们直接派生自存着的块。 这给系统改动提供了一个可靠的基线:如果你的系统答不出合成问题,那就是坏了。
这句话的逻辑方向要看清楚:它是一个单向判据。
答不出合成题 → 一定有问题 ✓ 这个推论成立
答得出合成题 → 系统很好 ✗ 这个推论不成立
图说:所以它是"体温计",不是"体检报告"。
它保证不了什么(这是全章最诚实的一段)
书自己把话说透了10:
合成问题系统性地比真实查询更容易,因为它们派生自干净、聚焦的块。 真实用户提问含糊、会把多个意图混在一起、会引用对话上下文、会问边缘情况。 合成问题抓不住查询难度的分布。
换成一句话:它测的是理想条件,不是那条又长又含糊的尾巴。
书还给了另外两条不该用 它的地方11: 别用它评清晰度、语气、有用性这些体验维度(那些要人判); 也别用它评多轮对话——生成出来的问题都是单轮的,抓不住对话的来回。
可直接带走的量
书给了几个具体的数12:
| 事项 | 书给的量 |
|---|---|
| 至少生成多少对 | 50 到 100 对 |
| 要覆盖什么 | 不同文档类型、不同问题复杂度(事实查找 / 比较 / 多跳推理)、知识边界附近的边缘情况 |
| 人工抽查多少 | 10 到 20 对,确认质量 |
| 什么时候要重来 | 知识库大改之后重新生成一遍 |
书还自曝了一句12:「本配方代码里那五个例子够做原型,但不足以支撑可靠的评测。」
6. 承重词二:让模型当法官 —— 它凭什么成立,以及它的盲区
这一章第二个承重词。一句话先给结论:让模型当法官,就是不给它标准答案, 只让它判两件事——「这条主张有没有被给的材料支持」和「这个答案有没有回应这个问题」。
它凭什么成立(这是最容易被质疑的一点)
第一反应通常是:让模型判模型,不就是自己给自己打分吗?
书给的理由很具体,而且它站得住13:
法官不需要知道正确答案——它只判断主张有没有被上下文支持、答案有没有回应问题。
❌ 如果要它判 "这个答案对不对"
→ 它得自己知道 正确答案 → 那它和被考的那个模型没有区别 → 这确实是自己判自己
✅ 而它实际要判的是:
材料里写着:"巴黎是法国的首都。"
答案里写着:"法国的首都是巴黎。"
判:这条主张被材料支持了吗? → 支持
图说:第二种判断只需要"读懂两段中文并比对",不需要任何法国地理知识。
这就是为什么它成立 —— 它被降格成了一道阅读理解题。
书还补了一句13:模型很擅长比较语义相似度和验证逻辑一致性,而且不需要领域知识; 所以在你没有标准答案、又需要大规模自动评测的时候,这条路是可行的。
它的盲区有名字
书列出的盲区很具 体,值得逐条记14:
| 它判不了什么 | 类型 |
|---|---|
| 语气 | 主观质量 |
| 品牌声音(这个答案听起来像不像我们公司说的话) | 主观质量 |
| 答案太啰嗦 | 会让用户恼火,但不算「错」 |
| 措辞让人困惑 | 同上 |
| 该反问澄清却没问 | 同上 |
书还点了一句叠加效应14:用合成测试数据的时候,这些局限还会更严重—— 因为这种自动出的题本来就倾向于比真实用户问得容易。
所以这两个承重词是相互加重的,不是相互补充的。
7. 那块判不了的区域,只能人来
三种收集人的判断的做法
书给了三种,从重到轻15:
| 做法 | 怎么做 | 什么时候用 |
|---|---|---|
| 两两比较 | 新旧两版回答同一组问题,让用户排名。这招在生产里也能用——时不时给用户看两个候选答案,问他更喜欢哪个 | 测试重大改动(换模型、检索大改)时最好用 |
| 点赞 / 点踩 | 用户只看到一个问答对时,收集这个最简单的信号 | 日常 |
| 点踩后弹一个短表单 | 一句自由文本 + 几个可选的快速标签 + 提交 | 想弄清「为什么不好」时 |
还可以什么都不问,只看日志
书列了一组被动收集的信号16:
| 记什么 | 能看出什么 |
|---|---|
| 时间戳 | 什么时候用得最多 |
| 用户标识 | 哪些群体在用 |
| 响应时间 | 瓶颈在哪一步 |
| 提示日志 | 一条回答到底是怎么生成的,可以逐步追 |
| 检索到的那些文档 | 可以拿来评检索准不准 |
| 模型的回答 | 可以估答案有没有回应问题、模型有没有正确理解给它的材料 |
人评最值钱的地方,书说得很准
这一句值得记17:
点踩往往指向知识库里内容缺失或过时,而不是技术故障。 文字反馈尤其宝贵,因为它揭示的是指标探测不到的东西:缺口、措辞不清、期待没被满足。
「不是技术故障」这半句最要紧: 你的检索、重排、生成可能全都工作正常, 只是那份文档去年就没更新了。这种事没有任何自动指标查得出来。
一套可以直接照做的节奏
书给了很具体的一套18:
自动指标 → 每一次代码改动或部署都跑
人评 → 每月一次,或者每次重大系统更新之后
每次抽 20 到 30 条回答
拉两三个团队成员或者内测用户一起看,以减少个人偏差
同时记两样:量化的打分(点赞点踩、1 到 5 分)
和质性的反馈(哪里错了、怎样会更好)
书也说清了为什么不能全靠人18: 人评对持续监控来说太慢也太贵,而且不一致——同一个答案不同人打分往往不同。
结论是一句话:两者是分工,不是二选一。 自动指标提供规模、一致性,以及对编造和检索跑偏这类技术故障的快速发现; 人评提供语气、完整性和「用起来到底有没有用」的判断。
判断(我们的,不是书里的):这一章有一个它自己没有回答的问题——判卷的那个模型准不准? 书用了整整一节论证「让模型当法官」为什么成立(它只判阅读理解,不判知识), 但从没有讨论过怎么验证这个法官本身。 而这件事其实有一个很朴素的办法,书里的材料已经够了: 把人评那 20 到 30 条的打分,和模型对同一批答案的判定放在一起比一比。 两者经常不一致,就说明你的自动指 标在骗你;基本一致,你才敢把人评的频率降下来。 如果错,会错在: 如果人评本身就不一致(书自己说了「同一个答案不同人打分往往不同」), 那这个比对的基准也不牢,比出来的差异说明不了谁对。 判据是:先让两三个人给同一批答案各打一遍分,看人和人之间差多少。 人和人之间的差,就是这把尺子的刻度精度上限。
8. 主走查:一个具体的改动 ——「把取回的块数从 10 降到 3」
这是本章的主走查,前面每个机制都在它上面占一步。
(那个时装电商的架构、四个可独立出错的部件、 「50 到 100 对」「抽查 10 到 20 对」「20 到 30 条」「每月一次」, 以及三条出题要求,都是书里的;下面的题目、分数、结论是我们为演示编的。)
第 0 步:要评的改动
改动:每次检索取回的块数,从 10 降到 3
期望的好处:交给模型的材料短了 —— 更便宜、更快、噪声更少
担心的坏处:该找到的东西可能被砍掉了
第 1 步:出题(第 5 节)
从时尚博客那个向量库里随机取 80 块文字,让模型照着出题。
提示里写死三条:直接聚焦某个具体事实 / 写成搜索框里那种自然问法 /
不许出现"根据这段文字"。
生成 80 对问答,人工抽查 15 对:
13 对合格
1 对含糊("时尚有哪些趋势?")—— 删掉
1 对出现了"上文提到的那位设计师" —— 违反第三条,删掉
→ 留下 78 对
再从真实的用户提问日志里,挑 20 条改写成测试题
(因为合成题系统性偏易 —— 第 5 节那条)
→ 最终题库:98 条
第 2 步:定指标(第 4 节)
这套系统有四个部件,但这次改动只碰"取回几块",所以:
检索那一头:取回的块里有多大比例是真有用的
生成那一头:答案有没有守住材料 · 答案有没有回应问题
→ 选三个,正好覆盖两头(第 17 章讲这三个怎么算)
另外记两个通用的:每次问答花了多少 token、耗时多少毫秒
第 3 步:跑一遍,拿到两组数(数是编的)
取 10 块 取 3 块 变化
检索:取回的块里有用的比例 0.31 0.68 ↑ 好很多
生成:答案守住材料的比例 0.86 0.89 ↑ 略好
生成:答案回应问题的比例 0.81 0.72 ↓ 变差了
每次问答的 token 数 4 200 1 400 ↓ 省了三分之二
每次问答的耗时 2.9 秒 1.6 秒 ↓ 快了
(这些数全是为演示编的。)
第 4 步:读这组数(这一步才是评测的意义)
三个指标里有两个变好、一个变坏 —— 而这正是第 4 节那条纪律要防的情况:
只盯前两行,你会以为这次改动是纯赚。
第三行为什么会掉?
一个合理的解释:有些问题需要好几块材料才答得全,
砍到 3 块之后模型只答了一半 —— 答案仍然真实(所以第二行没掉),
但没有完整回应问题(所以第三行掉了)。
→ 于是要去看具体的失败案例,而不是接受或否决这次改动。
第 5 步:让人看一眼(第 7 节)
从"答案回应问题"分数最低的那些题里抽 25 条,
拉三个人一起,每条按 1 到 5 打分并写一 句"哪里不对"。
发现:25 条里有 18 条是"比较型问题"
(「A 品牌和 B 品牌的退货政策有什么不同?」)
—— 这类问题天生需要两块以上材料。
→ 结论不是"3 块不行",而是"这类问题需要单独处理"
(第 11 章那一招:先把问题拆成子问题)
图说:注意这个结论是自动指标给不出来的 —— 它只会告诉你"第三行掉了"。
"掉在哪一类问题上"是人看出来的。
第 6 步:把这次评测收成一句
改动前:凭感觉。"取 3 块应该更省吧?"
改动后:98 条题、三个指标、两组数、25 条人评,
得出一个可执行的结论:块数可以降到 3,
但比较型问题要走单独的一条路。
图说:这就是"没有评测,优化就是猜"那句话的正面版本。
9. 作者的判断与证据
| 说法 | 它是什么 |
|---|---|
| 「你无法改进你无法度量的东西」 | 是格言,不是发现。 但它准确地点出了前面十五章的处境 |
| 「这类系统不学习,它只检索和生成」 | 是事实描述,而且是这一章的地基 |
| 「你是去改写真实查询,而不是去切分已有的带标签样本」 | 是从上一条推出来的, 推理成立 |
| 那个时装电商的四部件架构 | 是举例,不是实测系统 |
| 「每个部件都可能独立失败」 | 是机制事实 |
| 「检索指标可以从搜索引擎借」 | 是事实描述 |
| 三类标注数据决定能量什么 | 是逻辑推导,清楚且可操作 |
| 「选两三个覆盖不同部件的指标」 | 作者的经验建议,没有数据。 但理由(防止优化一个弄坏另一个)成立 |
| 让模型当法官为什么成立 | 是机制论证,而且这是这一章最好的一段论证 |
| 它的五个盲区 | 作者的经验清单,没有实验。 但每一条都很具体、可验证 |
| 「合成问题系统性地比真实查询更容易」 | 是机制推导,成立,而且这是全章最诚实的一句 |
| 「至少 50 到 100 对」「抽查 10 到 20 对」 | 作者给的经验数,没有来源 |
| 三种收集人的判断的做法 | 是做法描述 |
| 「点踩往往指向内容缺失或过时,而不是技术故障」 | 作者的观察,没有数据。 但它是这一章最有用的一条经验 |
| 「每月一次、每次 20 到 30 条、两三个人」 | 作者给的经验节奏,没有来源 |
| 「人评太慢太贵而且不一致」 | 是事实描述 |
10. 边界与局限
- 全章没有一次真实的评测结果。 书给了做法、给了提示词、给了阈值, 但没有一处「我们在某个系统上跑了这套,得到这些数」;
- 没有讲题库要多久更新一次。 只说了「知识库大改之后重新生成」, 而「大改」是多大,没有定义;
- 没有讲判卷的模型该选哪一档。 用便宜的小模型判会不会判错? 书在别的章节反复讲「选最小的够用模型」,唯独这一章没提;
- 没有讲判卷模型本身要不要被评。 让模型当法官,那个法官准不准? 怎么知道?全书没有一句;
- 没有讲不同部件的指标怎么合起来看。 四个部件各有各的数, 最后拿什么判断「整体是好了还是坏了」,书没有给;
- 两两比较那一招的成本没算过。 「在生产里给用户看两个答案」意味着每次问答都要生成两遍, 这笔账书一个字没提;
- 人评那套节奏没有考虑规模。 每月抽 20 到 30 条, 对一个每天几万次问答的系统来说,这个抽样率意味着什么,书没讨论。
11. 可带走的
- 「你无法改进你无法度量的东西。没有评测,优化就成了猜。」 前面十五章的每一处参数,在这一章之前都还是猜;
- 这件事和传统机器学习不是一回事:系统不学习,它只检索和生成。 问题不在「有没有学到模式」,在「有没有 检索到对的信息、有没有生成有用的答案」;
- 所以题不是从数据里切出来的,是改写真实查询来的—— 题要覆盖真实意图、不能逐字出现在库里、但答案必须能从现有资料里找到;
- 你的系统有好几个可以各自独立坏掉的部件(选源、转查询语句、按意思检索、生成), 每个都要有自己的数,才找得到瓶颈;
- 能量什么,取决于你手上有什么标注数据: 有标准答案就端到端量; 有标注过的检索结果就量检索;两样都没有,就量生成本身的内在质量—— 而这本书的重点全在第三种;
- 选两三个指标,而且至少一个管检索、一个管生成。 理由是防止你优化了一个部件,却在悄悄地让另一个变差;
- 合成测试数据 = 让模型照着库里的块自己出题。 出题提示里必须写死三条:聚焦具体事实 / 写成自然的搜索问法 / 不许出现「根据这段文字」这类说法;
- 它是单向判据:答不出合成题一定有问题,答得出不代表好。 因为合成问题系统性地比真实查询容易——它们派生自干净聚焦的块;
- 量:至少 50 到 100 对,人工抽查 10 到 20 对,知识库大改后重新生成;
- 让模型当法官之所以成立,是因为它不需要知道正确答案—— 它只判「这条主张有没有被材料支持」「这个答案有没有回应问题」, 这是一道阅读理解题,不是一道知识题;
- 它的盲区有名字:语气、品牌声音、太啰嗦、措辞让人困惑、该反问却没问。 而且用合成数据时这些局限还会加重;
- 人评最值钱的发现是「知识库里内容缺失或过时」—— 这种事你的检索、重排、生成全都正常,任何自动指标都查不出来;
- 节奏:自动指标每次改动都跑;人评每月一次或重大更新后, 每次抽 20 到 30 条,拉两三个人一起看以减少个人偏差。
12. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 「没有评测,优化就是猜」 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:4(搜「optimization becomes guesswork」) |
| 和传统机器学习的差别 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:6(搜「RAG systems don't learn」) |
| 题该怎么出 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:8(搜「reformulate real queries rather than split」) |
| 拿哲学问题问足球系统 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:10(搜「philosophical questions to a system that only knows football」) |
| 时装电商那个跑例 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:22(搜「chatbot that provides fashion advice」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:42(搜「Every component can fail independently」) |
| 检索指标可以借 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:46(搜「conceptually similar to traditional search engines」) |
| 三类标注数据 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:65(搜「identifying what labeled data you have」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:72(搜「If you have neither reference answers」) |
| 选两三个覆盖不同部件 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:74(搜「small, balanced set of metrics」) |
| 三个核心指标各管什么 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:100(搜「For this case, the three metrics」) |
| 三个指标针对独立的失效 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:122(搜「each metric targets an independent failure mode」) |
| 让模型当法官为什么成立 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:124(搜「The judge doesn't need to know the correct answer」) |
| 它的盲区 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:128(搜「struggles with subjective qualities like tone」) |
| 三种收集人的判断的做法 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:150(搜「pairwise comparison approach can even be used in production」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:154(搜「a short free-text question, optional quick labels」) |
| 被动监控的信号 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:162(搜「passive monitoring signals」) |
| 点踩指向内容缺失 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:182(搜「missing or outdated content in the knowledge base」) |
| 人评的节奏 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:188(搜「Sample 20–30 responses per review session」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:186(搜「too slow and expensive for continuous monitoring」) |
| 合成数据的做法与数据集 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:205(搜「Select random text chunks from your vector store」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:209(搜「RAG mini Wikipedia dataset」) |
| 出题提示的三条要求 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:249(搜「Direct and focused, seeking a specific factual」) |
| 它保证了什么 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:317(搜「guaranteed answerable from the knowledge base」) |
| 它保证不了什么 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:321(搜「systematically easier than real queries」) · text/35-ch10-chapter-10-evaluating-rag-systems.txt:324(搜「Don't rely on it for multiturn conversations」) |
| 至少 50 到 100 对 | Chapter 10. Evaluating RAG Systems | text/35-ch10-chapter-10-evaluating-rag-systems.txt:326(搜「at least 50–100 synthetic question-answer pairs」) |