面试题 · 评估
搜索「位置偏差」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请阐述构建高质量、可复现的Agent或RAG系统评估数据集的关键步骤，包括任务设计、标注策略、多样性保障与偏差控制等。
RAG评估重点
Agent评估重点
按学习路线查看教程、项目和面试题。
关键原则：任务设计必须从真实日志采样，而非人工臆造理想query。
| 层级 | 方法 | 目的 |
|---|---|---|
| 初标 | 领域专家+标注指南 | 建立标准 |
| 复核 | 交叉验证（≥2人）+ Cohen's Kappa | 一致性检验 |
| 仲裁 | 专家委员会处理分歧样本 | 边界case定义 |
可复现性保障：开源标注指南、标注者背景信息、决策日志。
量化指标：计算query的embedding分布熵，确保簇间距离均匀。
| 偏差类型 | 表现 | 控制手段 |
|---|---|---|
| 位置偏差 | 答案在文档开头/结尾被过度召回 | 答案位置随机化 |
| 流行度偏差 | 高频实体被过度采样 | 按实体频率逆加权采样 |
| 标注者偏差 | 标注者个人知识影响判断 | 盲测+背景多样性 |
| 模板偏差 | query句式过于统一 | 基于LLM的paraphrase扩增+人工校验 |
场景切入
假设你在做一个电商客服Agent，用户问“帮我查一下订单”，然后又说“退款怎么走”。你怎么设计评估数据集，才能既测工具调用又测检索质量，而且保证数据是从真实对话里来的，不是凭空捏的？
层层追问
你觉得评估一个Agent或RAG系统，数据构建最关键的是什么？……那标注质量怎么保证？……再细一点，多样性怎么覆盖？……还有偏差控制，具体怎么做？
直球架构
构建一个高质量、可复现的Agent或RAG评估数据集，请从头讲清楚步骤：任务设计、标注策略、多样性保障和偏差控制，每个环节要可落地。
这道题问的其实是，你怎么用一个评估数据集来模拟真实用户反馈，让[[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]]让模型自己反思评估结果，但会带来额外延迟和成本。