RAG 检索召回无关内容时，如何从 query rewrite、混合检索、rerank、过滤和拒答机制处理？｜高频面试题解析

60 秒回答模板

我会先把无关召回当成检索链路问题定位，而不是直接归因于大模型。第一步复盘线上样本里的原始 query、改写后 query、召回文档、检索分数、重排结果、最终引用和回答内容，判断问题来自用户表达偏差、索引噪声、切片粒度、召回策略失配、重排失效、权限过滤缺失，还是生成阶段没有识别证据不足。处理上分四层：查询侧做意图识别、改写、拆解、实体归一和歧义澄清；索引侧治理文档质量、切片、标题路径、时间、权限和业务元数据；召回侧采用稠密检索、关键词检索、结构化过滤和多路召回融合；排序与生成侧增加重排、相关性阈值、证据覆盖检查、引用约束和拒答兜底。最后用离线标注集和线上 badcase 闭环观察召回率、无关召回率、首个相关片段位置、拒答准确率、延迟和用户反馈，避免只凭单个案例调参。

考点 先定位再优化

难度 真实面经题

回答目标 让面试官看到你能把 RAG 无关召回从现象拆到根因，并能设计可落地的查询治理、索引治理、多路召回、重排过滤、拒答和评估闭环。

深入解析

先定义无关召回

无关召回不只是完全不相干，还包括主题相近但实体错、时间错、权限错、业务线错、片段缺上下文、召回了答案前后文但没有关键事实等情况。面试回答要先分类，否则后面的治理手段会混在一起。

建立可观测链路

每次请求要记录原始 query、改写 query、召回源、分数、重排排序、过滤原因、引用片段和最终回答。没有这些 trace，只能凭感觉改提示词，无法判断是检索错、排序错，还是生成时没有用好证据。

查询侧治理

用户问题短、口语化或有省略时，先做意图识别、实体归一、同义词扩展和 query rewrite；复杂问题可拆成多个子问题分别召回。对歧义 query，不应强行检索，而应补充上下文或进入澄清流程。

索引与切片治理

很多无关召回来自知识库本身：脏文档、重复文档、过期文档、标题缺失、切片过碎或过大、元数据不完整。实践中要把文档路径、标题、业务域、时间、权限、版本等作为过滤和排序信号，而不是只存正文向量。

混合召回与过滤

稠密向量适合语义相似，但容易召回看起来相似却事实不匹配的内容；关键词检索更适合精确实体、编号和专有名词。常见方案是稠密检索、关键词检索、结构化过滤多路召回，再按业务域、权限、时间和类型做硬过滤。

重排与阈值

第一阶段召回追求覆盖，第二阶段重排负责相关性精排，可以用交叉编码器、轻量模型或规则特征融合。必须设置相关性阈值和证据覆盖门槛，低于阈值时不要把低质量片段硬塞给生成模型。

拒答与降级

当相关证据不足时，系统应明确拒答、提示需要更多信息，或降级到人工、搜索、工单等流程。RAG 的安全边界不是永远回答，而是在证据不足时不编造。

闭环评估

把无关召回样本沉淀成 badcase 集，按问题类型、业务域、文档源和召回阶段分桶复测。每次改切片、索引、召回参数或重排模型，都要看整体指标和关键分桶是否回归。

易错点

只说调大模型提示词，不分析检索链路。
把向量相似度高等同于内容相关。
没有拒答机制，证据不足时仍然强行回答。
只优化召回率，不看无关召回率和首个相关片段位置。
忽略权限、时间、版本、业务域等结构化过滤。
把 query rewrite 当成万能方案，不保留原始 query 和可追踪日志。
没有 badcase 回归集，修一个案例坏一批案例。

面试官追问

如果召回结果看起来语义相似但答案不对，怎么处理？

先判断是不是实体、时间、业务域或版本不匹配。处理上可以加强关键词和结构化过滤，把实体、日期、产品线等作为硬约束或强特征，再用重排模型识别真正能回答问题的片段。

query rewrite 会不会把问题改错？

会，所以 rewrite 结果要可追踪，并尽量保留原始 query 参与召回。重要场景可以多 query 并行召回，用重排和证据校验决定最终使用哪一路结果。

无答案问题怎么评估？

要专门构造无答案样本，看系统是否正确拒答或澄清。只评估有答案问题会让系统倾向于强答，线上表现就是把无关内容包装成看似可信的回答。

线上 badcase 如何进入改进流程？

先记录完整链路，再人工标注根因和期望证据，加入回归集。后续每次改索引、召回、重排或阈值，都要跑这批样本，确认旧问题没有反复出现。

RAG 检索召回无关内容时，如何从 query rewrite、混合检索、rerank、过滤和拒答机制处理？