用真实问题集检验RAG上线质量

RAG 聊天机器人能答对演示里的几个问题，离可以上线还差一套验收标准。这篇文章的主张很直接：收集真实问题，写清正确答案必须包含什么、不能说什么，再让每次改动都经过同一套测试。

它最有用的地方，是把「回答看起来不错」拆成了可以定位、可以阻止发布的问题：资料有没有找对，答案有没有依据，过期政策会不会混进来，以及遇到越权请求时能不能守住边界。

测试集里，必须有机器人不该回答的问题

演示通常选择文档里有明确答案的问题。真实用户会问旧价格、已下架产品，也会带着错别字提问。系统如果把这些都当成普通问答，很容易补出一条不存在的退款政策。

作者建议从最近几个月的客服邮件、工单、在线聊天、销售通话问题，以及 FAQ 没能解决的疑问里，收集 50 到 200 个真实问题。这个范围是起步建议，文章没有给出不同规模测试集的效果对照。

题目要覆盖可回答、资料未覆盖、信息过期、权限受限和对抗性输入。作者特别建议，约四分之一的问题应当属于机器人不能自信作答的情况。测试目的不只是检查知识储备，还要验证它是否知道什么时候该停下来。

每道题的验收条件可以先放在表格里，包括：

• 答案必须包含的事实，例如「30 days」和「receipt required」，即 30 天、需要收据。
• 应当引用的来源文档，以及禁止出现的内容，例如已经停用的价格。
• 答错的严重程度，分为 critical、major、minor；金额、政策、隐私方面的错误归入 critical。

作者不建议逐题写完整范文，因为措辞不同也可能都正确。这里真正要固定的是事实和边界。否则，评测容易变成检查模型是否复述了参考答案。

答案错了，先查资料有没有找对

RAG，也就是检索增强生成，可以拆成两步：先找资料，再根据资料组织回答。两步出错，处理方式不同。

作者建议，对每道题检查正确来源是否进入检索结果前列，例如 top 5。如果目标段落没有被找出来，就应该先检查分块、搜索配置、文档清理，或者考虑把关键词搜索与向量搜索结合起来。单靠提示词，不能补回模型没有拿到的证据。

原文提到 Ragas 的四个指标：

指标	要回答的问题
context recall	检索是否找到了回答所需的资料
context precision	相关资料是否排在靠前的位置
faithfulness	回答中的陈述是否得到检索资料支持
answer relevancy	回答是否切中了用户的问题

按原文所述，context recall 需要参考答案，前面整理的关键事实可以充当比较依据。文章没有展开具体指标版本和配置，落地时还需要确认工具要求的输入格式。

这里最容易误读的是 faithfulness。它检查的是回答有没有依据检索结果，并不负责判断资料是否仍然有效。系统检索到旧政策，再准确复述旧政策，也可能拿到不错的忠实度评价。

有依据的回答，也可能是错的。

因此，来源正确、事实正确和时间有效性需要一起检查。测试集里的旧价格、过期政策，正是用来揭开这种指标盲区的。

自动评分可以省力，发布门槛必须提前定

作者提出的评分组合是：精确条件交给代码，语义判断交给模型，再用人工校准。

代码适合检查是否包含「30 days」、是否引用指定文档、是否出现禁说内容。回答是否完整、证据是否充分，则可以交给 LLM judge，也就是用另一个模型充当评委。

原文引用 Zheng 等人在 NeurIPS 2023 的研究：强模型与人类评委的一致率超过 80%，接近人类之间的一致程度。但同一研究也记录了偏差，包括偏爱先展示的答案、偏爱更长的答案，以及部分模型偏爱自身生成的回答。这个数字不能直接当成你所用评委在业务数据上的准确率。

作者建议，先人工评阅 30 到 50 个回答，再让模型评阅同一批，比较分歧并收紧评分说明。明确要求评委忽略篇幅；比较两个版本时，交换展示顺序再评一次，检查结论是否受位置影响。

分数最终要对应发布决策。原文给出的门槛包括：critical 错误为零；资料未覆盖的问题应有较高比例回答不知道；可回答问题应几乎都能找到正确来源；任何类别都不能比上一版退步。

这些是门槛方向，还不是可直接执行的完整规范。「较高比例」「几乎全部」没有具体数值，需要团队自己确定。否则，临近上线时仍然可能靠感觉放行。

模型更换，包括供应商升级模型版本，分块大小、embeddings、搜索设置调整，以及文档更新，都应触发全量重跑。每轮结果也要保留，方便在六个月后收到投诉时追查问题从哪次改动开始。

安全测试同样需要进入这套流程。作者举了两类：

一类是在测试文档里埋入指令，例如要求退款用户改发邮件到某个地址，检查模型会不会执行资料中的恶意命令。另一类是让低权限用户询问受限内容，检查权限过滤是否发生在段落进入模型之前。

原文将提示注入列为 OWASP 2026 年版榜单的首要风险，并称该版发布于 2026 年 8 月；这是原文的引用信息。具体测试建议的价值，则在于把文档注入和检索越权都变成了可重复验证的用例。

我的判断

我赞成这套方法的优先级：先写清什么叫答对，再谈模型表现。对于知识库问答，测试集往往比继续润色提示词更能帮助团队发现问题，因为它能区分「资料没找到」「资料已过期」和「模型没有遵循资料」。

但这篇是实施建议，不是效果实验报告。作者没有展示他们团队上线前后的错误率，也没有提供 50 到 200 题、约四分之一拒答题优于其他配比的对照数据。这些数字应当作为起点，不能当成经过验证的通用标准。

与单看一个综合分相比，按失败类型、严重程度和问题类别验收，更容易阻止危险回归。不过，「任何类别都不能退步」遇到模型输出波动时该怎么判，文章没说清。对于边界案例，可以保留重复运行结果并人工复核，避免一次偶然回答决定发布。

「critical 错误为零」也只能说明当前测试没有发现此类错误，不能证明系统绝无风险。尤其当助手可以退款、修改记录时，问答评测还不够。原文提醒了风险会上升，但没有展开动作执行部分的验收方法。

另外，代码检查也有前提。机械搜索「30 days」，可能漏掉含义正确的其他表达。适合精确比较的条件要精确检查，需要理解语义的条件则应留给模型或人工。

能拿来做什么

• 如果你正在做文档问答或客服助手，先整理 50 个真实问题，为每题补齐关键事实、来源、禁说内容和严重程度，并加入必须拒答或转人工的情况。
• 在 Node 服务的评测流程里，同时保存检索结果和最终回答，先检查正确资料是否进入 top 5，再判断回答质量，让失败能定位到具体环节。
• 给模型、embeddings、分块和文档更新建立统一的回归入口，提前写明哪些错误阻止发布，并留存每轮结果供版本比较。
• 在聊天界面加入赞踩反馈，对记录的问题去除个人信息，每周复查差评；每个确认的失败都补进测试集，让真实用户的问题持续修正验收范围。