检索质量这件事做过 RAG 的人应该都有体会向量检索上线第一天效果惊艳第二周开始被业务方追着问为什么搜出来的东西答非所问。我前后在三个不同规模的知识库项目里踩过检索质量的坑从最初只会调 top_k到后来把混合检索、Rerank、Query 改写这一整套组合拳打下来才算真正把召回率和准确率这两个指标同时按住。这篇就把这套优化链路完整拆一遍包括 RRF 融合里那个被很多人忽略的去重缺陷以及 HyDE 到底什么时候该用、什么时候是纯浪费 token。1. 纯向量检索为什么会在真实业务里翻车1.1 语义相似不等于业务相关先说一个最容易被误解的点向量检索算的是语义相似度不是业务相关性。这两者在 demo 阶段高度重合因为 demo 的 query 和文档往往是同一批人写的用词习惯一致。但真实业务里用户提问的方式和文档的表述方式经常是两套语言体系。举个我实际遇到的例子。一个做设备运维的知识库文档里写的是离心泵机械密封泄漏的排查流程用户搜的是泵漏水怎么处理。这两个在语义空间里确实近能召回。但用户搜3号泵昨天开始渗水向量检索就懵了——3号泵这个编号在文档里可能压根没出现过而昨天这种时间词对语义向量几乎是噪声。结果就是召回了一堆泛泛的泵维护手册真正那份3号泵检修记录反而排在后面。问题的本质是稠密向量擅长捕捉意思像但对精确的实体、编号、专有名词、数字极不敏感。而业务查询里恰恰充满了这类精确信息。1.2 稀疏检索补的正是这块短板BM25 这类稀疏检索关键词检索的逻辑完全相反。它不看语义只看词频和逆文档频率谁的关键词匹配得准谁排前面。3号泵这三个字只要在文档里出现过BM25 就能精准命中管你语义像不像。所以混合检索的核心动机不是两个一起用效果更好这种模糊说法而是两者能力互补维度稠密向量检索稀疏检索BM25匹配依据语义相似度词项精确匹配擅长同义改写、模糊意图实体、编号、专有名词、数字短板精确实体、罕见词同义词、语义泛化对 query 长度敏感度低短 query 效果好典型失败场景3号泵渗水怎么让设备不响我一般会先做一轮 query 分析如果业务查询里实体、编号、型号占比高混合检索的收益会非常明显如果全是自然语言长句收益相对小一些但通常还是正的。1.3 一个判断要不要上混合检索的土办法不用一上来就搞复杂架构。我的经验是先跑一个对照实验拿 50 到 100 条真实 query分别用纯向量和纯 BM25 各跑一遍人工标注前 10 条里有多少是相关的。如果两者召回的相关文档集合重叠度低于 60%说明它们确实在互补混合检索值得上如果重叠度很高比如 85% 以上那说明你的场景里两种方法看到的东西差不多先别急着上混合把精力放在 Rerank 上收益更大。这个重叠度指标比任何论文里的结论都实在因为它测的是你自己的数据。2. 混合检索的融合策略RRF 不是唯一解但通常是最稳的2.1 分数归一化融合的坑最直觉的融合方式是把两路分数归一化后加权求和。听起来合理实操里问题一堆。稠密检索的分数通常是余弦相似度范围在 -1 到 1 之间实际业务里大多落在 0.5 到 0.9BM25 的分数是无上界的可能是 3.2也可能是 47.8取决于语料。你要把这两个量纲完全不同的东西加权相加就得先归一化。而归一化本身就会引入偏差如果某一路的分数分布很集中比如全在 0.8 附近归一化后区分度会被放大或压缩权重就失真了。更麻烦的是分数分布会随 query 变化。同一个 BM25 模型对短 query 和对长 query 的分数尺度可能完全不同。你没法用一个固定的归一化参数通吃所有 query。2.2 RRF 用排名代替分数绕开了归一化难题RRFReciprocal Rank Fusion倒数排名融合的思路很聪明我不看你的分数只看你的排名。公式是RRF_score(d) Σ 1 / (k rank_i(d))其中rank_i(d)是文档 d 在第 i 路检索结果里的排名从 1 开始k是一个平滑常数通常取 60。这个设计的精妙之处在于排名是天然可比的不需要归一化。而且1/(krank)这个函数对排名靠前的文档给高权重对排名靠后的快速衰减天然符合头部结果更重要的直觉。k60 的作用是压平头部差异——如果没有 k第 1 名和第 2 名的权重差是 1 和 0.5差一倍有了 k60变成 1/61 和 1/62差距很小避免某一路的绝对第一名过度主导。我实测下来RRF 在绝大多数场景下比调参调半天的加权融合更稳而且几乎不用调参k 用 60 就行。这也是为什么 LangChain、LangChain4j 这些框架默认都用 RRF。2.3 RRF 的 k 值到底要不要调网上很多文章说 k 取 60 是经验值但没说为什么。我自己的理解是k 越大融合结果越民主各路检索的排名差异被压得越平k 越小越精英头部结果的话语权越大。实际调参时我会这样判断如果两路检索质量差不多k 用 60 或更大让它们充分投票如果某一路明显更可信比如向量检索在你的场景里就是比 BM25 准k 可以调小到 10 到 20让头部排名更有话语权如果两路质量都很差别指望调 k 能救先回去修检索本身。我做过一组对比k 从 10 调到 100NDCG 的波动通常在 2 到 3 个百分点以内。所以k 不是关键变量别在这上面过度投入。3. LangChain 和 LangChain4j 的 RRF 去重缺陷一个真实踩过的坑3.1 缺陷现象同一文档被重复计分这是最近社区讨论比较多的一个问题我自己也复现过。RRF 融合时如果同一个文档同时出现在两路检索结果里这很常见好的文档本来就该被两路都召回理想情况下它应该累加两路的 RRF 分数从而排名上升。但部分框架的默认实现里去重逻辑用的是文档的对象引用或完整内容哈希而不是稳定的文档 ID。结果就是同一个逻辑文档如果两路返回的对象实例不同比如一路返回的是原始 chunk另一路返回的是经过某种包装的 chunk去重就失效了融合结果里会出现两条看起来一样的记录各自只拿到一路的分数反而没有累加排名被稀释。更隐蔽的情况是去重时用了内容字符串做 key但两路返回的文本有细微差异比如一个带了标题前缀一个没带哈希对不上同样去重失败。3.2 为什么这个坑特别难发现因为它不报错。融合结果照样返回只是排序悄悄变差了。你在 demo 上看不出问题因为 demo 的文档少、两路结果重叠少。等到文档量上来、两路重叠变多效果就开始莫名其妙地下降而你还在怀疑是不是 embedding 模型不行。我当时的排查路径是这样的先固定 query把两路检索的原始结果各自打印出来人工看重叠情况再打印 RRF 融合后的结果对比同一文档的分数发现某文档在两路里都排前 5融合后却掉到第 12分数明显偏低定位到融合结果里它出现了两次各拿了一路的分。3.3 修复方案用稳定 ID 做去重键修复其实很简单核心是给每个文档一个稳定的唯一标识融合时以它为准做聚合。伪代码大概是这样def rrf_fuse(result_lists, k60): scores {} # doc_id - 累计分数 doc_map {} # doc_id - 文档对象 for results in result_lists: for rank, doc in enumerate(results, start1): doc_id doc.metadata[doc_id] # 稳定 ID不是对象引用 scores[doc_id] scores.get(doc_id, 0.0) 1.0 / (k rank) doc_map.setdefault(doc_id, doc) fused sorted(scores.items(), keylambda x: x[1], reverseTrue) return [(doc_map[did], score) for did, score in fused]关键点有三个doc_id 必须在入库时就生成并写进 metadata不能依赖运行时对象去重和累分用同一个 key保证同一文档累加分数返回时用 doc_map 取回文档对象避免重复。提示如果你用的是框架默认的 RRF先别急着信它。拿一个两路都命中的文档手动算一下它的 RRF 分数和框架输出对比。对不上就是去重逻辑有问题。3.4 顺带说一个相关的坑chunk 粒度不一致去重失效还有一个变种两路检索返回的 chunk 粒度不同。比如向量检索返回的是 512 token 的 chunkBM25 返回的是按段落切的 chunk同一个段落可能被切成不同的边界。这种情况下即使你用 doc_id 去重也可能因为 doc_id 定义在段落级而 chunk 级不同导致去重不彻底。我的做法是统一 chunk 策略入库时只切一次两路检索共用同一批 chunk 和同一套 ID。这样从源头消除了粒度不一致的问题。多花一点存储换来的是融合逻辑的干净。4. Rerank把召回得全变成排得准4.1 召回和排序是两个阶段别混为一谈混合检索解决的是召回问题——尽量把相关文档都捞进来哪怕顺序不完美。但捞进来之后前 10 条里可能混着几条不相关的直接喂给大模型会污染上下文。Rerank重排序解决的是排序问题。它的典型架构是混合检索先召回一个较大的候选集比如 top 50 到 100Rerank 模型对这 50 到 100 条逐一打分重新排序取 top 3 到 5 喂给大模型。为什么不能直接用 Rerank 做召回因为 Rerank 模型通常是 cross-encoder要把 query 和文档拼在一起过一遍模型计算量是 query 数乘以文档数。对全库做这个操作成本无法接受。所以它只能用在候选集上。4.2 Cross-encoder 和 Bi-encoder 的本质区别这是理解 Rerank 为什么准的关键。Bi-encoder就是普通的 embedding 模型query 和文档分别编码成向量然后算相似度。好处是文档可以离线编码好、建索引检索时只编码 query快。坏处是 query 和文档在编码时互相看不到交互信息丢失。Cross-encoderRerank 模型query 和文档拼在一起输入模型模型内部做完整的注意力交互。好处是精度高得多坏处是没法预计算每条 query-doc 对都要现算。打个比方Bi-encoder 像两个人各自写一份自我介绍然后比对两份介绍像不像Cross-encoder 像让两个人当面聊一次看聊不聊得来。后者当然更准但成本高只能对少数候选人做。4.3 Rerank 的收益到底有多大我在几个项目里做过对比混合检索 Rerank 相比纯混合检索top 3 的准确率通常能提升 15 到 30 个百分点。这个提升幅度取决于候选集大小候选集越大Rerank 能捞回的好文档越多但延迟也越高Rerank 模型质量不同模型差距明显原始召回质量如果召回阶段就没捞到相关文档Rerank 也变不出来。我的经验参数是候选集取 50Rerank 后取 top 5。候选集小于 30Rerank 的收益不明显大于 100延迟开始影响体验收益边际递减。4.4 Rerank 的延迟怎么控Rerank 是串行在检索链路上的延迟直接叠加到用户等待时间上。50 条候选的 cross-encoder 打分在 GPU 上通常几十毫秒CPU 上可能几百毫秒甚至更久。控延迟的几个手段候选集别贪大50 通常够用Rerank 模型选小的有些轻量 cross-encoder 精度损失不大但快很多批处理把 50 条拼成一个 batch 一次前向比逐条快得多异步预取如果业务允许可以在用户还在输入时就预跑一部分。注意如果你的场景对延迟极敏感比如要求 200ms 内返回Rerank 可能不适合放在主链路可以考虑降级为只在低置信度 query 上触发。5. Query 改写在检索之前先把问题问对5.1 用户的问题往往不是好的检索 query前面所有的优化都建立在query 是合理的这个假设上。但真实用户的 query 经常是口语化、有指代、缺上下文、多意图混杂。比如那个东西怎么弄、上次说的方案还有吗、A 和 B 哪个好顺便说下 C。这类 query 直接拿去检索效果必然差。Query 改写的目标就是把用户的话翻译成检索系统能听懂的话。5.2 几种主流改写策略的适用场景策略做什么适用场景代价指代消解把那个东西补全成具体实体多轮对话需要对话历史查询扩展补充同义词、相关词短 query、术语密集可能引入噪声查询分解把多意图 query 拆成多个子 query复合问题多次检索延迟增加HyDE先生成假设答案再用答案检索短 query、语义鸿沟大一次 LLM 调用多 query 生成生成多个改写版本分别检索后融合意图模糊多次检索5.3 HyDE 的原理和它的适用边界HyDEHypothetical Document Embeddings的思路很有意思用户问泵漏水怎么办直接拿这句话去检索可能和文档离心泵机械密封泄漏排查有语义鸿沟。但如果让 LLM 先生成一段假设性的答案——比如泵漏水通常需要检查机械密封步骤如下……——这段假设答案的用词和结构会更接近真实文档用它去检索命中率更高。原理上HyDE 是在做语义空间的对齐把 query 空间映射到 document 空间。但 HyDE 不是万能的它的边界很明确适合短 query、口语化 query、query 和文档表述差异大的场景不适合query 本身已经很精确比如就是文档标题、对延迟敏感、LLM 生成质量不稳定的场景风险如果 LLM 生成的假设答案跑偏了会把你带向错误的方向比不改写还差。我一般会先做 A/B同一批 query一半用原始 query 检索一半用 HyDE 检索对比 top 5 命中率。如果提升不明显就别上省一次 LLM 调用。5.4 多 query 生成 RRF一个被低估的组合比 HyDE 更稳的做法是多 query 生成让 LLM 把原始 query 改写成 3 到 5 个不同角度的版本每个版本各自检索最后用 RRF 融合。这个组合的好处是鲁棒单个改写版本可能跑偏但多个版本一起投票跑偏的那个会被稀释。而且它天然复用了前面讲的 RRF 融合逻辑架构上很统一。代价是检索次数翻倍延迟和成本都上升。我的做法是只在第一轮检索置信度低时才触发多 query——先正常检索如果 top 结果的分数普遍偏低再启动改写重检。这样大部分 query 走快路径只有难的 query 走慢路径。6. 把整条链路串起来一个可落地的配置6.1 完整链路和参数把前面所有环节串起来我实际用的链路是这样的用户 query → [可选] Query 改写指代消解 多 query 生成 → 混合检索 ├─ 稠密向量检索top 50 └─ BM25 检索top 50 → RRF 融合k60稳定 doc_id 去重 → 取 top 50 候选 → Rerankcross-encoder → 取 top 5 → 喂给大模型关键参数汇总环节参数我的取值说明向量检索top_k50召回要宽BM25top_k50与向量对齐RRFk60默认即可RRF去重键doc_id必须稳定Rerank候选集5030-100 之间Rerank输出top 5喂给 LLM6.2 分阶段上线别一次全上这套链路环节多一次性全上出了问题你都不知道是哪一环的锅。我的建议是分阶段第一阶段纯向量检索建立 baseline记录 top 5 命中率第二阶段加 BM25上 RRF 融合对比命中率变化第三阶段加 Rerank对比 top 3 准确率第四阶段加 Query 改写对比难 query 的表现。每个阶段都保留上一阶段的配置方便回滚和对比。我见过太多团队一次性上全套效果不好时完全无法定位。6.3 评估怎么做才靠谱没有评估所有优化都是玄学。我的做法是维护一个黄金测试集100 到 200 条真实 query每条标注好应该召回哪些文档。每次改动后跑一遍看 recall10、NDCG5、MRR 这几个指标。指标不用多三个够用Recall10相关文档有没有进前 10衡量召回能力NDCG5前 5 的排序质量衡量排序能力MRR第一个相关文档排多前衡量头部质量。黄金测试集要定期更新因为业务 query 分布会变。我一般每季度补充一批新 query淘汰过时的。7. 几个我踩过的坑和对应经验7.1 别在 RRF 之前做截断有人为了省事在两路检索各取 top 10 就融合结果融合后候选太少Rerank 没得选。RRF 的价值在于让两路充分投票你截断得太狠投票就不充分了。我的做法是两路各取 50融合后取 50给 Rerank 留足空间。7.2 Rerank 模型和 embedding 模型要匹配语言这个坑很隐蔽。如果你的语料是中文但 Rerank 模型是在英文语料上训练的效果会大打折扣。选型时一定要确认模型支持你的语料语言最好拿自己的数据实测一下。7.3 Query 改写不是越多越好我一开始贪心每个 query 生成 8 个改写版本结果延迟爆炸而且噪声也上来了。后来降到 3 到 5 个效果反而更稳。改写版本太多跑偏的概率也累积。7.4 监控线上 query 的分布变化检索质量下降很多时候不是模型的问题是业务 query 分布变了。比如新上了一批设备用户开始搜新型号而你的索引还没更新。我一般会监控 query 里的高频新词一旦发现索引覆盖不到就触发索引更新。7.5 缓存高频 query 的检索结果混合检索 Rerank Query 改写整条链路延迟不低。但真实业务里query 的重复率往往很高尤其是客服、运维场景。对高频 query 做结果缓存能显著降低平均延迟。缓存 key 用规范化后的 query注意别把不同用户的权限混在一起。8. 关于这套链路的一点个人体会这套组合拳打下来最大的感受是检索质量优化没有银弹每个环节都在补前一个环节的漏。混合检索补向量的漏Rerank 补召回的漏Query 改写补用户表达的漏。你不能指望某一环做到完美但每一环都做好一点整体就上去了。另一个体会是评估比优化更重要。我早期花大量时间调参但没有靠谱的评估调来调去都是凭感觉。后来把黄金测试集建起来才发现很多优化其实是负优化。所以如果你现在正准备做检索优化我的建议是先花两天把评估体系搭起来再动手改链路。最后说个具体的RRF 的去重缺陷这个问题值得你花十分钟去验证一下自己用的框架。方法很简单构造一个两路都能命中的文档手动算 RRF 分数和框架输出对比。对不上就自己实现一个融合函数代码不到 20 行比调任何参数都值。
