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 评测需要正样本，也需要负样本。无答案、越权、模糊、冲突和过期问题能检验系统是否会拒答。只测能回答的问题，会把一个爱编答案的系统误判成高能力系统。