9.4.1 RAG 评测集应该怎么构建？

先给结论：RAG 评测集不是“问题列表”，而是一套有结构的样本资产。它至少要把问题、标准答案或参考判断、证据范围、任务类型、难度标签和错误归因线索组织在一起。没有结构的题库，很难稳定支持调优和归因。

很多团队刚开始做评测集时，会先收集一批“常见问题”，然后直接跑系统看效果。这个动作不能说完全没用，但它往往只能回答一个很粗的问题：

• 这套系统大致能不能答

但它回答不了更关键的问题：

• 是检索没找回来，还是生成没忠实使用证据
• 是所有问题都不稳，还是只在某几类任务上掉线
• 是数据覆盖有问题，还是 query 理解、过滤、rerank、上下文构造出了问题

如果评测集不能支持这些判断，它就不够好。

一套能用的 RAG 评测集，通常至少要包含什么

最少应该把样本组织成下面几层信息：

• query：用户问题本身
• task_type：问题属于哪一类任务
• difficulty：这道题的难度层级
• expected_evidence_scope：正确答案应该依赖哪些文档、段落、表格或字段
• reference_answer 或 judging_rule：标准答案，或者清晰的评判标准
• metadata：业务域、时间范围、租户、语言、产品线等上下文
• failure_tag：如果这是一道线上失败回流样本，记录它原来的错误类型

其中最容易被忽略的是两项：

• expected_evidence_scope
• judging_rule

如果没有证据范围，你很难判断检索是否真的找到关键材料；如果没有评判规则，你就只能靠“看着像对”来打分。

不要把评测集当成题库，要把它当成诊断资产

真正有用的评测集，不只是为了算一个分数，而是为了支持下面这些工作：

• 比较两版 chunk 策略谁更好
• 判断新增 rerank 之后提升的是哪类问题
• 定位某次数据更新后为什么一类问题突然退化
• 区分“回答错了”到底是检索问题还是生成问题

所以评测集设计时，最好一开始就想清楚它服务哪些评测维度。通常可以分成三类：

• 检索层样本：重点看证据能不能找回来
• 生成层样本：重点看答案是否忠实、完整、符合任务要求
• 端到端样本：重点看最终体验和任务完成度

这三类样本可以重叠，但不要完全混成一类。否则最后只会得到一个模糊的总分。

更实用的构建顺序

如果你是从 0 开始做一套评测集，更稳的顺序通常是下面这样：

第一步，先定评测目标，而不是先凑题

先问清楚：

• 这套评测集主要用来验收什么
• 主要服务离线调优，还是版本回归检测
• 主要测 FAQ 问答、复杂知识问答、跨文档归纳，还是工具路由前的知识判断

如果目标不清楚，样本很容易越收越杂，最后谁都不满意。

第二步，先定义任务类型，再补样本

不要一开始就只靠业务同学随手给问题。更稳的做法是先定义任务桶，例如：

• 单文档事实问答
• 多文档综合问答
• 带过滤条件的问题
• 带时间边界的问题
• 需要表格或结构化字段支持的问题
• 资料不足时应拒答的问题

先把桶定义出来，再往桶里填样本，评测集才不容易偏斜。

第三步，给每类问题做难度分层

同样是“问答”，难度差别可能很大。至少可以先分成三层：

• 简单题：答案集中、证据单一、表达直接
• 中等题：需要在多个 chunk 之间拼接信息，或者问题本身略有歧义
• 困难题：涉及跨文档、多条件、时间版本、例外规则或资料不足判断

如果评测集几乎全是简单题，那它再大也很难说明系统上线后是否稳。

第四步，明确标准答案和证据依据

这一步很费时间，但价值极高。你至少要回答：

• 正确答案应该是什么
• 正确答案依赖哪些证据
• 允许哪些表述差异
• 哪些说法算错
• 哪些属于“看似合理但超出证据”

对于开放式问题，不一定非要有唯一标准答案，但必须有清晰的判定规则。

第五步，把线上失败问题持续回流

一套评测集如果从建立那天起就不再更新，它很快会失真。真实系统里最有价值的样本，往往来自这些来源：

• 用户投诉或人工复核失败样本
• 新版本上线后的回归问题
• 线上日志里高频但低满意度的问题
• 检索命中率看似正常，但回答质量异常的问题

这些样本能不断把评测集拉回真实世界。

一个更像真实工程的样本结构示意

下面是一个极简示意，重点不在格式本身，而在字段意识：

sample = {
    "query": "2026 年企业版退款规则里，哪些情况不支持退款？",
    "task_type": "single_doc_fact_qa",
    "difficulty": "medium",
    "metadata": {
        "domain": "refund_policy",
        "lang": "zh",
        "tenant": "enterprise"
    },
    "expected_evidence_scope": {
        "doc_ids": ["refund-policy-2026"],
        "sections": ["2.3", "2.4"]
    },
    "reference_answer": [
        "超出试用期后按约定条款执行",
        "定制化服务已开始交付时不支持无条件退款"
    ],
    "judging_rule": {
        "must_include": ["试用期", "定制化服务"],
        "must_not_claim": ["所有已付款订单都不可退款"]
    }
}

这个结构的价值在于，它能支持更细的评测和归因，而不是只看“最终答得像不像”。

小团队一开始不需要追求完美，但要先避免三个坑

坑一，只收“最容易答对的问题”

很多人会先从产品文档里挑几道很标准的问题，这样系统分数会很好看，但没有多少诊断价值。

坑二，只有标准答案，没有证据边界

没有证据边界时，你很难判断回答是忠于资料，还是模型自己补全出来的。

坑三，样本只来自离线整理，不来自线上失败

这样会让评测集越来越像“内部理解的问题”，而不是“用户真的会问的问题”。

更现实的起步建议

如果你的系统还在早期，不需要一开始就做成很大的评测平台。更现实的起步方式通常是：

1. 先做一个小而结构化的基线集
2. 覆盖 5 到 8 类关键任务
3. 每类先放少量高价值样本
4. 给样本补上证据范围和评判规则
5. 每次版本变化后看哪类题退化
6. 持续把线上失败样本回流进来

先把结构搭对，比一上来堆很多题更重要。

一句话总结

好的 RAG 评测集，不是题越多越好，而是要让每道题都能帮助你判断系统到底哪里强、哪里弱、哪里正在退化。