RAG 检索越多越好吗？把“正确拒答”纳入评测

RAG 检索越多越好吗把“正确拒答”纳入评测RAG 升级时我们习惯增加片段、增加重排、增加查询改写再让模型多检索几轮。但如果评测只包含“有答案”的问题就看不到另一种退化系统越来越不愿意承认自己不知道。本文根据采集文章整理拒答评测方法并核对其引用的 DeclineCraft 论文。以下研究数字是论文结果的转述本次没有复跑模型实验后半部分的评测模板是新增工程整理。1. 论文观察到了什么DeclineCraft 以 Minecraft Wiki 的时间截断语料构造评测包含 700 道可回答题、300 道不可回答题对 27 个模型形成的 40 种模型/思考设置进行比较。单次检索的平均正确拒答率为 56.4%允许继续检索的设置为 46.4%可回答题准确率则从 68.5% 变为 69.3%。这些结果只代表论文设定下的比较。DeclineCraft 论文正文这里需要保留研究边界多轮策略同时改变了上下文、后续查询等因素不能从汇总结果断言“重排本身必然导致幻觉”或“任何多轮检索都应删除”。一个领域和一套流程的发现更适合作为评测提醒。2. 为什么“没找到”不同于“不存在”用户问一个新版本功能旧索引里没有介绍。系统可以说“当前资料不足以确认这个功能。”也可能说“这个功能不存在。”后者是对世界事实的否定需要额外证据。旧资料没有提到它并不能证明它不存在。论文将承认知识不足与否定问题前提区分开避免把看似谨慎、实际缺乏依据的否定也算成成功拒答。对产品文档、发布说明和内部知识库这种差别很实用。索引的新鲜度应成为诊断信息但不能自动变成模型对新功能的否定依据。3. 先定义评测协议再标注题目这里最容易混淆两种任务只允许根据检索文档回答还是允许模型使用参数知识与文档联合回答。DeclineCraft 讨论后者企业内部知识助手常采用前者。本文的工程模板默认“只依据授权语料”。这属于协议选择并不是原论文的原样复现。判断不可回答之前应明确语料版本和时间点并人工核对权威来源避免把检索失败误标成知识不存在。4. 至少分开看这些指标指标分母与判定可回答题准确率可回答问题中答案正确的比例可回答题尝试率可回答问题中系统实际作答的比例正确拒答率 CAR不可回答问题中明确承认缺少足够知识的比例无依据的前提否定率不可回答问题中无支持地宣称对象或事实不存在的比例成本与延迟相同协议下每题消耗及响应时间不能只看 CAR一个总说“不知道”的系统可能在不可回答问题上表现漂亮却放弃了可回答任务。准确率、尝试率和拒答应一起比较。标签也需要区分模型判断失败与接口超时。服务错误不是诚实拒答应单独报告避免通过排除错误请求美化结果。5. 一个便于复用的分桶方式answerable 正确作答 - 正确答案 answerable 拒答 - 误拒 unanswerable 承认知识不足 - 正确拒答 unanswerable 无依据否定 - 前提否定 unanswerable 编造答案 - 不受支持的作答 任意题目 接口失败 - 运行错误单独统计以上是新增的评测分类不是论文官方代码。问题中涉及虚构对象或错误前提时是否允许明确否定也需要按任务证据定义不能把所有否定一概判错。6. 每次只验证一个升级固定题目、语料版本、生成模型和判定规则分别比较更多片段、重排、查询改写和额外检索轮次。报告每种变化对可回答准确率、拒答、成本与延迟的影响并复核代表性退化样本。小样本可以暴露明显失败模式却不足以支持很小幅度提升的强结论。正式发布前应根据业务影响确定样本量和置信区间涉及用户或任务分组时还要考虑同组样本的相关性。7. 缺少证据时停止也可以是合理结果多轮检索应有明确继续条件例如新查询能补足哪个缺口新增证据与已有证据有什么不同。若连续返回同样的片段继续循环可能只增加成本。最终回答应说清已确认的内容和仍缺的依据。把“当前资料无法确认”保留为一种正式结果评测才能衡量系统是否在该停下时停下。