完整题目
为了有效评估Agent或RAG系统的性能，应如何设计和构建高质量的评估数据集？请描述数据采集、标注流程、负样本构造以及确保数据代表性的方法。
本文目录
答案要点
- 区分Agent与RAG评估维度的差异
- 数据采集的多样性与真实性来源
- 负样本构造的hard negative策略
- 人工+自动化的混合标注流程
- 数据代表性验证方法
核心设计原则
Agent和RAG的评估目标不同：RAG重事实准确性，Agent重任务完成度与工具调用正确性，需分开设计。
数据采集
| 来源 | 适用场景 | 注意事项 |
|---|---|---|
| 真实用户日志 | 高价值、分布真实 | 脱敏+去偏，避免头部query过度采样 |
| 合成数据（LLM生成） | 快速覆盖长尾场景 | 需人工校验，控制幻觉比例 |
| 公开benchmark适配 | 跨模型可比 | 检查license，避免数据污染 |
关键：覆盖多轮对话、边界case（如无答案、需澄清）、跨领域query。
标注流程
RAG标注：
- 检索相关性：人工标注doc与query的相关性等级（0-3分）
- 答案准确性：对比标准答案，标注幻觉、遗漏、矛盾
Agent标注：
- 轨迹标注：记录正确工具调用序列作为gold path
- 状态检查：关键步骤的中间状态是否正确
效率优化：先用规则/模型预标注，人工抽检+修正，迭代提升质量。
负样本构造（Hard Negative）
- RAG：用BM25召回top-5中不相关的doc；语义相似但答案矛盾的doc对
- Agent：工具参数错误但语法正确；工具顺序错误但最终碰巧成功
原则：负样本要"看起来合理"，才能有效区分模型能力。
代表性验证
- 分布对齐：统计query长度、领域分布、复杂度（需推理步数）与线上对齐
- 分层抽样：按业务场景分层，确保每层有足够样本
- 动态更新：定期用线上bad case补充，避免评估数据老化
换一种问法，检查是否真正理解
场景切入
假设你要给电商客服系统做一个RAG评估，用户问“这个订单什么时候发货”，你准备怎么收集测试数据？特别是那些刁钻的、模型容易答错的问题，比如明明没发货却答成已发货，怎么刻意构造出来？
层层追问
你一般怎么评估RAG或者Agent的效果？……那评估数据从哪来？……如果真实日志里大部分是简单问题，长尾场景很少，你怎么补？……负样本呢，怎么造才能真的测出模型短板？
直球架构
设计一套RAG或Agent的评估数据集构建方案，要求覆盖数据采集、标注流程、负样本构造以及数据代表性验证。你会怎么设计？重点讲清楚负样本的hard negative策略和标注中如何保证质量。
练习口述回答 · 约4分钟
- 一句话定位：评估数据集本质是设计一场对系统的压力测试
- 区分RAG和Agent评估目标，数据采集要多样
- 标注流程：人工+自动混合，负样本构造用hard negative
- 代表性验证：分布对齐、分层抽样、动态更新
- 收尾：可延伸点——负样本难度如何控制
这道题其实是在问，你怎么设计一套评估数据集，能真正衡量一个[[Agent]]或[[RAG]]系统的能力边界。说白了，就是你怎么给它出一份有区分度的考卷，而不是随便找几个问题测一下就完事了。
首先得明确，RAG和Agent的评估目标完全不同。RAG重的是事实准确性，你得看它有没有[[幻觉]]、有没有漏掉关键信息；Agent重的是任务完成度和工具调用正确性，比如它有没有按正确顺序调API、参数传没传对。所以评估数据集必须分开设计，不能混在一起。
数据采集这块，我会优先用真实用户日志，因为它的分布最贴近线上。但有个坑，日志里头部query往往被过度采样，长尾场景覆盖不够。所以我会用合成数据来补，让LLM生成一些边界case，比如用户问一个没有答案的问题，或者需要澄清才能继续的场景。合成数据一定要人工校验，不然模型自己生成的幻觉会污染评估集。公开benchmark也可以拿来做跨模型对比，但要检查license，还得确保模型没在训练时见过这些数据，不然就是数据污染。
标注流程我倾向混合模式。对RAG，先让模型或规则做预标注，比如用[[BM25]]召回top-5文档，然后人工判断相关性等级和答案正确性。对Agent，我会记录正确工具调用序列作为gold path，再人工检查关键步骤的中间状态。这样效率和质量都能兼顾。预标注不是偷懒，而是让标注员聚焦在难例上，提升标注质量。
负样本构造是关键，这里有个原则：负样本要看起来合理，才能有效区分模型能力。对RAG，我会用BM25召回top-5中不相关的文档，或者找语义相似但答案矛盾的文档对。对Agent，我会构造工具参数错误但语法正确的样本，或者工具顺序错误但最终碰巧成功的样本。这些hard negative能让模型真正学到细粒度差异，而不是靠表面特征蒙混过关。
最后是代表性验证。我会统计query长度、领域分布、复杂度这些指标，确保和线上对齐。然后按业务场景分层抽样，比如客服场景、订单查询场景，每层保证足够样本。而且评估集必须动态更新，定期用线上bad case补充，不然模型会过拟合到旧数据上，评估结果越来越虚。
其实还有个细节我一直在想，就是负样本的难度怎么控制。如果负样本太难，模型全错，区分度也差；太简单，模型全对，也没意义。所以这里有个平衡点，可能需要用[[Rerank]]模型的打分做阈值，或者用[[Self-RAG]]让模型自己反思，但具体怎么调还没完全想透。
所以我整体会把评估数据集看成一套持续演化的测试工程，而不是一次性造完就完事。我更倾向用少量高质量样本加上动态补充策略，而不是堆大量低质量数据。