评估集防泄漏与复现
评估集版本复现、数据泄漏、偏差审计与切片覆盖
原题：请阐述构建高质量、可复现的Agent或RAG系统评估数据集的关键步骤，包括任务设计、标注策略、多样性保障与偏差控制等。
评估与监控 · 安克科技真题
30 秒回答
- 明确区分Agent与RAG的评估维度差异（工具调用vs检索质量）
- 数据构建需覆盖真实用户分布而非理想场景
- 标注策略必须包含多轮校验与一致性指标
- 多样性需从任务类型、难度、领域三维度设计
回答与解析
答案要点
- 明确区分Agent与RAG的评估维度差异（工具调用vs检索质量）
- 数据构建需覆盖真实用户分布而非理想场景
- 标注策略必须包含多轮校验与一致性指标
- 多样性需从任务类型、难度、领域三维度设计
- 偏差控制需显式处理位置偏差、流行度偏差和标注者偏差
一、任务设计：区分Agent与RAG的核心差异
RAG评估重点
- 检索相关性：召回率、精确率、NDCG
- 生成忠实度：答案是否基于检索内容，有无幻觉
- 答案完整性：是否覆盖用户问题的全部意图
Agent评估重点
- 工具调用准确性：参数解析、工具选择、调用时机
- 规划合理性：任务分解步骤是否最优、能否处理失败回退
- 多轮状态追踪：上下文记忆与槽位填充
关键原则：任务设计必须从真实日志采样，而非人工臆造理想query。
二、标注策略：三层质量控制
| 层级 | 方法 | 目的 |
|---|---|---|
| 初标 | 领域专家+标注指南 | 建立标准 |
| 复核 | 交叉验证（≥2人）+ Cohen's Kappa | 一致性检验 |
| 仲裁 | 专家委员会处理分歧样本 | 边界case定义 |
可复现性保障：开源标注指南、标注者背景信息、决策日志。
三、多样性保障：三维覆盖
- 任务类型：事实问答、推理、比较、多跳、开放式生成
- 难度分层：单文档→多文档→需外部知识→需工具组合
- 领域分布：按业务流量比例采样，避免长尾盲区
量化指标：计算query的embedding分布熵，确保簇间距离均匀。
四、偏差控制：四类典型偏差
| 偏差类型 | 表现 | 控制手段 |
|---|---|---|
| 位置偏差 | 答案在文档开头/结尾被过度召回 | 答案位置随机化 |
| 流行度偏差 | 高频实体被过度采样 | 按实体频率逆加权采样 |
| 标注者偏差 | 标注者个人知识影响判断 | 盲测+背景多样性 |
| 模板偏差 | query句式过于统一 | 基于LLM的paraphrase扩增+人工校验 |
五、可复现性 checklist
- 数据集版本化（DVC/Git LFS）
- 公开采样策略与过滤规则
- 提供基线模型运行脚本
- 记录随机种子与环境依赖
口语版讲法(约4分钟)
- 一句话定位：构建评估数据集本质是模拟真实用户反馈
- 边界划分：RAG与Agent评估的差异，以及RAG vs 微调的适用场景
- 标注策略：三层质量控制与可复现性
- 多样性保障：三维覆盖与量化指标
- 偏差控制：位置、流行度、标注者、模板偏差
- 落地风险与前提：常见失败场景与工程师取舍
这道题问的其实是，你怎么用一个评估数据集来模拟真实用户反馈，让Agent或RAG系统上线前就暴露问题。说白了，评估数据集就是系统的镜子，镜面不平，照出来的全是扭曲的。
先说边界划分。RAG和Agent的评估重点完全不同。RAG更关注检索质量，比如召回率、NDCG，还有生成内容是否忠实于检索结果，有没有Hallucination。Agent则更看重工具调用，比如Function Calling参数解析对不对、任务规划是否合理、多轮对话状态能不能记住。但真正落地时，两者常常是混合的，比如一个客服系统既有知识库检索又有工具调用，那评估就得两套一起上。另外，很多人会纠结RAG和SFT怎么选，我的判断是，如果知识频繁更新，RAG更合适，因为微调跟不上变化；如果知识相对稳定、对推理深度要求高，微调更合适。评估数据集也要对应调整。
具体到构建步骤，我重点讲几个核心点。
先说标注策略。我一般做三层：先让领域专家按标注指南做初标，建立标准；然后交叉验证，至少两个人标同一批数据，算Cohen's Kappa一致性指标，低于0.6就要复核；最后专家委员会仲裁分歧样本，特别是边界case。可复现性上，我会把标注指南、标注者背景、决策日志都开源，这样别人能复现我的评估流程。这里有个坑：标注者背景要多样，不能全是内部员工，否则数据会偏向理想场景。
再一个是多样性保障。我会从三个维度覆盖：任务类型，比如事实问答、推理、多跳、开放式生成；难度分层，从单文档到多文档再到需要工具组合；领域分布，按业务流量比例采样。比如一个电商客服系统，退款、物流、促销的query比例要跟线上一致，不能因为退款好标就多标。量化上，我会计算query的Embedding分布熵，确保簇间距离均匀，避免扎堆。
偏差控制是容易被忽视的点。常见四类：位置偏差，答案在文档开头容易被过度召回，我会把答案位置随机化；流行度偏差，高频实体被过度采样，我会按实体频率逆加权；标注者偏差，标注者个人知识影响判断，我会用盲测加标注者背景多样性；模板偏差，query句式太统一，我会用LLM做Paraphrase扩增再加人工校验。
落地时有个前提：如果线上日志质量差，比如用户query噪声大或意图不明确，那评估数据集再完美也没用。常见失败场景是，数据集构建特别漂亮，但上线后效果差，因为真实用户分布变了。所以上线我会特别关注数据漂移，定期用新日志更新评估集。
所以整体上，我更倾向把评估数据集看成一个持续迭代的活系统，而不是一次性交付。数据版本化、采样策略公开、基线模型运行脚本都要配套。
还有一个延伸点：评估数据集本身也可能引入偏差，比如标注者偏好某些回答风格，这时候可以用Self-RAG让模型自己反思评估结果，但会带来额外延迟和成本。
关键一句:评估数据集本身可能引入偏差，可以用Self-RAG让模型自反思来缓解，但需权衡延迟和成本
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服Agent，用户问“帮我查一下订单”，然后又说“退款怎么走”。你怎么设计评估数据集，才能既测工具调用又测检索质量，而且保证数据是从真实对话里来的，不是凭空捏的？
- 问法 2 · 层层追问
你觉得评估一个Agent或RAG系统，数据构建最关键的是什么？……那标注质量怎么保证？……再细一点，多样性怎么覆盖？……还有偏差控制，具体怎么做？
- 问法 3 · 直球架构
构建一个高质量、可复现的Agent或RAG评估数据集，请从头讲清楚步骤：任务设计、标注策略、多样性保障和偏差控制，每个环节要可落地。