很多 RAG 项目在优化时都会经历同一个阶段。
换了 Chunk 参数，随手问几个问题，感觉回答顺了一点。加了 Rerank，再问几个熟悉的问题，正确原文似乎排得更靠前。于是大家得出结论：“这次优化有效。”
可是一周以后，另一类问题又答错了。团队想复现之前的结果，却发现当时问了什么、正确证据在哪里、改了哪些参数，都没有完整记录。
没有固定评测集，RAG 优化的效果就很难复核，容易停留在演示层面。
这就是面试里经常被追问的一道题：
RAG 评测集应该怎么构建？为什么只准备问题和参考答案仍然不够？Recall@K、MRR 和 Faithfulness 又分别在评估哪一层？
只回答“让大模型生成一批 QA，再算准确率”，通常会暴露更多问题：
- 自动生成的问题是不是只会复述原文？
- 没有正确证据位置，怎么评估检索？
- 最终答案错了，怎么知道该修检索还是生成？
- 参数一直对着同一批题调，会不会把系统调到过拟合？
一条评测样本到底要保存什么？
最小结构不是“问题加答案”，而是“问题、答案、证据”。
问题要尽量接近真实用户表达，而不是照着文档标题改成问句。
参考答案可以是一段标准文本，也可以是一组必须覆盖的答案要点。开放式问题有多种正确说法时，用要点比逐字匹配更合理。
证据则要指向能够支持答案的具体内容，包括文档 ID、Chunk、页码、段落、幻灯片或视频时间位置。
为什么证据不能省？
假设系统最终答对了，但没有找到知识库原文，而是依靠模型训练知识碰巧说对。只看答案，这条样本会被判为成功；从 RAG 链路看，检索实际上失败了。
反过来，系统找到了正确证据，模型却理解错了。只看最终答案，团队可能误以为需要继续改检索参数。
证据把这两种错误拆开了。
答案告诉我们“应该说什么”，证据告诉我们“应该从哪里找到，以及这句话为什么成立”。
一个问题需要多段原文时，还要标出全部必要证据。
比如在一个教学场景中，用户问某项流程在特殊条件下是否适用，第一段原文给出通用规则，第二段才给出例外。系统只找回第一段，不能因为主题相关就算检索成功。
无答案问题也要进入评测集。它的参考动作不是随便写一句“没有”，而是标记当前资料不足，以及系统应该澄清、有限回答还是拒绝。
问题应该从哪里来？
问题来源通常有两类：人工编写和模型生成。
人工问题更容易贴近真实需求，也更容易覆盖隐含条件和复杂问法，但成本高，数量扩展慢。
模型生成适合快速得到初稿，却有一个明显倾向：它刚看完原文，生成的问题也会贴近原文措辞。这类问题像阅读理解，检索器只要抓住相同词面就容易答对，无法代表真实用户的口语表达。
更稳的做法是混合来源。
优先收集真实搜索、客服咨询、项目验收问题和人工阅读文档后提出的问题。模型可以补充同义表达、不同题型和长尾场景，但每道题都要人工确认三件事：用户是否可能这样问，资料里是否真的有答案，参考答案能否完全由标注证据推出。
问题类型也要有层次。
原词事实题检查基本命中。口语改写题检查语义召回。否定和例外题检查条件理解。流程题检查多步骤证据。比较题和多跳题检查多段信息。表格题检查结构解析。无答案题检查拒答边界。
如果一批题只是把“怎么报销”换成十种说法，数量看起来很多，知识覆盖仍然很窄。可以对照知识库目录、文档类型和用户任务做覆盖表，避免某一主题主导整体结果。
评测集怎样从文档变成可执行数据？
可以按七步完成。
第一步，确定知识范围和版本。明确哪些文档属于本次评测语料。
第二步，建立主题清单。按目录、文档类型和用户任务列出需要覆盖的区域。
第三步，收集问题。混合真实问法、人工设计与模型辅助生成。
第四步，撰写参考答案或答案要点，避免加入证据外常识。
第五步，标注支持证据。一个问题需要几段，就把几段都记录下来。
第六步，标记题型、难度、是否可回答和风险类型。
第七步，人工复核并版本化，保存每次修改原因。
问题生成只是中间一步，真正费工的是答案与证据校验、覆盖检查和版本管理。
这里有一个容易忽视的风险：评测集自己也会产生幻觉。
模型生成参考答案时，可能加入文档里没有的细节。人工只检查语言是否通顺，没有逐项对照原文，错误就会被写进 Ground Truth。之后系统严格按证据回答，反而被评为错误。
因此，参考答案中的每个事实要点都应能回到证据。不能回到原文的内容，要删除、改成可选说明，或者补充确实存在的证据。
Recall@K、MRR 和 Faithfulness 分别看什么？
RAG 是一条链路，指标也要分层。
检索层首先看 Recall@K。
它回答的是：人工标注的正确证据中，有多少进入了前 K 条。一个问题需要两段证据，系统只找回一段，覆盖就不完整。
Precision@K 看另一个方向：前 K 条里有多少内容真的相关。把候选数量不断放大，Recall 可能上升，噪声也会一起增加。
MRR 关注第一条正确证据的位置。正确原文排第一和排在后面，都叫“找回”，但后续只截取少量上下文时，结果完全不同。
冗余则看前几条是否反复提供同一份信息。多个相邻 Chunk 高度重复，表面上每条都相关，实际没有增加证据覆盖，还会浪费上下文。
生成层再看回答正确性、相关性和 Faithfulness。
正确性关注答案与参考答案是否一致。相关性关注回答是否真正解决用户问题，而不是说了一堆正确但偏题的话。Faithfulness 关注答案中的事实能否由本轮检索证据支持。
引用评估还要看引用的原文是否真的支持对应陈述，以及用户能否回到正确位置。
检索指标回答“证据找得怎样”，生成指标回答“模型怎样使用证据”，二者不能混成一个总分。
举个诊断思路。
Recall@K 下降时，可以检查解析、Chunk、Query、过滤和召回。Recall 正常而 MRR 下降，融合与重排更值得优先检查。正确证据已经排在前面，Faithfulness 却下降时，再看 Prompt、上下文组织和模型生成。
一个总分无法给出这种定位能力。
开发集、回归集和保留集为什么要分开？
开发集用于日常调试。
调整 Chunk 大小、检索权重、阈值和 Prompt 时，可以反复运行开发集，快速观察变化。
回归集保存已经发生过的 bad case。
每修复一个真实问题，就把原问题、正确证据和预期行为加入回归集。以后换模型或重构链路时，先确认旧问题没有重新出现。
保留测试集不参与日常调参。
当一个版本在开发集和回归集上都稳定后，再用保留集评估一次。它用来检查系统是否只适应了大家反复看到的题。
如果所有参数都对着同一批问题调整，团队会逐渐记住这些样本的特征。最终分数越来越高，新问题却没有变好。
数据隔离不是为了追求学术形式，而是为了判断优化有没有泛化到未见问题。
知识库本身更新后，评测数据也要版本化。制度改变、页面移动、答案失效时，不能直接覆盖旧样本。要记录对应的文档版本、证据变化和修改原因，才能解释不同时间的结果。
知识库更新后，怎样维护评测集？
评测集不是一次整理完就不再变化的静态文件。文档新增、删除或换版后，原来的问题可能继续有效，也可能需要换证据、改答案，甚至从“可回答”变成“当前资料不足”。如果不维护这些状态，系统按新资料答对了，反而可能被旧标准判错。
一种可执行的方法，是让每条样本绑定证据身份和知识库版本。文档更新时先做影响分析：哪些样本引用了被修改的文档、章节或 Chunk，哪些答案要点涉及变化字段。只复核受影响样本，比每次重新人工检查全部数据更可控。
复核结果可以分成四类。第一类是问题、答案和证据都不变，只更新可定位信息；第二类是问题仍有效，但参考答案或证据需要更新；第三类是旧问题已经不再适用，应保留历史状态但停止进入当前评测；第四类是新版本产生了新的用户任务，需要补充样本。不要直接删除旧记录，否则无法解释两个版本之间的指标变化。
运行评测时，应把知识库快照、样本集版本和系统配置一起写入结果。这样看到分数变化时，才能区分是文档内容变了、Ground Truth 变了，还是检索与生成策略变了。如果一次发布同时更换资料和算法，可以分别在旧快照与新快照上运行，避免把内容补齐误写成算法提升。
评测集本身也需要质量回归。可以定期抽查证据链接是否还能打开、答案要点能否逐项回到原文、题型和风险分布是否偏移，以及新增问题是否与旧题高度重复。维护目标不是追求样本数量不断增长，而是确保每个判定仍然有清楚、当前且可复查的依据。
人工复核一条样本，具体看什么？
下面用一个教学流程展示人工复核的典型顺序。它不是唯一标准，实际字段仍要按业务目标调整。
先看问题是否自然。它应该像用户会提出的问题，而不是把文档标题加上“是什么”。如果问题缺少必要条件，要判断这是否是有意设计的澄清题，而不是标注人员忘了写。
再看答案是否恰好回答问题。参考答案不需要堆满原文全部信息，只保留当前问题需要的事实和条件。过长的参考答案会让自动评审偏向“写得越多越好”。
第三步逐项核对证据。答案里的每个数字、日期、实体、否定关系和适用范围，都应能在证据中找到。如果一项结论需要两段原文，不能只标最容易看到的一段。
第四步检查证据边界。标注整份文档虽然省事，却无法准确计算 Chunk 级召回。应尽量定位到可以支持答案的最小完整片段，同时避免把例外条件切掉。
第五步检查题型标签和可回答状态。无答案题不能因为存在相似文档就被标成可回答，多跳题也不能因为一个片段讲了大部分内容就降成单跳题。
第六步让另一位复核者抽检有争议样本。两个人判断不一致时，先修改标注说明和判定规则，而不是简单取多数。评测集越往后使用，统一口径越重要。
每条样本可以保存 review_status、复核人、复核时间和争议说明。知识库更新或答案规则变化时，系统能筛出需要重新检查的样本。
人工复核的目标不是让所有问题都变得简单明确，而是让每一道题的预期行为有据可查。真实用户问题可以有歧义，但评测集必须说明遇到歧义时系统应该澄清、拒绝还是按某个明确条件回答。
评测数据还要防止“证据泄漏”。如果把参考答案、正确 Chunk ID 或人工解释意外拼进待测系统的 Prompt，结果会虚高。运行脚本应该明确区分模型可见字段和只供评分使用的字段。
自动生成问题时也要检查答案词是否被直接写进问题。问题本身带出结论，检索和生成都变得过于简单。
每次评测最好保存实际输入快照，包括系统看到的 Query、知识库版本和检索配置。这样才能证明模型没有接触评分字段，也能在结果异常时完整复现。
五种评测失真，漂亮分数是怎么来的？
第一种，只有答案，没有证据
最终回答看起来正确，但无法判断检索是否成功。
修复方法是补充具体证据位置，并分别计算检索和生成结果。不能把模型常识当成 RAG 成功。
第二种，模型生成的问题太像原文
文档标题是“差旅报销流程”，问题直接写成“差旅报销流程是什么”。关键词检索很容易命中，却没有测试口语表达。
应该加入真实问法和人工改写，并标记问题来源，单独比较原词题与口语题。
第三种，调参和评估使用同一批题
如果根据失败样本不断调整规则，最后仍用这些题报告结果，指标就会被开发过程污染。
这只能证明系统适配了已知问题。需要保留未参与调参的测试集，并限制查看频率。
第四种，平均分掩盖高风险问题
大量简单事实题表现很好，少量否定和例外题全部失败，整体平均仍可能好看。
指标要按题型、文档类型和风险分层。高风险问题应单独设通过条件，不能被简单问题抵消。
第五种，文档更新，Ground Truth 没更新
系统按新版资料回答，评测集仍把旧答案当标准。
每条样本要绑定知识库版本。更新文档时触发受影响样本复核，而不是等分数异常以后再猜。
LLM 能不能替代人工评审？
LLM 适合帮助判断开放答案是否覆盖要点、语义是否接近，以及事实句是否受证据支持。它能降低逐题检查成本，但不能直接当成绝对裁判。
不同提示、不同模型和不同上下文长度，评分可能变化。领域术语、复杂否定和多段证据也可能让裁判模型误判。
使用 LLM Judge 时，至少要固定评审提示和模型版本，保存它看到的问题、参考答案、证据和待评答案，并用一批人工标注样本校准。
对高风险样本、模型分歧样本和分数边界样本，仍然需要人工复核。
自动评审的价值是扩大覆盖和发现可疑项，不是让评测从此不需要人。
怎么用评测集验证一次改动？
先冻结知识库版本、问题集和正确证据。
记录当前基线的完整配置，包括解析版本、Chunk 策略、Embedding、候选数量、融合方式、Rerank、阈值和生成模型。
一次只改变一个主要因素，再运行同一批样本。保存每条问题的候选原文、排名、最终上下文、答案和引用，而不是只保存汇总指标。
汇总时分层看检索、生成和无答案表现，再按题型查看。总分上升但否定题下降，不能直接宣布改动成功。
最后运行回归集和保留集，确认已知问题没有退化，新问题也能得到同方向改善。
固定数据、记录配置、逐层比较、分组复盘和保留集验证，缺一项都可能把偶然结果当成提升。
评测集追问怎么接：先问证据和隔离
这些问题都围绕两条底线：每道题有没有可核验的正确证据，日常调参与最终验收是否使用了相互隔离的数据。
为什么 Ground Truth 必须带证据？
因为最终答案可能由模型常识碰巧说对。只有正确证据位置，才能分别判断检索是否找到依据、生成是否正确使用依据。
评测问题可以全部让大模型生成吗？
不建议。模型生成适合扩充初稿，但容易贴近原文措辞，也可能生成资料外答案。应混合真实问题、人工设计与模型辅助，并逐条核验证据。
Recall@K 高，为什么答案仍然会错？
正确证据进入前 K 条，不代表它排得足够靠前，也不代表模型最终看到了或正确理解了它。还要看 MRR、截断后的上下文和 Faithfulness。
为什么不能只看 Faithfulness？
答案完全忠于一段错误或不完整的检索内容，Faithfulness 仍可能不错。需要同时看证据是否正确、是否充分，以及答案是否解决问题。
数据集多久更新一次？
没有统一周期。知识库版本变化、出现新 bad case、用户问题分布改变或链路组件升级时，都应该触发复核。更新要有版本和变更记录。
把评测集讲成可版本化资产
最后把样本结构、指标分层、数据集隔离和版本触发串成一条线：
RAG 评测样本至少要有问题、参考答案或答案要点，以及能够直接支持答案的证据位置。证据很关键，因为最终答案可能靠模型常识碰巧说对，只有标出文档、Chunk 和页码，才能把检索失败与生成失败分开。问题来源会混合真实查询、人工设计和模型辅助生成，并覆盖原词、口语改写、否定、多跳、表格和无答案场景，全部经过人工核验。
指标要按链路分层。检索层用 Recall@K 看正确证据有没有找回，用 Precision@K 看噪声，用 MRR 看第一条正确证据的位置，同时检查冗余。生成层再看正确性、相关性和 Faithfulness，引用还要验证陈述与证据的支持关系。指标下降时，才能知道该查解析、召回、排序还是生成。
数据会拆成开发集、历史 bad case 回归集和不参与日常调参的保留测试集，并绑定知识库版本。每次改动固定同一批问题和证据，一次改变一个主要因素，保存逐题候选与答案，再分题型复盘，而不是只报一个平均分。
判断这套评测能否用于决策，只需追问三件事：Ground Truth 是否带可靠证据，指标下降能否定位到具体链路，以及漂亮分数是否避开了重复问题和数据泄漏。评测框架只是执行工具，不会自动保证这三件事。