拒答日志应该作为知识库迭代的一个输入源高频被拒的问题定期拉出来看哪些是知识库确实该覆盖但没覆盖的补进去哪些是真的不该这个系统来回答的在产品和交互层面做引导。做 RAG 的人早晚都会撞上这个问题而且通常不是在 demo 阶段是上了生产、用户量上来之后才发现有多头疼。大部分讲 RAG 的文章都在说怎么召回得更准——调 chunk size、换 embedding 模型、加 reranker。这些当然有用但都是在解决怎么把对的内容找出来。而知识库外提问是另一件事内容根本就不在你库里你检索再准也没用但系统照样会给你返回东西而且返回的东西往往看起来还挺像那么回事。这是很烦人的一个事搜不到还好说就怕没搜到还给你乱七八糟的东西系统基于一堆不相关的内容拼出了一个自信满满、但事实性错误的答案用户看不出来以为你的产品很靠谱。这个问题麻烦在哪第一个坑相似度阈值基本不可靠。刚上手做 RAG 的时候直觉就是设阈值低于 0.7 就不采用跑几天就发现不行。同一个 embedding 模型不同领域的 query相似度分数的分布完全不一样。有的场景 0.7 已经是强相关了有的场景 0.85 的内容跟 query 的关系还是很牵强。没法用一个全局阈值来区分相关和不相关除非你的知识库内容极其单一、用户提问方式极其稳定但生产环境基本不可能是这样。更麻烦的是有些 query 和文档之间关键词重合度很高、向量距离也很近但文档回答的其实是另一个问题。比如用户问怎么取消自动续费你知识库里确实有续费相关的文档但那是讲续费规则的不是讲取消操作的。Embedding 模型分不出这种差别它看到的就是续费这个词在两个地方都出现了语义空间里距离很近。检索系统兴高采烈地把这篇文档排在 top-3 返回给你然后 LLM 拿着这篇文档给用户编了一个取消续费的流程。第二个坑LLM 在有 context 的情况下天然倾向于用 context 回答而不是质疑 context。加一句如果没有相关信息就说不知道在 context 完全空白或者明显不相关的时候确实有用。但问题在于检索系统永远会返回 top-K向量数据库不会返回空结果它只会返回距离最近的那几条。LLM 看到的永远是有内容的状态。只要 context 里有文字LLM 的默认行为就是基于这些文字组织答案而不是先判断这些文字跟 query 到底有没有关系。把判断逻辑塞进 prompt 能缓解但不能根治因为 LLM 对这个文档能不能回答这个问题的判断本身也在受 context 影响它看到文档里有一些看起来沾边的词就容易说服自己这大概算是相关吧。这两个问题叠在一起线上跑出来的效果就是用户提了一个知识库覆盖不到的问题 → 检索照样返回了 top-K 文档 → LLM 基于这些文档拼出了一个答案 → 答案读起来通顺、自信、像模像样 → 但关键信息是错的或者编的。这种 failure mode 比检索漏召回严重得多漏召回用户至少知道你没答上来而这种用户以为你答对了。在哪一层处理我的经验是两层搜前搜后各一道。检索层能做的是粗筛把明显不靠谱的拦住单一阈值不靠谱但多种信号叠加之后能拦住不少。一个低成本有效的方法是token overlapquery 里的关键词和检索回来的文档之间做词级别的 overlap 检查。向量相似度高但关键词几乎不重叠说明 embedding 被语义相近但领域不同的内容带偏了。反过来关键词大量撞上了但你读一遍发现是在讨论不同的事情可能是术语刚好重合。两种情况都可以作为置信度降低的信号。多路召回交叉验证也能提供信号dense retrieval 和 sparse retrievalBM25各自召回 top-K看两边的重叠度。如果重叠度很低说明 semantic match 和 lexical match 之间分歧很大这次检索的结果不该被无条件信任。但这些只能拦下明显不相关的那些看起来相关但其实答非所问的检索结果靠规则信号拦不住需要下一步。生成前做一次相关性校验检索结果拿到之后别直接塞给 LLM 生成答案先让它判断这些文档到底能不能回答用户的问题。至于需不需要专门训一个分类模型我的看法是不需要直接复用 RAG 链路上已经在调的那个 LLM 就够。不是说训一个 BERT 做 query-document 二分类技术上不可行推理快、延迟低理论上适合。但实际维护成本比看起来高得多。知识库内容一更新、用户问法一变化分类边界就跟着漂。你今天标了一批数据训出来的模型过两个月知识库加了几篇新文档模型对什么是相关的判断可能就不对了。持续标注、持续重训这个工作量放在一个小规模团队里根本不现实。用 LLM 做这个判断的优势不需要额外维护一个模型链路少一个组件排查问题少一个变量。而且 LLM 对这段文字讨论的是 A而用户问的是跟 A 表面相似但实质不同的 B这种细微差别的分辨能力目前的判别式模型差了一个量级。落地上几个点值得注意Prompt 里要让 LLM对每一条文档做判断不要笼统地问这些文档和问题相关吗。笼统地问它倾向于给一个模糊的评价。逐条打 tagrelevant/partially_relevant/irrelevant再要求给一句话理由效果会稳定很多。建议用 structured output 约束格式不约束的话 LLM 很容易跑偏。相关的定义要在 prompt 里写清楚。不是文档和 query 是否属于同一主题而是**文档内容是否能直接用来回答用户的问题**。这个定义直接决定拒答的准确率和召回率之间的平衡。拒答分层做不要一刀切。全都不相关就直接拒答告诉用户这个系统的能力边界在哪部分相关就把已有的信息给出来同时说明哪些部分找不到答案。最坏的情况是把明明有的信息判成不相关然后拒了用户比收到一个不太准的答案更恼火。Prompt 层面的最后一道防线相关性校验也可能漏prompt 层面的防御指令必须有但写法比有没有更重要。如果没有相关信息就说不知道这句话实际效果很差因为 LLM 看到 context 里有内容的时候不会真的去质疑这些内容跟 query 的关系。改成把判断作为一个显式步骤嵌入 prompt先判断资料是否真的能回答用户的问题如果不能不要硬拼凑直接说明原因。把判断 → 决定是否回答作为第一步而不是一个注意事项行为上会有明显差别。说在最后拒答的目的主要是是兜底如果用户频繁问知识库外的问题说明两件事至少有一件成立要么知识库覆盖有严重缺口要么产品层面没有让用户搞清楚这个系统应该用来干什么。这两个问题都不是调 prompt 能解决的。拒答日志应该作为知识库迭代的一个输入源高频被拒的问题定期拉出来看哪些是知识库确实该覆盖但没覆盖的补进去哪些是真的不该这个系统来回答的在产品和交互层面做引导。
拒答日志应该作为知识库迭代的一个输入源高频被拒的问题定期拉出来看哪些是知识库确实该覆盖但没覆盖的补进去哪些是真的不该这个系统来回答的在产品和交互层面做引导。做 RAG 的人早晚都会撞上这个问题而且通常不是在 demo 阶段是上了生产、用户量上来之后才发现有多头疼。大部分讲 RAG 的文章都在说怎么召回得更准——调 chunk size、换 embedding 模型、加 reranker。这些当然有用但都是在解决怎么把对的内容找出来。而知识库外提问是另一件事内容根本就不在你库里你检索再准也没用但系统照样会给你返回东西而且返回的东西往往看起来还挺像那么回事。这是很烦人的一个事搜不到还好说就怕没搜到还给你乱七八糟的东西系统基于一堆不相关的内容拼出了一个自信满满、但事实性错误的答案用户看不出来以为你的产品很靠谱。这个问题麻烦在哪第一个坑相似度阈值基本不可靠。刚上手做 RAG 的时候直觉就是设阈值低于 0.7 就不采用跑几天就发现不行。同一个 embedding 模型不同领域的 query相似度分数的分布完全不一样。有的场景 0.7 已经是强相关了有的场景 0.85 的内容跟 query 的关系还是很牵强。没法用一个全局阈值来区分相关和不相关除非你的知识库内容极其单一、用户提问方式极其稳定但生产环境基本不可能是这样。更麻烦的是有些 query 和文档之间关键词重合度很高、向量距离也很近但文档回答的其实是另一个问题。比如用户问怎么取消自动续费你知识库里确实有续费相关的文档但那是讲续费规则的不是讲取消操作的。Embedding 模型分不出这种差别它看到的就是续费这个词在两个地方都出现了语义空间里距离很近。检索系统兴高采烈地把这篇文档排在 top-3 返回给你然后 LLM 拿着这篇文档给用户编了一个取消续费的流程。第二个坑LLM 在有 context 的情况下天然倾向于用 context 回答而不是质疑 context。加一句如果没有相关信息就说不知道在 context 完全空白或者明显不相关的时候确实有用。但问题在于检索系统永远会返回 top-K向量数据库不会返回空结果它只会返回距离最近的那几条。LLM 看到的永远是有内容的状态。只要 context 里有文字LLM 的默认行为就是基于这些文字组织答案而不是先判断这些文字跟 query 到底有没有关系。把判断逻辑塞进 prompt 能缓解但不能根治因为 LLM 对这个文档能不能回答这个问题的判断本身也在受 context 影响它看到文档里有一些看起来沾边的词就容易说服自己这大概算是相关吧。这两个问题叠在一起线上跑出来的效果就是用户提了一个知识库覆盖不到的问题 → 检索照样返回了 top-K 文档 → LLM 基于这些文档拼出了一个答案 → 答案读起来通顺、自信、像模像样 → 但关键信息是错的或者编的。这种 failure mode 比检索漏召回严重得多漏召回用户至少知道你没答上来而这种用户以为你答对了。在哪一层处理我的经验是两层搜前搜后各一道。检索层能做的是粗筛把明显不靠谱的拦住单一阈值不靠谱但多种信号叠加之后能拦住不少。一个低成本有效的方法是token overlapquery 里的关键词和检索回来的文档之间做词级别的 overlap 检查。向量相似度高但关键词几乎不重叠说明 embedding 被语义相近但领域不同的内容带偏了。反过来关键词大量撞上了但你读一遍发现是在讨论不同的事情可能是术语刚好重合。两种情况都可以作为置信度降低的信号。多路召回交叉验证也能提供信号dense retrieval 和 sparse retrievalBM25各自召回 top-K看两边的重叠度。如果重叠度很低说明 semantic match 和 lexical match 之间分歧很大这次检索的结果不该被无条件信任。但这些只能拦下明显不相关的那些看起来相关但其实答非所问的检索结果靠规则信号拦不住需要下一步。生成前做一次相关性校验检索结果拿到之后别直接塞给 LLM 生成答案先让它判断这些文档到底能不能回答用户的问题。至于需不需要专门训一个分类模型我的看法是不需要直接复用 RAG 链路上已经在调的那个 LLM 就够。不是说训一个 BERT 做 query-document 二分类技术上不可行推理快、延迟低理论上适合。但实际维护成本比看起来高得多。知识库内容一更新、用户问法一变化分类边界就跟着漂。你今天标了一批数据训出来的模型过两个月知识库加了几篇新文档模型对什么是相关的判断可能就不对了。持续标注、持续重训这个工作量放在一个小规模团队里根本不现实。用 LLM 做这个判断的优势不需要额外维护一个模型链路少一个组件排查问题少一个变量。而且 LLM 对这段文字讨论的是 A而用户问的是跟 A 表面相似但实质不同的 B这种细微差别的分辨能力目前的判别式模型差了一个量级。落地上几个点值得注意Prompt 里要让 LLM对每一条文档做判断不要笼统地问这些文档和问题相关吗。笼统地问它倾向于给一个模糊的评价。逐条打 tagrelevant/partially_relevant/irrelevant再要求给一句话理由效果会稳定很多。建议用 structured output 约束格式不约束的话 LLM 很容易跑偏。相关的定义要在 prompt 里写清楚。不是文档和 query 是否属于同一主题而是**文档内容是否能直接用来回答用户的问题**。这个定义直接决定拒答的准确率和召回率之间的平衡。拒答分层做不要一刀切。全都不相关就直接拒答告诉用户这个系统的能力边界在哪部分相关就把已有的信息给出来同时说明哪些部分找不到答案。最坏的情况是把明明有的信息判成不相关然后拒了用户比收到一个不太准的答案更恼火。Prompt 层面的最后一道防线相关性校验也可能漏prompt 层面的防御指令必须有但写法比有没有更重要。如果没有相关信息就说不知道这句话实际效果很差因为 LLM 看到 context 里有内容的时候不会真的去质疑这些内容跟 query 的关系。改成把判断作为一个显式步骤嵌入 prompt先判断资料是否真的能回答用户的问题如果不能不要硬拼凑直接说明原因。把判断 → 决定是否回答作为第一步而不是一个注意事项行为上会有明显差别。说在最后拒答的目的主要是是兜底如果用户频繁问知识库外的问题说明两件事至少有一件成立要么知识库覆盖有严重缺口要么产品层面没有让用户搞清楚这个系统应该用来干什么。这两个问题都不是调 prompt 能解决的。拒答日志应该作为知识库迭代的一个输入源高频被拒的问题定期拉出来看哪些是知识库确实该覆盖但没覆盖的补进去哪些是真的不该这个系统来回答的在产品和交互层面做引导。
