RAG系统的评测集，不是把一批常见问题和标准答案简单放进文件，而是对“检索是否找到正确证据、生成是否忠实于证据、系统是否满足业务要求”的系统性刻画。评测集质量直接决定迭代方向：如果只看最终回答，往往无法判断问题究竟出在文档解析、文本切片、向量或关键词召回、重排序，还是生成环节。
先按业务问题建立样本
样本应从真实业务任务出发，而不是从知识库文档标题反推问题。每条样本至少包含用户问题、期望命中的证据片段、参考答案，以及必要的来源信息。参考答案不宜只写一句结论，还应明确回答必须覆盖的关键事实，便于区分“部分正确”和“完整正确”。
覆盖范围要有层次：既包括单文档事实问答，也包括跨段落、跨文档的关联问题；既要测试自然表达，也要纳入人名、编号、缩写等对精确匹配敏感的查询。对于GraphRAG或Agentic RAG，还应增加多跳推理、问题拆解和多轮检索样本，但不能让复杂样本取代基础事实问答。
用错误类型设计评测集
高质量评测集必须包含“容易答对”和“容易答错”的对照样本。重点覆盖以下情况：
- 知识库中存在答案，但表述分散或上下文较长；
- 问题包含同义表达、歧义词或精确编号；
- 检索结果相似但实际不相关；
- 资料不足，系统应明确说明无法判断，而不是编造答案；
- 不同文档存在时间、版本或结论差异，需要识别适用范围；
- 问题本身超出知识库边界，测试系统是否能够拒答并保留出处。
评测时应将检索和生成拆开观察。检索侧关注目标证据是否进入候选结果，以及排序是否足够靠前；生成侧关注答案是否覆盖关键事实、是否出现证据之外的内容、是否正确引用来源。这样才能避免把“召回失败”误判成“大模型能力不足”。
评测集还应划分为开发集和留出集。开发集用于调整切片、检索融合和重排序策略，留出集则尽量保持稳定，避免反复调参导致系统只记住题目。上线后持续收集真实失败问题，经过脱敏、去重和人工复核后补入评测集；每次新增样本都应记录错误类型。评测的目标不是追求一个孤立分数，而是让每次改动都能回答：召回更准了吗，答案更忠实了吗，拒答更可靠吗。