RAG 资料里没答案时，企业知识库应该怎么避免硬答？直接答案是：不要只设一个相似度阈值，而要把“能不能回答”拆成四道闸：先限定搜索范围，再筛相关性，再判断证据是否足够，最后对生成结果逐句核验。任何一道闸没过，都不能把“看起来相近”的内容包装成确定答案。
很多企业第一次做知识库问答，最容易掉进一个坑：向量库永远会返回 Top-K，模型永远擅长把相近片段组织成一段顺滑的话。于是用户问“海外出差票据丢失怎么补办”，知识库只有国内报销制度，系统却能编出一套像模像样的海外流程。文字很专业，风险也很专业。
为什么“搜到了”不等于“有答案”？
向量检索解决的是“哪几段最像”，不是“这些证据能不能推出结论”。当索引非空时，系统总能排出第一名、第二名和第三名；但第一名只代表相对更近，不代表足以回答。
企业场景里真正要区分三种状态：第一，证据完整存在，问题里的对象、条件、时间和结论都能在文档里找到；第二，证据只覆盖一部分，比如有国内流程但没有海外流程；第三，只有主题相似，无法推出答案。第二种最危险，因为模型会替企业补上缺失规则。
第一道闸：先锁定搜索范围，不让越权内容混进来
RAG 的无答案控制首先不是模型问题，而是权限和范围问题。检索前要确定用户是谁、能查哪个知识库、哪些文档版本有效、哪些资料已经过期。范围错了，后面的高相似度没有意义。
例如用户只有公开制度权限，检索却把内部草稿带回来。即使草稿里有答案，系统也不能使用它。企业知识库要把权限过滤放在检索前，而不是在生成后让模型“自觉不要说”。
第二道闸：相关性只能粗筛，不能一票放行
相似度阈值仍然有用，但它只能筛掉明显不相关的内容。Embedding 模型、距离函数、Chunk 切分、文档长度都会影响分数，所以不要从网上抄一个 0.78 或 0.82 就当生产规则。
正确做法是准备两组样本：一组是知识库确实有答案的问题，一组是知识库没有答案或只有部分证据的问题。每次调阈值时，同时观察“有答案却被拒绝”和“没答案却被放行”两类错误。企业更怕哪一类错误，要由业务风险决定，而不是由模型分数决定。
第三道闸：判断证据充分性，而不是只看片段相似
证据充分性要回答一个更硬的问题：当前候选片段是否覆盖了回答所需的关键条件。流程题要有完整步骤，比较题要有两边资料，带时间或地区的问题必须找到对应限定条件，多跳问题可能需要多段原文共同成立。
建议把 Query 先解析成“待验证要点”，再逐项绑定证据。解析模型只负责列检查清单，不负责补答案。某个要点没有原文支持时，它应留在缺失列表里，而不是由大模型常识填上。
{
"decision": "answer | limited_answer | clarify | refuse",
"evidence": ["policy_v3#chunk_18", "travel_expense_faq#chunk_04"],
"missing_conditions": ["海外票据补办规则", "当前有效版本"],
"reason": "retrieved passages are related, but do not cover the overseas scenario",
"next_action": "ask_clarifying_question"
}第四道闸：生成后核验，拦住“证据外的漂亮话”
即使检索和充分性判断都通过，生成阶段仍可能加入原文没有的数字、期限、例外条件或强断言。企业版 RAG 不能只让模型在答案后面加引用编号，而要检查每个事实句是否能回到本轮证据。
找不到支持的句子，要么删除，要么改成有限回答，要么触发澄清或拒答。引用文件名是真的，不代表结论是真的；证据链才是企业知识库的安全底线。
证据不够时，系统该怎么降级？
- 受控重试：允许改写 Query、扩大候选或补一次关键词检索，但必须有次数上限，不能不断放宽门槛。
- 请求澄清：当问题缺少地区、产品、版本或对象时，直接问用户补条件，比猜一个答案更可靠。
- 有限回答：只回答文档能证明的部分，并明确写出未覆盖条件。
- 拒答：关键证据缺失、资料越权或版本冲突时，明确说明当前知识库没有足够依据。
一个可落地的工程实现框架
在工程上，最稳的方式是把“能不能回答”放在 RAG pipeline 的守卫层，而不是全塞进 prompt。下面这个伪代码展示了最小闭环：先查范围，再看相关性，再判充分性，最后做生成后核验。
def should_answer(query, evidence, policy):
scope_ok = check_scope(query.user, evidence.documents)
relevance_ok = max(e.score for e in evidence) >= policy.min_relevance
sufficiency = judge_required_facts(query, evidence)
grounded = verify_generated_facts(evidence)
if not scope_ok:
return "refuse", "outside_allowed_scope"
if not relevance_ok:
return "refuse", "low_relevance"
if not sufficiency.ok:
return "limited_answer", sufficiency.missing_conditions
if not grounded.ok:
return "revise_or_refuse", grounded.unsupported_claims
return "answer", "grounded"
上线前检查清单
- 是否把用户权限、知识库范围、文档版本放在检索前过滤？
- 是否同时保留可回答和不可回答样本，用来校准阈值？
- 是否区分“低相关”“部分相关但证据不足”“证据冲突”“版本过期”？
- 是否记录每次回答采用了哪些证据、缺少哪些条件、为什么放行或拒答？
- 是否逐句检查生成结果，删除没有证据支撑的数字、期限和强断言？
- 是否为证据不足设计了重试、澄清、有限回答和拒答四种动作？
常见问题
只用最高相似度能判断无答案吗？
不能。最高分只说明它比其他候选更像，不说明它覆盖问题所需的实体、时间、范围、版本和必要证据。最高分可以做粗筛，不能做最终裁判。
Prompt 写“资料不足就拒答”够不够？
不够。Prompt 不知道检索范围是否正确，也可能把相关但不充分的片段当作完整证据。它是最后约束之一，不是范围过滤、充分性判断和生成后核验的替代品。
误拒绝太多，直接降低阈值可以吗？
先定位原因。可能是 Query 改写丢了否定词，可能是正确文档不在搜索范围，可能是 Chunk 切分把证据拆散，也可能是模型不理解领域术语。直接降低全局阈值，常常会把另一批无答案问题放行。
DELine 怎么帮企业把这套机制落地？
DELine 面向企业知识库、AI Agents 和 RAG 应用提供落地诊断与实施服务：从权限与数据源梳理、Embedding 与检索评估、证据充分性规则设计，到生成后核验、审计日志和灰度上线。目标不是让系统“更会编”，而是让它在没有证据时敢停、会说边界，并留下可回放的决策记录。
企业准备上线内部知识库问答或 AI Agent 时，建议先做一轮 RAG 无答案控制评估。把 20-50 个真实高风险问题跑一遍，就能看出系统是在按证据回答，还是在用相似内容补空白。
