RAG 问答金标构建

30 秒回答

1. 区分开发集/测试集/对抗集三层评估体系
2. 说明问题生成的四种来源（人工设计、LLM生成、真实日志、混合策略）
3. 阐述答案标注的完整流程（候选答案生成→多轮人工校验→置信度打分）
4. 解释真实性验证的具体手段（溯源检查、一致性校验、专家抽检）

回答与解析

答案要点

• 区分开发集/测试集/对抗集三层评估体系
• 说明问题生成的四种来源（人工设计、LLM生成、真实日志、混合策略）
• 阐述答案标注的完整流程（候选答案生成→多轮人工校验→置信度打分）
• 解释真实性验证的具体手段（溯源检查、一致性校验、专家抽检）
• 说明保证多样性的维度设计（文档类型、问题复杂度、答案位置、否定/多跳等挑战类型）

评估数据集的三层架构

问题来源的四种策略

1. 人工专家设计

• 领域专家基于文档直接编写
• 优势：质量高、覆盖边缘场景
• 劣势：成本高、主观性强

2. LLM辅助生成

Prompt模板要点：
- 指定角色（"你是领域专家"）
- 约束条件（基于给定文档、禁止脑补）
- 多样性控制（事实型/推理型/比较型/总结型）

3. 真实用户日志挖掘

• 从生产环境脱敏后的query中采样
• 需配合人工清洗过滤噪声

4. 混合策略（推荐）

• 70% LLM生成 + 20% 真实日志 + 10% 人工设计对抗样本

答案标注流程

Step 1: 候选答案生成

• 使用多个不同RAG系统并行生成答案
• 保留答案分布的多样性

Step 2: 多轮人工校验

• 第一轮：标注员独立标注（3人）
• 第二轮：分歧案例仲裁（专家介入）
• 第三轮：溯源检查（答案是否能在文档中找到依据）

Step 3: 置信度打分

• 高置信：3人一致且可溯源
• 中置信：2人一致或需推理
• 低置信：存疑，不入测试集

真实性验证手段

多样性维度设计

文档维度

• 类型：结构化表格、非结构化文本、图文混排
• 长度：短片段（<512 token）、长文档（>4k token）
• 领域：单领域深度 vs 跨领域混合

问题维度

• 答案位置：头部/中部/尾部/跨文档
• 复杂度：单跳检索 → 多跳推理 → 数值计算 → 时序推理
• 挑战性：显性答案 vs 隐性推断 vs 需要否定回答

关键比例控制

• 可回答 : 不可回答 = 8:2（测试拒答能力）
• 单跳 : 多跳 = 6:3:1（基础:进阶:挑战）

口语版讲法(约4分钟)

• 评估体系分层：开发/测试/对抗集各有用途
• 问题来源：人工、LLM、真实日志的混合策略
• 答案标注：多轮校验与置信度打分
• 真实性验证：溯源、一致性、负样本
• 多样性设计：文档类型、问题复杂度、挑战类型

这道题其实是在问，怎么造一套靠谱的数据来评估RAG系统好不好用，而不是随便找几个问题测测就完事。我一般会从三个层面来构建评估集：开发集、测试集和对抗集。开发集大概500到1000条，用来迭代调优，比如调 chunk 大小或者 rerank 阈值；测试集1000到3000条，做最终对比评测；对抗集200到500条，专门挑高难度、容易翻车的场景，比如需要多跳推理或者要回答“不存在”。三层分开，避免调参时过拟合到测试数据上。

先说问题怎么来。我倾向于混合策略，大概70%用 LLM 生成，20%从真实用户日志里挖，10%人工设计对抗样本。LLM生成效率高，但容易有幻觉，所以我会给一个严格的 prompt 模板，要求它基于给定文档出题，禁止脑补。真实日志最贴近业务，但噪声多，需要人工清洗。举个例子，在客服退款场景里，用户常问“为什么我的退款还没到账”，这种真实 query 直接拿来用就很有价值。人工设计则专门造一些刁钻的，比如“满减和折扣券能叠加吗”，这种跨规则的问题。

答案标注是重头戏。第一步，我会用多个不同RAG系统并行生成候选答案，保留多样性。第二步，三轮人工校验：三个标注员独立标，有分歧的由专家仲裁，最后强制溯源，答案必须在文档里能找到依据。第三步打置信度：三人一致且能溯源才算高置信，直接入测试集；两人一致或需要推理的算中置信，可以入但标记风险；低置信的存疑，先不入。这里有个坑：标注员容易受自己认知影响，比如觉得某答案合理但文档里没有，所以 溯源检查一定要严格执行，否则评测结果会虚高。

真实性验证我主要做三件事。一是自动溯源，强制模型输出引用片段，用字符串匹配加语义相似度双重验证。二是一致性校验，同一个问题换几种说法反复问，看答案是否稳定。三是负样本注入，混入文档里没有答案的问题，测试系统能不能正确拒答。专家抽检是兜底，对抗集100%人工复核，测试集抽10%。

多样性这块，我会从文档和问题两个维度设计。文档上，既有结构化表格也有非结构化文本，长度从短片段到长文档都有。问题上，答案位置覆盖头部、中部、尾部甚至跨文档；复杂度分单跳、多跳、数值计算、时序推理；挑战性上，显性答案和需要隐性推断的比例要平衡。关键比例我控制为可回答比不可回答8比2，单跳比多跳比挑战大概是6比3比1。

其实这里有个延伸点：对抗集的难度怎么量化，我目前是用错误类型来分类，比如缺失证据、矛盾证据、无关证据，但不同错误对系统的影响权重不一样，怎么自动分配权重是个开放问题。

所以整体上，我更倾向把评估数据集当成一个活的资产，而不是一次性造完就扔。上线我会特别关注真实用户日志的反馈，定期用新日志更新对抗集，因为业务规则会变，比如满减政策调整后，旧问题可能就失效了。

关键一句:对抗集的难度量化，按错误类型分类但权重分配是开放问题

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个电商客服RAG系统，上线前要测它的回答质量。你会怎么设计一套评估数据集？从哪搞问题，答案怎么标，怎么保证测出来的结果靠谱？

2. 问法 2 · 层层追问

   评估RAG系统你一般用什么数据集？……如果自己构建，问题从哪来？……那答案怎么标注才可靠？……怎么验证答案是不是真的从文档里来的？……怎么让测试集覆盖各种难的情况？

3. 问法 3 · 直球架构

   设计一个RAG系统的评估数据集构建方案。问题来源有哪些渠道？答案标注的完整流程是什么？真实性验证手段有哪些？如何保证数据在文档类型、问题复杂度、挑战类型上的多样性？