Appearance
9.4.2 为什么评测问题必须覆盖不同任务类型？
先给结论：RAG 系统不是在回答一种问题，而是在同时处理多种认知任务。评测问题如果只覆盖单一题型，测出来的就不是系统整体能力，而只是它对某一类问题的偏科表现。
很多团队的评测集都有一个隐含偏差：
- 样本大多来自 FAQ
- 问题都比较短
- 答案都能在单一段落里直接找到
这种评测集通常会让系统看起来很强，因为它主要在测：
- 检索能不能找到明显相关段落
- 生成能不能把一段材料改写成答案
但真实线上问题往往远不止这一种。
为什么任务类型不覆盖，分数会失真
假设你的评测集 80% 都是单文档事实问答，那么系统只要把这类问题做好，整体得分就会很好看。可一到真实环境里，用户还会问：
- 需要跨文档综合的问题
- 带时间条件的问题
- 带权限或租户边界的问题
- 需要结构化字段配合的问题
- 资料不足时本该拒答的问题
如果这些题型在评测集里几乎不存在，离线分数就会产生一种错觉：
- 好像系统整体已经不错了
其实更准确的说法是：
- 系统只是在你给出的那一小类题上表现不错
从系统设计角度看，不同题型其实在考不同能力
不要把所有问题都看成“只是问法不同”。很多题型背后考的是不同环节。
单文档事实问答
这类问题重点在：
- 能否找准相关 chunk
- 回答是否忠实
它比较适合检验基础检索和基础生成。
多文档综合问答
这类问题重点在：
- 能不能把多个来源的信息拼起来
- 会不会遗漏关键前提
- 会不会把不同文档里的说法错拼成一个结论
它更容易暴露：
- recall 不足
- rerank 不稳
- 上下文构造混乱
带过滤条件的问题
例如：
- 只看某租户
- 只看某产品版本
- 只看某时间范围
这类问题的关键不只是“召回相关内容”，而是“先过滤，再检索或带过滤检索”。它更容易暴露：
- metadata 设计不完整
- filter 没有进入检索阶段
- 新旧版本内容混用
结构化字段参与的问题
例如查库存、订单状态、配额、计费信息，这类问题常常更像：
- 数据查询
- 结构化检索
- 工具调用
如果你把它们硬塞进普通文档问答评测里，结果会非常混乱。因为它测的已经不是纯 RAG 文本链路了。
资料不足应拒答的问题
这是最容易被漏掉的一类题。很多评测集只测“能不能答”，却不测：
- 不该答的时候能不能停住
- 资料不足时会不会编
但真实系统里，这类题往往比“答错”更危险。
更实用的任务覆盖框架
如果你现在要快速检查自己的评测集有没有偏科，可以先看它是否至少覆盖了下面这些桶：
- 直接事实问答
- 多段落拼接问答
- 多文档综合问答
- 带过滤条件的问题
- 带版本/时效约束的问题
- 结构化字段参与的问题
- 资料不足应拒答的问题
- 模糊、口语化、表达不完整的问题
不一定每个系统都要把这 8 类都做得很深，但至少要先知道自己没测到哪些类型。
为什么还要覆盖不同难度，而不是只覆盖不同题型
同一种任务类型里，难度也可能差很多。
例如同样是多文档综合：
- 简单题可能只需要合并两段信息
- 困难题可能涉及版本差异、例外条款和条件组合
所以更稳的做法是：
- 每种任务类型里，再分简单、中等、困难三层
这样你最后看的不是一个总分，而是：
- 哪类题稳
- 哪类题一上难度就崩
很多误判，其实都来自题型分布失衡
真实项目里，经常会出现这些误判：
- FAQ 评测很高，就误以为复杂问答也能做好
- 文本问答很稳，就误以为结构化查询也没问题
- 单轮短问题表现不错，就误以为真实对话也稳定
这些都不是系统真的“突然变差”，而是评测集一开始就没覆盖到。
一种简单但有效的构造方法
如果你暂时还没有很多资源做复杂标注，可以先用下面这个方法起步：
- 先列出系统里最常见的 5 到 8 类任务
- 每类任务先收 10 到 20 个高价值问题
- 每类都覆盖简单、中等、困难
- 每类都至少放 1 到 2 个“资料不足应拒答”的样本
- 评测结果按任务类型分别看，不只看总分
这比直接收 100 个混在一起的问题更有用。
一句话总结
RAG 评测集必须覆盖不同任务类型，因为不同题型考的是不同系统能力；如果题型覆盖不够，离线高分很可能只是某一种简单问题的高分。