RAG 评测数据集（RAG Evaluation Datasets & Benchmarks）

概述

本主题聚焦 RAG 系统的评测数据集与常态化横评方法。核心立场来自 wiki/sources/RAG横评设计文档：把 RAG 评测从一次性脚本升级为可持续运行的横评体系，产出「跨时间、跨系统可对比的 regression 报告」。配套可运行脚手架见 ragbench.zip（其 DESIGN.md 与设计文档逐字相同）。

核心抽象与四大设计原则

被测系统 = 一份 system config（embedding / chunking / retriever / reranker / LLM / prompt 版本）；横评 = 在冻结的 corpus + queryset + judge 三元组下跑多份 config 出对比。正交实验：一次只动一个变量，便于归因。
四大原则：评测即 CI（config 驱动）· 分层归因（检索/生成解耦）· 版本三元组冻结 · LLM-judge 可信度工程。

数据集设计要点

维度	要点
corpus	必须冻结版本（`corpus@2026-06-01`）；慎用公开 benchmark 当 corpus（被测 LLM 可能预训练见过→分数虚高），自建私有 queryset 兜底
queryset 分层	single-hop / multi-hop / aggregation / unanswerable（拒答能力，生产最大风险点）
标注	gold answer（correctness）+ gold chunk（检索层独立评分）；queryset < 100 方差极大，须标注置信区间
可复用资源	框架 RAGAS / ARES / TruLens；检索/embedding BEIR / MTEB；真实带噪声 CRAG / LongBench-RAG

指标体系（分层归因）

检索层（需 gold chunk）：Recall@k / Hit Rate、Precision@k、MRR、NDCG@k、Context Relevance。
生成层：Faithfulness（拆 claims 逐条判 context 支持，防幻觉）、Answer Relevance（反向生成 query 比对）、Context Precision/Recall、Correctness、Hallucination Rate（单列）、Refusal Correctness（单列）。
运营指标（强制带）：TTFT、端到端延迟、单 query 成本。

LLM-as-judge 可信度工程

位置/长度偏置控制（A/B 随机化、多次取均）、judge 与被测家族解耦（防自我偏好）、rubric 显式化 + few-shot 锚点、人工校准（Cohen’s κ / Spearman，低于阈值重校准）、多裁判投票、judge drift 锁版本（进版本三元组）。

常态化工程（与一次性评测的区别）

版本三元组冻结：corpus + queryset + judge 版本一起记录——最易出 bug 处。
检索结果缓存：key = hash(retriever_config + corpus_version + query_id)，隔离变量 + 省钱 + 复现。
回归基线：出 delta 而非绝对分，掉超阈值（如 5%）告警。
CI pipeline：GitHub Actions 定时触发 + regression gate。

落地：RAGBench 脚手架

ragbench.zip 把上述设计逐条映射到代码：config.py（正交 inherits）、Frozen.triple_id（三元组）、metrics/retrieval.py + judge/engine.py（分层评分）、cache.py（检索缓存）、report/regression.py（delta 告警）、metrics/aggregate.py:bootstrap_ci（置信区间）、.github/workflows/eval.yml（CI + regression gate）。真实 judge：--judge anthropic（temperature=0、强制 JSON、与被测解耦）。

高频坑（Caveats）

坑	后果	缓解
数据泄漏	公开 benchmark 被预训练见过，分数虚高	自建私有 queryset 兜底
检索-生成耦合归因	端到端低分不清谁拖累	分层评分 + 缓存固定 context
judge drift	judge 升级后历史分数失效	judge 锁版本进三元组
样本量不足	queryset<100 方差极大	标注置信区间
只看质量分	忽略生产成本/延迟	ops 指标强制带

开放问题

？ mock 检索的固有局限：纯词面检索无法区分「无答案」与「低词重叠」，须靠「检索分 + 抽取式覆盖率」双阈值近似拒答；接真实 embedding/LLM 后消失。这正是横评要量化的检索-生成权衡。

[2026-08-10] 三轴稳健性审计与 MIST-Bench

来源：评测日报 08-10。

三轴稳健性审计（arXiv 2608.05153）

固定检索架构，沿 embedder / 语料 / judge 三轴变化，共 4,440 次主矩阵实验——正是本页”正交实验 + 版本三元组冻结”原则的大规模实践：

过度引用是架构性普遍现象：GraphRAG 每答 11–15 个 ID、引用精确率仅 0.12–0.23（检索召回 0.68–0.87）；但忠实度后果取决于语料——DO-178C 上忠实度随 hop 数 74%→40%，维基链上 42%→58%。
最关键发现——judge 轴极其脆弱：GPT-5.4 跨 embedder 自我一致性 kappa 仅 0.137，41% 条目判决翻转。本页”LLM-as-judge 可信度工程”需升级：除锁版本外，还应做跨配置 self-kappa 检查，并把结果写入报告（见 LLM-as-Judge 证据链）。

MIST-Bench（arXiv 2608.06377）：把”抗干扰”重定义为”选择性信任”

每个条目渲染 clean / misleading / correct-context / irrelevant-context 四条件；配套 SC2W 指标统计”误导信号把对题翻成错题”的频次。
无视全部上下文的模型看起来最鲁棒，实际上上下文可信时毫无用处——鲁棒性评测必须四条件分列报告，不能只看单一”抗干扰”分。
SCOPE（DPO on 配对失败对）显著降低 SC2W 而不损害其余条件准确率。适用于一切 RAG/长上下文团队的”该信的时候信不信”对照。

10xAI Wiki

导航