微信扫码
与创始人交个朋友
我要投稿
一段时间以来,我们发现,任何AI应用几乎都离不开RAG,检索增强生成(Retrieval-Augmented
Generation,RAG)技术正在静默而深刻的影响着生成式AI行业的进步。假如你是一位prompr工程师,如果不了解几种RAG技术,那你一定不合格。
01
RAG:突破AI的认知界限
传统的大语言模型,尽管在处理各种任务时表现出色,但仍然存在固有的局限性。它们的知识仅限于训练数据,无法实时更新,也难以处理高度专业化的领域问题。RAG技术的出现,恰恰解决了这些痛点。
如果我们能赋予AI实时访问和利用海量外部知识的能力,会发生什么?这正是RAG所实现的。它不仅提高了AI输出的准确性和可靠性,还使AI具备了持续学习和适应新知识的能力。
来自复旦大学的研究团队在这一领域取得了突破性进展,他们系统性地探索了RAG的最佳实践,为开发者提供了宝贵的实施指南。研究团队深入分析了RAG系统的各个组成部分,包括查询分类、文档分块、检索、重排序、重新打包和总结等模块。他们不仅比较了每个模块的不同实现方法,还探讨了这些模块之间的相互影响,找到了目前技术环境下最优的组合策略。在此感谢复旦大学的研究团队,为我们在现有技术环境下总结了最优的RAG实践!论文在7月1日发表,代码链接在论文的摘要末尾。
02
RAG:精密的知识管理系统
RAG系统的工作流程堪称一个精密的知识管理和利用系统。根据研究团队提供的检索增强生成(RAG)系统的架构图,我们可以清晰地看到RAG系统的各个关键组件及其相互关系:
1.大语言模型(Large Language Model):作为系统的核心,负责理解查询和生成回答。
2.查询分类(Query Classification):判断输入查询是否需要检索外部知识。
3.检索(Retrieval):从外部知识源中检索相关信息。包括多种方法如BM25、Contriever等。
4.重排序(Reranking):对检索结果进行进一步排序,提高相关性。
5.重新打包(Repacking):调整检索文档的顺序,优化上下文。
6.总结(Summarization):压缩检索到的文档,提取关键信息。
7.外部知识源(External Source):包含分块(Chunking)和嵌入(Embedding)等处理步骤。
8.向量数据库(Vector Database):存储和索引文档嵌入。
9.微调(Fine-tune):通过不同策略优化模型性能。
10.评估(Evaluation):从多个维度评估系统性能。
这个架构图全面展示了RAG系统的复杂性和各组件的相互作用,为理解和优化RAG系统提供了清晰的框架。它强调了从查询处理到知识检索、信息整合再到最终生成的完整流程,展现了现代AI系统如何结合大规模语言模型与外部知识以提升性能和可靠性。
2.1 查询分类:智能门卫
查询分类模块犹如RAG系统的智能门卫。它的任务看似简单——判断输入查询是否需要检索增强,但其重要性却不容忽视。研究发现,合理使用查询分类可将系统平均响应时间从16.58秒缩短到11.71秒,同时还略微提升了整体性能。
这一发现对Prompt工程师的启示是深远的。在设计RAG系统时,查询分类不应被视为可有可无的附加功能,而应该被视为核心组件之一。它不仅能显著提高系统响应速度,还能通过避免不必要的检索来优化资源利用。
2.1.1深入理解查询分类
为了更好地理解查询分类的工作机制,让我们分析一下下面这张图:
这张图详细展示了RAG系统中查询分类模块的工作原理,它将输入的查询分为"需要检索"和"无需检索"两类。这种分类对于提高系统效率和性能至关重要。
2.1.1.1. 信息充分的查询:
- 这类查询包含足够的信息,可以直接由语言模型处理,无需额外检索。
- 例子包括翻译任务、改写任务、总结任务等。
- 这些任务通常涉及对给定信息的处理,而不需要额外的背景知识。
2.1.1.2. 信息不足的查询:
- 这类查询需要额外的信息支持,因此需要进行检索。
- 例子包括搜索类任务、开放式问答、需要最新信息的查询等。
- 这些任务通常需要访问外部知识库来补充必要的信息。
2.1.1.3. 背景知识:
- 一些查询虽然提供了部分信息,但仍需要检索来补充完整的背景知识。
- 例如,继续写作任务可能需要检索相关的历史背景或人物信息。
2.1.1.4. 无背景知识:
- 一些查询完全依赖外部信息,需要全面的检索支持。
- 例如,询问未来事件的地点或寻求特定问题的建议。
这种细致的查询分类机制使RAG系统能够:
- 提高效率:对不需要检索的查询直接处理,节省时间和计算资源。
- 提升准确性:为需要额外信息的查询提供精确的知识支持。
- 优化用户体验:根据查询类型提供最适合的响应方式。
- 资源管理:合理分配系统资源,重点支持需要检索的复杂查询。
对于Prompt工程师来说,理解这种查询分类机制非常重要。它可以帮助设计更智能的提示策略,根据不同类型的查询来调整系统的行为,从而在各种场景下都能获得最佳性能。例如,对于信息充分的查询,可以设计直接利用给定信息的提示;而对于信息不足的查询,则可以设计引导系统进行有效检索的提示。
2.2 检索模块:RAG的"大脑"
检索模块是RAG系统的核心,它就像人类大脑中负责记忆检索的部分。研究团队比较了多种检索方法,包括原始检索、"假设性文档嵌入(Hypothetical Document Embeddings,HyDE)、混合检索以及HyDE与混合检索的结合。
HyDE 技术的核心思想是:对于给定的查询,首先生成一个假设性(或虚拟性)的理想文档(即可能包含答案的虚构文档),然后使用这个假设性文档的嵌入来检索实际的相关文档。这种方法旨在提高检索的相关性和准确性。
结果显示,HyDE与混合检索的结合方法在性能上表现最佳,RAG得分高达0.580。这种方法的优势在于它既利用了HyDE生成假设文档的创新性,又结合了混合检索的全面性。然而,这种高性能是以计算成本为代价的,每次查询需要11.71秒。
对于Prompt工程师来说,这一发现提供了重要的设计思路。在构建RAG系统时,需要根据具体应用场景来权衡性能和效率。例如,对于需要实时响应的客户服务chatbot,可以选择更快速的混合检索或原始检索方法。而对于追求高质量输出的内容生成系统,则可以考虑使用HyDE与混合检索的结合方法。
此外,工程师还可以考虑实现动态检索策略。系统可以根据查询的复杂度、时间要求等因素,自动选择最合适的检索方法。这种灵活性可以让RAG系统在各种应用场景中都能发挥最佳性能。
2.2.1 嵌入模型的选择
嵌入模型之前研究者详细全面地总结了分块(Chunking)相关的关键点,分块策略在RAG系统中的重要性,以及如何通过优化分块大小、技术和嵌入模型来提高系统性能。
2.2.1.1. 分块的重要性:
o 将文档分割成小段对提高检索精度和避免LLM的长度问题至关重要。
o 可以在不同粒度级别进行:标记级、句子级和语义级。
2.2.1.2. 分块级别:
o 标记级分块简单但可能分割句子,影响检索质量。
o 语义级分块使用LLM确定断点,保留上下文但耗时。
o 句子级分块在保留文本语义和简单高效之间取得平衡。
2.2.1.3. 句子级分块,从五个维度考察:
2.2.1.4. 块大小:
o 大块提供更多上下文,但增加处理时间。
o 小块改善检索召回率并减少时间,但可能缺乏足够上下文。
o 最佳块大小为512,在忠实度(97.59)和相关性(97.41)之间取得平衡。
2.2.1.5. 分块技术:
o 高级技术如small-to-big和滑动窗口通过组织块关系改善检索质量。
o 滑动窗口技术表现最佳,平均忠实度为97.41,相关性为96.85。
接着研究者将目前流行的五种不同的向量数据库,从四个关键方面进行了评估:
2.2.2.1.多重索引类型(Multiple Index Type):
o Milvus和Faiss支持多重索引类型,这提供了更灵活的搜索优化选项。
o 其他数据库(Weaviate,Chroma,Qdrant)不支持多重索引类型。
2.2.2.2.十亿级扩展(Billion-Scale):
o Milvus和Qdrant能够处理十亿级别的向量,适合大规模应用。
o 其他数据库在这方面的能力有限。
2.2.2.3.混合搜索(Hybrid Search):
o 除Faiss外,所有数据库都支持混合搜索,结合了向量搜索和传统关键词搜索。
2.2.2.4.云原生(Cloud-Native):
o 除Faiss外,所有数据库都具有云原生特性,便于在云环境中部署和管理。
· Milvus是唯一一个在所有四个方面都表现出色的数据库,显示出其全面性和versatility。
· Faiss虽然支持多重索引类型,但在其他方面表现较弱,特别是在云部署方面。
· Qdrant在除多重索引类型外的所有方面都表现良好。
· Weaviate和Chroma虽然支持混合搜索和云原生,但在处理大规模数据和索引灵活性方面有限制。
这个比较突出了Milvus作为一个全面解决方案的优势,同时也展示了不同数据库在各个方面的strengths and weaknesses。选择合适的向量数据库时,需要根据具体项目的需求和scale来权衡这些特性。
检索模块的效果很大程度上依赖于所使用的嵌入模型。让我们看看下面这张表格,它展示了不同嵌入模型在namespace-Pt/msmarco数据集上的性能对比:
这些数据对于理解和选择RAG系统中的嵌入模型至关重要。让我们深入分析这些结果:
2.2.3.1. 评估指标:
- MRR@k (Mean Reciprocal Rank at k):衡量模型在前k个结果中找到相关文档的能力。
- R@k (Recall at k):衡量模型在前k个结果中检索到相关文档的比例。
2.2.3.2. 性能最佳的模型:
- BAAI/LLM-Embedder和BAAI/bge-large-en 在多个指标上表现最佳。
- 这两个模型在 MRR@1、MRR@10和R@10 上都取得了最高分。
2.2.3.3. 模型大小与性能:
- 通常,较大的模型(如 large 版本)性能优于较小的模型。
- 但BAAI/bge-small-en-v1.5 在某些指标上表现也很不错,显示了小模型的潜力。
2.2.3.4. 版本迭代的影响:
- 新版本的模型(如 v1.5)通常比旧版本表现更好,体现了模型迭代的重要性。
这些结果对RAG系统的设计有重要启示:
一. 模型选择:根据具体应用场景的需求(如对准确性、速度的不同要求)选择合适的嵌入模型。
二. 性能与效率平衡:在高性能大模型和计算效率高的小模型之间权衡。
三. 版本更新:及时关注和采用最新版本的模型,以获得性能提升。
四. 任务适配:根据特定任务的重要指标(如更看重MRR还是Recall)来选择模型。
对Prompt工程师而言,理解这些嵌入模型的性能特征非常重要。它可以帮助他们为不同的应用场景设计更有效的提示策略,如针对高召回率的任务使用不同于追求高精度任务的提示方式。
2.3 重排序:精准定位关键信息
重排序模块就像是RAG系统的"信息过滤器"。它的作用是进一步提升检索结果的相关性,确保最重要的信息能被优先处理。研究比较了多种重排序方法,包括monoT5、monoBERT、RankLLaMA和TILDEv2。
实验结果表明,使用monoT5进行重排序能够获得最高的平均得分。这一发现强调了重排序在提升生成质量中的关键作用。对于Prompt工程师来说,这意味着在RAG系统中集成有效的重排序机制可以显著提高最终输出的质量。
在实际应用中,工程师可以考虑实现多级重排序策略。例如,可以先使用计算速度较快的方法(如TILDEv2)进行初步筛选,然后再使用更精确但计算成本较高的方法(如monoT5)对Top-K结果进行精细重排序。这种策略可以在保证性能的同时,有效控制计算成本。
2.4 重新打包:优化上下文排列
重新打包模块的作用类似于给检索到的信息"排版"。研究者比较了正向排序、反向排序和两侧排序三种策略。结果显示,反向排序策略表现最佳,RAG得分达到0.560。
这一发现揭示了一个重要的认知原理:将最相关的信息放在靠近查询的位置,有助于生成模型更好地理解和利用上下文。对Prompt工程师而言,这提供了一个优化RAG系统输出质量的重要方向。
在实际应用中,工程师可以考虑实现动态打包策略。例如,可以根据任务类型、查询长度等因素,自动选择最合适的排序方法。甚至可以尝试使用机器学习模型来学习最优的文档排序方式,进一步提升系统性能。
2.5 总结模块:提炼精华信息
总结模块就像是RAG系统的"信息压缩器"。研究比较了Recomp和LongLLMLingua两种总结方法。结果表明,Recomp方法在性能上略胜一筹。然而,研究者也发现,在某些情况下,完全移除总结模块反而能获得更好的性能和更低的延迟。
这一发现为Prompt工程师提供了一个重要的设计思路:总结模块并非必不可少,其使用与否应该根据具体应用场景和系统要求来决定。在一些对实时性要求极高的应用中,可以考虑省略总结步骤以提高响应速度。
在实际应用中,工程师可以考虑实现自适应总结策略。系统可以根据检索结果的长度、复杂度等因素,动态决定是否进行总结,以及使用何种总结方法。这种灵活性可以让RAG系统在各种应用场景中都能保持最佳性能。
2.6 生成器微调:提升模型适应性
研究团队探讨了生成器微调对RAG系统性能的影响,尝试了使用相关文档、随机文档以及混合文档进行微调的策略。结果表明,使用相关和随机文档混合进行微调的策略效果最佳。
这一发现对Prompt工程师具有重要的指导意义。在微调RAG系统的生成器时,不应只关注与任务直接相关的文档,还应引入一定比例的随机文档。这种方法不仅可以提高模型对相关信息的利用能力,还能增强其对不相关信息的鲁棒性,从而提高模型的泛化能力和抗干扰能力。
在实际应用中,工程师可以考虑实现动态微调策略。例如,可以根据系统的实际使用情况,定期收集用户查询和系统响应,用这些真实数据来持续微调模型。这种方法可以让RAG系统不断适应新的应用场景和用户需求,保持长期的高性能。
03
RAG的最佳实践:性能与效率的平衡艺术
基于大量实验结果,研究团队提出了两种RAG实施策略,分别针对追求最高性能和平衡性能与效率的场景。让我们通过下面这张详细的实验结果表格来深入分析这些策略:
这张表格提供了对RAG系统不同组件和配置的全面评估结果,为我们提供了宝贵的洞察。让我们深入分析这些数据:
3.1 评估指标解读
- 表格涵盖了多个任务领域:常识推理(Commonsense)、事实检查(Fact Check)、开放域问答(ODQA)、多跳问答(Multihop)和医疗问答(Medical)。
- 使用了准确率(Acc)、精确匹配(EM)、F1分数等指标,以及综合的RAG得分。
- 同时考虑了平均延迟(Latency),体现了性能与效率的权衡。
3.2 关键发现
3.2.1. 查询分类模块的影响:
- 引入查询分类后,整体性能略有提升(平均分从0.465提高到0.478)。
- 查询分类显著降低了延迟(从16.58秒减少到11.71秒)。
3.2.2. 检索模块比较:
- "Hybrid with HyDE"方法在多数指标上表现最佳,平均分达到0.478。
- 然而,它也带来了较高的延迟(11.71秒)。
- 纯Hybrid方法在医疗任务上表现突出(0.750),同时保持较低延迟(1.45秒)。
3.2.3. 重排序模块的作用:
- monoT5重排序方法整体表现最佳,平均分为0.478。
- 不同重排序方法在性能和延迟上存在差异,如RankLLaMA性能好但延迟高。
3.2.4. 重新打包策略:
- 反向排序(reverse)策略略优于其他方法,在医疗和RAG任务上表现尤为出色。
3.2.5. 总结模块的影响:
- Recomp总结方法略优于LongLLMLingua。
- 有趣的是,移除总结模块在某些任务上反而提高了性能,同时减少了延迟。
基于这些发现,研究团队提出了两种RAG实施策略:
3.3 追求最佳性能的RAG配置:
3.3.1. 集成查询分类模块
3.3.2. 采用"Hybrid with HyDE"检索方法
3.3.3. 使用monoT5进行重排序
3.3.4. 采用反向排序策略
3.3.5. 使用Recomp进行总结
这种配置在实验中获得了最高的平均得分0.483,但计算开销较大。它适合那些对输出质量要求极高,且能够容忍较长响应时间的应用场景。例如,在生成高质量的研究报告、详细的技术文档或复杂的数据分析时,这种配置可以发挥其优势。
3.4 平衡效率和性能的RAG配置:
3.4.1. 集成查询分类模块
3.4.2. 采用Hybrid检索方法
3.4.3. 使用TILDEv2进行重排序
3.4.4. 采用反向排序策略
3.4.5. 使用Recomp进行总结
这种配置在保持较好性能的同时,大幅降低了系统延迟。它适合那些需要在性能和效率之间取得平衡的应用场景。例如,在开发实时性要求较高的客户服务chatbot或交互式学习系统时,这种配置可能是更好的选择。
04
RAG的实践启示
对于Prompt工程师和AI系统开发者来说,这些研究结果提供了丰富的实践启示:
4.1. 模块化设计的重要性:
每个模块都对整体性能有显著影响,证实了RAG系统模块化设计的价值。在实际开发中,应该注重系统的模块化,以便灵活调整和优化各个组件。
4.2. 性能与效率的权衡:
高性能配置(如Hybrid with HyDE)通常伴随较高延迟,实际应用中需要根据具体需求权衡。工程师应该根据应用场景的特点,选择合适的性能-效率平衡点。
4.3. 任务特异性:
不同配置在各类任务上表现不一,突显了为特定领域定制RAG系统的重要性。在开发针对特定领域的AI应用时,应该进行针对性的优化和调整。
4.4. 查询分类的价值:
查询分类不仅提升了性能,更大幅降低了延迟,是一个值得重视的优化点。工程师应考虑在RAG系统中实现智能的查询分类机制。
4.5. 灵活配置的必要性:
最佳配置因任务而异,强调了设计灵活、可配置RAG系统的重要性。开发可动态调整的RAG系统架构,能够适应不同的应用需求。
4.6. 意外发现的价值:
某些情况下,简化系统(如移除总结模块)反而能提升性能,提醒我们要警惕过度复杂化。在系统设计中,应该保持开放心态,不断测试和验证各种可能性。
检索增强生成技术无疑是AI领域的一个重要突破。研究团队已经在探索将RAG扩展到图像生成和理解任务中。未来,我们可能会看到更多跨模态的RAG应用,如视频分析、音频处理等。未来的RAG系统可能会具备实时学习能力,能够从每次交互中学习并更新其知识库,实现真正的持续学习。RAG系统可能会更加个性化,能够根据用户的历史交互和偏好来定制检索和生成策略。为了处理更大规模的知识库,未来可能会出现分布式RAG系统,能够在多个服务器或设备上协同工作。这项研究通过系统性地探索RAG的最佳实践,为Prompt工程师和AI开发者提供了宝贵的指导,在此推荐给大家。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-10-06
Anthropic RAG: 上下文检索技术
2024-10-06
AI检索黑马获2000万美元融资,推进RAG系统精准化,破解AI幻觉难题
2024-10-06
OpenRAG:全面增强RAG推理,超越Self-RAG、RAG 2.0、Command R+
2024-10-06
如何引入chunk层级优化RAG性能:从树结构RAPTOR到GEM-RAG加权图方案解读
2024-10-06
KAG:RAG已经不够了,知识增强生成才是王道,提升朴素RAG一倍性能
2024-10-05
打造自己的RAG解析大模型:Windows下部署OCR应用服务(可商业应用)
2024-10-05
基于RAG的to B智能体(Agent)应用实践
2024-10-03
RAG实战篇:将用户输入转换为精确的数据库查询语言
2024-07-18
2024-07-09
2024-07-09
2024-07-08
2024-07-09
2024-06-20
2024-07-07
2024-05-05
2024-07-07
2024-05-19
2024-09-30
2024-09-26
2024-09-26
2024-09-20
2024-09-16
2024-09-12
2024-09-11
2024-09-10