跳到主内容RAG 评测集怎么构建？问题、答案和证据必须怎么标？ · AlgoMooc面试题 · RAG 项目面试题
RAG 评测集怎么构建？问题、答案和证据必须怎么标？
比如在一个教学场景中，用户问某项流程在特殊条件下是否适用，第一段原文给出通用规则，第二段才给出例外。系统只找回第一段，不能因为主题相关就算检索成功。
无答案问题也要进入评测集。它的参考动作不是随便写一句“没有”，而是标记当前资料不足，以及系统应该澄清、有限回答还是拒绝。
问题应该从哪里来？
人工问题更容易贴近真实需求，也更容易覆盖隐含条件和复杂问法，但成本高，数量扩展慢。
模型生成适合快速得到初稿，却有一个明显倾向：它刚看完原文，生成的问题也会贴近原文措辞。这类问题像阅读理解，检索器只要抓住相同词面就容易答对，无法代表真实用户的口语表达。
优先收集真实搜索、客服咨询、项目验收问题和人工阅读文档后提出的问题。模型可以补充同义表达、不同题型和长尾场景，但每道题都要人工确认三件事：用户是否可能这样问，资料里是否真的有答案，参考答案能否完全由标注证据推出。
原词事实题检查基本命中。口语改写题检查语义召回。否定和例外题检查条件理解。流程题检查多步骤证据。比较题和多跳题检查多段信息。表格题检查结构解析。无答案题检查拒答边界。
如果一批题只是把“怎么报销”换成十种说法，数量看起来很多，知识覆盖仍然很窄。可以对照知识库目录、文档类型和用户任务做覆盖表，避免某一主题主导整体结果。
评测集怎样从文档变成可执行数据？
第一步，确定知识范围和版本。明确哪些文档属于本次评测语料。
第二步，建立主题清单。按目录、文档类型和用户任务列出需要覆盖的区域。
第三步，收集问题。混合真实问法、人工设计与模型辅助生成。
第四步，撰写参考答案或答案要点，避免加入证据外常识。
第五步，标注支持证据。一个问题需要几段，就把几段都记录下来。
问题生成只是中间一步，真正费工的是答案与证据校验、覆盖检查和版本管理。
这里有一个容易忽视的风险：评测集自己也会产生幻觉。
模型生成参考答案时，可能加入文档里没有的细节。人工只检查语言是否通顺，没有逐项对照原文，错误就会被写进 Ground Truth。之后系统严格按证据回答，反而被评为错误。
因此，参考答案中的每个事实要点都应能回到证据。不能回到原文的内容，要删除、改成可选说明，或者补充确实存在的证据。
Recall@K、MRR 和 Faithfulness 分别看什么？
它回答的是：人工标注的正确证据中，有多少进入了前 K 条。一个问题需要两段证据，系统只找回一段，覆盖就不完整。
Precision@K 看另一个方向：前 K 条里有多少内容真的相关。把候选数量不断放大，Recall 可能上升，噪声也会一起增加。
MRR 关注第一条正确证据的位置。正确原文排第一和排在后面，都叫“找回”，但后续只截取少量上下文时，结果完全不同。
冗余则看前几条是否反复提供同一份信息。多个相邻 Chunk 高度重复，表面上每条都相关，实际没有增加证据覆盖，还会浪费上下文。
生成层再看回答正确性、相关性和 Faithfulness。
正确性关注答案与参考答案是否一致。相关性关注回答是否真正解决用户问题，而不是说了一堆正确但偏题的话。Faithfulness 关注答案中的事实能否由本轮检索证据支持。
引用评估还要看引用的原文是否真的支持对应陈述，以及用户能否回到正确位置。
检索指标回答“证据找得怎样”，生成指标回答“模型怎样使用证据”，二者不能混成一个总分。
Recall@K 下降时，可以检查解析、Chunk、Query、过滤和召回。Recall 正常而 MRR 下降，融合与重排更值得优先检查。正确证据已经排在前面，Faithfulness 却下降时，再看 Prompt、上下文组织和模型生成。
开发集、回归集和保留集为什么要分开？
调整 Chunk 大小、检索权重、阈值和 Prompt 时，可以反复运行开发集，快速观察变化。
每修复一个真实问题，就把原问题、正确证据和预期行为加入回归集。以后换模型或重构链路时，先确认旧问题没有重新出现。
当一个版本在开发集和回归集上都稳定后，再用保留集评估一次。它用来检查系统是否只适应了大家反复看到的题。
如果所有参数都对着同一批问题调整，团队会逐渐记住这些样本的特征。最终分数越来越高，新问题却没有变好。
数据隔离不是为了追求学术形式，而是为了判断优化有没有泛化到未见问题。
知识库本身更新后，评测数据也要版本化。制度改变、页面移动、答案失效时，不能直接覆盖旧样本。要记录对应的文档版本、证据变化和修改原因，才能解释不同时间的结果。
评测集不是一次整理完就不再变化的静态文件。文档新增、删除或换版后，原来的问题可能继续有效，也可能需要换证据、改答案，甚至从“可回答”变成“当前资料不足”。如果不维护这些状态，系统按新资料答对了，反而可能被旧标准判错。
一种可执行的方法，是让每条样本绑定证据身份和知识库版本。文档更新时先做影响分析：哪些样本引用了被修改的文档、章节或 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 是否带可靠证据，指标下降能否定位到具体链路，以及漂亮分数是否避开了重复问题和数据泄漏。评测框架只是执行工具，不会自动保证这三件事。
