RAG 检索为空时如何阻止模型编造：证据门槛、引用绑定与拒答回退

RAG 知识库上线后，最让人不放心的场景不是检索接口报错，而是检索返回几段看似相关的文字，模型就开始用肯定语气补全没有证据的结论。尤其是内部制度、价格、权限和版本规则，答错一次往往比直接说“不知道”更麻烦。稳定的做法是把证据门槛放在生成前，把引用绑定放在生成后，证据不够就明确回退。

先复现一次“知识库没答案，模型却答得很像真的”

假设用户问：“试用期员工能不能申请本季度的远程办公补贴？”检索器返回了两段旧制度：一段讲正式员工，另一段讲去年已经失效的补贴规则。若只把 top-k 文本拼进提示词，模型很可能把“正式员工”和“试用期”混在一起，再给出一个完整但未经支持的结论。

排查日志时先看三个值：hit_count、最高相似度 top_score、来源的 effective_to。如果命中数为 0，或者最高分低于业务阈值，生成环节根本不应该启动。命中数大于 0 也不能直接放行，过期文档和只覆盖半个问题的片段同样属于无效证据。

把“相关”拆成三道可检查的门

一个实用的证据门可以先从三项开始，不必一上来就做复杂的评估模型。

阈值不能照抄别人的数字。不同 embedding 模型、切片长度和业务语料会改变分数分布。可以从一批人工标注的问题开始，分别观察“有答案”和“无答案”的分数区间，再选一个宁可多回退、不要放过明显无证据问题的初始值。

type Evidence struct {
    Text       string
    Score      float64
    SourceID   string
    EffectiveTo time.Time
    Covers     []string
}

func passEvidence(question string, hits []Evidence, now time.Time) bool {
    if len(hits) == 0 || hits[0].Score 

这里的 coversQuestion 不一定要做成另一个大模型判断器，第一版可以用文档元数据里的产品名、地区、角色、时间范围等字段做硬过滤。先把明显不适用的片段排掉，通常比继续堆更多候选文本更有效。

生成前先决定：回答、追问，还是拒答

证据门通过后才调用模型，并且把“只能依据证据回答”写成清楚的输入约束。门没通过时，服务端直接返回结构化结果，前端再决定显示提示、请求用户补充条件，还是转人工。

{
  "status": "needs_more_context",
  "answer": "当前知识库没有覆盖“试用期员工”这一条件，无法确认补贴资格。",
  "citations": [],
  "next_question": "你想查询的是哪一地区、哪一版制度？"
}

拒答不是把所有不确定问题都挡掉。可把结果分成三类：证据充分时正常回答；证据部分覆盖时先追问缺失条件；完全没有依据时给出可解释的拒答。这样用户看到的是下一步，而不是一句冷冰冰的“无法回答”。

答案句和引用要一一对得上

提示词里写“请附引用”只能改变模型的表达，不能证明引用真的支持结论。更稳的返回结构是让模型为每个事实句带上 source_id，服务端检查这个 ID 是否来自本次检索结果，并确认引用片段确实包含相关实体或条件。

{
  "claims": [
    {
      "text": "正式员工可以申请该补贴。",
      "source_ids": ["policy-2026-03"]
    }
  ],
  "answer": "该制度只明确覆盖正式员工，试用期员工是否适用需要向人事确认。",
  "status": "partially_supported"
}

如果模型返回了不在白名单里的 source_id，或者关键句的引用为空，就把结果降级为待核对。不要为了让页面看起来完整而自动补一个“最相近”的来源，这会制造比无引用更难发现的错觉。

冲突证据要显式处理，不能让模型自行投票

同一问题命中两版制度时，最高分片段未必是最新版本。建议在入库时给文档补充版本号、生效时间、适用部门和地域；检索阶段先按这些字段过滤，再按语义分数排序。

• 同一 source_key 有多个版本：优先选择生效中的版本。
• 两份有效制度互相矛盾：回答“存在冲突”，并列出来源交给人工确认。
• 来源已过期但没有替代版本：拒答并提示查找最新制度入口。
• 用户问题缺少地区或角色：先追问，不用默认值猜测。

这一步看起来不如调 prompt 有趣，但它处理的是业务事实的生命周期。RAG 的“知识”不是永久不变的文本，版本和适用范围没有进入检索条件，生成模型只能替你掩盖数据管理问题。

用四组指标判断回退策略有没有帮上忙

上线后建议按周抽样看四个指标：有证据回答率、无证据拒答率、引用覆盖率、人工纠正率。最重要的不是拒答越少越好，而是“没有证据却给出肯定回答”的比例持续下降。

1. 构造一批知识库明确没有答案的问题，确认系统会拒答或追问。
2. 为同一制度准备新旧版本，确认过期版本不会压过当前版本。
3. 随机删除一个引用片段，确认引用校验能把答案标成待核对。
4. 让两个来源给出冲突条件，确认页面展示冲突，而不是合成一个新结论。

相关问题

相似度阈值设得越高越安全吗？

不一定。阈值过高会把本来有答案的问题全部挡掉，关键是用真实标注集观察误放行和误拒答的代价，再按业务风险分层设置。

只返回检索原文是不是就不会编造？

能减少生成环节的风险，但用户仍需要可读答案。更稳的是原文、结论和引用一起返回，并让服务端校验结论与来源关系。

什么时候应该转人工？

涉及权限、金额、合规、医疗或两份有效制度冲突时，建议提供人工入口。模型可以整理已找到的证据，但不应替代最终裁定。

结构化输出能解决 RAG 幻觉吗？

它主要约束字段和格式，不能证明字段内容有证据。即使 JSON 完全合法，也要独立检查引用、时效和问题覆盖。

把“回答得像真的”改成“证据足够才回答”

RAG 的可靠性不只取决于召回模型，也取决于什么时候允许生成、答案如何绑定来源、证据冲突时谁来做决定。先建立命中数、分数、有效期和覆盖范围这几道门，再把拒答和人工回退做成正常产品路径，知识库才不会把不确定性包装成确定答案。