评估集防泄漏与复现

这道题问的其实是，你怎么用一个评估数据集来模拟真实用户反馈，让[[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噪声大或意图不明确，那评估数据集再完美也没用。常见失败场景是，数据集构建特别漂亮，但上线后效果差，因为真实用户分布变了。所以上线我会特别关注数据漂移，定期用新日志更新评估集。

所以整体上，我更倾向把评估数据集看成一个持续迭代的活系统，而不是一次性交付。数据版本化、采样策略公开、基线模型运行脚本都要配套。