RAG 在线部分：检索优化 —— 多路召回与结果融合 · devcfg

1. 引言：单一路由不够用，多路召回如何解决检索“偏科”问题？

在RAG（检索增强生成）系统上线后，是否遇到过这样的场景：用户问“高血压患者如何调整饮食？”，系统却返回了一篇关于“如何制作低脂沙拉”的文章。你可能会下意识地责怪大模型，但更多时候，问题的根源在于检索这个环节出现了“偏科”现象。

想象一下，你的知识库就是一座庞大的图书馆，而传统的单一检索方式就像是只雇佣了一位只会一种查找方式的图书管理员。他要么只会看图书的标题（基于关键词的稀疏检索，如BM25），要么只会感知语义上的“感觉”（基于向量的稠密检索）。当用户的需求触及到他能力之外的领域时，他给出的结果自然也就跑偏了。

• 稠密检索（Dense Retrieval） 的“偏科”：它擅长捕捉语义相似性，能理解“高血压的饮食建议”和“低钠饮食可降低血压”是相关的。但它对精确的关键词匹配不敏感，比如用户想找一份名为“高血压指南_2024.pdf”的文档，它可能因为“2024”这个关键词权重不高而将其排在后面。更糟的是，当用户提出一个全新的、在语料库中没有高度相似表述的查询时，稠密检索的表现会急剧下降，这就是所谓的领域外泛化问题。

• 稀疏检索（Sparse Retrieval） 的“偏科”：它像一个严格的文字匹配器，对“高血压”、“饮食”这类关键词的匹配精准无比。但它完全忽略了语义，无法理解“高钠摄入”与“血压升高”之间的逻辑关系。所以，当用户问“如何改善心血管健康状况？”，它可能无法关联到“低盐饮食”的相关文档。

正是单一检索策略的这些固有缺陷，催生了 RAG多路召回策略 的概念。其核心思想非常朴素：不要把所有鸡蛋放在一个篮子里。我们同时雇佣多个“各有所长”的图书管理员，让他们分别从不同角度（语义、关键词、假设文档、知识图谱等）查找，然后将他们找到的结果进行融合与筛选，最终得到一个更全面、更准确的结果集。

这就像是法庭上的“证据融合”：单一的目击证人口供可能有误，但结合了物证、书证、电子数据等多重证据链后，案件的真相就会更加清晰且可靠。多路召回与结果融合，正是为了构建这条通往高精度检索的“多重证据链”。

在本文中，你将不再是只能使用单一检索工具的开发者。你将系统性地掌握：

1. 深刻理解：为什么单一检索（稠密或稀疏）总是“偏科”，以及多路召回如何通过“协同作战”解决这个问题。

2. 核心算法：彻底搞懂结果融合的明星算法——RRF（倒数排名融合），理解它为何能如此巧妙地平衡不同召回源的排名置信度。

3. 实战代码：掌握如何用Python实现一个完整的、可工作的多路召回与RRF融合模块，并附带你关心的去重与排序细节。

4. 进阶调优：学会如何针对不同业务场景调整融合策略，包括权重分配、参数调优以及二次重排，让你的RAG系统更加智能。

准备好开始这场检索优化的实战之旅吧，本文将带你彻底告别检索“偏科”的烦恼，迈向 RAG知识库召回率提升的新阶段。

2. 核心概念：什么是多路召回与结果融合？

要理解RAG多路召回策略，我们首先要将其拆解为两个核心动作：多路召回 和 结果融合。

2.1 多路召回：从“单打独斗”到“多方围剿”

多路召回的核心定义是：在RAG系统的在线检索阶段，不是仅使用一种检索策略，而是同时并行地启动多个、从不同角度出发的检索引擎，每个引擎都独立地检索整个知识库，并各自产出一份候选文档列表。

这些“路”可以包括但不限于：

1. 稠密向量检索（Dense Retrieval）：这是最主流的方式。系统会使用强大的Embedding模型（如 bge-large、text-embedding-ada-002），将用户的查询和知识库中的所有文档片段都转换为高维向量。然后通过向量数据库（如FAISS、Milvus）进行相似度（如余弦相似度）计算，找到在语义空间上最接近的Top-K个文档。

它的优势在于能理解同义、近义等复杂语义关系。

2. 稀疏向量检索（Sparse Retrieval）：这是传统信息检索的扛把子，最著名的代表就是BM25算法。它基于词频（TF）和逆文档频率（IDF）计算查询和文档的匹配度。它的优势在于对精确关键词的匹配极其敏感，并且几乎不需要任何预训练模型，部署成本低，在小众、专有名词领域表现稳定。稠密稀疏向量融合召回正是希望结合二者之长，让检索既懂语义又懂关键词。

3. HyDE（假设文档嵌入）：这是一种非常巧妙的策略。它不是直接用用户的查询去检索，而是先让大模型（LLM）根据用户的查询，生成一个假设的、最符合用户意图的理想文档。然后，系统再对这个“虚构”的文档进行向量化，并用它去知识库中检索真实的文档。这个“中间人”策略能有效弥合用户简短查询与复杂文档之间的语义鸿沟。

4. 基于知识图谱的图检索（Graph Retrieval）：如果你的知识库已经被构建成了知识图谱（记录了实体之间的关系，如“《高血压指南》-【作者】-【张三】”），那么你可以利用图数据库进行多跳推理。例如，查询“张三写的关于高血压的书”，图检索可以沿着“张三” -> “作者” -> “高血压指南”的路径，精准找到目标。这在需要上下文或关系推理的场景中非常有效。

提示：多路召回并不是越多越好。在选择召回路径时，需要权衡计算成本和收益。对于大多数通用场景，“稠密 + 稀疏”两路组合通常就能带来显著的 RAG知识库召回率提升。对于专业领域或需要复杂推理的场景，再加入HyDE或图检索会更合适。

2.2 结果融合：从“众说纷纭”到“达成共识”

当我们并行地派出了多位“侦探”，他们各自带回了一些“嫌疑文档”（候选结果）后，问题就来了：谁的结果更可信？ 他们可能都指向了同一个目标，也可能给出了截然不同的排名。结果融合正是为了解决这个问题而生的。

结果融合的目标是：将多个异构的、可能相互矛盾或重叠的候选列表，整合成一个单一、高质量、且排好序的最终结果列表。这个过程需要解决几个关键问题：

1. 去重：这是前提。不同的召回路径很可能检索到同一篇文档。例如，关于“低钠饮食可降低血压”的片段，稠密检索和稀疏检索都可能命中。如果不进行去重，这段内容会被重复计入最终结果，不仅浪费了大模型宝贵的上下文窗口（Token），还会导致回答偏离重点。这就是我们常说的 多路召回去重方法。

2. 归一化与对齐：不同检索策略产出的分数（Score）通常是不可比的。稠密检索的输出可能是余弦相似度（0到1），而BM25的输出可能是几十甚至几百的整数。我们不能直接将这些分数相加或平均，因为它们不在同一个“计量单位”上。融合算法的核心任务之一，就是将这些来自不同标尺的分数，映射到一个可统一比较的、无差异的排名体系中。

3. 排序与加权：在去重和对齐后，我们需要决定如何对这些候选文档进行最终排序。这就像让多位评委给参赛者打分，我们需要一个科学的、公平的计分规则。常见的融合算法包括：

   • 加权得分融合：对每一个融合结果，计算其在各个召回路径中的得分加权和。例如：最终得分 = 0.7 * 归一化的稠密得分 + 0.3 * 归一化的稀疏得分。

这种方法需要人工确定权重，比较依赖经验。
- 基于排序的融合：这类算法不关心原始分数，只关心文档在每个召回路径中的排名位置。其中，最著名的无疑是我们将要重点讲解的RRF（倒数排名融合）算法。它的鲁棒性极高，不需要调参，是工程中的首选。

总而言之，多路召回保证了检索的“广度”和“召回率”，而结果融合则保证了检索的“精度”和“相关性”。两者相辅相成，共同构成了一个更强大的RAG检索优化方案。

3. 常见多路召回策略一览

在深入代码之前，我们有必要像“武器库”一样，盘点一下几种最常见的召回策略，了解它们的适用场景和优缺点，这样我们在实战中才能做到“心中有数，手中有招”。

召回策略	原理简述	核心优势	核心劣势	适用场景
稠密向量检索	将查询和文档映射到高维语义空间进行相似度计算。	理解语义、同义词、近义词；泛化能力强。	对关键词不敏感；需要高质量Embedding模型；在小样本、罕见实体上效果可能不佳。

| 通用场景、开放域问答、对语义理解要求高的任务。 |
| 稀疏向量检索(BM25) | 基于词频（TF）和逆文档频率（IDF）的经典统计模型。 | 精确匹配关键词；索引构建简单、计算快；对专有名词效果好。 | 无法理解语义；不会匹配同义词；对查询非常敏感。 | 专有名词检索、精确匹配、作为稠密检索的有效补充。

|
| HyDE | 先用LLM生成一个“假设文档”，再用它去检索。 | 能弥合简短查询与复杂文档之间的语义鸿沟；提升零样本检索能力。 | 依赖LLM的生成质量；会引入额外的LLM调用成本；可能产生幻觉。 | 查询意图模糊、需要上下文理解、领域外检索。 |
| 图检索(GraphRAG) | 在知识图谱上进行路径搜索和多跳推理。

| 能处理复杂的、依赖实体关系的查询；能挖掘出深层、跨文档的关联。 | 需要预先构建知识图谱，成本高；查询灵活性不如向量搜索。 | 需要多步推理、推荐、相关性分析、问答涉及复杂实体关系的场景。 |

最佳实践：对于初创或资源有限的团队，我强烈建议从“稠密 + 稀疏”这两路开始。这是性价比最高的组合，能解决80%以上的检索问题。你可以使用 LangChain 或 LlamaIndex 等框架，它们已经内置了常用的检索器和融合器。

4. 结果融合的核心算法：RRF（倒数排名融合）

在众多融合算法中，RRF（Reciprocal Rank Fusion）以其简洁、高效和无需训练的特性，成为了工业界的“万金油”。它不依赖于不同检索器产出的分数，只依赖于排名，这使得它天然就能处理不同检索器之间分数不可比的问题。

4.1 RRF的原理与公式

RRF的公式非常优美且直观：

$$Score_{RRF}(d) = \sum_{r \in R} \frac{1}{k + rank_r(d)}$$

让我们来拆解这个公式：

• **d**：我们正在评估的一个候选文档。

• **R**：所有召回路径的集合。例如，R = {稠密检索, 稀疏检索, HyDE}。

• **rank_r(d)**：文档 d 在召回路径 r 中的排名。注意，排名是从1开始的。如果文档 d 没有被召回路径 r 检索到，则我们忽略这一项。

• **k**：这是一个常数，通常设为 60。它的作用是防止某个召回路径中排名极高的文档获得过大的分数。想象一下，如果 k=0，那么排名第一的文档将获得分数 1/1 = 1，而排名第二的文档将获得 1/2 = 0.5，差距过大。加入 k 后，排名第一的文档获得 1/(60+1) ≈ 0.016，排名第二的获得 1/(60+2) ≈ 0.016，差距被大幅缩小且变得平滑。

k 值越大，不同排名之间的分数差异就越小，融合结果越倾向于“平均”；k 值越小，高排名文档的影响力就越大。工程上，k=60 是一个经过大量实践验证的、表现非常稳健的起点。

举个例子：
假设有两个召回路径：稠密检索（D）和稀疏检索（S）。它们分别返回了以下结果（括号内是排名）：

• D: doc1(1), doc2(2), doc3(3)
• S: doc2(1), doc1(4), doc4(5)

现在，我们计算每个文档的RRF得分（假设 k=60）：

• doc1：在D中排名1，分数 = 1/(60+1) ≈ 0.0164；在S中排名4，分数 = 1/(60+4) ≈ 0.0156。总分为：0.0164 + 0.0156 = 0.0320。
• doc2：在D中排名2，分数 = 1/(60+2) ≈ 0.0161；在S中排名1，分数 = 1/(60+1) ≈ 0.0164。

总分为：0.0161 + 0.0164 = 0.0325。

• doc3：只在D中出现，排名3，分数 = 1/(60+3) ≈ 0.0159。总分为：0.0159。
• doc4：只在S中出现，排名5，分数 = 1/(60+5) ≈ 0.0154。总分为：0.0154。

最终排序结果：**doc2 (0.0325) > doc1 (0.0320) > doc3 (0.0159) > doc4 (0.0154)**。

从这个例子可以看出，doc1 虽然在稠密检索中排第一，但它在稀疏检索中只排第四。而 doc2 在两个检索器中的排名都很好（第2和第1），所以它的总分超过了doc1。RRF算法通过这种巧妙的机制，自动为那些被多个检索器都“认可”的文档赋予了更高的权重，这比任何人工设定权重都要稳健。

4.2 RRF与去重的天然关联

RRF的另一个巨大优势在于它的去重能力。仔细看RRF的公式，它是对文档 d 进行操作的。当我们在计算 doc2 的得分时，我们只计算了一次，只是将其在两个召回列表中的排名都贡献给了它。

这实际上就已经完成了多路召回去重方法中最重要的一步：按文档ID进行合并。我们在代码实现中，可以使用一个字典，以 doc_id 作为键，在处理每条召回列表时，都去更新这个字典中对应 doc_id 的RRF得分。最终，一个 doc_id 只对应一个总分，自然而然地就实现了去重。

4.3 加权RRF：当某些召回路径更可信时

虽然标准RRF对每个召回路径一视同仁，但在某些情况下，我们可能认为某个召回路径比其他路径更可靠。例如，在你精心调优了知识库数据质量后，你可能希望给稠密检索更高的权重。

这时，可以通过引入一个权重向量来扩展RRF公式：

$$Score_{weightedRRF}(d) = \sum_{r \in R} \frac{w_r}{k + rank_r(d)}$$

其中 w_r 是召回路径 r 的权重。比如，你可以设置 w_稠密 = 1.5，w_稀疏 = 1.0。这样，稠密检索中排名高的文档，它的分数优势就会被放大。这种方法通常被称为 混合检索权重排序。在实际调优中，权重值通常通过网格搜索（Grid Search）在一个小型的验证集上找到最佳组合。

注意: 加权RRF虽然更灵活，但也引入了新的超参数（权重），这增加了调优的难度。如果没有明确的业务偏好或评估数据支撑，使用标准的、不加权的RRF是更安全、更推荐的默认选择。

5. 实战代码：实现多路召回与RRF融合

纸上得来终觉浅，绝知此事要躬行。下面，我们就用Python来实现一个完整的RAG检索优化实战，将我们刚才学到的所有概念串联起来。

5.1 模拟数据

为了专注演示融合逻辑，我们首先模拟两个召回路径的结果：一个代表稠密检索，一个代表稀疏检索。

import json
from typing import List, Dict

# --- 1. 模拟多路召回数据 ---
# 假设每个结果是一个字典，包含: doc_id, score, text
sparse_results = [
    {"doc_id": "doc1", "score": 0.85, "text": "高血压患者饮食建议"},
    {"doc_id": "doc2", "score": 0.72, "text": "低钠饮食可降低血压"},
    {"doc_id": "doc3", "score": 0.60, "text": "高血压注意事项"}
]
dense_results = [
    {"doc_id": "doc2", "score": 0.91, "text": "低钠饮食可降低血压"},
    {"doc_id": "doc4", "score": 0.80, "text": "高血压运动指南"},
    {"doc_id": "doc1", "score": 0.75, "text": "高血压患者饮食建议"}
]

代码解释：

• sparse_results 代表稀疏检索（如BM25）输出的结果，按分数降序排列。
• dense_results 代表稠密检索（如向量相似度）输出的结果，按分数降序排列。
• 注意，doc1 和 doc2 同时出现在了两个结果中，这正是我们需要处理的情况。

5.2 RRF融合核心函数

接下来，我们将实现RRF融合的核心逻辑。

# --- 2. 实现RRF融合函数 ---
def rrf_fuse(lists: List[List[Dict]], k: int = 60) -> List[Dict]:
    """
    使用倒数排名融合(RRF)算法对多个召回结果进行融合。

    Args:
        lists: 一个列表，包含多个召回路径的结果列表。
              每个结果列表是字典的列表，每个字典必须有'doc_id'和'text'字段。
        k: RRF公式中的常数k，默认60。

    Returns:
        按RRF得分降序排列的、已去重的文档列表。
    """
    # 用于存储最终结果的字典，key是doc_id，value是包含doc_id, text, rrf_score的字典
    rank_map = {}

# 遍历每一个召回路径
    for lst in lists:
        # 关键: 对当前召回路径的结果，按score降序排列，并分配rank
        # rank从1开始，这是RRF公式的核心输入
        sorted_lst = sorted(lst, key=lambda x: x["score"], reverse=True)
        for rank, item in enumerate(sorted_lst, start=1):
            doc_id = item["doc_id"]
            # 如果这个doc_id第一次出现，则初始化它的信息
            if doc_id not in rank_map:
                rank_map[doc_id] = {"doc_id": doc_id, "text": item["text"], "rrf_score": 0}
            
            # 将当前rank的RRF贡献累加到该文档的得分上
            rank_map[doc_id]["rrf_score"] += 1.0 / (k + rank)

    # 将字典转换为列表，并按照rrf_score降序排序
    fused_results = sorted(rank_map.values(), key=lambda x: x["rrf_score"], reverse=True)
    return fused_results

# 调用RRF融合
fused_results = rrf_fuse([sparse_results, dense_results])

关键代码逐行解析：

1. def rrf_fuse(lists, k=60): 函数定义。k 参数的可调整性是我们调优的关键。

2. rank_map = {}: 创建一个空字典作为“主表”，用于存储每个文档的RRF得分。这是实现多路召回去重方法的核心数据结构。

3. for lst in lists: 外层循环，处理每个召回路径的结果。

4. sorted_lst = sorted(lst, key=lambda x: x["score"], reverse=True): 重要性第一。 在计算RRF之前，我们必须对每个召回路径的结果按照其原始得分进行排序。这个排序过程是计算rank的基础。如果原始列表已经是排序好的，这一步可以省略，但为了保险，我们总是显式排序。

5. for rank, item in enumerate(sorted_lst, start=1): 分配排名（rank）。enumerate 的 start=1 参数确保了排名从1开始。

6. if doc_id not in rank_map: 这是去重逻辑。如果 doc_id 不存在，就创建一个新的条目。

如果存在（比如 doc1 在稀疏和稠密中都有），我们就不创建新的，而是直接累加后面的 rrf_score。
7. rank_map[doc_id]["rrf_score"] += 1.0 / (k + rank): 累加RRF得分。这是公式的核心计算。
8. fused_results = sorted(rank_map.values(), ...): 最后，将字典的 values() 取出来，转成列表，并按最终累积的 rrf_score 进行降序排序。

5.3 输出结果

# --- 3. 打印并分析融合结果 ---
print("融合后排序结果（已去重）：")
for item in fused_results:
    print(f"  doc_id: {item['doc_id']}, rrf_score: {item['rrf_score']:.4f}, text: {item['text']}")

预期输出：

融合后排序结果（已去重）：
  doc_id: doc2, rrf_score: 0.0325, text: 低钠饮食可降低血压
  doc_id: doc1, rrf_score: 0.0320, text: 高血压患者饮食建议
  doc_id: doc3, rrf_score: 0.0159, text: 高血压注意事项
  doc_id: doc4, rrf_score: 0.0154, text: 高血压运动指南

分析：

1. 去重成功：doc1 和 doc2 在结果中只出现了一次，它们在两个召回列表中的得分已经被正确融合。
2. 排序合理：doc2 在两个召回列表中的排名都很高（第1和第2），因此其 rrf_score 最高。doc1 虽然在一个列表中排第一，但在另一个列表中只排第四，所以评分略低于 doc2。

doc3 和 doc4 都只在一个列表中出现，分数相应较低。

提示：当你在 rank_map 中遇到重复 doc_id 时，我们只从第一次出现的记录中提取了 text 字段。在实际系统中，你可能需要确保来自不同召回路径的“相同文档”的 text 字段是一致的。可以使用统一的文档ID系统和预处理步骤来保证这一点，避免因为文本不一致导致模型困惑。

6. 进阶技巧：稠密稀疏向量融合召回调优

你已经掌握了多路召回与RRF融合的核心方法。现在，我们来聊聊如何让它变得更好用、更聪明。这部分是资深开发者与初级工程师的分水岭。

6.1 动态权重分配：不再是“一刀切”

在前面的加权RRF中，你可能会想：“有没有办法不人工设定权重，而是让系统根据查询类型自动选择？” 这就是动态权重的思想。

例如，对一个研究型查询“Transformer模型的演进历史”，你可能希望稠密检索的权重更高，因为它能捕捉到“演进历史”这种抽象概念。但，对一个工具查询“2024款小鹏G9的充电接口规格”，则应该大幅提高稀疏检索（BM25）的权重，因为“2024款”、“小鹏G9”、“充电接口规格”这些关键词才是核心。

实现思路：

1. 查询分类：用一个轻量级的分类器（如基于规则的、或用一个小模型）来判断查询的类型。例如，判断查询中是否包含年份、型号、价格等特定领域词汇。
2. 权重分配：根据分类结果，动态地为不同召回路径分配权重。

   # 伪代码示例
   def dynamic_weights(query):
       if any(word in query for word in ["2024", "型号", "规格", "价格"]):
           return {"sparse": 0.8, "dense": 0.2}
       else:
           return {"sparse": 0.3, "dense": 0.7}

3. 应用：在计算加权RRF时，使用动态获取的权重。

6.2 二次重排：用交叉编码器做最后把关

RRF虽然好，但它本质上是基于排名的“快速”融合，并没有重新评估文档与查询的精确相关性。即使是融合后的Top-K结果，里面可能依然有一些相关性不高的文档。

方案： 使用一个更精确、但计算量更大的交叉编码器（Cross-Encoder） 对RRF融合后的Top-N（如前50个）结果进行精细重排（Re-ranking）。交叉编码器不像双编码器（Bi-Encoder，即稠密检索用的模型）那样将查询和文档分别编码，而是将它们作为一个整体输入模型，直接计算它们之间的相关性分数。这个分数更准，但速度慢，所以只能对少量候选结果做。

流程：
用户查询 -> [多路召回 -> RRF融合] -> 获得Top-50候选 -> [交叉编码器重排] -> 输出Top-10最终结果

这被称为 多路召回结果重排 的经典两阶段范式。第一级用高效的方法（稠密+稀疏+RRF）快速过滤出候选，第二级用精确但昂贵的方法（交叉编码器）进行精排。

实战库推荐：你可以使用 sentence-transformers 库中的交叉编码器模型，如 cross-encoder/ms-marco-MiniLM-L-6-v2。

6.3 调优RRF的 k 值

k 值的调优是优化RRF最常见的工作。我们可以通过一个简单的网格搜索来找到最优的 k。

# 在验证集上测试不同k值的效果
best_k = None
best_score = -1

for k_value in [30, 60, 100, 200]:  # k的候选值
    # ... 在这部分，用你的RAG系统对验证集进行检索 ...
    # 计算在k_value下的Recall或NDCG等指标
    # current_score = evaluate_with_k(your_system, k=k_value)
    # if current_score > best_score:
    #     best_score = current_score
    #     best_k = k_value

print(f"最佳k值为: {best_k}")

一般来说，k 值在 30-100 之间表现都还不错。k 值越小，越强调排名靠前的文档；k 值越大，越“平均主义”，更强调文档被多少召回路径检索到。

7. 踩坑记录：去重、重复文档与计算开销的实战陷阱

再好的理论，在落地时都可能遇到各种“意外”。下面这些是我在实际项目中踩过的坑，希望你能绕开。

7.1 踩坑一：文档ID不一致导致的去重失败

问题：你构建了稠密检索（使用bge-large）和稀疏检索（使用Elasticsearch或meili）。在产生结果时，稠密检索返回的文档ID是数据库的自增ID（如 123），而稀疏检索返回的文档ID是Elasticsearch内部生成的ID（如 a1b2c3d4）。虽然在知识库里它们对应的是同一篇文档，但在 rank_map 中，它们被认为是两个不同的文档，导致去重失败，同一篇内容被输出了两次。

解决方案：统一文档ID。在构建知识库索引时，无论是稠密向量库还是稀疏检索库，都使用同一个、全局唯一的文档ID（如原始PDF文件名的哈希 + 段落序号）。

7.2 踩坑二：丢失血缘关系，合并后文段无法形成完整内容

问题：某篇文档被切成了多个片段（chunk）。召回时，稠密检索命中了片段A，稀疏检索命中了片段B。在RRF融合时，它们被当作两个独立的、不相关的文档进行去重和排序。最终，大模型可能只收到了片段A或片段B中的某一个，由于缺乏上下文，无法给出完整、准确的回答。

解决方案：在融合阶段，除了 doc_id，还需要保留其父文档ID。我们可以在去重的同时进行血缘合并：如果发现多个片段属于同一个父文档，我们可以将它们拼接成一个更长的段落，或者至少将它们的原始位置标记给大模型，让大模型知道它们属于同一个源。这可以通过在 rank_map 的条目中增加一个 parent_doc_texts 列表来实现。

7.3 踩坑三：大规模召回时的排序计算瓶颈

问题：当你的召回路径多、且每个路径都返回大量的候选结果（如Top-2000）时，对所有文档进行RRF排序的CPU和内存消耗会显著上升，甚至可能拖垮服务的响应时间。

解决方案：剪枝（Pruning） 或 二阶段召回。不会直接对每个召回路径的Top-2000进行融合。我们可以先对每个召回路径只取Top-K（比如Top-100），然后用RRF融合这些结果。如果你担心丢失一些被其他召回路径遗漏的重要文档，可以再取Top-2000结果中的后100条，与Top-100结果一起进行第二轮融合。这本质上是牺牲了一点精准度来换取更快速度。

8. 总结与拓展：从多路融合到智能路由的演进

经过本文的深入探讨，你已经掌握了RAG在线检索优化的核心秘密武器：多路召回与结果融合。

让我们回顾一下核心要点：

1. 核心思想：用多种策略（稠密、稀疏、HyDE、图检索等）并行检索，弥补单一策略的“偏科”问题，显著提升 RAG知识库召回率提升。

2. 核心算法：RRF（倒数排名融合） 是一种无需训练、鲁棒性极强的“去中心化”融合策略，它通过融合排名而非分数，天然解决了分数不可比的问题，并完美支持去重。

3. 核心实践：我们从模拟数据到完整代码，实现了基于RRF的融合，并强调了 rank 分配和 rank_map 在去重中的关键作用。

4. 核心调优：动态权重分配、引入交叉编码器的二次重排（多路召回结果重排）、以及 k 值的网格搜索，是将你的融合系统推向极致的进阶技巧。

5. 核心陷阱：统一文档ID、维护血缘关系、以及通过剪枝控制计算开销，

总结

通过本文的学习，相信你已经对「RAG多路召回策略」有了更深入的理解。建议结合实际项目多加练习。如有疑问，欢迎交流！