企业官网建设流程全解析

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：一个总说“不知道”的系统可能在不可回答问题上表现漂亮，却放弃了可回答任务。准确率、尝试率和拒答应一起比较。

标签也需要区分模型判断失败与接口超时。服务错误不是诚实拒答，应单独报告，避免通过排除错误请求美化结果。

5. 一个便于复用的分桶方式

answerable + 正确作答 -> 正确答案 answerable + 拒答 -> 误拒 unanswerable + 承认知识不足 -> 正确拒答 unanswerable + 无依据否定 -> 前提否定 unanswerable + 编造答案 -> 不受支持的作答 任意题目 + 接口失败 -> 运行错误，单独统计

以上是新增的评测分类，不是论文官方代码。问题中涉及虚构对象或错误前提时，是否允许明确否定，也需要按任务证据定义，不能把所有否定一概判错。

6. 每次只验证一个升级

固定题目、语料版本、生成模型和判定规则，分别比较更多片段、重排、查询改写和额外检索轮次。报告每种变化对可回答准确率、拒答、成本与延迟的影响，并复核代表性退化样本。

小样本可以暴露明显失败模式，却不足以支持很小幅度提升的强结论。正式发布前，应根据业务影响确定样本量和置信区间；涉及用户或任务分组时，还要考虑同组样本的相关性。

7. 缺少证据时，停止也可以是合理结果

多轮检索应有明确继续条件，例如新查询能补足哪个缺口，新增证据与已有证据有什么不同。若连续返回同样的片段，继续循环可能只增加成本。

最终回答应说清已确认的内容和仍缺的依据。把“当前资料无法确认”保留为一种正式结果，评测才能衡量系统是否在该停下时停下。