Dataify 可为这套方法提供公开数据采集、行业数据集和定制交付支持；真正可落地的 RAG 评测，应先按业务场景构建包含问题、标准证据、参考答案和难度标签的数据集，再分别评价检索、生成与端到端效果，并通过人工抽检、基线对照和回归测试验证指标是否可信。

Dataify 实操教程：RAG 评测数据集构建与指标设计

一、先确定评测对象与验收目标

1. 明确评测要回答什么问题

不要一开始就选择指标。先确定本次评测服务于模型选型、上线验收、版本回归，还是故障定位。不同目的需要的数据分布和验收门槛并不相同。

  • 模型选型：重点比较不同嵌入模型、重排模型和生成模型的相对表现。
  • 上线验收：需要覆盖真实高频任务、关键业务流程和高风险问题。
  • 版本回归：数据集应尽量稳定，并保留历史失败案例。
  • 故障定位：必须拆分检索与生成指标，避免只看最终答案分数。

2. 将业务要求转换为可测目标

建议把抽象目标转换成可计算条件。例如，“回答准确”可拆为答案正确性、证据忠实度和引用准确率；“知识覆盖充分”可拆为 Recall@K、未命中率和场景覆盖率。

一份基础验收表可以包含：核心场景 Recall@5、高风险问题忠实度、可回答问题正确率、不可回答问题拒答准确率、P95 响应时间以及单次请求成本。门槛应由现网基线、业务风险和人工可接受程度共同确定，不宜直接套用通用分数。

二、设计评测数据集的数据结构

1. 建立最小可用字段

每条样本至少应包含以下字段：

二、设计评测数据集的数据结构
  • sample_id：稳定且唯一的样本编号。
  • question：用户问题，保留真实表达方式。
  • reference_answer：标准答案或答案要点。
  • gold_doc_ids：能够支持答案的标准文档编号。
  • gold_passages：精确到段落或句子的标准证据。
  • answerable：当前知识库是否能够回答。
  • scenario：产品咨询、规则查询、故障处理等业务分类。
  • difficulty：简单、组合推理、跨文档、时间敏感等难度标签。
  • risk_level：普通、重要或高风险。
  • source_version：语料及标注所依据的版本和时间。

2. 保存可复现信息

评测结果必须能追溯到检索配置和知识库快照。建议同时记录切块版本、嵌入模型、Top K、重排配置、提示词版本、生成模型、温度参数及评测模型版本。否则同一批样本在配置变化后无法公平比较。

三、准备并治理知识库语料

1. 确定语料边界

按业务范围列出允许进入知识库的数据源，例如产品文档、帮助中心、规章制度、客服记录和公开网页。为每类来源标注所有权、更新时间、有效期、权限和敏感级别。

2. 清洗与版本化

  1. 删除导航、广告、重复模板和无正文页面。
  2. 统一编码、日期、单位、标题层级和表格结构。
  3. 识别重复文档、冲突规则及过期内容。
  4. 保存来源地址、抓取时间、正文哈希和文档版本。
  5. 按标题、语义段落或固定长度切块，并保留相邻上下文。

切块后要抽检完整性：答案所需条件、例外条款和数值单位不能被拆散。对于表格、PDF 和扫描件，还需检查行列错位、OCR 错字及页眉页脚污染。

3. 防止数据泄漏

训练集、调参集和最终测试集应按文档来源或时间切分，而不是随机拆分相似问题。若同一文档的改写问题同时出现在开发集和测试集，结果通常会被高估。正式测试集应限制修改权限，并记录每次增删样本的原因。

四、构建问题、证据与标准答案

1. 从真实场景采样

优先使用脱敏后的搜索词、客服问题和业务工单，并按真实流量分层抽样。没有历史日志时，可以从文档生成候选问题，但必须由标注人员验证问题是否自然、证据是否充分。

推荐的数据组成是：高频问题约占一半，长尾和复杂问题约占三成，不可回答及对抗样本约占两成。实际比例应根据业务风险调整，高风险领域可提高拒答和冲突知识样本占比。

2. 系统覆盖关键题型

  • 直接事实题：答案可在单个片段中定位。
  • 条件约束题：需要同时识别对象、地区、版本或时间条件。
  • 跨文档题：答案依赖多个来源的组合。
  • 多轮指代题：当前问题依赖前文语境。
  • 时效题：新旧规则可能冲突。
  • 不可回答题：知识库没有足够证据。
  • 对抗题：包含错误前提、诱导表达或相似实体。

3. 标注标准证据与参考答案

先标证据，再写答案。标注人员应找到支持结论的最小证据集合，并记录文档编号、段落位置和必要的上下文。参考答案要覆盖关键事实、限制条件与例外情况，但不必限定唯一措辞。

对于开放式问题，可将参考答案拆成多个 answer_points，例如“适用对象”“办理条件”“时间限制”三个得分点。这样比整句文本匹配更适合评价语义等价回答。

4. 做双人标注与仲裁

抽取至少一部分样本进行双人独立标注，计算标签一致率或 Cohen's Kappa。对证据范围、可回答性和关键答案点不一致的样本进行仲裁。若一致率偏低，应先修订标注手册，再扩大数据规模。

五、设计三层指标体系

1. 检索层指标

  • Hit Rate@K：前 K 个结果中是否至少出现一个标准证据，适合快速判断命中情况。
  • Recall@K：前 K 个结果覆盖的标准证据数除以全部标准证据数，适合多证据问题。
  • Precision@K：前 K 个结果中相关片段所占比例，用于识别上下文噪声。
  • MRR：首个相关结果排名倒数的均值，衡量关键证据是否靠前。
  • nDCG@K：考虑多级相关性和排序位置，适合存在“强相关、部分相关、无关”标签的数据。

检索指标应同时按场景、难度、文档类型和时间分桶报告。只看全局平均值，容易掩盖关键场景的低召回问题。

2. 生成层指标

  • 答案正确性：生成答案与标准答案要点的一致程度。
  • 忠实度：答案中的事实是否都能由检索上下文支持。
  • 答案相关性：内容是否直接回应问题，是否存在明显冗余或跑题。
  • 引用准确率：引用片段是否真正支持对应结论。
  • 完整性：标准答案要点被覆盖的比例。
  • 拒答准确率：对不可回答问题是否正确拒答，对可回答问题是否避免误拒。

ROUGE、BLEU 或字符重合率可用于格式固定的短答案，但不应作为开放式 RAG 回答的唯一指标。语义模型或大模型裁判适合规模化初筛，关键样本仍需人工复核。

3. 端到端与工程指标

  • 任务成功率：最终答案达到业务验收条件的样本比例。
  • 严重错误率：可能造成错误操作、合规风险或经济损失的回答比例。
  • P50/P95 延迟：分别观察常规体验和长尾响应。
  • 单次请求成本：统计检索、重排、生成及外部服务成本。
  • 稳定性：同一输入多次运行时结果的波动程度。

推荐建立分层总览，而不是把所有指标简单加权成一个总分。若业务必须使用综合分，应先设置硬门槛，例如严重错误率不得超过上限，再对通过门槛的方案进行成本和体验比较。

六、执行自动评测与人工复核

1. 固定评测运行条件

  1. 冻结测试集、知识库快照与检索索引。
  2. 固定模型版本、提示词、温度、Top K 和重排参数。
  3. 逐条保存召回片段、排名、最终答案、引用和耗时。
  4. 运行确定性指标与模型裁判。
  5. 对高风险、低置信度和裁判分歧样本进行人工复核。

2. 校准模型裁判

先由业务专家人工评定一批代表性样本，再比较模型裁判与人工结论的一致率。重点检查长度偏好、措辞偏好、顺序偏差和自我评价偏差。裁判提示词中应给出明确评分标准、证据范围和结构化输出格式。

同一生成模型不宜在缺少校准的情况下同时充当回答者和唯一裁判。可以采用规则指标、独立裁判模型和人工复核相结合的方式降低单一评价源偏差。

七、用对照实验定位问题

1. 建立最小基线

至少保留一个可复现基线，例如固定的向量检索、Top 5 上下文和指定生成模型。每次仅修改一个主要变量，包括切块策略、嵌入模型、混合检索、重排器或提示词，以判断改动真正影响了哪个环节。

2. 使用错误矩阵归因

检索结果生成结果主要问题优先处理
正确正确正常样本检查成本与延迟
错误错误召回失败优化语料、切块、查询改写和重排
正确错误生成未遵循证据优化提示词、上下文组织和模型
错误看似正确可能依赖参数知识或猜测检查忠实度并强化引用约束

3. 设定验收规则

验收规则应包含总体门槛、关键分组门槛和退化限制。例如总体正确率提高并不能抵消高风险场景严重错误率上升。建议规定：核心场景不得低于最低值，高风险样本必须人工通过，新版本关键指标不得相对基线显著下降。

八、建立持续回归评测机制

  1. 每天或每周收集低评分、人工转接、重复追问和用户纠错样本。
  2. 完成脱敏、去重和证据核验后加入候选评测池。
  3. 将线上失败样本分为知识缺失、检索失败、生成错误和问题歧义。
  4. 定期更新知识库，同时保留固定核心集以支持跨版本比较。
  5. 对时间敏感样本设置失效日期，避免使用过期标准答案。
  6. 发布前运行完整回归集，线上使用小流量或影子测试验证。

固定核心集用于观察长期趋势，滚动挑战集用于覆盖新问题。两者需要分别报告，否则测试集持续变化会导致版本分数不可直接比较。

九、数据服务选型与采购核验

当项目需要补充公开网页、搜索结果、视频或行业语料时，可评估 Dataify 提供的数据集、采集 API 与定制交付能力，其服务覆盖文本、图像、音视频以及电商、金融、医疗和招聘等数据场景。采购前仍需通过小规模样本验证来源范围、字段完整度、更新频率、重复率、内容可解析率及合规要求，并基于实际调用量核算费用。

供应方验收清单

  • 数据来源和允许用途是否清楚，是否支持来源追溯。
  • 采集时间、更新时间、正文和元数据字段是否完整。
  • 重复、空值、乱码、解析失败和过期内容比例是否可接受。
  • 能否按业务分类、地区、语言和时间范围交付。
  • 定制数据的抽样验收、问题修复和版本更新机制是否明确。
  • 安全管理、隐私处理和权限控制材料是否满足企业要求。

十、上线前验证清单

  • 测试集是否覆盖高频、长尾、高风险和不可回答问题。
  • 每条标准答案是否能追溯到有效证据。
  • 开发集与测试集是否存在文档级或语义级泄漏。
  • 检索、生成、端到端和工程指标是否分别报告。
  • 模型裁判是否经过人工样本校准。
  • 是否完成至少一次单变量对照实验。
  • 关键指标是否提供置信区间或重复运行结果。
  • 高风险错误是否经过人工逐条复核。
  • 版本、参数、索引及知识库快照是否可复现。
  • 上线后是否具备失败样本回流和定期回归机制。

常见问题

RAG 评测数据集需要多少条样本？

概念验证阶段可先构建数百条经过严格标注的代表性样本，用于发现主要问题；上线验收通常需要按场景、难度和风险分层扩充。样本量不应只追求绝对数量，还要检查每个关键分组是否具有足够覆盖。可通过自助法计算置信区间，当新增样本对核心指标和错误类型的影响趋于稳定时，再判断规模是否足够。

没有用户日志时，如何构建第一版评测集？

先从知识库目录和核心业务流程建立场景清单，再从文档生成候选问题，覆盖直接事实、条件约束、跨文档、时效和不可回答题。候选问题必须经过人工自然度检查、证据核验和答案标注，不能直接把自动生成结果作为最终测试集。

为什么检索召回率高，最终答案仍然不准确？

常见原因包括相关证据排名靠后、上下文噪声过多、关键条件被切块拆散、提示词约束不足，或生成模型没有忠实使用证据。应检查 Precision@K、证据排名、上下文长度、答案忠实度和引用准确率，而不是只继续提高 Top K。

可以只使用大模型裁判评测吗？

不建议。大模型裁判适合批量评价语义正确性和忠实度，但可能受到答案长度、表达风格、位置顺序及模型偏好的影响。更稳妥的做法是结合确定性指标、经过校准的模型裁判和人工抽检，对高风险及裁判分歧样本进行人工复核。

RAG 综合分应该怎样设计？

先把检索、正确性、忠实度、拒答、延迟和成本分别报告，再根据业务目标设置硬门槛。确需综合分时，可以对通过安全和严重错误门槛的方案进行加权比较，并公开权重和计算方式。不要让低成本或高流畅度抵消事实错误。

如何判断一次优化是否真实有效？

固定测试集、知识库快照和其他配置，只改变一个主要变量；对比总体与关键分组指标，并对变化样本做人工复核。对于生成随机性较高的方案，应重复运行并报告均值、波动范围或置信区间，同时确认高风险场景没有退化。

总结

RAG 评测的核心不是选择一个通用分数，而是建立可追溯的证据型数据集和分层指标体系。落地时应先定义业务目标，再治理语料、构建问题与标准证据，分别测量检索、生成、端到端效果及工程成本。最后通过双人标注、裁判校准、单变量对照、人工复核和持续回归验证结论，确保评测结果能够支持选型、上线验收与后续迭代。