RAG 评测集怎么构建？为什么每条用例要标到来源片段？

简化版

评测集是衡量 RAG 效果的尺子，尺子错了，量出来的一切都是错的。每条用例至少要有问题、标准答案、答案所在的来源片段。标准答案是硬要求，没有它就无法判断召回全不全、答案对不对；来源片段要精确到单条，Context Recall 才能直接用集合运算算出来，而且分母不会被撑大。用例有三种来源：手工录入贴近真实问法，从文档自动生成用来快速铺量但分数偏乐观，从用户点踩沉淀最真实但标准答案必须由人补。

详细版

一条合格的用例：

字段	作用
问题	拿去跑检索和问答
标准答案	判断召回是否覆盖、答案是否正确的依据
来源片段 ID	答案实际出自哪几个片段，用于算检索指标
来源类型	手工录入、文档生成、反馈沉淀，分析分数时要区分
是否启用	标准答案没补完的用例不参与评测

三种来源各有定位：

手工录入：按真实用户的口气出题，数量少但最能反映线上水平；
文档自动生成：让模型照着片段出题并标出来源，快速搭起一套能跑的评测集，但问法和原文高度重合，分数天然偏乐观；
用户反馈沉淀：把点踩的问题收进评测集，是真实的失败样本，标准答案必须由懂业务的人补。

完整版教学

一、评测集是尺子

RAG 的每一项优化，比如加混合检索、开重排、换切分策略，都要回答一个问题：效果到底有没有变好？ 凭几个问题手工试一试，换一批问题结论可能就反了。评测集就是固定下来的那一批问题，每次改动之后在同一批用例上重跑一遍，分数的变化才有意义。

也正因为它是尺子，评测集本身的质量比任何一项优化都重要。标准答案写错、来源片段标错、问题太简单，量出来的分数都会误导后面所有的决策。

记忆钩子：先保证尺子准，再去量效果。评测集错了，调得越努力，离正确方向越远。

二、一条用例要记哪些信息

一个可用的用例表结构：

CREATE TABLE eval_case (
  id                  INT PRIMARY KEY AUTO_INCREMENT,
  dataset_id          INT NOT NULL,           -- 所属评测集
  question            VARCHAR(1000) NOT NULL, -- 问题
  ground_truth        LONGTEXT,               -- 标准答案
  reference_chunk_ids VARCHAR(500),           -- 答案所在片段的 ID，逗号分隔
  source              VARCHAR(30),            -- 手工录入 / 文档生成 / 反馈沉淀
  enabled             VARCHAR(10)             -- 标准答案没补完的用例先停用
);

来源类型要单独记下来，因为三种来源的用例难度不同：只看总分会掩盖问题，按来源拆开看，才知道「自动生成的用例得分高、真实用户的用例得分低」这种落差。

三、标准答案为什么是硬要求

RAG 评测常用的四个指标里，有两个直接依赖标准答案：

指标	测什么	是否需要标准答案
Context Recall	该找的资料找回来没有	需要：拿标准答案去比对召回的资料
Context Precision	有用的资料是否排在前面	可以不需要，但有标准答案判得更准
Faithfulness	答案有没有编	不需要：比对的是答案和资料
Answer Relevancy	答案有没有跑题	不需要：比对的是答案和问题

没有标准答案，只能测「答案是否忠于资料、是否切题」，测不出「该找的资料有没有找全」，也测不出答案本身对不对。所以录入用例时，标准答案必须填；暂时写不出来的，宁可先停用这条用例。

四、来源片段为什么要精确到单条

Context Recall 最省事的算法是集合运算：

Context Recall = 召回结果中命中的参照片段数 ÷ 全部参照片段数

参照片段就是用例上记的来源片段 ID。这里有一个常见的偷懒做法：从一篇文档批量生成用例时，每条用例都把整篇文档的所有片段记为来源。看一个算例：

一篇文档切成 9 段，据此生成 5 条用例，每条都记成 9 个片段
问「电源适配器保修多久」，答案只在第 2 段
检索召回了第 2 段，答案完全正确
Context Recall = 1 / 9 ≈ 0.111

答案对了，分数却是 0.111。更糟的是，检索 top_k = 5 时最多召回 5 段，这个指标的理论上限被卡死在 5/9 ≈ 0.556，永远拿不到高分。分母错了，指标就不再反映检索好坏，只反映「文档被切成了几段」。精确到单条之后，同一个问题只要召回了第 2 段，Context Recall 就是 1/1 = 1.0。

没有标来源片段的用例怎么办？留空，不要瞎填。留空时让模型逐句判断「标准答案能否在召回资料里找到依据」，多花几次模型调用，但分数是有意义的；填一串错的参照，算出来的数字只会误导。

五、三种来源各自的问题

文档自动生成：会「泄题」。 模型照着片段出题，问法和原文用词高度重合：

原文：GTE-3000Pro 整机质量保证期为自出厂之日起 24 个月
出题：GTE-3000Pro 整机的质量保证期是多长时间？
真实用户：我这机器保修多久？过保了吗？

向量检索面对「几乎是原文改成疑问句」的问题当然一击即中，所以自动生成的评测集分数天然偏乐观，测出 0.8 不代表线上能有 0.8。它的定位是快速铺量。

手工录入：贵，但像真实用户。 按真实用户的口气出题，覆盖口语化、缺主语、带错别字的问法，数量不必多，但要有。

用户反馈沉淀：最真实，但标准答案不能交给模型。 系统刚刚答错了这个问题，再让同一个模型生成「正确答案」，多半还是错的。沉淀下来的用例先停用、标成待补充，由懂业务的人补完标准答案再启用。

六、自动生成的用例怎么把关

自动生成省力，但要有几道关口：

让模型一起返回来源编号。 给模型的片段带上「[片段1]」「[片段2]」编号，要求每条问答对返回答案所在片段的编号，程序再换成真实的片段 ID；
半条用例直接丢掉。 只有问题没有答案的条目入库后，Context Recall 算不出来，平均分被拉低还查不出原因；
人工核对标准答案。 模型可能看错段落、把相邻条款张冠李戴，比如「备件保修 6 个月」「有偿维修保修 3 个月」挨在一起时很容易答混。核对时把问题、标准答案、来源片段原文三样摆在一起看。

七、评测集要持续维护

评测集不是建一次就完事：

随线上反馈增长：每周把点踩的问题沉淀进来，评测集会越来越接近真实分布；
用启用开关管理：有问题的用例先停用，而不是删除，保留修改记录；
结构要均衡：专有名词类、口语改写类、多轮追问类、知识库里没有答案的问题都要有，否则某一类优化的效果测不出来；
固定之后再比较：对比两套策略时，必须用同一版评测集，中途增删用例会让前后分数失去可比性。

八、常见误区与追问

误区：评测集越大越好，全交给模型自动生成。 自动生成的问题和原文用词高度重合，分数偏乐观，必须混入手工录入和真实反馈的用例。
误区：来源片段记整篇文档更省事，也不会错。 参照片段过多会把 Context Recall 的分母撑大，答案完全正确也只能拿到很低的分，指标失去意义。
误区：点踩沉淀的用例可以让模型补标准答案。 系统刚答错了这个问题，同一个模型再生成的「正确答案」多半还是错的，必须由懂业务的人补。
误区：模型没标出来源时随便填一个片段。 错误的参照比没有参照更糟，留空时改用模型语义判断，分数才有意义。
误区：评测集建好就不用再动。 线上问题分布会变，要持续把失败样本沉淀进来，并用启用开关管理有问题的用例。
追问：自动生成的评测集分数偏乐观，还有什么用？ 用来快速铺量、做策略之间的相对比较；判断线上真实水平，要看手工录入和反馈沉淀那部分用例的分数。
追问：没有标准答案，还能评测 RAG 吗？ 能测 Faithfulness 和 Answer Relevancy，判断答案是否忠于资料、是否切题，但测不出召回是否完整、答案本身是否正确。

九、加强记忆

评测集是尺子，尺子错了量什么都错。每条用例要有问题、标准答案、来源片段 ID、来源类型和启用状态：标准答案是硬要求，没有它测不了召回和正确性；来源片段必须精确到单条，Context Recall 等于命中的参照片段除以全部参照片段，记成整篇文档会把分母撑大，9 段文档、top_k 为 5 时上限只有 5/9。三种来源分工明确：自动生成用来铺量但会泄题、分数偏乐观；手工录入贴近真实问法；点踩沉淀最真实，但标准答案必须由人补。自动生成要带回来源编号、丢掉半条用例、人工核对原文；评测集要持续沉淀、用开关管理、比较时用同一版。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的评测集管理支持三种来源，用例存在 eval_case 表里，关键字段有 question、ground_truth、reference_chunk_ids（逗号分隔的片段 ID）、source（手工录入、文档生成、反馈沉淀）和 enabled：

手工录入：标准答案必填，提示语里写明为什么必须填；
从文档自动生成：片段带编号交给模型，要求以 JSON 返回 question、ground_truth、source_index 三个字段，程序把序号换成真实的 chunk_id 写进 reference_chunk_ids；只有问题没有答案的条目在生成阶段直接丢掉；
从点踩沉淀：点踩的问题进入评测集时 ground_truth 为空、enabled 为「否」，页面用橙色「待补充」标签标出，补完标准答案才能启用。

用例列表上有「看原文」按钮，把问题、标准答案和来源片段原文摆在一起核对；手工录入和反馈沉淀的用例没有来源片段，按钮置灰。跑评测时，带了 reference_chunk_ids 的用例直接用集合运算算 Context Recall，不调模型。

为什么这样取舍

自动生成只负责铺量。 生成的问题和原文用词高度重合，分数偏乐观，要靠另外两个来源把分数拉回真实水平。
沉淀的用例默认停用。 标准答案没补之前参与评测，只会拉低平均分还查不出原因。

面试官还会追问

评测功能一共建了哪几张表？它们各自管什么？
用户点踩的问题沉淀成用例之后，怎么找回当时的那次提问和回答？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版