如果你的知识库检索系统出现过两种状态查不到也硬答或者明明有相关文档却拒绝回答那问题大概率不在生成模型本身而在系统缺少一个回答边界判断模块。最近在折腾 RAG 检索链路时一个很典型的问题反复出现“My retrieval cant tell a question it can answer from one it cant”。翻译过来就是检索系统分不清哪些问题它能回答哪些问题它根本答不了。这不是一个概念问题而是一个工程问题。向量检索返回相关性不返回可答性。相关文档存在不等于答案存在相似度分数高也不等于推理链成立。如果检索器没有能力识别这种边界下游大模型要么开一个不可控的幻觉口子要么把所有问题都推向“我知道一点但不多”的错误答案。这篇文章不打算引入复杂框架就围绕可答性判断这一个能力拆解落地路径。我们会分析三种典型失败模式给出三种可执行方案再补一套带拒绝机制的 RAG 服务示例以及接口 API 和批量任务的响应设计。同时会借一个具体场景——数据库连接时常见的public key retrieval is not allowed错误——来对照说明当系统无法产生可操作的边界信息时用户会陷入什么样的困境。适合正在做知识库问答、RAG 评估或者准备把检索能力接进内部工具的工程师阅读。1. 核心能力速览先给一张速览表让你快速判断这个方案是否值得往下看能力项说明解决场景RAG / 知识库问答中系统无法判断问题是否可回答主要手段归一化相似度阈值、LLM 可答性分类、引用覆盖率校验、多查询验证输出结果结构化可答性标记、置信度、缺失信息说明、显式拒绝文案适用系统基于向量数据库的语义检索、基于大模型的 RAG 服务、企业知识库部署门槛不依赖特定框架可在现有检索服务上作为独立模块叠加是否需要 GPU嵌入模型和 LLM 按原有能力运行可答性分类阶段可选择纯 CPU 的小模型是否支持 API支持建议将可答性判断结果一并写入查询接口响应是否支持批量任务支持批量请求需要补充限流、日志和失败重试主要风险阈值校准不当会造成误拒或漏拒需要正负样本评估这张表里的每一项下面都会展开。重点先说清楚可答性判断不是替代检索也不是替代生成而是在检索和生成之间加一个“质量闸门”。2. 检索边界问题为什么很难被感知很多团队对检索系统抱有朴素的预期给一个问题找到 top-k 个相似片段喂给大模型就能得到答案。但实际跑起来后你会发现检索器返回的相似度分数只能说明“字面上有多接近”完全无法说明“这段文本是否真的包含问题的答案”。经常出现的情况是这样的用户问“这个功能怎么做权限配置”检索系统返回的片段是关于功能上线公告的词汇重叠明显、语义也相关但整篇片段里没有任何权限配置的操作步骤。这个状态下大模型被迫接着往下写于是它开始根据训练知识补全一个可能根本不存在的配置流程。这个补全过程就是幻觉。更隐蔽的问题是误拒。有些问题实际上能从知识库文档中找到答案但因为切块粒度太大、嵌入模型没有充分建模专业术语或者文档被拆到了不同片段里导致检索分数没有达到阈值。系统最终答复“没有找到相关内容”。这种错误在文本里几乎无法自动感知尤其是当问题本身比较专业、回复看起来克制且“合理”时用户会以为知识库真的没有这个内容。还有一个更棘手的状态过度自信。检索相似度分数很高文档也确实相关但推理链无法成立。比如用户问“该方案的风险有哪些”检索到的是方案背景说明书里面只写了目标、方法和时间计划没有风险章节。系统直接提取关键词生成一段“概括性”回答其实是把背景描述重新组织了一遍。从人工检查角度看答案偶尔能看出破绽但从自动化角度很难发现。这些问题汇总起来就是标题里的那句话检索系统分不清能答和不能答。它不擅长暴露自己的盲区。所以我们需要一个显式的可答性判定模块在最终回答前做一次“自我检查”。这种自我检查本质上是给检索结果补充可操作的元信息。顺着这个思路有一个非常典型的工程错误可以作为参照物就是public key retrieval is not allowed。3. 一个边界问题的现实镜像public key retrieval is not allowed这个报错本身不是语义检索问题而是一个数据库连接问题但它非常适合用来理解“边界信息缺失”给调用方带来的困境。在 MySQL 8 的默认认证插件caching_sha2_password下客户端通过 JDBC 连接数据库时如果连接没有使用 TLS并且客户端没有预先配置受信任的公钥客户端需要从服务器获取公钥来加密密码传输。但 JDBC 默认不允许自动获取公钥于是连接直接失败提示public key retrieval is not allowed。从用户视角看这句报错的可用信息量非常少。你只知道系统不允许“公钥检索”但不清楚这个操作是否安全、应该如何授权、是否需要换一种认证方式。你被卡在那个边界上既无法继续连接也得不到下一步动作的提示。解决办法通常是二选一让连接走 TLS 加密通道并在客户端配置信任链或者在开发环境中显式允许获取服务器公钥对应 JDBC URL 参数是allowPublicKeyRetrievaltrue。在非安全连接下使用allowPublicKeyRetrievaltrue意味着密码通过服务器公钥加密后在普通通道传输安全性相比 TLS 要弱所以生产环境不建议这样配置尤其是需要传输敏感数据的场景。把这个报错对齐到检索系统你会发现逻辑高度相似用户提问就是客户端请求知识库就是服务器检索器是握手的通道。当系统无法回答一个超出覆盖范围的问题时很多检索服务只返回一句“未找到相关结果”或直接生成一个看似合理的答案。用户既不知道问题是否需要换种问法也不知道缺的是哪个文档更不知道是因为权限受限、索引没更新还是语义匹配失败。这就是检索系统向用户呈现的public key retrieval is not allowed。因此后面要做的可答性判断模块可以理解为一个给检索结果补充元信息的中间层。回答不了不可怕可怕的是回答不了的时候说不出为什么回答不了。4. 可答性判断的三种工程方案可答性判断不是一个单点算法而是多种信号融合。下面按复杂度从低到高介绍三种工程方案。你可以根据自己的预算和稳定性要求组合使用。4.1 相似度阈值与分数归一化这是最轻量、最容易先落地的一版。基本思路检索时得到一组向量距离或相似度分数设置一个阈值低于阈值就判定为不可回答。但实际工程里不能直接用原始向量距离做判断因为不同嵌入模型产出的分数分布差异很大。有的模型在 0.7 以上才可能相关有的模型在 0.4 就有明显语义关联。所以做阈值前需要对查询和文档之间的相似度做归一化处理常见的做法是收集一批典型问题对检索分数做 min-max 归一化或分位数归一化让分数落到一个相对稳定的区间。这个方案的优点是实现成本和推理成本都很低适合流量大、调用频次高的检索服务。缺点是它只能识别“整体相似度不足”的情况无法识别“文档相关但答案缺失”的情况。比如前面说的权限配置问题片段与查询高度相关但答案确实不在里面单纯看阈值无法拦截。示例逻辑如下import numpy as np def judge_by_threshold(similarities, threshold0.52): mean_sim float(np.mean(similarities)) if mean_sim threshold: return { answerable: False, strategy: threshold, confidence: round(mean_sim, 4) } return { answerable: True, strategy: threshold, confidence: round(mean_sim, 4) }这个函数不是真实项目里的完整实现但代表了一种判断姿势在进入大模型之前先用阈值拦一道。阈值需要通过正负样本校准先跑一批能回答和不能回答的问题画出分数分布再选择误拒率和漏拒率相对平衡的点位。4.2 LLM 可答性分类阈值之外更可靠的方式是用一个分类提示让大模型直接判断“给定资料是否能回答问题”。这一步可以在检索后、生成前执行也可以在生成后让大模型结合答案再判断一次。推荐的做法是前者优先因为节约一次生成调用。典型的分类提示模板如下你是知识库检索质检员。请判断下面的问题能否仅根据给定资料获得可靠答案。 问题{question} 资料 {chunks} 判断规则 1. 如果资料中明确包含答案回答 answerabletrue。 2. 如果资料与问题相关但缺少关键事实或操作步骤回答 answerablefalse。 3. 如果问题完全在资料覆盖范围之外回答 answerablefalse。 只输出 JSON {answerable: true/false, reason: 简要理由, missing: 列出缺失的关键信息}用代码封装起来import json from typing import List, Dict, Any def judge_with_llm(llm_client, question: str, chunks: List[str], max_chars_per_chunk: int 800) - Dict[str, Any]: trimmed [c[:max_chars_per_chunk] for c in chunks] prompt f 你是知识库检索质检员。请判断下面的问题能否仅根据给定资料获得可靠答案。 问题{question} 资料 {chr(10).join(f[{i1}] {c} for i, c in enumerate(trimmed))} 只输出 JSON {{answerable: true/false, reason: 简要理由, missing: 缺失信息描述}} resp llm_client.chat(promptprompt) try: return json.loads(resp) except Exception: return {answerable: True, reason: 分类结果解析失败默认放行, missing: }这里要注意分类结果解析失败时不要默认拒绝而要默认放行同时记录一条分类异常日志方便事后分析。默认拒绝会把误拒率瞬间拉高影响真实可用性。4.3 引用覆盖率与多查询验证如果业务对准确性要求更高建议在生成答案后做一轮引用覆盖校验。具体做法是让生成阶段输出答案时携带引用片段编号然后逐句检查答案的关键信息是否确实来自对应片段。可以把答案按句号切分对每一句做一次轻量向量召回计算该句与引用片段的重合度。如果句子中存在大量片段里没有的关键实体、数值或操作指代就标记为存疑。这是一种“事后校验”逻辑和前面的前置可答性判断互补。多查询验证的思路更直接一个查询可能因为措辞、同义词或者检索块切分问题而失败可以同时生成多个改写版本对每个版本都做检索把返回的候选文档合并。如果多个查询变体都得不到可用的片段那“不可回答”的判断会更加可信。反之如果某个变体检索到了关键片段说明原始查询表达可能需要引导用户改写而不是直接拒绝回答。5. 可运行示例带可答性门槛的 RAG 服务把上面的方案组合成一个最简单的服务核心链路如下接收用户查询编码查询向量在向量索引中召回 top-k 片段计算相似度均值和分布用 LLM 分类器判断可答性可答则生成答案并返回来源不可答则返回结构化拒绝信息。下面是一个简化示例用于演示流程实际部署时需要替换模型名称、索引路径和 LLM 客户端地址。pip install sentence-transformers faiss-cpu fastapi pydantic代码部分拆成两个文件避免把流程全部塞进一个脚本。第一个文件answer_gate.pyimport json import numpy as np from typing import List, Dict, Any from sentence_transformers import SentenceTransformer import faiss class AnswerGate: def __init__( self, encoder, index, docs: List[str], llm_client, threshold: float 0.45, top_k: int 5 ): self.encoder encoder self.index index self.docs docs self.llm_client llm_client self.threshold threshold self.top_k top_k def retrieve(self, query: str): vec self.encoder.encode([query], normalize_embeddingsTrue).astype(float32) scores, indices self.index.search(vec, self.top_k) hits [] for score, idx in zip(scores[0], indices[0]): if idx 0 or idx len(self.docs): continue hits.append({ score: float(score), text: self.docs[idx], doc_id: int(idx) }) return hits def judge(self, query: str, hits: List[Dict[str, Any]]) - Dict[str, Any]: # 信号一阈值判断 if not hits: return { answerable: False, strategy: threshold, reason: 没有检索到任何候选片段, missing: 知识库中可能缺少相关问题覆盖, confidence: 0.0 } mean_score float(np.mean([h[score] for h in hits])) if mean_score self.threshold: return { answerable: False, strategy: threshold, reason: f平均相似度 {mean_score:.4f} 低于阈值 {self.threshold}, missing: 需要更具体或更接近知识库术语的查询, confidence: round(mean_score, 4) } # 信号二LLM 分类 chunks [h[text] for h in hits] prompt f 你是知识库检索质检员。请判断下面的问题能否仅根据给定资料获得可靠答案。 问题{query} 资料 {chr(10).join(f[{i1}] {c} for i, c in enumerate(chunks))} 只输出 JSON {{answerable: true/false, reason: 简要理由, missing: 缺失信息描述}} try: resp_text self.llm_client.chat(promptprompt) parsed json.loads(resp_text) parsed[confidence] round(mean_score, 4) parsed[strategy] thresholdllm return parsed except Exception as exc: print(fllm judge failed: {exc}, use threshold only) return { answerable: True, strategy: threshold, reason: LLM 分类失败按阈值放行, missing: , confidence: round(mean_score, 4) } def query(self, query: str) - Dict[str, Any]: hits self.retrieve(query) judge self.judge(query, hits) answer None if judge.get(answerable): answer self.llm_client.chat(f请根据知识库片段回答问题{query}) return { query: query, answerable: judge.get(answerable), confidence: judge.get(confidence, 0.0), reason: judge.get(reason, ), missing: judge.get(missing, ), answer: answer, sources: hits }第二个文件server.py提供 HTTP 接口from fastapi import FastAPI from pydantic import BaseModel from answer_gate import AnswerGate app FastAPI() class QueryRequest(BaseModel): query: str threshold: float | None None # 初始化部分按实际环境替换 gate None app.post(/api/query) def query(req: QueryRequest): if gate is None: return {error: gate not initialized} return gate.query(req.query) app.get(/health) def health(): return {status: ok}启动命令uvicorn server:app --host 127.0.0.1 --port 8000调用验证curl -X POST http://127.0.0.1:8000/api/query \ -H Content-Type: application/json \ -d {query: 当前版本的备份策略是什么}这个示例的核心价值不在于代码本身而在于把可答性判断从“隐式行为”变成了“显式结果”。服务输出中直接包含answerable字段下游调用方可以根据这个字段决定是否把答案展示给用户还是转人工处理。6. 接口 API 与批量任务设计可答性判断要真正进入生产必须落到接口协议和批量任务里。推荐在原有检索问答接口上增加一组标准字段而不是用非标准文本拼接。响应结构参考{ query: 如何配置访问控制策略, answerable: false, confidence: 0.36, strategy: thresholdllm, reason: 检索到的文档描述了访问控制模块的概览但未包含具体配置步骤, missing: 缺少访问控制策略的配置手册或操作示例, answer: null, sources: [ { doc_id: 12, score: 0.61, text: 访问控制模块支持基于角色的权限管理... } ], user_message: 抱歉当前知识库中还没有能可靠回答该问题的内容。请补充关键词或转人工处理。 }当answerablefalse时避免直接把内部检索理由原样暴露给终端用户。reason和missing字段适合作为内部日志user_message用于面向用户的文案。如果还要对用户更友好可以加一个suggested_query_rewrite把系统认为“更接近知识库表达”的改写建议返回给调用方。批量任务分为离线跑批和在线小流量两类。离线跑批场景通常是评估把一组问题和期望结果写入 JSONL循环请求接口收集answerable判断结果计算准确率和误拒率。在线批量推送场景则要关注限流避免一个批量任务把向量索引和 LLM 服务打满。下面是简化版的批量处理脚本骨架import json import time import requests INPUT_FILE ./queries.jsonl OUTPUT_FILE ./result.jsonl API_URL http://127.0.0.1:8000/api/query BATCH_DELAY 0.2 def process_line(line, session): payload {query: line[query]} resp session.post(API_URL, jsonpayload, timeout60) return resp.json() with open(INPUT_FILE, r, encodingutf-8) as f_in, \ open(OUTPUT_FILE, w, encodingutf-8) as f_out: session requests.Session() for idx, line in enumerate(f_in): item json.loads(line) result process_line(item, session) result[line_id] idx f_out.write(json.dumps(result, ensure_asciiFalse) \n) time.sleep(BATCH_DELAY)批量任务里需要加失败重试。超时、连接重置、LLM 解析失败都可能发生建议对非 2xx 响应和解析异常做三次重试重试间隔递增。同时把每次调用的延迟、可答性判断策略、检索评分分布写入日志方便后续分析阈值偏差。7. 资源占用与性能观察加入可答性判断后最直接的代价是多一次 LLM 分类调用延迟和成本都会上升。如果全部查询都走 LLM 分类系统吞吐量可能会受到影响。合理做法是设计两段式策略先用低成本的阈值做初筛只有分数落在灰色区间时才调用 LLM 分类比如平均相似度在阈值 80% 到 130% 之间。这样大多数高置信度或极低置信度的请求可以走快速通道。实际要观察的性能指标包括以下几个方面第一是延迟拆分。把一个完整请求拆成检索耗时、分类耗时、生成耗时三段。如果分类耗时明显高于生成耗时可以考虑更换更小的分类模型或者把分类与检索并行执行。第二是显存和内存占用。嵌入模型和向量索引会占用内存分类 LLM 如果是本地模型会占用显存。显存占用需要按实际模型版本和量化方式测试不同量化等级的差异会比较明显。观察方法上建议用nvidia-smi做周期采样而不是只等 OOM 出现。如果服务容器化还需要让监控系统周期性采集 GPU 指标。如果你想看实时数值可以在服务启动后执行watch -n 2 nvidia-smi第三是批量任务带来的峰值压力。批量任务不要一次性把全部查询抛给服务而是做一个小型队列控制并发数和间隔观察 CPU、GPU、内存和接口延迟在推进过程中的变化。如果延迟明显上涨优先降低并发数再做模型量化或减少top_k的召回数量。第四是缓存策略。完全相同的知识库查询在短期内重复出现的概率不低尤其是工单场景。可以在服务前加一层基于查询哈希的缓存缓存命中时跳过检索和分类直接返回上一次结果。这个优化在批量任务中效果显著因为批量任务里通常有大量相似或重复的提问。8. 常见问题与排查方法可答性判断模块上线后大概率会遇到下面这些情况。整理成排查表遇到问题时按顺序检查。问题现象可能原因排查方式解决方案所有查询都被判定为不可回答阈值设置过高或者分数归一化范围失配打印检索分数分布与正负样例对照调低阈值重新校准归一化参数明显可回答的问题被判为不可回答检索片段切分过粗关键信息被切断查看sources中返回的文本内容调整切块策略增加重叠长度不可回答的问题产生幻觉答案阈值和 LLM 分类都放行说明判断逻辑失效检查分类提示词是否要求严格引入引用覆盖率校验逐句核验LLM 分类结果解析失败模型输出不稳定的 JSON 文本记录原始返回字符串查看格式增加 JSON 提取兜底逻辑或改用约束解码批量任务中途大量超时并发过高模型推理队列堆积观察服务日志和 GPU 利用率降低批量并发加重试机制接口返回中answerablefalse但用户认为能回答判断策略与用户预期不一致对这类型问题做专项分析增加领域规则或自定义词典连接数据库报public key retrieval is not allowedJDBC 不允许获取服务器公钥检查连接 URL 和认证插件测试环境可按需配置allowPublicKeyRetrievaltrue生产建议使用 TLS 受信任连接语义检索结果相似度普遍很低嵌入模型与领域表达不匹配抽取专业术语测试嵌入效果换用领域微调嵌入模型或加入查询改写最需要警惕的是“默认放行”带来的幻觉风险。在 LLM 分类失败时如果默认放行虽然不会挡住真问题但会漏掉假阳性。此时要在日志里记录清晰的分类异常率如果异常率超过预期就说明提示模板或模型能力需要调整而不是放任不管。9. 最佳实践与合规边界可答性判断的最终目标不是把系统变得保守而是让回答边界变得可预测。落到工程上有几点建议值得长期坚持。第一维护一套正负样例集。正例是知识库中明确可回答的问题负例是主题相关但无法从当前知识库得到答案的问题。每次调整阈值或替换嵌入模型时都在这套样例集上重跑一遍记录可答性准确率、误拒率和漏拒率。没有这套评估任何阈值调整都是盲目的。第二将“不可回答”也视为产品功能。拒绝时给出具体的缺失信息说明、改写建议或转人工入口比简单说“没有答案”要好得多。设计用户端文案时可以借鉴数据库连接错误的教训错误信息本身要可执行不要只给一个状态码。第三涉及人脸、声音、隐私数据或受版权保护的文档内容时必须建立授权与合规边界。可答性判断模块本质上会让系统暴露更多数据比如missing字段可能包含知识库未覆盖的敏感主题sources字段会把原文片段透出。所以在接口层要控制日志保留时长避免在日志中记录完整原文。对外返回时应只保留必要的文档标题或摘要不返回大段原文。第四监控真实拒绝率。如果产品上线后发现拒绝率过高用户会失去信任如果拒绝率过低说明判断边界过宽幻觉风险上升。建议每日统计拒绝率、人工纠错量、幻觉投诉量用数据反向校正阈值。第五不要忽略检索质量本身。可答性判断可以拦住很多问题但它不能替代高质量的分块策略、查询改写和索引更新。先保证检索系统能把真实可用的文档召回到前三再谈可答性过滤。否则你能得到的最好结果也只是在质量糟糕的候选集上做出一个更保守的决策。10. 总结与下一步这次要解决的核心问题是让检索系统明确知道自己能回答什么不能回答什么。通过归一化阈值、LLM 分类和引用覆盖率校验三套信号可以把“不可回答”从一种隐式行为变成显式结果并从接口层面反馈给上游调用方。最值得先验证的功能是在你的知识库 sample 上跑一批正负样例看看当前阈值和分类模型能拦住多少假阳性误拒率是多少。最容易踩的坑是阈值校准不同的嵌入模型、不同领域的文档分数分布差异都会比较大直接套用网上参数通常不可靠。后续可以考虑把可答性判断独立成一个小服务统一管理阈值版本和评估数据集。当知识库更新、嵌入模型升级或者换了 LLM 之后用同样的评估集重新跑一遍判断结果的差异一目了然。再往下可以接入多查询改写、引用逐句校验、人工标注回流等能力让边界判断越来越接近真实业务需要。这套东西上线后至少不需要再担心用户问一个知识库覆盖不到的问题时系统突然给出一个看起来相当自信却完全不存在的答案。让系统学会说“我不知道”本身就是一种质量提升。建议收藏备用下个 RAG 项目可以直接照这个思路落地。
