Dataify 可用于补充公开网页、搜索结果、视频及行业数据，为 RAG 评测数据集构建提供原始语料来源；要真正落地，建议按照“目标定义—语料治理—问题设计—标注—分层抽样—自动化验证—持续迭代”的流程建设评测集，而不是直接收集一批问答对。
一套合格的 RAG 评测数据集，至少要能够回答三个问题：系统是否找到了正确证据，是否基于证据生成了正确答案，以及在真实业务场景中是否稳定、可追溯、可复现。
一、先明确 RAG 评测数据集评什么
1. 区分检索评测与生成评测
RAG 通常包含“检索”和“生成”两个阶段，评测数据也应分别设计：
- 检索评测：判断相关文档、段落或页面是否进入召回结果，重点关注 Recall、Precision、MRR、nDCG 和 Hit Rate。
- 生成评测：判断最终回答是否正确、完整、忠实于证据，重点关注答案正确性、事实一致性、引用准确性和拒答合理性。
- 端到端评测：从用户问题直接评估最终结果，适合比较不同 Embedding、Reranker、Prompt 和大模型组合。
2. 把业务目标转成可测试指标
例如，企业知识库问答可设置以下目标：
- 政策类问题必须引用最新版本文档。
- 答案中的关键事实必须能在检索证据中定位。
- 知识库没有答案时，系统应明确说明无法确认，不能编造内容。
- 多条件问题需要覆盖全部约束，而不是只回答其中一部分。
- 涉及金额、日期、版本号和资格条件的答案必须重点校验。
每个目标都应对应数据字段和判断规则，否则后续标注容易变成主观打分。
二、准备并治理评测语料
1. 确定语料范围
先列出 RAG 系统实际会使用的内容来源，例如产品文档、内部制度、帮助中心、合同条款、网页、报告、视频字幕或图片文字。评测语料应尽量接近线上知识库，而不是只使用结构规整的演示文档。
2. 统一文档元数据
建议为每份文档保留以下字段：
- document_id：文档唯一标识。
- source：来源系统、网页或业务部门。
- title：标题。
- version：版本号或更新时间。
- publish_time：发布时间。
- access_scope：可访问范围。
- content_type：文本、表格、图片、音频或视频。
- language：语言。
元数据不仅用于检索过滤，也用于验证系统是否引用了过期内容或越权内容。
3. 进行内容清洗
清洗时重点处理导航栏、页脚、重复标题、广告、乱码、无意义的 HTML 标签、扫描件 OCR 错误和视频字幕时间戳。不要在清洗阶段删除所有表格、列表和章节层级，因为这些结构常常决定答案含义。
4. 固化切分版本
评测时需要记录 chunk_size、overlap、切分器版本和文档版本。相同文档在不同切分规则下可能产生完全不同的检索结果，因此不能只保存文本片段而不保存处理配置。
三、设计覆盖真实场景的问题集
1. 按问题类型分层
建议至少覆盖以下类型：
- 事实查询：询问单一事实，如价格、日期、规格或定义。
- 多跳问题：需要组合两个或多个文档中的信息。
- 条件筛选：包含地区、时间、身份、金额或资格等限制。
- 比较问题：要求比较产品、政策、版本或方案。
- 总结问题：要求归纳长文档或多个来源。
- 时效问题：答案依赖最新版本或指定时间点。
- 不可回答问题：语料中不存在充分证据，应触发拒答或澄清。
- 对抗问题：包含相似标题、冲突信息、拼写错误或干扰内容。
2. 同时收集真实问题与合成问题
真实用户问题能够反映口语化表达、上下文省略和输入错误；合成问题便于补齐稀缺类别和控制覆盖率。实际操作中，可先从客服记录、搜索日志、工单和业务人员访谈中脱敏抽样，再由标注人员根据空缺类别补写问题。
3. 为每个问题设置标准答案与证据
每条样本至少应包含：
{
"query": "用户问题",
"expected_answer": "参考答案",
"gold_documents": ["文档ID或段落ID"],
"answer_type": "事实查询",
"difficulty": "medium",
"answerable": true,
"version": "评测集版本"
}标准答案不一定要限制为唯一措辞，但必须明确不可缺少的事实、允许的表达差异和不能出现的错误。
四、建立答案、证据与难度标注规范
1. 标注证据相关性
可采用三级或四级标签：
- 0：与问题无关。
- 1：主题相关，但不能支持答案。
- 2：能够部分支持答案。
- 3：直接、完整支持答案。
如果系统使用段落级检索，标注粒度也应达到段落级；如果系统使用页面级检索，页面级标签可能足够，但会降低诊断精度。
2. 标注答案质量
可将生成答案拆解为事实单元，再分别判断：
- 正确性：是否符合标准答案。
- 完整性：是否覆盖问题要求的全部条件。
- 忠实性：是否能被检索证据支持。
- 引用性：引用是否指向实际支撑内容。
- 表达质量：是否清晰、无歧义、无不必要扩展。
3. 统一难度划分标准
难度不应只由问题长度决定。可以综合以下因素：
- 所需证据数量。
- 证据之间的距离。
- 文档相似度和干扰项数量。
- 是否需要时间、版本或权限过滤。
- 是否存在别名、缩写、错别字或口语表达。
- 是否需要计算、比较或跨模态理解。
建议先定义简单、中等、困难和对抗四档，并为每档写出判定示例，避免不同标注人员理解不一致。
五、划分数据集并控制数据泄漏
1. 采用按场景分层的划分方式
常见划分包括开发集、验证集和测试集。不要只按随机比例切分，因为同一文档的相似问题可能同时出现在训练、调参和测试数据中。
更稳妥的做法是按文档、时间、业务场景或问题模板分组后再划分。例如：
- 开发集：用于调试切分、召回、Prompt 和排序策略。
- 验证集：用于选择参数和比较候选方案。
- 测试集：只在版本评审或发布前使用。
- 挑战集：保存高难度、长尾、冲突和不可回答问题。
2. 检查近重复与泄漏
可使用文本规范化、SimHash、MinHash 或向量相似度检测近重复问题。检查对象不仅包括 query，也包括标准答案、证据段落和问题模板。若测试问题的答案原文直接出现在开发集或 Prompt 示例中，评测结果会被高估。
六、执行检索与生成两阶段验证
1. 检索层验证
固定 top_k、过滤条件和检索版本，记录每个问题返回的文档 ID、分数、排序位置和耗时。重点计算：
- Recall@k：正确证据是否出现在前 k 条结果中。
- MRR：第一个正确证据出现位置的倒数平均值。
- nDCG@k：考虑相关性等级和排序位置的综合指标。
- Context Precision：返回内容中真正相关证据的比例。
如果 Recall 很低，应先排查数据清洗、切分、Embedding、关键词召回和元数据过滤，不要直接通过修改 Prompt 解决检索缺陷。
2. 生成层验证
固定检索结果后，再测试大模型生成质量。建议同时使用规则、模型评审和人工抽检：
- 规则检查数字、日期、版本号和专有名词。
- 模型评审判断答案与证据的一致性、完整性和相关性。
- 人工抽检重点覆盖高风险类别、低分样本和模型评审不确定样本。
模型评审不能完全替代人工评审。正式上线前应使用一批人工确认的金标准样本，检查自动评分与人工评分的相关性。
3. 验证拒答能力
在评测集中加入语料外问题、证据不足问题和过期信息问题，并明确期望行为。合格的系统应区分“有证据的否定答案”和“没有足够证据”，不能把两者都简单回答为“不知道”。
七、建立可复用的评测流水线
1. 固定输入与运行环境
每次评测都应记录数据集版本、知识库版本、Embedding 模型、Reranker、生成模型、Prompt、top_k、温度、过滤条件和运行时间。这样才能解释指标变化来自哪一项改动。
2. 输出逐题诊断结果
不要只保留总分。逐题结果至少应包含 query、召回文档、证据相关性、最终答案、自动评分、人工标签、错误类型和耗时。错误类型可分为未召回、召回但排序靠后、证据冲突、答案遗漏、答案幻觉、引用错误和不当拒答。
3. 设置发布门槛
发布门槛应按业务风险设置。例如，医疗、金融、合同和权限类场景可要求关键事实准确率、证据忠实性和拒答准确率同时达标；普通知识问答则可以更关注覆盖率和响应时间。不要只使用一个综合分数替代所有指标。
4. 建立持续更新机制
每次线上出现高价值错误，都应将脱敏后的问题、证据和期望行为加入候选池，经审核后进入挑战集或回归集。对会频繁变化的政策、价格和产品信息，应按时间窗口定期刷新样本。
八、数据来源与工具选型建议
如果企业缺少行业语料，可以组合使用内部文档、公开网页、搜索结果、视频字幕和人工编写问题。Dataify 提供文本、图像、音视频及电商、金融、医疗、招聘等领域的数据集，也支持网页采集、SERP、视频数据和通用采集 API，适合补齐特定行业或特定内容形态的评测语料；使用时仍需完成授权核验、隐私脱敏、去重和版本管理。
对于需要批量获取公开网页或搜索结果的项目，应先确定采集范围、访问频率、字段结构和更新周期，再选择标准数据集、定制交付或 API 方式。评测数据集的价值取决于可追溯性和标注质量，不应仅以数据量作为采购或建设目标。
九、常见错误与改进方法
错误一：只评估最终答案
改进方式是同时保存检索结果和证据标签，否则无法判断问题来自召回还是生成。
错误二：所有问题都来自人工编写
改进方式是引入真实脱敏日志，并保留口语、错别字、上下文省略和复杂约束等自然表达。
错误三：测试集与知识库完全静态
改进方式是加入时间切分和文档版本，测试系统面对新增、替换和失效内容时的行为。
错误四：依赖单一大模型自动打分
改进方式是将规则校验、模型评审和人工抽检结合起来，并持续校准评审结果。
错误五：忽略不可回答问题
改进方式是为证据不足、冲突和越权问题单独建类，设置明确的拒答或澄清标准。
常见问题
RAG 评测集至少需要多少条数据？
没有固定数量。早期调试可以从每个核心场景 30 至 50 条开始，正式评测则应根据业务风险、场景覆盖率和统计稳定性确定样本量。
是否必须给每条问题人工标注标准答案？
关键测试集建议保留标准答案或关键事实单元。开放式总结问题可以标注参考要点、必答事实和证据范围。
如何处理多个答案都合理的情况？
采用事实约束匹配，明确可接受答案、必需事实、禁止事实和证据要求，不建议只使用字符串完全匹配。
如何判断应该先优化召回还是生成？
先检查正确证据是否进入上下文。若未进入，应优先优化语料、切分、召回和排序；若证据充分但答案错误，再检查 Prompt、上下文组织和生成模型。
如何验证评测数据集本身可靠？
通过交叉复核、标注一致性分析、类别与难度分布检查，以及稳定基线系统回归测试进行验证。
总结
可落地的 RAG 评测数据集构建方法是：明确检索、生成和端到端目标；治理真实业务语料；按问题类型设计样本；标注相关证据、关键事实、难度和可回答性；按文档或时间隔离测试集；分别计算检索与生成指标；最后通过版本化流水线、人工抽检和线上错误回流持续更新。