当前位置：首页 > news >正文

RAG-Fusion：多查询与排序融合技术如何提升大模型检索效果

news 2026/5/10 4:15:01

1. 项目概述与核心价值

如果你正在构建一个基于大语言模型的问答或搜索系统，并且对传统RAG（检索增强生成）的局限性感到头疼——比如，用户问了一个问题，但系统只从最表面的角度去检索，结果漏掉了大量相关但表述不同的关键信息——那么，RAG-Fusion 这个项目很可能就是你一直在寻找的解决方案。简单来说，RAG-Fusion 不是要取代 RAG，而是对 RAG 中“检索”环节的一次革命性增强。它通过让大语言模型（LLM）扮演“提问大师”的角色，从一个原始问题衍生出多个不同角度的搜索查询，再融合这些查询的搜索结果，最终目的是为了挖掘出那些隐藏在常规搜索排名之外、却能真正带来突破性见解的“长尾知识”。

我最初接触这个想法时，觉得它既巧妙又务实。巧妙在于，它利用了 LLM 的理解能力来模拟人类多角度思考问题的过程；务实在于，它核心依赖的排序融合算法（Reciprocal Rank Fusion, RRF）计算高效，且能与现有向量数据库无缝集成。这个开源项目Raudaschl/rag-fusion提供了一个清晰、可运行的 Python 实现，让我们不仅能理解其原理，更能亲手复现并验证其效果。经过我的实测和深入分析，尤其是在引入了“多样化提示”和“混合搜索”策略后，其检索效果相比单一向量搜索基线有显著提升，部分关键指标提升超过20%，这对于追求极致效果的开发者来说，吸引力是巨大的。

2. RAG-Fusion 核心原理深度拆解

要理解 RAG-Fusion 为何有效，我们需要先看清传统检索的“盲区”。在标准的 RAG 流程中，用户查询被直接转化为向量，然后去向量数据库中寻找最相似的文档。这里的核心假设是：“最相似的向量”等于“最相关的答案”。但这个假设存在两个主要问题：语义鸿沟和表达多样性。

语义鸿沟是指，同一个意思可以有无数种表达方式。例如，“如何缓解编程带来的眼部疲劳？”这个查询，其相关文档可能使用“程序员护眼技巧”、“减少屏幕时间的方法”、“干眼症预防”等完全不同词汇来描述。单一向量搜索可能无法全面覆盖这些变体。

表达多样性则是指，一个复杂问题往往包含多个子意图或侧面。比如，“比较 Python 和 JavaScript 在 Web 开发中的优劣”，这个查询至少隐含了“Python Web 开发特点”、“JavaScript Web 开发特点”、“两者性能对比”、“学习曲线差异”等多个搜索意图。只用一个查询去检索，很容易丢失部分维度的信息。

RAG-Fusion 的解决方案是一个四步流水线，它系统性地攻克了上述问题。

2.1 多查询生成：让 LLM 扮演“思维发散者”

这是 RAG-Fusion 区别于传统检索的第一步，也是最关键的一步。项目中使用 OpenAI 的 GPT 模型，根据原始查询生成多个相关的查询变体。这里的核心技巧在于提示工程。

原始项目提供了一个基础提示模板，其核心是要求模型生成“不同”的查询。但经过评估发现，一个更强大的“多样化提示”能显著提升效果。这个改进的提示会明确要求 LLM 从以下角度生成查询：

同义词替换：使用不同的关键词表达相同概念。
视角转换：从用户、专家、初学者等不同身份提问。
具体化与抽象化：生成更具体（包含细节）和更概括（更高层次）的版本。
意图分解：将复合问题拆分成多个子问题。

例如，对于“什么是机器学习？”，生成的变体可能包括：“机器学习的基本定义”、“ML 的核心算法有哪些？”、“解释人工智能中的机器学习”、“给新手讲解机器学习概念”。这样，我们就从一个点，扩展成了一个覆盖更广语义空间的“查询网”。

实操心得：多查询生成是主要的成本和时间开销来源，因为每个变体都需要调用一次 LLM API。在实际应用中，需要权衡生成查询的数量（通常 3-5 个为宜）与效果、成本之间的关系。对于对延迟敏感的场景，可以考虑使用更小、更快的本地模型来执行此步骤。

2.2 并行向量搜索：广撒网

生成了 N 个查询变体后，RAG-Fusion 会并行地对每一个变体执行独立的向量搜索。这一步通常使用像 ChromaDB、Weaviate 或 Pinecone 这样的向量数据库来完成。每个搜索都会返回一个按相似度分数排序的文档列表（例如，Top K 个文档）。

这一步的意义在于“广撒网”。每个查询变体都像一个独特的探针，从不同角度刺入文档库。有的探针可能找到了主流、高相关度的文档（出现在多个结果列表的前列），有的则可能挖掘出一些冷门但高度相关、仅对某种特定表述敏感的文档。此时，我们拥有了 N 个独立的、有序的文档列表。

2.3 倒数排序融合：民主化投票机制

现在我们有了 N 个排名列表，如何将它们合并成一个最终的最优排名？简单取并集或平均分数都会有问题。RRF 算法提供了一个优雅且高效的解决方案。

RRF 的核心思想是：一个文档在多个列表中的排名都很靠前，比它在某一个列表中排名第一但其他列表中不见踪影，更能证明其普遍相关性。这类似于一种“民主投票”机制。

其计算公式为：RRF_score(d) = Σ (1 / (k + rank_i(d)))

其中：

d代表某个文档。
rank_i(d)是该文档在第i个查询的搜索结果列表中的排名（如果未出现，则通常设为一个很大的常数，如列表长度+1）。
k是一个平滑常数，通常设为 60（经验值），用于避免当排名为1时分母过小，起到平滑作用。

计算过程示例：假设我们有3个查询（Q1, Q2, Q3），每个返回 Top 3 文档。文档 A 在三个列表中的排名分别为：第1位、第3位、未出现（我们设 rank=4）。取 k=60。则文档 A 的 RRF 分数 =1/(60+1) + 1/(60+3) + 1/(60+4)≈0.0164 + 0.0159 + 0.0156≈0.0479。

文档 B 在三个列表中的排名分别为：第2位、第2位、第2位。则文档 B 的 RRF 分数 =1/(60+2) + 1/(60+2) + 1/(60+2)=3 * (1/62)≈3 * 0.0161≈0.0484。

虽然文档 A 有一个“冠军”（排名第一），但文档 B 在三个列表中表现稳定且靠前。最终，RRF 分数赋予文档 B 更高的权重（0.0484 > 0.0479），这符合我们“普遍相关性优于偶然高分”的直觉。

注意事项：RRF 的一个巨大优势是其无参数性（除了常数 k）。它不需要对各个列表的分数进行标准化或校准，因为只依赖排名序位。这使得它能轻松融合来自不同检索器（如关键词搜索和向量搜索）的结果，这也是后续“混合搜索”策略得以实现的基础。

2.4 结果生成与呈现

经过 RRF 融合后，我们得到了一个重新排序的文档列表。此时，项目提供了两种输出方式：

直接返回排序后的文档列表：供下游任务（如精排、答案生成）使用。
使用 LLM 进行答案合成：将重排序后的 Top N 篇文档作为上下文，让 LLM 生成一个综合性的答案。这步就是标准的 RAG 生成环节，但得益于更优的检索结果，生成的答案通常更全面、准确。

3. 项目架构与代码实操解析

Raudaschl/rag-fusion项目的结构非常清晰，遵循了“核心管道”与“评估工具”分离的原则，便于理解和使用。

3.1 核心管道剖析

核心逻辑位于main.py的rag_fusion_pipeline函数中。我们可以将其拆解为几个关键函数块来理解：

1. 环境与依赖加载项目使用python-dotenv管理 OpenAI API 密钥，这是生产级项目的常见做法。首先需要复制.env.example为.env并填入你的密钥。

# 安装依赖 pip install openai chromadb python-dotenv tqdm tabulate rank_bm25 # 设置环境变量 cp .env.example .env # 然后编辑 .env 文件，填入你的 OPENAI_API_KEY

2. 多查询生成函数这是第一个关键函数。它接收原始查询和配置参数，调用 OpenAI ChatCompletion API。

def generate_queries(original_query, num_queries=4, model="gpt-3.5-turbo"): prompt = f""" You are a helpful assistant that generates multiple search queries based on a single input query. Generate {num_queries} different search queries that are variations of the following query. The queries should explore different aspects, synonyms, or related contexts to the original. Original query: {original_query} """ # 调用 OpenAI API response = openai.ChatCompletion.create(...) # 解析返回的文本，提取出多个查询，通常以列表形式返回 queries = parse_response(response) return [original_query] + queries # 通常包含原始查询本身

实操要点：parse_response函数需要根据模型返回的格式进行稳健处理。有时模型可能返回编号列表，有时是逗号分隔，有时是换行分隔。建议使用正则表达式或简单的字符串分割，并做好错误处理，确保总能提取出预期数量的查询。

3. 并行搜索执行项目使用 ChromaDB 作为向量数据库。对于每个生成的查询，调用collection.query方法。

def search_queries(queries, collection, top_k=5): all_results = [] for query in queries: results = collection.query( query_texts=[query], n_results=top_k ) # results 包含文档id、元数据、距离分数等 all_results.append(results) return all_results

4. 倒数排序融合实现这是算法的核心。项目中的实现清晰地展示了 RRF 的计算过程。

def reciprocal_rank_fusion(all_results, k=60): fused_scores = {} for i, results in enumerate(all_results): # results['documents'][0] 是第i个查询的文档列表 for rank, doc_id in enumerate(results['ids'][0]): # ChromaDB 返回的 id 可能是字符串，确保其可哈希 if doc_id not in fused_scores: fused_scores[doc_id] = 0 # RRF 公式：分数累加 fused_scores[doc_id] += 1 / (k + rank + 1) # rank 从0开始，所以+1 # 按分数降序排序 sorted_docs = sorted(fused_scores.items(), key=lambda x: x[1], reverse=True) return sorted_docs

5. 结果整合与输出最后，根据融合后的文档 ID，从所有结果中提取出完整的文档内容、元数据，并格式化输出。

def format_final_results(sorted_docs_with_scores, all_results): final_docs = [] for doc_id, score in sorted_docs_with_scores: # 需要从 all_results 中找到这个 doc_id 对应的原始文档内容 doc_content = find_doc_by_id(doc_id, all_results) final_docs.append({ 'id': doc_id, 'score': score, 'content': doc_content, # ... 其他元数据 }) return final_docs

运行整个流程只需执行python main.py，它会加载示例数据（或你自己的数据），并演示从查询到最终排序结果的完整过程。

3.2 评估模块：用数据说话

项目的evaluate.py及其相关模块是其实用价值的另一大体现。它没有停留在“玩具示例”，而是引入了信息检索领域的标准数据集NFCorpus和评估指标，进行了严谨的对比实验。

1. 数据集准备NFCorpus 是一个医学/营养学领域的数据集，包含 3,633 篇文档和 323 个带有分级相关性标注的测试查询。评估脚本会自动下载和处理这个数据集。

# 在 eval/dataset.py 中 def load_nfcorpus(data_dir="./datasets"): # 检查本地是否已存在，否则从网络下载 # 加载文档集合、查询集和相关度判断文件 # 相关度判断通常是一个字典：{query_id: {doc_id: relevance_score}} return corpus, queries, qrels

2. 检索方法对比评估脚本实现了多种检索方法进行对比：

BM25：基于传统关键词匹配的强基线。
Baseline：使用原始查询的单一向量搜索。
Hybrid：BM25 和向量搜索结果的 RRF 融合（不调用 LLM）。
RAG-Fusion：标准的多查询生成 + 向量搜索 + RRF。
RAG-Fusion +Diverse：使用改进的多样化提示的 RAG-Fusion。
Hybrid+Diverse：多样化查询 + 每个查询同时进行 BM25 和向量搜索 + RRF 融合。

3. 评估指标解读评估使用了信息检索领域的核心指标，理解这些指标有助于判断哪种方法更适合你的场景：

Precision@k：在前 k 个返回结果中，相关文档所占的比例。衡量“准不准”。
Recall@k：在前 k 个返回结果中，找到了多少比例的全部相关文档。衡量“全不全”。
NDCG@k：归一化折损累计增益。不仅考虑相关与否，还考虑相关度等级和排名位置，是衡量排序质量的综合指标。
MRR：平均倒数排名。第一个相关文档出现排名的倒数的平均值。衡量系统找到第一个正确答案的速度。

运行评估命令可以直观地看到对比：

# 运行一个快速对比（采样10个查询） python evaluate.py --sample 10 # 运行完整对比（采样50个查询，这是项目默认的评估规模） python evaluate.py --sample 50

4. 核心优化策略与实战技巧

根据项目评估结果和我的实践经验，有以下几个关键的优化方向可以显著提升 RAG-Fusion 的效果。

4.1 提示工程：从“生成不同查询”到“生成多样化查询”

这是成本最低、效果提升最明显的优化点。原版的提示词可能只要求“生成不同的查询”，而改进后的“多样化提示”明确指令模型从不同维度进行思考。

基础提示（可能效果一般）：

请基于以下问题生成4个不同的搜索查询：{原始查询}

多样化提示（效果更佳）：

你是一个专业的搜索查询优化师。请针对以下用户问题，生成4个在意图、角度、具体程度上各不相同的搜索查询变体，以覆盖更全面的信息。 请考虑： 1. 使用同义词或近义词替换核心概念。 2. 从不同受众视角（如初学者、专家、从业者）提问。 3. 将宽泛问题具体化，或将具体问题抽象化。 4. 如果原问题包含多个子问题，尝试拆解。 用户问题：{原始查询}

在我的测试中，使用多样化提示后，由于生成的查询变体在语义空间上分布更广，检索结果的召回率（Recall）和归一化折损累计增益（NDCG）通常有可观的提升。

4.2 混合搜索：免费的午餐

评估结果中一个非常有趣的发现是：Hybrid（BM25+向量搜索+RRF）方法，在不增加任何 LLM 调用成本的情况下，其效果（尤其是 MRR）已经优于单一的向量搜索基线。

这背后的逻辑是：BM25 擅长精确的关键词匹配（解决“术语匹配”问题），而向量搜索擅长语义匹配（解决“同义不同词”问题）。两者是互补的。通过 RRF 将它们的结果融合，相当于让两个各有所长的“专家”共同投票，自然能得出更稳健的排序。

实现 Hybrid 搜索的伪代码：

def hybrid_search(query, vector_collection, bm25_index, top_k=5, k=60): # 1. 向量搜索 vector_results = vector_collection.query(query_texts=[query], n_results=top_k) # 2. BM25 搜索 bm25_scores = bm25_index.get_scores(query) # 获取所有文档分数 bm25_top_indices = np.argsort(bm25_scores)[::-1][:top_k] # 取top_k bm25_results = format_bm25_results(bm25_top_indices) # 格式化成与向量结果类似的结构 # 3. 使用 RRF 融合两个结果列表 fused_results = reciprocal_rank_fusion([vector_results, bm25_results], k=k) return fused_results

实操心得：对于中文场景，BM25 的实现需要配合好的分词器（如 jieba, HanLP）。确保 BM25 和向量搜索使用的文档文本预处理流程（分词、去除停用词等）尽可能一致，以保证公平性。混合搜索是提升检索鲁棒性的必备策略。

4.3 策略组合：Hybrid + Diverse RAG-Fusion

这是项目评估中的“冠军”策略。它结合了上述两大优化：

多样化提示：生成 N 个多角度的查询。
混合检索：对每一个生成的查询，同时执行 BM25 和向量搜索，得到 2N 个结果列表。
全局 RRF 融合：将 2N 个列表通过 RRF 融合成一个最终排名。

这种方法相当于发动了一场“多兵种协同作战”：多样化查询负责从不同角度包抄，BM25 和向量搜索则分别从“精确匹配”和“语义匹配”两条战线推进，最后 RRF 作为总指挥汇总战果。评估数据显示，这种组合在几乎所有指标上都达到了最佳。

性能与成本权衡：

优点：效果最好，能最大程度挖掘相关信息。
缺点：计算成本和延迟最高。需要进行 N 次 LLM 调用（生成查询）和 2N 次搜索（BM25 搜索通常很快，向量搜索是主要开销）。
建议：在生产环境中，可以根据查询的复杂度、对延迟的要求以及成本预算，动态选择策略。例如，对于简单查询，使用 Hybrid 即可；对于复杂、开放的查询，则启用完整的 Hybrid+Diverse RAG-Fusion。

4.4 参数调优指南

生成查询数量 (num_queries)：通常 3-5 个为宜。太少可能覆盖不全，太多则增加成本且可能引入噪声。可以从 3 开始，根据评估指标调整。
RRF 平滑常数 (k)：默认值 60 在多数情况下工作良好。理论上，k值越小，排名靠前的文档权重越大；k值越大，排名的影响越平滑。除非有充分理由，否则不建议修改。
每次搜索返回文档数 (top_k_per_query)：每个查询变体检索的文档数量。不宜过小，否则可能漏掉一些只在某个角度排名中等的关键文档。一般设置为最终希望返回文档数的 2-3 倍。例如，最终要返回10篇文档，每个查询可以检索20-30篇。
向量检索的相似度阈值：可以在向量搜索时设置一个最小相似度分数阈值，过滤掉完全不相关的文档，减少融合时的噪声。但这个阈值需要根据嵌入模型和数据集进行校准。

5. 常见问题、排查技巧与扩展方向

在实际部署和测试 RAG-Fusion 时，你可能会遇到以下典型问题。

5.1 查询生成质量不稳定

问题：LLM 生成的查询变体有时偏离原意，或过于重复。排查与解决：

检查提示词：确保提示词清晰、明确地要求“多样化”。可以加入少样本示例（Few-shot），给模型提供明确的生成范式。
调整温度参数：在调用 LLM 生成查询时，适当提高temperature（如设为 0.7-0.9）可以增加创造性，但过高会导致无关输出。需要平衡。
后处理过滤：对生成的查询进行简单后处理，例如计算生成查询与原始查询的嵌入相似度，过滤掉相似度过高（几乎重复）或过低（可能偏离主题）的查询。
备用方案：如果生成质量始终不佳，可以考虑使用规则模板生成查询变体（如添加前缀“概述一下”、“详细解释”、“对比分析”等），虽然灵活性不如 LLM，但稳定可控。

5.2 检索结果重复或冗余

问题：最终融合后的列表中存在内容高度相似的文档。解决：RRF 本身不处理内容去重。需要在融合后增加一个去重步骤。

基于嵌入的去重：计算最终 Top N 篇文档两两之间的余弦相似度，如果超过阈值（如 0.9），则移除分数较低的一篇。
基于摘要的去重：使用更轻量的模型（如 Sentence-BERT）生成文档摘要或关键句向量，进行相似度比较和去重。
在 RRF 前去重：更激进的做法是在每个查询的检索结果中进行去重，但这可能影响 RRF 的“投票”机制，需谨慎。

5.3 处理超长上下文与文档分块

问题：原始文档很长，直接嵌入会丢失细节，且不利于精准定位答案。解决：这是 RAG 系统的通用问题，在 RAG-Fusion 中同样重要。

智能分块：不要简单按固定字数分割。优先按段落、标题等自然边界分块。对于长文档，可以考虑使用滑动窗口（Overlap）分块，避免答案被切断。
多层次检索：可以先在“文档标题/摘要”级别进行 RAG-Fusion 检索，定位相关文档，再在相关文档内部进行更细粒度的“段落级”检索。
元数据过滤：在搜索时，可以利用 ChromaDB 的元数据过滤功能，先限定文档类别、时间范围等，提升检索效率。

5.4 性能优化与成本控制

问题：完整的 Hybrid+Diverse 流程延迟高、API 调用成本高。优化策略：

缓存：对常见的查询及其生成的查询变体进行缓存。可以使用 Redis 或内存缓存，键为原始查询的哈希值。
异步并行：确保多个查询的向量搜索是异步并行执行的，而不是串行，这能大幅减少 I/O 等待时间。
降级策略：实施熔断降级机制。例如，当 LLM 服务超时或失败时，自动降级到 Hybrid 搜索或纯 BM25 搜索。
本地模型：对于查询生成步骤，可以考虑使用量化后的、参数较小的本地 LLM（如 Llama 3.1 8B, Qwen2.5 7B），虽然生成质量可能略有下降，但能彻底消除 API 成本并降低延迟。