RAG 工程实战（四）：明明召回了正确知识，为什么最终 Top-K 还是漏了？

目录0. 一个容易被忽视的 RAG 检索问题1. 为什么不能只依赖向量相似度BM25 补充的是词法匹配能力2. RRF 融合两路都找到了为什么还可能漏3. Rerank为什么精排也不一定能救回来3.1 Rerank 无法处理没有传给它的 Chunk3.2 Rerank 的相关性评分也可能出错4. 真正排查时应该看哪些数据不要只记录最终 Top-K5. Top-N 和 Top-K 应该怎么选择6. 我的工程取舍最后Dense、BM25、RRF、Rerank每增加一个检索环节我们似乎都在努力提高准确率。但一个容易忽视的问题是正确知识可能早就被找到了却没能走到最后。0. 一个容易被忽视的 RAG 检索问题做 RAG 时我们很容易形成一种直觉只要知识库中存在正确答案并且向量检索成功召回了对应 Chunk后面的事情似乎就简单了。但实际上检索到正确知识不代表它一定会进入最终提供给 LLM 的上下文。举个例子。用户询问「EVM-RK3588 开发板如何开启 SSH 服务」知识库中存在多篇相关文档包括 RK3588、RK3568 等型号的说明以及 SSH 安装、连接、服务配置等内容。初始检索时包含正确操作步骤的 Chunk 已经被召回。但经过后续融合、排序和 Top-K 筛选最终留下的可能是几段高度相关、却不能直接回答问题的内容。于是我们需要追问正确知识究竟在哪一步被淘汰了这篇文章不讨论 LLM 已经看到正确证据却仍然回答错误的情况而是聚焦于检索阶段研究正确证据为什么没能进入最终 Top-K。以下以常见的 Dense BM25 RRF Rerank 混合检索架构为例展开分析并不代表每个 RAG 项目都包含这些模块。1. 为什么不能只依赖向量相似度向量检索的优势在于语义匹配。例如「怎样远程登录开发板」和「开发板 SSH 连接配置方法」虽然字面表达不同但语义接近Embedding 模型有机会把它们映射到相近的向量空间。但企业知识库中经常会出现另一类内容设备型号、接口名称、错误码、产品编号以及其他专有名词。比如EVM-RK3588RK3588RK3568这些名称可能拥有非常接近的上下文语义但它们并不是同一个型号。Embedding 能够帮助我们找到语义相近的内容却不保证严格区分所有字符级差异。这时候就需要引入关键词检索。BM25 补充的是词法匹配能力BM25 是经典的文本相关性评分算法它会综合词频、逆文档频率和文档长度等因素进行排序。对于设备型号、专有名词等场景BM25 可以与 Dense Retrieval 形成互补。但这里还要区分三个概念自定义词典负责改善分词效果让完整型号尽可能被正确识别。BM25负责根据匹配到的词项计算相关性分数。关键词 Boost则是在具体检索实现中对型号字段或精确匹配结果施加额外权重。它们可以配合使用但不是同一回事。因此一种常见方案就是Dense 负责语义召回BM25 负责词法召回然后将两路候选进行融合。2. RRF 融合两路都找到了为什么还可能漏Dense 和 BM25 返回的分数并不在同一个尺度上。直接将向量相似度和 BM25 分数相加通常缺乏合理依据。因此RRFReciprocal Rank Fusion成为一种常见的排名融合方案。其核心公式为RRF(d) Σ [1 / (k rank_r(d))]其中rank表示候选在某一路检索中的排名k是平滑常数常见示例取 60。RRF 不直接比较原始相似度而是根据不同检索列表中的排名为同一候选累加分数。一个候选如果在多路检索中都排名靠前通常会获得更大的融合优势。这看起来非常合理。但 RRF 衡量的是跨检索路径的排名共识并不是对业务事实正确性的验证。假设某条包含准确型号配置的 Chunk在 BM25 中排名很靠前但 Dense 没有召回它。另一条泛化的 SSH 使用说明同时在 Dense 和 BM25 中获得较高排名。融合之后后者就有可能排在正确证据前面。这并不意味着 RRF 算错了。而是我们必须认识到两路检索都认为某段内容相关不代表它就是最能回答用户问题的证据。不过仅仅排名下降还不等于证据丢失。真正关键的是下一步RRF 融合完成后系统通常只保留前 N 个候选。如果正确 Chunk 排在第 N1 名那么它就没有机会进入后续 Rerank。这才是第一个需要重点关注的候选淘汰节点。3. Rerank为什么精排也不一定能救回来为了进一步提高检索质量很多系统会在融合召回之后增加 Rerank。典型流程是Dense Top-M BM25 Top-M \ / \ / RRF ↓ 候选 Top-N ↓ Rerank(Query, Chunks) ↓ 最终 Top-K ↓ LLM与初始向量召回不同Reranker 通常会结合用户 Query 和候选 Chunk 的具体文本重新评估两者的相关性。它有机会纠正前面排序不合理的问题。但有两个限制。3.1 Rerank 无法处理没有传给它的 Chunk假设正确 Chunk 在 RRF 融合后排名第 12但系统只保留 Top-10 进入 Rerank。那么无论 Reranker 多强都不可能把它重新排回来。因为它从未见过这条证据。这也说明Rerank 的效果不仅取决于模型本身还取决于前一阶段提供的候选集合。3.2 Rerank 的相关性评分也可能出错即使正确 Chunk 进入了 Rerank也不代表它一定排名第一。例如用户询问 RK3588 的具体配置但候选中同时出现了大量 RK3568 的相似操作说明。Reranker 是否能够正确识别型号差异需要结合实际模型与测试数据验证。如果它将正确 Chunk 排到最终 Top-K 之外正确证据依旧无法进入 LLM。因此我认为需要区分两件事排序变化正确证据的名次下降但仍留在候选集合中。候选淘汰排序后执行 Top-N 或 Top-K 截取正确证据被真正排除。前者不一定造成最终问题后者才会让下游失去使用这条证据的机会。4. 真正排查时应该看哪些数据当最终 Top-K 缺少正确证据时我认为不应该第一时间去修改 RRF 参数或更换 Rerank 模型。应该先定位正确证据第一次消失的位置。我们可以为同一次 Query 记录各阶段的 Chunk ID 和排名。例如下面这组构造数据检索阶段正确 Chunk C 的情况Dense 召回未命中BM25 召回第 2 名RRF 融合第 7 名RRF Top-NN10成功保留Rerank第 6 名最终 Top-KK5被淘汰以上仅为说明排查方法的假设案例并非真实项目日志。通过这条记录可以得到几个明确结论首先Dense 没有召回正确 Chunk但 BM25 弥补了这一不足。其次RRF 虽然改变了它的排名但并没有直接导致最终丢失。最后正确证据进入了精排候选集合却在 Rerank 后的 Top-K 筛选中被淘汰。这样我们至少知道应该从哪里开始分析而不是笼统地说“RAG 检索效果不好”。不要只记录最终 Top-K如果只记录最终返回给 LLM 的五个 Chunk实际上很难判断是哪一步出现了问题。我更建议记录Dense / BM25 各自的候选 ID 与原始排名。RRF 融合后的候选排名。进入 Rerank 的 Top-N 集合。Rerank 后的排名及最终 Top-K。每一步的执行耗时。这些记录最好使用稳定的 Chunk ID 关联避免仅凭文本或局部排名判断是否属于同一条证据。对于已经人工标注正确证据的测试问题还可以统计不同阶段的证据保留情况。例如正确证据保留率S 最终 Top-K 保留正确证据的问题数÷ 初始候选集合包含正确证据的问题数 × 100%这里的 S 是为了分析检索链路而定义的条件保留率不是一个必须采用的行业标准指标。它能够帮助我们区分到底是最初没有召回正确知识还是召回成功后又被淘汰5. Top-N 和 Top-K 应该怎么选择这可能是实际工程中最需要权衡的问题。RRF 后保留的 Top-N 太小意味着较多候选可能提前被淘汰Reranker 的纠错空间有限。但 Top-N 过大又会增加精排计算量和请求延迟。同样最终 Top-K 太小可能遗漏必要证据太大则可能引入更多噪声和 Token 成本。因此不能简单认为把 Top-N、Top-K 全部调大就能解决问题。我认为更合理的方法是设计一组对照实验。例如固定知识库和测试问题对比方案检索链路ADense → Top-KBBM25 → Top-KCDense BM25 → RRF → Top-KDDense BM25 → RRF Top-N → Rerank Top-K测试问题可以覆盖三类场景普通语义问题用户表达与文档原文存在较大差异。精确关键词问题包含设备型号、错误码、接口名称等信息。多证据问题需要多个 Chunk 共同提供完整答案。重点观察三个指标正确证据是否进入最终 Top-K。正确证据在哪一阶段第一次被淘汰。不同方案带来的检索耗时与精排开销。另外还可以固定最终 K调整 RRF 输出的 N观察更多候选是否真的提高了最终证据覆盖率。这里需要强调Rerank 不一定在所有数据集上都优于 RRFBM25 也不一定在所有型号查询中都能正确召回。真正的效果应该通过具体知识库和测试问题验证。6. 我的工程取舍经过这轮分析我更倾向于按照问题发生的阶段进行优化而不是盲目叠加检索算法。如果初始候选就缺少正确证据应该优先检查语义召回、BM25 分词、精确型号匹配以及各路召回数量。如果正确证据在 RRF Top-N 时被淘汰应该分析融合排名和候选规模而不是直接责怪 Reranker。如果正确证据进入精排却没进入最终 Top-K才重点评估 Rerank 模型、输入内容和最终 K 的选择。另外对于设备型号、版本号等明确约束我更倾向于在适当场景下结合结构化字段或精确匹配过滤而不是把一切都交给向量相似度或 Rerank 模型判断。归根结底每个检索环节解决的问题不同优化之前必须先找到真正的瓶颈。最后RAG 的检索质量不应该只看某一路是否召回了正确 Chunk也不应该单纯相信“多加一个 Rerank 就会更准确”。从 Dense、BM25 到 RRF再到 Rerank整条链路实际上在不断调整候选的排名并逐步缩小候选范围。真正需要关注的是能回答用户问题的正确证据是否最终进入了提供给 LLM 的 Top-K。对我来说这也是多阶段检索最值得关注的工程细节召回决定系统有没有机会找到答案而后续融合、精排与候选截取决定这份证据能不能最终被使用。至于正确证据已经完整进入 Prompt但大模型仍然回答错误那又是另一个值得单独讨论的问题了。参考资料MicrosoftHybrid Search OverviewElasticReciprocal Rank FusionCohereRerank 模型工作原理