微信扫码
与创始人交个朋友
我要投稿
RAG通过检索现有的大量知识,结合强大的LLM,为复杂的问答、文本摘要和生成任务带来了全新的解决方案。然而,尽管RAG有其独特的优势,但在实践过程中也遭遇了多个挑战:
当前搜索技术的限制:RAG受到限制的方面与我们的检索式基于词汇和向量的搜索技术相同。
人类搜索效率低下:人类在向搜索系统输入他们想要的内容时并不擅长,如打字错误、含糊的 查询或词汇有限,这常常导致错过那些超出显而易见的顶部搜索结果的大量信息。虽然RAG有 所帮助,但它并没有完全解决这个问题。
搜索的过度简化:我们普遍的搜索范式是将查询线性映射到答案,缺乏理解人类查询的多维 性。这种线性模型通常无法捕捉更复杂用户查询的细微差别和上下文,导致结果相关性较低。
为了解决这些挑战,业界提出了很多种优化策略,今天我想分享的是一种代价小但是效果明显的优化策略——RAG-Fusion。
RAG-Fusion解决了RAG固有的限制,通过生成多个用户查询并重新排序结果。利用逆向排名融合和自定义向量评分加权进行综合、准确的搜索。RAG-Fusion旨在弥合用户明确询问与他们意图询问之间的差距,更接近于发现通常隐藏的变革性 知识。
主要流程如下图所示:
我们为什么要生成多个查询?
在传统的搜索系统中,用户通常输入一个查询来查找信息。虽然这种方法直接简单,但它有局限 性。单一查询可能无法完全捕捉用户感兴趣的全部范围,或者可能过于狭窄而无法产生全面的结果。因 此,从不同角度生成多个查询就显得尤为重要。
一般我们会使用LLM来对用户原始的Query生成多个查询,这些查询不是随机变化。它们是经过精心生成的,以提供原始问题的不同视角。例如,如果原始查询是关于“气候变化的影响”,那么生成的查询可能包括像“气候变化的经济后果”、“气候变化与公共健康”等角度。这种方法确保了搜索过程考虑了更广泛的信息范围,从而提高生成总结的质量和深度。
逆向排名融合(RRF)是一种由滑铁卢大学和谷歌联合开发的技术,用于将多个搜索结果列表融合为一个完整的排名。该方法被誉为优于任何单独的系统,也超越了普通的重新排名方法。
这项技术通过汇总不同搜索请求的排名,提高了最相关文档在结果列表顶部出现的可能性。它的独特之处在于,RRF并不依赖于搜索引擎给予的具体分数,而是依赖相对排名,使其很适合结合可能有不同规模或分数分布的查询结果。
通常,RRF会被用来混合词汇和向量搜索的结果。虽然这种方式可以弥补向量搜索在查找特定术语(如缩写)时可能存在的不足,但结果有时可能看起来就像是将多个结果集拼凑在一起,因为使用词汇和向量搜索的同一查询很少产生相同的结果。
简单来说,你可以把RRF想象成那种喜欢在做决定前听取所有人意见的人。只不过在这里,这种“听众”的角色不仅不会让人感到烦恼,反而能帮助提高结果的准确性。就像在多元视角中找到最佳解答一样,观点越多,结果就越精确。
@search.score
。对于搜索结果中的每个文档,引擎基于其在列表中的位置分配倒数排名分数。分数按 1/(rank + k)
计算,其中 rank
是文档在列表中的位置,k
是一个常量,经实验证明,如果将它设置为 60 这样较小的值,则效果最佳。请注意,这个 k
值是 RRF 算法中的常量,与控制最近的邻域数的 k
完全不同。最后,将重新排名的文档和所有查询输入到LLM提示中,以生成典型的RAG方式的生成性输出,如 请求回应或摘要。
在我的实际使用中发现,使用多个查询的一个挑战是可能稀释用户的原始意图。为了缓解这一点,我们在prompt中要求LLM更重视原始查询。
RAG-Rusion在实际使用过程中优势还是挺明显的,可以看到的有以下6点:
更优质的源材料:使用RAG Fusion时,你的搜索深度不仅仅是“增强”——而是被放大。重新排 名的相关文档列表意味着你不只是在信息表面刮刮而已,而是潜入观点的海洋。结构化输出易 于阅读,直观上可信赖,这在对人工智能生成内容持怀疑态度的世界中至关重要。
增强用户意图:对齐RAG Fusion的核心设计是作为一个富有同情心的人工智能,揭示用户努力表达但可能无法清晰表述的内容。采用多查询策略捕捉用户信息需求的多面性表现,因此提供全面的输出,并与用户意图产生共鸣。
结构化、富有洞见的输出:通过汲取多样化的信息源,模型制作出组织良好且富有洞见的答 案,预测后续问题并主动解答。
自动纠正用户查询:该系统不仅解释,还优化用户查询。通过生成多个查询变体,RAG Fusion执行隐含的拼写和语法检查,从而提高搜索结果的准确性。
处理复杂查询:人类语言在表达复杂或专业思想时常常出现障碍。该系统作为语言催化剂,生 成可能包含所需专业术语或术语的变体,用于更集中和相关的搜索结果。它还可以将更长、更 复杂的查询分解成向量搜索可以处理的更小、更易管理的部分。
搜索中的意外发现:考虑“未知的未知”——直到遇到你才知道需要的信息。通过采用更广泛的 查询范围,系统促进了发现意外信息的可能性。虽然这些信息并非明确寻求,但对用户来说却 可能是一个欧雷卡时刻。这使RAG Fusion区别于其他传统搜索模型。
然而,你需要知道,RAG以及其许多优化策略,都有其特定的局限性和挑战,RAG-Rusion也同样如此:
过于冗长的风险:RAG-Fusion的深度有时可能导致信息泛滥。输出可能过于详细,令人不堪重负。
平衡上下文窗口:多查询输入和多样化文档集的引入可能会使语言模型的上下文窗口受到压 力。对于上下文限制较紧的模型,这可能导致输出不连贯甚至被截断。
使用RAG-Fusion需要警惕的一点是LLM生成的查询有时可能偏离原始意图,所以考虑我们向人工智能让渡多少控制权以及代价是什么非常重要。尽管我们已经优先考虑原始的用户查询,确保其在生成过程中的重要性,但是有时候差一点的模型对prompt的指令的遵循度不是很好。为了解决这个问题,我们在实际生产上做了一些产品UI上的调整:
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-25
RAG搭建中,如何选择最合适的向量索引?
2024-11-25
RAG的2024—随需而变,从狂热到理性(下)
2024-11-25
RAG的2024—随需而变,从狂热到理性(下)
2024-11-25
糟糕!LLM输出半截Json的答案,还有救吗!
2024-11-24
解读GraphRAG
2024-11-24
RAGChecker:显著超越RAGAS,一个精细化评估和诊断 RAG 系统的创新框架
2024-11-23
FastRAG半结构化RAG实现思路及OpenAI O1-long COT蒸馏路线思考
2024-11-23
检索增强生成(RAG):解密AI如何融合记忆与搜索
2024-07-18
2024-05-05
2024-07-09
2024-05-19
2024-07-09
2024-06-20
2024-07-07
2024-07-07
2024-07-08
2024-07-09
2024-11-25
2024-11-06
2024-11-06
2024-11-05
2024-11-04
2024-10-27
2024-10-25
2024-10-21