这道题其实是在问,怎么造一套靠谱的数据来评估[[RAG]]系统好不好用,而不是随便找几个问题测测就完事。我一般会从三个层面来构建评估集:开发集、测试集和对抗集。开发集大概500到1000条,用来迭代调优,比如调 chunk 大小或者 rerank 阈值;测试集1000到3000条,做最终对比评测;对抗集200到500条,专门挑高难度、容易翻车的场景,比如需要多跳推理或者要回答“不存在”。三层分开,避免调参时过拟合到测试数据上。
先说问题怎么来。我倾向于混合策略,大概70%用 LLM 生成,20%从真实用户日志里挖,10%人工设计对抗样本。LLM生成效率高,但容易有[[幻觉]],所以我会给一个严格的 prompt 模板,要求它基于给定文档出题,禁止脑补。真实日志最贴近业务,但噪声多,需要人工清洗。举个例子,在客服退款场景里,用户常问“为什么我的退款还没到账”,这种真实 query 直接拿来用就很有价值。人工设计则专门造一些刁钻的,比如“满减和折扣券能叠加吗”,这种跨规则的问题。
答案标注是重头戏。第一步,我会用多个不同RAG系统并行生成候选答案,保留多样性。第二步,三轮人工校验:三个标注员独立标,有分歧的由专家仲裁,最后强制溯源,答案必须在文档里能找到依据。第三步打置信度:三人一致且能溯源才算高置信,直接入测试集;两人一致或需要推理的算中置信,可以入但标记风险;低置信的存疑,先不入。这里有个坑:标注员容易受自己认知影响,比如觉得某答案合理但文档里没有,所以 溯源检查一定要严格执行,否则评测结果会虚高。
真实性验证我主要做三件事。一是自动溯源,强制模型输出引用片段,用字符串匹配加语义相似度双重验证。二是一致性校验,同一个问题换几种说法反复问,看答案是否稳定。三是负样本注入,混入文档里没有答案的问题,测试系统能不能正确拒答。专家抽检是兜底,对抗集100%人工复核,测试集抽10%。
多样性这块,我会从文档和问题两个维度设计。文档上,既有结构化表格也有非结构化文本,长度从短片段到长文档都有。问题上,答案位置覆盖头部、中部、尾部甚至跨文档;复杂度分单跳、多跳、数值计算、时序推理;挑战性上,显性答案和需要隐性推断的比例要平衡。关键比例我控制为可回答比不可回答8比2,单跳比多跳比挑战大概是6比3比1。
其实这里有个延伸点:对抗集的难度怎么量化,我目前是用错误类型来分类,比如缺失证据、矛盾证据、无关证据,但不同错误对系统的影响权重不一样,怎么自动分配权重是个开放问题。
所以整体上,我更倾向把评估数据集当成一个活的资产,而不是一次性造完就扔。上线我会特别关注真实用户日志的反馈,定期用新日志更新对抗集,因为业务规则会变,比如满减政策调整后,旧问题可能就失效了。