大规模语言模型（LLMs）已经成为我们生活和工作的一部分，它们以惊人的多功能性和智能化改变了我们与信息的互动方式。

然而，尽管它们的能力令人印象深刻，但它们并非无懈可击。这些模型可能会产生误导性的“幻觉”，依赖的信息可能过时，处理特定知识时效率不高，缺乏专业领域的深度洞察，同时在推理能力上也有所欠缺。

在现实世界的应用中，数据需要不断更新以反映最新的发展，生成的内容必须是透明可追溯的，以便控制成本并保护数据隐私。因此，简单依赖于这些“黑盒” 模型是不够的，我们需要更精细的解决方案来满足这些复杂的需求。正是在这样的背景下，检索增强生成技术（Retrieval-Augmented Generation，RAG）应时而生，成为LLM时代的一大趋势。

基础RAG架构

从上图可以看出基础RAG架构的流程是十分简单的，其最大的特点是数据单向流通。因此搭建一个这样的系统是十分快捷的，但离真正能投入到生产环境中使用还是很远的。为了增强原有架构的文档召回率和系统鲁棒性，其优化路径大致有两条：增加召回管道和增加反馈机制。增加召回管道就是查询变换（子查询、rag-fusion）、混合检索这类通过多路召回来最大化召回率的优化方法；增加反馈机制就是rerank、后退提示、self-rag这类基于原始结果进行优化来最大化准确率的优化方法。

通过这两条路径，原来的RAG架构的数据和信息不再是单向流通，而是多向且并行流通。

进阶RAG结构

为了给读者重呈现一个清晰的优化思路，本文将按照数据流动的方向从文本预处理、文本分块、嵌入、检索和生成等环节依次介绍各个优化方法。

文本数据预处理

不管RAG系统结构怎样复杂，由于其数据驱动的特性，高信噪比的数据仍然是十分重要的。在检索之前对原始数据的优化包括以下方法：

实体解析：消除实体和术语的歧义以实现一致的引用。例如，将“LLM”、“大语言模型”和“大模型”标准化为通用术语。文档划分：合理地划分不同主题的文档。不同主题的文档是集中在一处还是分散在多处？如果人类都不能轻松地判断出需要查阅哪个文档才能回答提问，那么检索系统也无法做到。数据增强：使用同义词、释义甚至其它语言的翻译来增加知识库的多样性。处理特殊数据：例如时间敏感数据，对于经常更新的主题，实施一种机制来使过时的文档失效或更新。增加元数据：增加内容摘要、时间戳、用户可能提出的问题等附加信息来丰富知识库。文本分块

通常被检索知识库中的数据量是远超于LLM所能接受的输入长度的，因此合理的分块（Chunking）应尽可能做到在不超出LLM输入长度限制的情况下，保证块之间的差异性和块内部的一致性。当然这是最理想的状态，在实际应用中，可能有一篇文档像散文一般，不同段落之间没有明显内容区别，段落内部又特别地“散”，整篇文档又特别地长。当然我们不可能先验地将文本按内容完美分块，毕竟下游还有LLM这样智能的模型可以发挥其“智慧”来回答用户问题，我们提供的块不过是“提示”。但我们仍然还是需要尽可能提供有用的信息给LLM，而不是提供无关的信息分散其注意力。因此，可以采用以下高级的分块方法：

句分割：使用NLTK或者spaCy库提供的句子分割功能，主流开发框架如langchain都有集成。递归分割：通过重复地应用分块规则来递归地分解文本。例如，在langchain中会先通过段落换行符（\n\n）进行分割。然后检查这些块的大小，如果大小不超过一定阈值，则该块被保留。对于超过阈值的块，使用单换行符（\n）再次分割。以此类推，不断根据块大小更新更小的分块规则（如空格，句号）。这种方法可以灵活地调整块的大小。例如，对于文本中的密集信息部分，可能需要更细的分割来捕捉细节；而对于信息较少的部分，则可以使用更大的块。语义分割：通过计算向量化后的文本的相似度来进行语义层面的分割。特殊结构分割：针对特定结构化内容（例如Markdown、LaTex、JSON等）的专门分割器。这些分割器特别设计来处理这些类型的文档，以确保正确地保留其结构。

分块还有一个因素比较重要，就是块的大小。除了嵌入模型，文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。处理长篇文章或书籍时，较大的分块有助于保留更多的上下文和主题连贯性；而对于社交媒体帖子，较小的分块可能更适合捕捉每个帖子的精确语义。如果用户的查询通常是简短和具体的，较小的分块可能更为合适；相反，如果查询较为复杂，可能需要更大的分块。实际场景中，我们可能还是需要不断实验调整，在一些测试中，128大小的分块往往是最佳选择，在无从下手时，可以从这个大小作为起点进行测试。

嵌入

接下来就是数据处理的最后一个环节，相当于数据的类型转换，即对文本数据使用嵌入（Embedding）模型进行向量化（Vectorization），以便于在检索阶段使用向量检索（Vector Retrieval）。嵌入阶段有以下几个可以优化的点：

尽量使用动态嵌入：动态嵌入相较于静态嵌入更能够处理一词多义的情况。例如：我买了一张光盘”，这里“光盘”指的是具体的圆形盘片，而在“光盘行动”中，“光盘”则指的是把餐盘里的食物吃光，是一种倡导节约的行为。语义完全不一样的词使用静态嵌入其向量是固定的。相比之下，引入自注意力机制的模型，如BERT，能够提供动态的词义理解。这意味着它可以根据上下文动态地调整词义，使得同一个词在不同语境下有不同的向量表示。微调嵌入：大多数嵌入模型都是在通用语料上进行训练的，有些项目为了让模型对垂直领域的词汇有更好的理解，会对嵌入模型进行微调。使模型能够对垂直领域词汇和通用词汇一视同仁，不被分散注意力。混合嵌入：对用户问题和知识库文本使用不同的嵌入模型。查询优化

在实际环境中，可能由于用户的表述多样性亦或是模糊的，导致在检索阶段召回率和准确率较低，这时就需要对查询做一个优化，能够规范和丰富查询所包含的信息，便于在系统中检索到与用户相关的文档。对查询的优化方法有以下几个：

查询重写：通过提示LLM或者使用专门的“问题重写器”（通常是经过微调的小型Transformer）来对用户的问题进行改写。后退提示：提示LLM提出一个关于高层次概念或原则的抽象通用问题（称之为“后退”问题）。后退问题的抽象程度需要根据特定任务进行调整。最终后退问题和原始问题一起进行检索。例如，对于问题“Estella Leopold在1954年8月至11月期间上了哪所学校？”这个问题很难直接解决，因为有时间范围的详细限制。在这两种情况下，提出一个后退问题“Estella Leopold的教育经历怎么样的？”则有助于系统的检索。Follow Up Questions：使用LLM针对历史对话和当前问题生成一个独立问题。这个方法主要针对以下情况：a. 后续问题建立在前一次对话的基础上，或引用了前一次谈话。例如，如果用户先问“我在意大利能做什么”，然后问“那里有什么类型的食物”——如果只嵌入“那里有哪种类型的食物“，LLM就不知道“那里”在哪里。b.嵌入整个对话（或最后k条消息）。如果后续问题与之前的对话完全无关，那么它可能会返回完全无关的结果，从而在生成过程中分散LLM的注意力。HyDE：用LLM生成一个“假设”答案，将其和问题一起进行检索。HyDE的核心思想是接收用户提问后，先让LLM在没有外部知识的情况下生成一个假设性的回复。然后，将这个假设性回复和原始查询一起用于向量检索。假设回复可能包含虚假信息，但蕴含着LLM认为相关的信息和文档模式，有助于在知识库中寻找类似的文档。多问题查询：基于原始问题，提示LLM从不同角度产生多个新问题或者子问题，并使用每一个新问题进行检索，在后续阶段使用RRF或者rerank合并来自不同问题的检索结果。例如，对于原始问题：谁最近赢得了总冠军，红袜队还是爱国者队？，可以生成两个子问题：a. 红袜者队上一次赢得总冠军是什么时候？b. 爱国者队上一次赢得总冠军是什么时候？检索

检索（Retrieval）最终的目标就是获取最相关的文档或者保证最相关的文档在获取的文档列表中存在。为了达成这个目标，该环节有以下几个优化方法：

上下文压缩：当文档块过大时，可能包含太多不相关的信息，传递这样的文档块可能导致更昂贵的LLM调用和更差的响应。上下文压缩的思想就是通过LLM的帮助根据上下文对单个文档内容进行压缩，或者对返回结果进行一定程度的过滤仅返回相关信息。句子窗口搜索：相反，文档文块太小会导致上下文的缺失。其中一种解决方案就是窗口搜索，该方法的核心思想是当提问匹配好文档块后，将该文档块周围的块作为上下文一并交给LLM进行输出，来增加LLM对文档上下文的理解。父文档搜索：父文档搜索也是一种很相似的解决方案，父文档搜索先将文档分为尺寸更大的主文档，再把主文档分割为更短的子文档两个层级，用户问题会与子文档匹配，然后将该子文档所属的主文档发送给LLM。自动合并：自动合并是在父文档搜索上更进一步的复杂解决方案。同样地，我们先对文档进行结构切割，比如将文档按三层树状结构进行切割，顶层节点的块大小为1024，中间层的块大小为512，底层的叶子节点的块大小为128。而在检索时只拿叶子节点和问题进行匹配，当某个父节点下的多数叶子节点都与问题匹配则将该父节点作为结果返回。混合检索：RAG系统从根本上来说是作为开放域、基于自然语言的问答系统。为了获得开放式用户查询的高事实召回率，概括和聚焦应用场景以选择合适的检索模式或组合至关重要。在大多数文本搜索场景中，主要目标是确保最相关的结果出现在候选列表中。混合检索通过混合多个检索方法来实现不同检索技术的协同作用从而能够最大化事实召回率。例如，可以采用向量检索+关键词检索的组合来构建RAG系统的检索模块。路由机制：当建立了多个针对不同数据类型和查询需求的索引后，例如，可能有一个索引专门处理摘要类问题，另一个专门应对直接寻求具体答案的问题，还有一个专门针对需要考虑时间因素的问题。这时就需要使用路由机制来选择最合适的索引进行数据检索，从而提升检索质量和响应速度。使用Agent：该方法就是使用Agent来决定应该采用什么样的检索方法，从不同的检索方法中选取一种或多种进行召回。同时组合方式也是灵活的，是垂直关系还是平行关系。例如：对于查询“最新上映的科幻电影推荐”，Agent可能首先将其路由至专门处理当前热点话题的索引，然后利用专注于娱乐和影视内容的索引来生成相关推荐。检索后处理

检索后处理这个概念还是很宽泛的，是对检索结果进行进一步的处理以便于后续LLM更好的生成，比较典型的就是重排序（Rerank）。向量检索其实就是计算语义层面的相似性，但语义最相似并不总是代表最相关。重排模型通过对初始检索结果进行更深入的相关性评估和排序，确保最终展示给用户的结果更加符合其查询意图。实现重排序除了可以提示LLM进行重排，更多的是使用了专门的重排序模型（例如闭源的有Cohere，开源有BAAI和IBM发布的模型）。这些模型会考虑更多的特征，如查询意图、词汇的多重语义、用户的历史行为和上下文信息，从而保证最相关的文档排在结果列表的最前面。

生成

在生成（Generation）阶段的优化更多的是考虑用户体验，有以下几点可以供参考：

多轮对话：也就是带聊天历史的RAG，以AI搜索为例，明星产品perplexity就是支持多轮对话的，这样用户可以通过连续对话来深入了解解决某个问题。增加追问机制：在prompt中加入“如果无法从背景知识回答用户的问题，则根据背景知识内容，对用户进行追问，问题限制在3个以内”。这个机制并没有什么技术含量，主要依靠大模型的能力。不过大大改善了用户体验，用户在多轮引导中逐步明确了自己的问题，从而能够得到合适的答案。prompt优化：RAG系统中的prompt应明确指出回答仅基于搜索结果，不要添加任何其他信息。例如，可以设置prompt：“你是一名智能客服。你的目标是提供准确的信息，并尽可能帮助提问者解决问题。你应保持友善，但不要过于啰嗦。请根据提供的上下文信息，在不考虑已有知识的情况下，回答相关查询。”当然也可以根据场景需要，适当让模型的回答融入一些主观性或其对知识的理解。此外，使用Few-shot的方法指导LLM如何利用检索到的知识，也是提升LLM生成内容质量的有效方法。用户反馈循环：基于现实世界用户的反馈不断更新数据库，标记它们的真实性。结语

以上这些方法就是针对基础RAG在各个环节的优化方法，在实际开发过程中并不是所有方法都是有效的，不同问题有不同的解决方案，针对应用场景选择合适的优化方法组合才能最大限度发挥RAG的作用。

这里再贴一个Github链接：https://github.com/Jenqyang/LLM-Powered-RAG-System

收集了一些优秀的RAG项目以及开发框架，欢迎Star~✨