大模型RAG综述

山科智能信息处理实验室

于 2024-09-01 22:29:57 发布

阅读量91

点赞数

文章标签：语言模型

原文链接：https://zhuanlan.zhihu.com/p/675509396

版权

什么是RAG?

检索增强生成（Retrieval Augmented Generation），简称 RAG，已经成为当前最火热的LLM应用方案。大模型已经成为人工智能的前沿话题，想必大家对大模型的能力有了一定的了解，但是当我们将大模型应用于实际业务场景时会发现，通用的基础大模型基本无法满足我们的实际业务需求，主要有以下几方面原因：

知识的局限性：模型自身的知识完全源于它的训练数据，而现有的主流大模型（ChatGPT、文心一言、通义千问…）的训练集基本都是构建于网络公开的数据，对于一些实时性的、非公开的或离线的数据是无法获取到的，这部分知识也就无从具备。
幻觉问题：所有的AI模型的底层原理都是基于数学概率，其模型输出实质上是一系列数值运算，大模型也不例外，所以它有时候会一本正经的胡说八道，尤其是在大模型自身不具备某一方面的知识或不擅长的场景。而这种幻觉问题的区分是比较困难的，因为它要求使用者自身具备相应领域的知识。
数据安全性：对于企业来说，数据安全至关重要，没有企业愿意承担数据泄露的风险，将自身的私域数据上传第三方平台进行训练。这也导致完全依赖通用大模型自身能力的应用方案不得不在数据安全和效果方面进行取舍。

而RAG是解决上述问题的一套有效方案。

在这个过程中，有两个主要步骤：语义搜索和生成输出。在语义搜索步骤中，我们希望从我们的知识库中找到与我们要回答的查询最相关的部分内容。然后，在生成步骤中，我们将使用这些内容来生成响应。

RAG架构

RAG的架构如图中所示，简单来讲，RAG就是通过检索获取相关的知识并将其融入Prompt，让大模型能够参考相应的知识从而给出合理回答。因此，可以将RAG的核心理解为“检索+生成”，前者主要是利用向量数据库的高效存储和检索能力，召回目标知识；后者则是利用大模型和Prompt工程，将召回的知识合理利用，生成目标答案。

完整的RAG应用流程主要包含两个阶段：

数据准备阶段：数据提取——>文本分割——>向量化（embedding）——>数据入库
应用阶段：用户提问——>数据检索（召回）——>注入Prompt——>LLM生成答案

下面我们详细介绍一下各环节的技术细节和注意事项：

数据准备阶段：

数据准备一般是一个离线的过程，主要是将私域数据向量化后构建索引并存入数据库的过程。主要包括：数据提取、文本分割、向量化、数据入库等环节

数据提取
- 数据加载：包括多格式数据加载、不同数据源获取等，根据数据自身情况，将数据处理为同一个范式。
- 数据处理：包括数据过滤、压缩、格式化等。
- 元数据获取：提取数据中关键信息，例如文件名、Title、时间等。
文本分割：
文本分割主要考虑两个因素：1）embedding模型的Tokens限制情况；2）语义完整性对整体的检索效果的影响。一些常见的文本分割方式如下：
- 句分割：以”句”的粒度进行切分，保留一个句子的完整语义。常见切分符包括：句号、感叹号、问号、换行符等。
- 固定长度分割：根据embedding模型的token长度限制，将文本分割为固定长度（例如256/512个tokens），这种切分方式会损失很多语义信息，一般通过在头尾增加一定冗余量来缓解。
向量化（embedding）：

向量化是一个将文本数据转化为向量矩阵的过程，该过程会直接影响到后续检索的效果。目前常见的embedding模型如表中所示，这些embedding模型基本能满足大部分需求，但对于特殊场景（例如涉及一些罕见专有词或字等）或者想进一步优化效果，则可以选择开源Embedding模型微调或直接训练适合自己场景的Embedding模型。

模型名称	描述	获取地址
ChatGPT-Embedding	ChatGPT-Embedding由OpenAI公司提供，以接口形式调用。	https://platform.openai.com/docs/guides/embeddings/what-are-embeddings
ERNIE-Embedding V1	ERNIE-Embedding V1由百度公司提供，依赖于文心大模型能力，以接口形式调用。	https://cloud.baidu.com/doc/WENXINWORKSHOP/s/alj562vvu
M3E	M3E是一款功能强大的开源Embedding模型，包含m3e-small、m3e-base、m3e-large等多个版本，支持微调和本地部署。	https://huggingface.co/moka-ai/m3e-base
BGE	BGE由北京智源人工智能研究院发布，同样是一款功能强大的开源Embedding模型，包含了支持中文和英文的多个版本，同样支持微调和本地部署。	https://huggingface.co/BAAI/bge-base-en-v1.5

数据入库：

数据向量化后构建索引，并写入数据库的过程可以概述为数据入库过程，适用于RAG场景的数据库包括：FAISS、Chromadb、ES、milvus等。一般可以根据业务场景、硬件、性能需求等多因素综合考虑，选择合适的数据库。

应用阶段：

在应用阶段，我们根据用户的提问，通过高效的检索方法，召回与提问最相关的知识，并融入Prompt；大模型参考当前提问和相关知识，生成相应的答案。关键环节包括：数据检索、注入Prompt等

数据检索：

常见的数据检索方法包括：相似性检索、全文检索等，根据检索效果，一般可以选择多种检索方式融合，提升召回率。

相似性检索：即计算查询向量与所有存储向量的相似性得分，返回得分高的记录。常见的相似性计算方法包括：余弦相似性、欧氏距离、曼哈顿距离等。
全文检索：全文检索是一种比较经典的检索方式，在数据存入时，通过关键词构建倒排索引；在检索时，通过关键词进行全文检索，找到对应的记录。

注入Prompt：

Prompt作为大模型的直接输入，是影响模型输出准确率的关键因素之一。在RAG场景中，Prompt一般包括任务描述、背景知识（检索得到）、任务指令（一般是用户提问）等，根据任务场景和大模型性能，也可以在Prompt中适当加入其他指令优化大模型的输出。

RAG 框架

RAG的研究范式一直在进化，可以总结为三大类：Naive RAG, Advanced RAG 和 Modular(模块化) RAG。RAG不论是在效果上还是性价比上都比单独使用LLM要好得多，当然也有部分问题。Advanced RAG 和 Modular RAG的发展的出现就是为了解决Naive RAG在使用上出现的缺点。

Naive RAG

朴素RAG（naive RAG）研究范式代表了最早的方法论，它在ChatGPT广泛采用后不久就获得了显著地位。朴素RAG遵循一个传统的过程，包括索引、检索和生成。它也被描述为一个“检索-阅读”框架。

索引

数据索引：包括清理和提取原始数据，将 PDF、HTML、Word、Markdown 等不同格式的文件转换成纯文本。
分块：将加载的文本分割成更小的片段。由于语言模型处理上下文的能力有限，因此需要将文本划分为尽可能小的块。
嵌入和创建索引：这一阶段涉及通过语言模型将文本编码为向量的过程。所产生的向量将在后续的检索过程中用来计算其与问题向量之间的相似度。由于需要对大量文本进行编码，并在用户提问时实时编码问题，因此嵌入模型要求具有高速的推理能力，同时模型的参数规模不宜过大。完成嵌入之后，下一步是创建索引，将原始语料块和嵌入以键值对形式存储，以便于未来进行快速且频繁的搜索。

检索

根据用户的输入，采用与第一阶段相同的编码模型将查询内容转换为向量。
系统会计算问题向量与语料库中文档块向量之间的相似性，并根据相似度水平选出最相关的前 K 个文档块作为当前问题的补充背景信息。

生成

将给定的问题与相关文档合并为一个新的提示信息。
随后，大语言模型（LLM）被赋予根据提供的信息来回答问题的任务。
根据不同任务的需求，可以选择让模型依赖自身的知识库或仅基于给定信息来回答问题。如果存在历史对话信息，也可以将其融入提示信息中，以支持多轮对话。

Naive RAG 的挑战
Naive RAG 系统在实际应用中主要面临以下三个方面的挑战：

检索质量

低精度问题：检索结果中的文档块可能与查询内容不完全相关，可能导致信息错误或不连贯。
低召回率问题：未能检索到所有相关文档块，影响大语言模型获取足够的背景信息来合成答案。
过时信息问题：数据的冗余或过时可能导致检索结果的不准确性。

回应生成质量

低精度问题：错误信息：模型可能在缺乏足够上下文的情况下虚构答案。
低召回率问题：回答不相关性：模型生成的答案可能未能准确针对查询问题。
过时信息问题：有害或偏见性回应：生成的回应可能包含有害或偏见性内容。

增强过程

上下文融合：如何有效将检索到的文段上下文融入当前生成任务，避免内容杂乱无章。
处理冗余和重复：多个检索到的文段包含相似信息时，需要避免内容重复。
评估文段价值：判断多个检索到的文段对生成任务的重要性或相关性。
保持输出一致性：检索到的内容可能风格或语调不同，需调和差异以确保输出的一致性。

Advanced RAG

Advanced RAG是为了解决Naive RAG的不足而开发的，它实现了预检索和后检索策略。为了解决Naive RAG在索引过程中遇到的挑战，Advanced RAG改进了其索引方法，使用了滑动窗口、细粒度分割和元数据等技术。它还引入了各种方法来优化检索过程。

预检索过程

优化数据索引：优化数据索引的目标是提高被索引内容的质量。这涉及五种主要策略：增强数据粒度、优化索引结构、添加元数据、对齐优化和混合检索。

增强数据粒度旨在提高文本的标准化、一致性、事实准确性和丰富上下文，以改善RAG系统的性能。这包括移除无关信息、消除实体和术语的歧义、确认事实准确性、保持上下文和更新过时文档。
优化索引结构涉及调整块的大小以捕获相关上下文，跨多个索引路径查询，并利用图结构中的节点关系来捕获相关上下文。
添加元数据信息涉及将引用的元数据（如日期和目的）整合到块中以用于过滤，并整合章节和子部分的参考元数据以提高检索效率。
对齐优化通过在文档中引入“假设性问题”来解决文档之间的对齐问题和差异。
混合检索指通过多路召回的方式进行检索融合。

检索：在检索阶段，主要关注点是通过计算查询和块之间的相似度来识别适当的上下文。嵌入模型是这个过程的核心。在高级RAG中，嵌入模型有优化的潜力。

微调嵌入模型。微调嵌入模型显著影响RAG系统中检索内容的相关性。这个过程涉及定制嵌入模型以增强特定领域背景下的检索相关性，特别是对于处理不断演变或罕见术语的专业领域。
动态嵌入适应于单词使用的上下文，与静态嵌入不同，后者为每个单词使用单一向量。

检索后处理：从数据库检索到有价值的上下文后，关键是将其与查询合并作为LLMs的输入，同时解决上下文窗口限制带来的挑战。简单地一次性向LLM展示所有相关文档可能会超出上下文窗口限制，引入噪声，并妨碍对关键信息的关注。需要对检索到的内容进行额外处理以解决这些问题。

Rerank。重新排名检索到的信息，将最相关内容重新定位到提示的边缘，是一个关键策略。
提示压缩。研究表明，检索文档中的噪声对RAG性能有不利影响。在后处理中，重点是压缩无关上下文，突出关键段落，并减少整体上下文长度。

Modular RAG

模块化RAG结构与传统的朴素RAG框架不同，提供了更大的灵活性和适应性。能针对不同问题调整和优化模块。它通过改进搜索和整合多种信息源，提高了解决问题的能力，模块化RAG范式在RAG领域越来越成为常态。

新模块

搜索模块：相比于前面提及的RAG中的简单搜索，搜索模块针对特定场景进行定制，并结合了对额外语料库的直接搜索。这种整合是通过LLM生成的代码、SQL或Cypher等查询语言以及其他自定义工具实现的。
记忆模块：借助大模型本身的记忆功能来实现，寻找和大模型历史回复最接近的，来进行回复。
融合：RAG-Fusion通过使用大模型技术对用户的原始Query和历史对话信息进行扩写（改写），生成multi-queries，从而增强了传统搜索系统，解决了它们的局限性。
路由：根据查询内容选择最佳数据源或路径，整合不同来源的信息，选择合适的数据存储，如向量存储、图数据库或关系数据库。
预测：解决了检索内容中常见的冗余和噪声问题。该模块不直接从数据源检索，而是利用LLM生成必要的上下文。
任务适配器：将RAG适配到各种下游任务，自动化检索过程，提高跨任务的通用性，使用LLM作为查询生成器，开发特定任务的端到端检索器。

这些模块共同提升了RAG系统的性能，使其能够适应不同的应用场景和任务需求。模块化RAG的设计允许研究者和开发者根据特定需求定制系统，实现更好的性能和更高的适应性。通过这种模块化方法，RAG技术能够更有效地解决复杂的信息检索和生成任务，同时保持系统的可维护性和可扩展性。

新模式

RAG本就是一个高度组织性的项目，在迭代过程中，是需要对这些模块进行优化和调整的，而往里面新增模块。主要有两种形式：

直接进行增加和替换。
调整模块之间的协同流程，尤其是大模型和检索模块之间的互动。

优化RAG流水线

检索过程的优化旨在提高RAG系统中信息的效率和质量。当前研究集中在整合多样化的搜索技术、精炼检索步骤、融入认知回溯、实施多功能查询策略和利用嵌入相似性。这些努力共同旨在在检索效率和RAG系统中上下文信息深度之间实现平衡。

检索过程的优化：旨在提高RAG系统中信息的效率和质量。当前研究集中在整合多样化的搜索技术、精炼检索步骤、融入认知回溯、实施多功能查询策略和利用嵌入相似性。这些努力共同旨在在检索效率和RAG系统中上下文信息深度之间实现平衡。
混合搜索探索：RAG系统通过智能整合各种技术（包括基于关键词的搜索、语义搜索和向量搜索）来优化其性能。这种方法利用每种方法的独特优势，以适应多样化的查询类型和信息需求，确保持续检索到高度相关和内容丰富的信息。混合搜索的使用作为检索策略的有力补充，从而增强了RAG流水线的整体效能。
递归检索和查询引擎：递归检索涉及在初始检索阶段获取较小的块以捕获关键的语义含义。随后，在过程的后期阶段向LLM提供包含更多上下文信息的较大块。这种两步检索方法有助于在效率和提供丰富上下文的响应之间取得平衡。
子查询：根据场景，可以采用各种查询策略。
假设文档嵌入：HyDE基于这样一个信念：生成的答案可能在嵌入空间中比直接查询更接近。使用LLM，HyDE为查询创建一个假设性文档（答案），嵌入这个文档，并使用结果嵌入来检索与假设文档相似的真实文档。这种方法不是基于查询寻求嵌入相似性，而是关注从一个答案到另一个答案的嵌入相似性。然而，它可能不会始终产生理想的结果，特别是当语言模型对主题不熟悉时，可能导致更多错误实例。

RAG技术详解

1. 分块 & 向量化

首先我们需要为文档内容创建向量索引，然后在运行时搜索与查询向量余弦距离最近的向量索引，这样就可以找到与查询内容最接近语义的文档。

1.1 分块

Transformer 模型具有固定的输入序列长度，即使输入上下文窗口很大，一个句子或几个句子的向量也比几页文本的向量更能代表其语义含义，因此对数据进行分块—— 将初始文档拆分为一定大小的块，而不会失去其含义。有许多文本拆分器实现能够完成此任务。

块的大小是一个需要重点考虑的问题。块的大小取决于所使用的嵌入模型以及模型需要使用 token 的容量。如基于 BERT 的句子转换器，最多需要 512 个 token，OpenAI ada-002 能够处理更长的序列，如 8191 个 token，但这里的折衷是 LLM 有足够的上下文来推理，而不是足够具体的文本嵌入，以便有效地执行搜索。

1.2 向量化

下一步是选择一个搜索优化的模型来嵌入我们的块。有很多选项，比如bge-large或E5嵌入系列。只需查看MTEB 排行榜以获取最新更新即可。

2. 搜索索引

2.1 向量存储索引

RAG 管道的关键部分是搜索索引，它存储了我们在上一步中获得的向量化内容。最原始的实现是使用平面索引——查询向量和所有块向量之间的暴力计算距离。为了实现1w+元素规模的高效检索，搜索索引应该采用向量索引，比如faiss、以及annoy。这些工具基于近似最近邻居算法，如聚类、树结构或HNSW算法。此外，还有一些托管解决方案，如 OpenSearch、ElasticSearch 以及向量数据库，它们自动处理上面提到的数据摄取流程，例如Pinecone、Weaviate和Chroma。取决于你的索引选择、数据和搜索需求，还可以存储元数据，并使用元数据过滤器来按照日期或来源等条件进行信息检索。

2.2 分层索引

在大型数据库的情况下，一个有效的方法是创建两个索引——一个由摘要组成，另一个由文档块组成，然后分两步进行搜索，首先通过摘要过滤掉相关文档，然后只在这个相关组内搜索。

2.3 假设性问题和 HyDE

另一种方法是让LLM 为每个块生成一个问题，并将这些问题嵌入到向量中，在运行时对这个问题向量的索引执行查询搜索（将块向量替换为索引中的问题向量），然后在检索后路由到原始文本块并将它们作为 LLM 获取答案的上下文发送。这种方法提高了搜索质量，因为与实际块相比，查询和假设问题之间的语义相似性更高。还有一种叫做HyDE的反向逻辑方法——你要求 LLM 在给定查询的情况下生成一个假设的响应，然后将其向量与查询向量一起使用来提高搜索质量。

2.4 内容增强

这里的内容是将相关的上下文组合起来供 LLM 推理，以检索较小的块以获得更好的搜索质量。有两种选择：一种是围绕较小的检索块的句子扩展上下文，另一种是递归地将文档拆分为多个较大的父块，其中包含较小的子块。

2.4.1 语句窗口检索器

在此方案中，文档中的每个句子都是单独嵌入的，这为上下文余弦距离搜索提供了极大的查询准确性。为了在获取最相关的单个句子后更好地推理找到的上下文，我们将上下文窗口扩展为检索到的句子前后的 k 个句子，然后将这个扩展的上下文发送到 LLM。

绿色部分是在索引中搜索时发现的句子嵌入，整个黑色 + 绿色段落被送到 LLM 以扩大其上下文，同时根据提供的查询进行推理。

2.4.2 自动合并检索器（或父文档检索器）

这里的思路与语句窗口检索器非常相似——搜索更精细的信息片段，然后在在LLM 进行推理之前扩展上下文窗口。文档被拆分为较小的子块，这些子块和较大的父块有引用关系。

首先在检索过程中获取较小的块，然后如果前 k 个检索到的块中有超过 n 个块链接到同一个父节点（较大的块），我们将这个父节点替换成给 LLM 的上下文——工作原理类似于自动将一些检索到的块合并到一个更大的父块中，因此得名。请注意，搜索仅在子节点索引中执行。

2.5 融合检索或混合搜索

这是一个很早以前的思路：结合传统的基于关键字的搜索和现代语义或向量搜索，并将其结果组合在一个检索结果中。这里唯一的关键是如何组合不同相似度分数的检索结果。这个问题通常通过 Reciprocal Rank Fusion算法来解决，该算法能有效地对检索结果进行重新排序，以得到最终的输出结果。

混合或融合搜索通常能提供更优秀的检索结果，因为它结合了两种互补的搜索算法——既考虑了查询和存储文档之间的语义相似性，也考虑了关键词匹配。

3. 重排和过滤

我们使用上述任何算法获得了检索结果，现在是时候通过过滤、重排或一些转换来完善它们了。在 LlamaIndex 中，有各种可用的后处理器，根据相似性分数、关键字、元数据过滤掉结果，或使用其他模型（如 LLM）、sentence-transformer 交叉编码器，Cohere 重新排名接口或者基于元数据重排它们。这是将检索到的上下文提供给 LLM 以获得结果答案之前的最后一步。

现在，我们将探索更高级的 RAG 技术，比如查询转换和路由。这些技术涉及到大语言模型的使用，代表了一种更复杂的逻辑思维——在 RAG 流程中融合了 LLM 的推理能力。

4. 查询转换

查询转换是一系列技术，使用 LLM 作为推理引擎来修改用户输入以提高检索质量。有很多技术实现可供选择。

对于复杂的查询，大语言模型能够将其拆分为多个子查询。这些子查询会并行执行，检索到的信息随后被汇总到一个 LLM 提示词中。

5. 聊天引擎

关于构建一个可以多次用于单个查询的完美 RAG 系统的下一件工作是聊天逻辑，就像在 LLM 之前时代的经典聊天机器人中一样考虑到对话上下文。这是支持后续问题、代词指代或与上一个对话上下文相关的任意用户命令所必需的。它是通过查询压缩技术解决的，将聊天上下文与用户查询一起考虑在内。与往常一样，有几种方法可以进行上述上下文压缩——一个流行且相对简单的ContextChatEngine，首先检索与用户查询相关的上下文，然后将其与内存缓冲区中的聊天记录一起发送到 LLM，以便 LLM 在生成下一个答案时了解上一个上下文。更复杂的情况是CondensePlusContextCode——在每次交互中，聊天记录和最后一条消息被压缩到一个新的查询中，然后这个查询进入索引，检索到的上下文与原始用户消息一起传递给 LLM 以生成答案。

6. 查询路由

查询路由是 LLM 驱动的决策步骤，决定在给定用户查询的情况下下一步该做什么——选项通常是总结、对某些数据索引执行搜索或尝试许多不同的路由，然后将它们的输出综合到一个答案中。查询路由器还用于选择数据存储位置来处理用户查询。这些数据存储位置可能是多样的，比如传统的向量存储、图形数据库或关系型数据库，或者是不同层级的索引系统。在处理多文档存储时，通常会用到摘要索引和文档块向量索引这两种不同的索引。定义查询路由器包括设置它可以做出的选择。选择特定路由的过程是通过大语言模型调用来实现的，其结果按照预定义的格式返回，以路由查询指定的索引。如果是涉及到关联操作，这些查询还可能被发送到子链或其他智能体，如下面的多文档智能体方案所展示的那样。

7. 智能体（Agent）

智能体几乎从第一个 LLM API 发布开始就已经存在——这个思路是为一个具备推理能力的 LLM 提供一套工具和一个要完成的任务。这些工具可能包括一些确定性功能，如任何代码函数或外部 API，甚至是其他智能体。

让我们来看一下多文档智能体的方案—— 这是一个非常复杂的配置，涉及到在每个文档上初始化一个Agent，该智能体能进行文档摘要制作和传统问答机制的操作，还有一个顶层智能体，负责将查询分配到各个文档智能体，并综合形成最终的答案。

每个文档智能体都有两个工具：向量存储索引和摘要索引，它根据路由查询决定使用哪一个。对于顶级智能体来说，所有文档智能体都是其工具。

该方案展示了一种高级 RAG 架构，其中每个智能体都做路由许多决策。这种方法的好处是能够比较不同的解决方案或实体在不同的文档及其摘要中描述，以及经典的单个文档摘要和 QA 机制——这基本上涵盖了最常见的与文档集合聊天的用例。

这种复杂配置的缺点可以通过图片发现 —— 由于需要在智能体内部的大语言模型之间进行多次往返迭代，其运行速度较慢。顺便一提，LLM 调用通常是 RAG 管道中耗时最长的操作，而搜索则是出于设计考虑而优化了速度。因此，对于大型的多文档存储，建议考虑对此方案进行简化，以便实现扩展。

8. 响应合成

这是任何 RAG 管道的最后一步——根据我们检索的所有上下文和初始用户查询生成答案。最简单的方法是将所有获取的上下文（高于某个相关性阈值）与查询一起连接并提供给 LLM。但是，与往常一样，还有其他更复杂的选项，涉及多个 LLM 调用，以优化检索到的上下文并生成更好的答案。

响应合成的主要方法有：

通过将检索到的上下文逐块发送到 LLM 来优化答案
概括检索到的上下文，以适应提示
根据不同的上下文块生成多个答案，然后将它们连接或概括起来。

RAG融合

RAG融合是一种用于（可能）提升RAG应用检索阶段的技术。

下面这张图片展示了大概的工作流程。基本上，主要思路就是利用LLM来生成多个查询，期望能够通过这些查询让问题的各个方面在上下文中显现出来。之后你可以使用生成的查询进行向量搜索，并且基于其在结果集中的显示方式来对内容进行重新排序。

优点：

提供多样化的上下文：你可以从不同的角度查看用户的查询，所以顶级结果里会出现更多样化的内容片段。与专注于单一视角的内容段落相比，你更有可能看到能够涵盖话题多个方面的内容作为顶级结果出现。
额外的控制层面：像其他机器学习解决方案一样，RAG融合提供了额外的控制手柄，让你可以微调你的应用，并让它更加符合你的期望目标。
自动校正：通过使用LLM作为用户在文本框中输入内容与实际在数据库中搜索内容之间的中间人，你可以纠正拼写错误，添加与用户查询相关的上下文信息（关于用户的信息、时间、他们的账户状态等），以及潜在地筛选特定类型的内容。
成本：RAG融合虽然增加了对LLM的调用，但其成本效益存在争议。由于LLM通常基于令牌数量计费，RAG融合在生成查询时的令牌使用较少，因此成本较低，而生成回答时令牌使用较多，成本较高。尽管RAG融合增加了调用次数，但由于第一次调用成本低，且能减少后续的高成本调用，因此在成本上仍有优势。

缺点：

延迟:正如你现在可能知道的，LLMs需要大量的计算资源，因此它们的速度相对较慢。根据你的应用程序，向LLM发送一次额外的请求可能会让用户的体验变得糟糕，因为他们可能需要等待几百毫秒的时间。
自动纠错:是的，这是一个优点，但是当它不起作用时，也可能是一个缺点。这通常发生在你的内容包含内部术语或行话，而这些术语或行话没有出现在LLM学习过的数据中。在这种情况下，LLM可能会出现困惑并生成完全无关的查询，从而影响到最后的结果。
成本:如果RAG融合对你应用程序的整体效益贡献不大，你最终可能会花费更多的费用，但收益却很有限。

总结

RAG（Retrieval-Augmented Generation）是一种先进的技术框架，旨在通过结合大型语言模型（LLMs）的内在知识与外部数据源的动态知识库，提升模型在知识密集型任务中的准确性和可信度。RAG技术通过三个主要的发展阶段——Naive RAG、Advanced RAG和Modular RAG——不断演进，其中涉及关键组件如检索、生成和增强技术的优化。它通过索引、检索和生成步骤，使得模型能够处理大规模数据集，同时保持了数据的实时更新和安全性。RAG不仅提高了回答的准确性和减少了幻觉问题，还通过模块化设计提供了更高的灵活性和可定制性，使其能够适应各种应用场景和需求。此外，RAG技术的发展还包括了对多模态领域的扩展和评估方法的改进，为未来的研究方向和实际部署提供了坚实的理论和实践基础。