一段时间以来，我们发现，任何AI应用几乎都离不开RAG，检索增强生成（Retrieval-Augmented Generation，RAG）技术正在静默而深刻的影响着生成式AI行业的进步。假如你是一位prompr工程师，如果不了解几种RAG技术，那你一定不合格。

传统的大语言模型，尽管在处理各种任务时表现出色，但仍然存在固有的局限性。它们的知识仅限于训练数据，无法实时更新，也难以处理高度专业化的领域问题。RAG技术的出现，恰恰解决了这些痛点。

如果我们能赋予AI实时访问和利用海量外部知识的能力，会发生什么？这正是RAG所实现的。它不仅提高了AI输出的准确性和可靠性，还使AI具备了持续学习和适应新知识的能力。

来自复旦大学的研究团队在这一领域取得了突破性进展，他们系统性地探索了RAG的最佳实践，为开发者提供了宝贵的实施指南。研究团队深入分析了RAG系统的各个组成部分，包括查询分类、文档分块、检索、重排序、重新打包和总结等模块。他们不仅比较了每个模块的不同实现方法，还探讨了这些模块之间的相互影响，找到了目前技术环境下最优的组合策略。在此感谢复旦大学的研究团队，为我们在现有技术环境下总结了最优的RAG实践！论文在7月1日发表，代码链接在论文的摘要末尾。

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系统不断适应新的应用场景和用户需求，保持长期的高性能。

基于大量实验结果，研究团队提出了两种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或交互式学习系统时，这种配置可能是更好的选择。

对于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开发者提供了宝贵的指导，在此推荐给大家。