RAG技术通过检索外部知识库，再结合大语言模型，确实为复杂的问答、文本摘要和内容生成等任务带来了全新的解题思路。不过，技术落地从来不是一帆风顺的。尽管RAG优势明显，但在实际应用中，它也遇到了几个难以绕过的关键挑战：
检索技术的天花板：简单来说，RAG的检索能力上限，依然受限于传统的基于词汇和向量的搜索技术本身。它运行得再快，也跳不出搜索框架的制约。
人类的表达效率问题：现实情况是，大多数人并不擅长准确表述自己真正想搜索的内容。拼写错误、表达含糊、反复使用少数几个词汇——这些现象屡见不鲜。结果就是，大量隐藏在表层结果之下的高质量信息被遗漏。RAG虽然能提供帮助，但治标不治本。
搜索被过度简化了：当前我们习惯的搜索范式，是将用户的查询直接线性映射到一个答案上。但人类的需求是立体、多维的，这种线性思维模型根本无法捕捉复杂查询背后的细微差别和上下文，最终结果的相关性自然会打折扣。
为了解决这些问题，业界提出了多种优化策略。今天想分享一个思路，成本很低，但效果出乎意料——RAG-Fusion。
为什么需要RAG-Fusion？
RAG-Fusion的出现，正是为了突破RAG原有的局限。它的核心思路很简单：不再只依赖用户那一个粗糙的查询，而是先生成多个角度的用户查询，再把搜索回来的结果进行重新排序。这背后依赖的是逆向排名融合（RRF）和自定义的向量评分加权，最终实现更综合、更准确的搜索。它的目标，是弥合“用户明确问的”与“用户真正想知道的”之间的鸿沟，去发掘那些隐藏的、有变革意义的知识。
工作流程
整体流程如下图所示，大致可以分为五个步骤：
- 查询生成/改写：利用大语言模型，将用户最初的原始问题拆解、改写成多个不同的查询。
- 向量搜索：对生成的每一个查询，都进行一次基于向量的搜索，实现“多路并发”的召回。
- 倒数排序融合：应用逆向排名融合（RRF）算法，根据文档在多个不同查询中的表现，重新评估它们的整体相关性。
- 重排：再利用一些重排算法，对上一步的结果进行精细化调整。
- 输出生成：最终，参考重排后排名靠前的搜索结果，生成最终输出。
1. 多查询生成
为什么要费劲生成多个查询？
在传统搜索中，用户输入一个查询，系统就根据这个查询去查找。简单直接，但局限也明显。单一的查询很可能无法涵盖用户关心的所有方面，或者其定义过于狭窄，导致找不到全面的结果。此时，从不同角度生成多个查询就显得非常必要。
通常做法是借助LLM，对用户最初的Query进行拆解和变形。这些生成的新查询并非随机乱改，而是精心设计，旨在提供原始问题的不同视角。举例来说，如果用户搜索“气候变化的影响”，那么LLM生成的查询可能包括“气候变化的经济后果”“气候变化与公共健康”等。这种思路确保了搜索过程能覆盖更广阔的信息面，最终的输出在质量和深度上自然会更好。
2. 逆向排名融合（RRF）
什么是RRF
逆向排名融合（RRF）这项技术，由滑铁卢大学和谷歌联合开发，专门用来将多个搜索结果列表融合成一个更优的整体排名。其表现据说比任何一个单独系统都好，也超越了普通的重新排名方法。
它的原理是通过汇总不同搜索请求中的排名，提高最相关文档在最终结果列表顶部出现的概率。最妙之处在于，RRF不依赖搜索引擎给出的具体分数，只关注每个文档的相对排名。这意味着它能很好地融合来自不同系统、评分尺度可能完全不一样的搜索结果。
以前，RRF常被用来混合词汇搜索和向量搜索的结果。这确实能弥补向量搜索在查找特定术语（如缩写）时的短板。但有时，融合出的结果看起来像是把几个结果集硬拼在一起，因为用词汇和向量对同一个查询进行搜索，很少会得到完全相同的结果。
简单来说，你可以把RRF想象成一位决策者，他在做决定前需要听取所有人的意见。只不过在这里，扮演“听众”角色不仅不烦人，反而能帮我们筛选出更准确的结果。就像从多视角中寻找最佳答案一样，观点越多，最后的结论就越精确。
RRF 技术实现
- 先从并行执行的多个查询中，获取它们各自的排名搜索结果。
- 为每个排名列表中的每个文档分配一个倒数排名分数。对于搜索结果中的每个文档，RRF会根据它在该列表中的位置来计算分数，公式为 1/(rank + k)。其中，rank是文档的位置，k是一个常量。根据实验，当k取60这样较小的值时效果最好。需要特别注意的是，这个k值与控制最近邻域数的那个k完全不同。
- 合并分数。对于同一个文档，把它从每个搜索系统中获得的倒数排名分数都加起来，生成一个合并后的总分。
- 最终，引擎根据这个合并后的总分，对文档进行重新排名和排序。得到的列表就是融合后的排名。
3. LLM生成响应
最后一步，把重新排名后的文档和所有生成的多路查询，一起输入到LLM的提示词中，让它按照典型的RAG方式（如生成回复或摘要）来生成最终输出。在实际使用中，一个潜在的挑战是，生成的多个查询可能会稀释用户最初的意图。为了缓解这个问题，我们通常在prompt里特别强调，要求LLM更重视原始查询。
RAG-Fusion 的反思
在实际使用中，RAG-Fusion的优势确实很明显，可以总结为以下几点：
源材料质量更高：使用RAG Fusion，搜索深度绝不仅仅是“增强”，而是被放大了。重新排名的文档列表，让你不是只在信息表面刮一刮，而是真正潜入观点的海洋中。这种结构化的输出本身就好读，直观上让人觉得可信，这在今天对AI生成内容普遍持怀疑态度的世界里，是一个极其宝贵的品质。
增强用户意图理解：RAG Fusion的核心设计，就像一个善解人意的人工智能，努力去揭示用户想表达但又说不清楚的东西。多查询策略捕捉了用户信息需求的多面性，所以最终的输出非常全面，能真正与用户的深层意图产生共鸣。
结构化且富有洞见的输出：通过汲取多样化的信息源，模型能制作出结构良好且富有洞见的答案，甚至能预判并主动解答用户接下来可能问的问题。
自动纠正用户查询：这个系统不仅能解释查询，还能优化查询。通过生成多个查询变体，RAG Fusion在无形中完成了拼写和语法检查，从而提高了搜索结果的准确性。
处理复杂查询：人类在表达复杂或专业的想法时，语言上常常会遇到障碍。RAG Fusion就像一种语言催化剂，生成的查询变体可能自动包含了用户本应使用但没有用上的专业术语，从而获得更集中、更相关的搜索结果。它还能把又长又复杂的查询，拆解成向量搜索能处理的更小、更易管理的小块。
搜索中的意外发现：想想那些“未知的未知”——你直到遇到它，才知道自己需要它。通过采用更广泛的查询范围，系统促成了发现意外信息的可能性。这些信息虽然不是用户明确在找的，但对用户来说却可能是一个“欧雷卡”时刻。这一点，让RAG Fusion明显区别于其他传统的搜索模型。
然而，任何技术都有它的两面性，RAG以及它的各种优化策略，也有自己特定的局限和挑战。RAG-Fusion同样如此：
过于冗长的风险：RAG-Fusion的深度，有时候会导致信息泛滥。输出可能过于详细，让人感觉不堪重负。
平衡上下文窗口的难题：多查询输入和多样化的文档集，会挤占语言模型的上下文窗口。对于上下文限制比较严的模型来说，这可能导致输出不连贯，甚至被截断。
生产经验
在使用RAG-Fusion时，需要特别警惕一点：LLM生成的查询有时可能会偏离原始用户意图。所以我们必须认真思考，我们要把多少控制权让渡给AI，以及相应的代价是什么。尽管我们在prompt中已经优先考虑了原始用户查询，确保其重要性，但有时模型能力不够强，对指令的遵循度就会差一些。为了解决这个问题，我们在实际的产品UI上做了一些调整：
- 把选择权交给用户：给用户提供开关RAG-Fusion的选项，让他们在手动控制和增强的AI辅助之间自由选择。
- 提升透明度：通过工具提示或简要说明，展示RAG-Fusion的工作方式，帮助用户设定明确的预期。同时，对于LLM生成的查询，我们也一并展示给用户，让整个搜索过程对用户完全可见。