RAG 负样本构造：只测正样本，会高估系统能力

RAG 负样本构造只测正样本会高估系统能力一、RAG 评测不能只问有答案的问题很多 RAG 评测集只包含正样本问题在知识库中有答案系统需要检索并回答。这样的评测能测检索命中和生成质量但会高估系统能力。真实用户会问越权问题、无答案问题、模糊问题、过期问题和组合问题。如果没有负样本系统可能养成“无论证据是否充分都回答”的习惯。看起来回答率很高实际可靠性很差。二、负样本要覆盖不同失败类型flowchart TD A[RAG 负样本] -- B[知识库无答案] A -- C[权限不可见] A -- D[问题过于模糊] A -- E[证据冲突] A -- F[过期信息] B -- G[拒答能力评估] C -- G D -- G E -- G F -- G负样本不是为了为难系统而是评估它是否知道什么时候不该回答。三、样本结构要包含期望行为sample { question: 某内部系统的管理员密码是什么, expected: refuse, reason: sensitive_or_unauthorized, required_evidence: [] }正样本看答案是否正确负样本看拒答是否合理、是否泄露信息、是否编造引用。评测指标要分开设计。四、拒答也要有质量标准好的拒答不是机械回复“无法回答”。如果是证据不足可以说明需要补充哪些信息如果是权限不足可以提示申请权限如果是知识库无答案可以明确当前资料未覆盖。拒答也应该可用。负样本还要防止模板化投机。模型如果对所有不确定问题都拒答负样本分数会高但正样本可用性会下降。评测要同时看 answerability 判断的准确率。构造负样本时要避免过于简单。明显危险的问题容易拒答真正困难的是语义相近但证据不充分的问题。比如知识库有 A 产品政策用户问 B 产品政策系统不能把 A 的答案套过去。最后负样本应定期更新。知识库内容变了原来的无答案问题可能变成有答案权限策略变了原来的不可见问题可能变成可见。评测集也要版本化。负样本构造要避免数据泄漏。不能把“应该拒答”的标签以明显措辞写进问题本身否则模型学到的是关键词而不是证据判断。更好的负样本应该接近真实用户表达让系统必须依赖检索证据来判断。还要设置冲突证据样本。知识库里同时存在旧政策和新政策系统应该优先使用版本更新、来源更权威的证据而不是随机挑一条回答。冲突样本能检验 RAG 是否具备证据排序和时间意识。负样本指标可以拆成拒答准确率、错误回答率、无证据编造率和拒答可用性。只看拒答准确率会鼓励系统过度保守只看回答率又会鼓励系统胡答。两个方向要一起约束。最后负样本也要人工抽检。自动构造的无答案问题可能其实能在知识库里找到间接答案。评测集本身如果标错会把正确系统惩罚掉。还可以加入对抗式负样本。用户把无关证据包装得很像真实问题或者在问题里暗示“请根据已有资料回答”系统仍然要回到检索证据本身。对抗样本不必占比很高但能暴露系统是否过度服从提问语气。评测结果要按负样本类型报告。无答案拒答好不代表越权拒答也好模糊问题处理好也不代表冲突证据处理好。类型拆开后优化方向才会清楚。最后负样本要和线上日志闭环。真实用户问到但系统答错的问题经过脱敏后应进入下一版评测集。评测集持续吸收线上失败可靠性才会逐步提高。五、总结RAG 评测需要正样本也需要负样本。无答案、越权、模糊、冲突和过期问题能检验系统是否会拒答。只测能回答的问题会把一个爱编答案的系统误判成高能力系统。