rag-">大模型RAG系统中“提问超出知识库范围”的系统化治理

在RAG系统的实际落地中，最令人头疼的往往不是“答得不好”，而是“不知道还说得很像”。模型在知识库里明明没有召回到相关内容，却依然输出了一个结构完整、语气笃定、细节丰富的答案。若不是业务方恰好熟悉该领域，几乎无法分辨真伪。这类现象在学术上属于“幻觉”（hallucination）的一个子类，在RAG语境下更准确的叫法是检索失败导致的幻觉：检索环节没有拿到支撑材料，生成环节却没有表达“未知”，而是转而依赖参数化记忆或纯粹的语言先验拼凑出一个看似合理的回答。

这个问题不解决，RAG在严肃场景中基本不可用。法律咨询、医疗问答、企业内部知识助手——这些场景对“错误答案”的容忍度极低，一次自信的错误回答所造成的损害，可能远超“系统暂时无法回答”带来的体验损失。因此，工程上必须把“不知道就说不知道”从一个提示词技巧，升级为贯穿整条链路的系统性能力。

一、问题定位：根源不在生成端

许多团队遇到该问题的第一反应是调提示词，加一句“如果检索内容不足以回答，请明确说明无法回答”。这种做法有效果，但非常有限。原因在于，生成端只是整条链路的最后一环，它拿到的是上游喂给它的上下文。如果检索环节召回了一堆语义相近但实质无关的片段，生成端看到的“证据”是存在的，它并没有理由拒答；如果检索为空，部分模型也会倾向于用自身知识补全，而不是主动暴露空白。

把RAG链路拆开看，问题可能在每一个环节发生：

用户提问
  ↓ ① Query处理（改写、意图识别、范围判定）
  ↓ ② 检索（向量召回、关键词召回、混合召回）
  ↓ ③ 相关性判定（召回内容是否真正支撑回答）
  ↓ ④ 生成（基于上下文的受控作答）
  ↓ ⑤ 输出校验（答案是否有依据、是否越界）

多数团队只在第④步做了干预，前面几步处于“裸奔”状态。这就像工厂只在出厂时做质检，原料、加工、组装环节全不设卡，出厂质检的压力自然巨大且容易漏检。更合理的思路是在多环节设置拦截点，把“是否在知识库范围内”的判定分散到上游，而不是全部压给生成端。

二、第一道防线：意图识别与服务边界判定

在检索之前，先判断用户的问题是否落在系统承诺的服务范围内。这一步常被跳过，但投入产出比很高：在最上游拦掉明显越界的问题，后续所有环节的压力都会下降。

方案一：基于规则的边界判定。 最简单直接的做法是用关键词、正则、白名单主题分类等规则做粗筛。例如企业内部知识助手可以限定只处理与产品文档、流程规范相关的问题，对闲聊、时事、竞品对比等直接拒答。规则维护成本低、可解释性强，适合边界清晰、领域收敛的场景。缺点是对表达变体敏感，用户换一种说法就可能绕过，因此规则更适合作为快速兜底而非唯一手段。

方案二：基于分类模型的意图判定。 训练或微调一个轻量分类器，把用户问题映射到“域内/域外”二分类，或更细的多标签领域分类。相比规则，分类模型对改写、同义表达更鲁棒。工程上可以用小参数模型做在线推理，延迟可控。需要注意分类器的训练数据要覆盖真实分布，否则会出现“域内问题被误杀”的问题，因此要设置灰度与人工复核机制。

方案三：基于语义相似度的范围探测。 维护一组“域内代表性问句”或领域主题向量，计算用户问题与这些向量的相似度，低于阈值则判定为疑似越界。这种方法不需要额外训练，冷启动快，但对代表性问句的覆盖度依赖较高，适合作为辅助信号与其他方法融合。

实践中的建议是规则 + 模型 + 阈值融合：规则负责高置信度的硬边界，模型负责语义泛化，相似度作为补充信号。三者任一判定越界即可触发拒答或转人工，同时记录判定来源便于后续分析误杀率。

三、第二道防线：检索质量与相关性判定

即便问题在域内，检索也可能失败——知识库确实没有对应内容，或召回质量不足以支撑回答。因此需要在检索之后、生成之前加入判定环节。

检索结果的绝对质量信号。 包括召回数量、Top-K相似度分数分布、分数间隔（第一名与第二名的差距）等。如果最高相似度低于经验阈值，或召回结果分数整体偏低且分散，说明知识库很可能没有相关内容。这些信号实现成本低，可作为第一层过滤。

相关性判定的精细化。 相似度高不等于相关。向量召回容易受表面语义相近影响，召回的片段可能只是“提到同一个词”而非“回答了这个问题”。工程上可以引入交叉编码器做重排序，并对Top-N结果做二分类判定“是否支撑该问题”。更实用的做法是让一个判定模型回答一个明确的问题：给定问题和候选片段，该片段是否包含回答所需的关键信息？输出为是/否/部分支撑。只有判定为“是”或“部分支撑”的片段才进入生成上下文，否则视为检索失败。

上下文充分性判定。 在拼接上下文之前，再对整体做一次判断：现有材料是否足以回答该问题？这一步可以用轻量模型完成，输出“充分/不充分”。不充分时直接进入拒答或澄清流程，不把问题交给生成端去“自由发挥”。这一环节是抑制检索失败型幻觉的关键闸门。

四、第三道防线：生成端的受控作答

生成端并非无能为力，但它的角色应从“自由作答”转为“受控作答”。

明确的上下文约束。 在提示中要求模型仅依据给定材料作答，并显式给出“材料不足时的处理方式”：输出统一的结构化拒答标记，而不是自然语言自由发挥。使用结构化输出（如固定字段的JSON）可以让下游程序稳定识别拒答意图，避免模型用模糊措辞掩盖不确定性。

引用与依据绑定。 要求模型在输出答案时附带所依据的片段编号或原文摘录。若模型无法给出引用，则答案视为无依据。这一约束不仅能抑制编造，还便于输出校验环节做自动化核查。

不确定性的显式表达。 允许模型输出“部分回答”并标注哪些部分缺乏依据，而不是非黑即白地全答或全拒。这需要在提示设计与后处理上配合，确保前端能正确呈现置信度信息。

五、第四道防线：输出校验与兜底

生成之后仍需校验，重点是“答案是否有依据”和“是否越界”。

依据核查。 将生成答案中的关键断言与上下文片段做比对，可用句子级相似度或轻量蕴含判定模型，检查答案是否被材料支撑。对于无法找到支撑的断言，标记为高风险并触发降级策略。

越界检测。 检查答案是否引入了知识库之外的实体、数据或结论。对于严肃场景，可设置实体白名单或数值来源校验，凡无法溯源的内容一律拦截。

降级与兜底策略。 校验不通过时不应直接把原答案返回给用户。可选的策略包括：返回统一的“暂无可靠依据”提示、转人工、提供相关文档链接让用户自行判断，或返回检索到的原始片段并说明“未找到直接答案，以下材料可能相关”。兜底策略要按业务风险分级配置，而不是一刀切。

六、工程落地要点

链路埋点与可观测性。 在每个拦截点记录判定结果、阈值、耗时与最终走向，形成完整的决策链路日志。没有埋点就无法评估各环节的拦截率和误杀率，也无法定位漏检发生在哪一步。建议为每次请求生成一个追踪ID，串联Query处理、检索、判定、生成、校验各阶段。

阈值校准与持续迭代。 相似度阈值、判定模型置信度阈值都需要用真实流量校准，而不是拍脑袋设定。可以通过人工标注一批“域内可答/域内不可答/域外”样本，评估各阈值下的召回与误杀，找到业务可接受的平衡点。上线后定期抽样复核，防止数据分布漂移导致阈值失效。

分层防御而非单点依赖。 任何单一环节都有漏检可能：意图分类会误判，检索相似度会失真，生成端会绕过约束，校验模型也有盲区。多环节叠加的意义在于降低“所有环节同时失效”的概率，而不是追求某一环节的绝对准确。

拒答体验的设计。 拒答不是系统失败的象征，而是可信度的体现。前端文案应清晰说明“当前知识库未覆盖该问题”，并给出可行的下一步（换个问法、联系人工、查看相关文档），避免用户把拒答理解为系统故障。

结语

“用户提问不在知识库范围内”不是一个靠一句提示词就能解决的问题，它本质上是RAG链路中多个环节共同作用的结果。把判定与拦截分散到意图识别、检索质量评估、相关性判定、受控生成与输出校验各个节点，形成分层防御体系，才能在严肃业务场景中把检索失败型幻觉压到可接受的水平。工程上的关键不在于某个环节做得多精妙，而在于整条链路的判定信号是否可观测、阈值是否可校准、兜底策略是否与业务风险匹配。把这些基础工作做扎实，RAG系统才真正具备“知道自己不知道”的能力。