候选人我的 RAG 知识库效果不好用户问的问题经常搜不到正确答案。面试官你怎么优化的我换了更好的向量库从 Milvus 换成了 Elasticsearch。换库解决了吗……没有还是搜不准。面试官在心里叹了口气。向量库只是存储不是检索质量的瓶颈。搜不准90% 的问题是检索策略的问题——而检索策略的终极答案是混合检索 重排。这篇把 RAG 检索质量的完整方案讲透。这也是 RAG 系列的收官之篇。为什么纯向量检索会搜不准先看一个场景。用户问iPhone 15 Pro 256G 现在什么价格你的知识库里有一篇文档《iPhone 15 Pro 各版本价格表256G 版本 ¥8999》。纯向量检索会怎样它把问题变成向量去库里找语义最接近的文档。问题里有iPhone 15 Pro、256G、价格这些关键词文档里也都有——理论上应该能搜到。但有两个情况向量检索会翻车情况一精确匹配失效。用户问的是IP15 Pro 256G 多少钱口语化缩写。向量检索能理解IP15 Pro≈iPhone 15 Pro但如果你问的是订单号PO-20240715-001、型号RTX4090这种必须精确匹配的信息向量检索的模糊反而成了缺点——它可能给你返回语义相似但编号不同的文档。情况二语义漂移。两个文档都看起来相关向量检索分不清哪个才是真正回答了用户的问题。比如用户问退货政策库里有《退货政策 v2.0》和《售后常见问题含退货案例》向量距离可能差不多但前者才是权威答案。纯向量检索的命门它只懂像不像不懂对不对。方案混合检索Hybrid Search思路很简单用两种检索器各搜一遍把结果融合。-BM25关键词检索精确匹配订单号、型号、人名、专有名词它最强。不懂同义词但命中即精准。-向量检索语义检索理解同义词、口语化表达。模糊但覆盖面广。两个检索器各返回 Top-50然后融合成一份 Top-10。融合算法推荐 RRFReciprocal Rank Fusion倒数排名融合score(d) Σ 1 / (k rank_i(d))k 一般取 60。核心思想不看分数看排名。一个文档在 BM25 里排第 3、在向量检索里排第 5它的融合分就是 1/63 1/65。两边都靠前的文档胜出。为什么用 RRF 而不是加权平均因为 BM25 的分数和向量相似度根本不是一个量纲没法直接加权。RRF 只看排名天然免疫两个检索器的分数尺度不一致问题还不用调权重。Spring AI 里启用混合检索// 配置 ES 的混合检索关键词 向量 SearchRequest request SearchRequest.builder() .query(question) .topK(50) .searchType(SearchType.HYBRID) // 混合检索 .build(); ListDocument docs vectorStore.similaritySearch(request);生产上常见组合Elasticsearch自带 BM25 向量、pgvectorBM25 用 PostgreSQL 全文检索 向量列、或 Milvus 独立 ES。进阶两阶段检索召回 重排混合检索解决了搜得全不全还没解决排得准不准。融合后的 Top-10 里可能还是混着几个相关但不对的文档。这时候上重排Rerank。第一阶段召回BM25 向量检索各取 Top-50RRF 融合去重成 Top-30。要求快、全宁可多捞不能漏。第二阶段精排用 Rerank 模型如 bge-reranker-v2-m3对 Top-30 逐条精算相关性取 Top-5 送入 LLM。要求准。为什么 Rerank 比向量检索准因为向量检索是把问题和文档分别编码成向量再算距离——两个独立编码信息在编码过程中被压缩丢失了。Rerank 模型是把问题文档拼接在一起做交叉编码Cross-Encoder模型能看到问题和文档的完整交互相关性判断精细得多。# bge-reranker 用法示意伪代码 from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-v2-m3) pairs [(question, doc) for doc in top30] scores reranker.predict(pairs) # 逐条打分 # 按分数排序取 Top-5 top5 sorted(zip(top30, scores), keylambda x: -x[1])[:5]成本账Rerank 是逐条计算30 条大概多花 200ms。但这 200ms 换来的是进 LLM 的文档从 10 条变 5 条Token 消耗减半回答质量明显提升总成本反而降了。查询改写容易被忽略的第一步混合检索之前还有一个前置环节——查询改写Query Rewriting。用户的原始提问往往不适合直接检索- 那个 256G 的手机多少钱 —— 那个指代不明- 跟刚才说的那款比呢 —— 依赖上下文- 帮我看看 —— 太口语化检索词太少不改写就检索召回质量天然受限。常见的改写策略策略一指代消解。结合历史对话把那个、它替换成实际指代的对象String REWRITE_PROMPT 结合历史对话把用户的问题改写成适合检索的独立问句。 如果问题已经清晰原样输出。 【历史对话】 {history} 【用户问题】 {question} 输出改写后的问句不要任何解释。 ;策略二扩展关键词。用户问退款改写时补充同义词退货、退款流程、退款政策提高 BM25 的命中率。策略三拆解复合问题。帮我查一下订单状态和物流信息 → 拆成订单状态、物流信息两个检索请求分别召回再合并。查询改写的成本每次多一次小模型调用几厘钱 几百毫秒。值得吗我们实测加上改写后检索命中率提升了 8 个百分点。性价比很高尤其是用户提问口语化严重的场景。什么时候可以不用重排重排不是银弹两个场景可以省掉场景一知识库规模小几百条以内。暴力检索 人工维护的文档质量够高Top-K 直接送 LLM 也行。杀鸡不用牛刀。场景二延迟极度敏感。Rerank 多花 200ms如果产品要求首字延迟 1 秒就要权衡。可以降级方案只对 Top-10 做 Rerank而不是 Top-30。判断标准检索结果里相关但不对的噪声多不多。噪声多 → 上重排噪声少 → 省掉。用测试集评估别拍脑袋。一个完整的生产链路把前面所有知识串起来一个生产级 RAG 检索链路用户问题 ↓ ① 查询改写可选口语化 → 标准问法 ↓ ② 混合召回BM25 取 Top-50 向量检索取 Top-50 ↓ ③ RRF 融合去重 → Top-30 ↓ ④ Rerank 精排 → Top-5 ↓ ⑤ 注入 Prompt带引用来源→ LLM 生成回答 ↓ ⑥ 回答后校验引用是否真实存在每一步都有它的职责- 查询改写解决用户问得糙- 混合召回解决搜不全、精确匹配失效- RRF 融合解决两个检索器怎么合并- Rerank 解决排得不准- 引用校验解决幻觉面试官问RAG 检索质量怎么优化你能把这条链路讲出来就是 P6 级别的答案。 面试官视角的标准回答如果面试官问RAG 检索质量差你怎么优化先说结论检索质量差90% 不是向量库的问题是检索策略的问题。我的方案是混合检索 两阶段精排。brbr第一步混合检索。纯向量检索的弱点是只懂像不像不懂对不对订单号、型号这类精确信息容易翻车。所以我用 BM25 关键词检索 向量语义检索并行各取 Top-50。BM25 保精确向量保语义互补。brbr第二步RRF 融合。两个检索器的分数不是一个量纲不能直接加权。RRF 只看排名score Σ 1/(krank)两边都靠前的文档胜出不用调权重。brbr第三步Rerank 精排。融合后的 Top-30 用交叉编码模型逐条精算相关性取 Top-5 送 LLM。Rerank 把问题和文档拼接编码比向量检索的独立编码精细得多。brbr补充效果数据混合检索 重排后我们的检索命中率从 62% 提升到 91%进 LLM 的 Token 少了成本也降了。brbr补充一点检索质量是系统工程查询改写、混合召回、融合、精排、引用校验每一环都值得做。只换向量库解决不了问题。AIGC 面试系列 13-17 篇流式输出、上下文记忆、幻觉治理、Embedding、混合检索重排到这里告一段落。从AI 回答怎么蹦出来的到向量怎么来的再到搜不准怎么办——这些不是孤立的知识点而是一个完整 AIGC 后端工程师的实战地图。你把这五篇吃透配合前面 12 篇AIGC 方向的面试基本能平趟。老规矩面试官问 AIGC不背答案要能聊。