1. 背景介绍
RAG（Retrieval Augmented Generation，检索增强生成 ）方法是指结合了基于检索的模型和生成模型的能力，以提高生成文本的质量和相关性。该方法是Meta在2020年发表的文章《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出的，该方法让LM（Language Model，语言模型）能够获取内化知识之外的信息，并允许LM在专业知识库的基础上，以更准确的方式回答问题。而在大模型时代，它更是用于解决幻觉问题、知识时效问题、超长文本问题等各种大模型本身制约或不足的必要技术。
2. RAG的挑战
RAG主要面临三个方面的挑战：检索质量、增强过程和生成质量。
2.1 检索质量
语义歧义
：向量表示（例如词嵌入）可能无法捕捉概念之间的细微差别。例如，“苹果”一词可能指的是水果或科技公司。嵌入可能会混淆这些含义，导致不相关的结果。
用户输入变复杂
：与传统关键词或者短语搜索逻辑不太一致，用户输入问题不再是词或者短句，而是转变成自然对话声知识多轮对话数据，问题形式更加多元，紧密关联上下文，输入风格更加口语化。
文档切分
：文档切分主要有两种方式：一种是基于形式的切分，比如利用标点和段落的结束；另一种是基于文档内容的意义进行切分。如何将这些文档块转换成电脑能够理解和比较的形式（即“嵌入”），进而影响这些块与用户搜索内容的匹配程度。
多模内容的提取及表征（例如表格、图表、公式等）
：如何对多模内容进行提取及动态表征，是目前面临的现实问题，尤其是处理那些含糊或负面的查询，对 RAG 系统的性能有显著影响。
2.2 增强过程
上下文的集成
：这里的挑战是将检索到的段落的上下文与当前的生成任务顺利地集成。如果做得不好，输出可能会显得脱节或缺乏连贯性。
冗余和重复
：如果多个检索到的段落包含相似的信息，则生成步骤可能会产生重复的内容。
排名和优先级
：确定多个检索到的段落对于生成任务的重要性或相关性可能具有挑战性。增强过程必须适当权衡每个段落的价值。
2.3 生成质量
过度依赖检索内容
：生成模型可能过于依赖增强信息，导致幻觉问题突出，而不是增加价值或提供合成。
无关性
：这是另一个令人担忧的问题，即模型生成的答案无法解决查询问题。
毒性或偏见
：这也是另一个问题，即模型生成的答案有害或令人反感。
3. 整体架构
3.1 产品架构
从图上可以清晰的看出，整个产品架构包含如下四层：
最底层是模型层。在模型层屏蔽掉了模型的差异，不仅可以支持自研的序列猴子，也可以支持开源的大模型，第三方的模型。此外，为了优化embedding的效果，提出一种跨语言Embedding模型，有效的解决跨语言检索问题，同时提高了模型的效果。
离线理解层。在该层，主要围绕智能知识库和搜索增强两个模块设计的。关于智能知识库主要负责将非结构化的文本进行处理，从而转化为检索知识库，主要包括文本解析，表格识别，OCR识别等。搜索增强通过引入问句改写、重排等模块，保证检索的精准度。
在线问答层，为了满足产品设计需要，这里支持多文档、多轮次、多模态及安全性与拒识等，在一定程度上提高了产品的竞争力，同时也满足了不同场景的用户需求。
场景层，针对不同行业的特点，预制多种场景类角色，降低产品使用门槛。
3.2 技术架构
为了理解检索增强生成框架，我们将其分为三个主要组成部分：query理解、检索模型和生成模型。
query理解：该模块旨在对用户的query进行理解或者将用户的query生成结构化的查询，既可以查询结构化的数据库也可以查询非结构化的数据，进而提高召回率。该模块包括四部分，他们分别是
query改写，query扩写和意图识别等
。各个模块的介绍我们将在之后的章节进行详细介绍。
检索模型：该模型旨在从给定的文档集或知识库中检索相关信息。他们通常使用信息检索或语义搜索等技术来根据给定的查询识别最相关的信息。基于检索的模型擅长查找准确且具体的信息，但缺乏生成创意或新颖内容的能力。从技术上来讲， 检索模型主要包括
文档加载、文本转换、Embedding等模块
。我们将在之后的章节中详细介绍。
生成模型：该模型旨在根据给定的Prompt或上下文生成新内容。目前，生成模型可以生成富有创意且连贯的文本，但它们可能会在事实准确性或与特定上下文的相关性方面遇到困难。在RAG框架中，生成模型主要包括
chat系统（长期记忆和短期记忆）、Prompt优化等
。这些内容在之后的章节中也会介绍。
总之，检索增强生成结合了检索模型和生成模型优势，克服它们各自的局限性。在此框架中，基于检索的模型用于根据给定的查询或上下文从知识库或一组文档中检索相关信息。然后，检索到的信息将用作生成模型的输入或附加上下文。通过整合检索到的信息，生成模型可以利用基于检索的模型的准确性和特异性来生成更相关、更准确的文本。这有助于生成模型立足于现有知识，生成与检索信息一致的文本。
4. Query理解
目前，RAG系统可能会遇到从知识库中检索到与用户query不相关的内容。这是由于如下问题：（1）用户问题的措辞可能不利于检索，（2）可能需要从用户问题生成结构化查询。为了解决上述问题，我们引入query理解模块。
4.1 意图识别
意图识别是指接收用户的query和一组"选择"（由元数据定义）并返回一个或多个选定的"选择模块"。它既可以单独使用（作为 "选择器模块"），也可以作为查询引擎或检索器使用（例如，在其他查询引擎/检索器之上）。它是原理简单但功能强大的模块，目前主要利用 LLM 实现决策功能。它可以应用于如下场景：
决定是进行摘要（如使用摘要索引查询引擎）还是进行语义搜索（如使用矢量索引查询引擎）；
决定是否一次 "尝试 "多种选择并将结果合并（使用多路由功能）。
核心模块有以下几种形式：
LLM 选择器将选择作为文本转储到提示中，并使用 LLM 做出决定；
构建传统的分类模型，包括基于语义匹配的分类模型、Bert意图分类模型等。
4.2 Query改写
该模块主要利用LLM重新措辞用户query，而不是直接使用原始的用户query进行检索。这是因为对于RAG系统来说，在现实世界中原始query不可能总是最佳的检索条件。
4.2.1 HyDE
Hypothetical Document Embeddings（HyDE）是一种生成文档嵌入以检索相关文档而不需要实际训练数据的技术。首先，LLM创建一个假设答案来响应query。虽然这个答案反映了与query相关的模式，但它包含的信息可能在事实上并不准确。接下来，query和生成的答案都被转换为嵌入。然后，系统从预定义的数据库中识别并检索在向量空间中最接近这些嵌入的实际文档。
4.2.2 Rewrite-Retrieve-Read
这项工作引入了一个新的框架--Rewrite-Retrieve-Read，从query改写的角度改进了检索增强方法。之前的研究主要是调整检索器或LLM。与之不同的是，该方法注重query的适应性。因为对于 LLM 来说，原始query并不总是最佳检索结果，尤其是在现实世界中。首先利用LLM 进行改写query，然后进行检索增强。同时，为了进一步提高改写的效果，应用小语言模型（T5）作为可训练的改写器，改写搜索query以满足冻结检索器和 LLM的需要。为了对改写器进行微调，该方法还使用伪数据进行有监督的热身训练。然后，将 "先检索后生成 "管道建模为强化学习环境。通过最大化管道性能的奖励，改写器被进一步训练为策略模型。
4.3 Query扩写
该模块主要是为了将复杂问题拆解为子问题。该技术使用分而治之的方法来处理复杂的问题。它首先分析问题，并将其分解为更简单的子问题，每个子问题会从提供部分答案的相关文件检索答案。然后，收集这些中间结果，并将所有部分结果合成为最终响应。
4.3.1 Step-Back Prompting
该工作探索了LLM如何通过抽象和推理两个步骤来处理涉及许多低级细节的复杂任务。第一步先是使用 LLM "后退一步"生成高层次的抽象概念，将推理建立在抽象概念的基础上，以减少在中间推理步骤中出错的概率。这种方法即可以在有检索的情况下使用，也可以在无检索的情况下使用。当在有检索情况下使用时，抽象的概念和原始问题都用来进行检索，然后这两个结果都用来作为LLM响应的基础。
4.3.2 CoVe
Chain of Verification (CoVe) 旨在通过系统地验证和完善回答以尽量减少不准确性，从而提高大型语言模型所提供答案的可靠性，特别是在事实性问题和回答场景中。它背后的概念是基于这样一种理念，即大型语言模型（LLM）生成的响应可以用来验证自身。这种自我验证过程可用于评估初始响应的准确性，并使其更加精确。
在RAG系统中，针对用户实际场景中日益复杂的问题，借鉴了 CoVe技术，将复杂 Prompt 拆分为多个独立且能并行检索的搜索友好型query，让LLM对每个子查询进行定向知识库搜索，最终提供更准确详实答案的同时减少幻觉输出。
4.3.3 RAG-Fusion
在这种方法中，原始query经过LLM 生成多个query。然后可以并行执行这些搜索查询，并将检索到的结果一并传递。当一个问题可能依赖于多个子问题时，这种方法就非常有用。RAG-Fusion便是这种方法的代表，它是一种搜索方法，旨在弥合传统搜索范式与人类查询的多面性之间的差距。这种方法先是采用LLM生成多重查询，之后使用倒数排名融合（Reciprocal Rank Fusion，RRF）来重新排序。
4.3.4 ReAct
最近，在RAG系统中，使用ReAct思想，将复杂查询分解成更简单的"子查询"，知识库的不同部分可能会围绕整个查询回答不同的 "子查询"。这对组合图尤其有用。在组成图中，一个查询可以路由到多个子索引，每个子索引代表整个知识语料库的一个子集。通过查询分解，我们可以在任何给定的索引中将查询转化为更合适的问题。
ReAct的模式如上图所示，它是将思维链提示（Chain of Thoughts，简写为CoT）和Action计划生成结合起来，相互补充增强，提升大模型解决问题的能力。其中CoT的Reasoning推理跟踪有助于模型诱导、跟踪和更新行动计划以及处理异常。Action操作允许它与知识库或环境等外部来源接口并收集其他信息。
4.4 Query重构
考虑Query理解模块整体pipeline的效率，参考Query改写和Query扩写核心思想，自研了Query重构模块，该模块强调了通过一次请求，实现对原始用户输入的复杂问题进行改写、拆解和拓展，挖掘用户更深层次的子问题，从而借助子问题检索效果更高的特点来解决复杂问题检索质量偏差的问题，旨在提高查询的准确性和效率。
5. 检索模型
5.1 检索模型的挑战
依赖于外部数据是否有合理的分割（不能所有的知识转化成一个向量，而是需要分割数据后转化再存入向量数据库）
依赖于Prompt拼接，当我们将返回的最相似的文档进行排序后，与用户的问题一起送给大模型，实际上是想让大模型在长上下文中准确识别定位到合适的内容进行回答。
《Lost in the Middle: How Language Models Use Long Contexts》文章指出，当相关信息出现在输入上下文的开头或结尾时，性能往往最高，而当模型必须在长上下文中间获取相关信息时，性能会明显下降，即使对于明确的长上下文模型也是如此。
5.2 架构
5.3 文档加载器
文档加载器提供了一种 "加载 "方法，用于从配置源加载文档数据。文档数据是一段文本和相关元数据。文档加载器可从多种不同来源加载文档。例如，有一些文档加载器可以加载简单的 .txt 文件或者加载任何网页的文本内容，甚至加载 YouTube 视频的副本。此外，文档加载器还可以选择实现 "懒加载"，以便将数据懒加载到内存中。
5.4 文本转换器
检索的一个关键部分是只获取文档的相关部分。当加载文档后，通常需要对其进行转换，以便更好地适应应用程序。这涉及几个转换步骤，以便为检索文档做好准备。其中一个主要步骤是将大型文档分割（或分块）成较小的块，即文本转换器。最简单的例子是，当需要处理长篇文本时，有必要将文本分割成若干块，以便能放入模型的上下文窗口中。理想情况下，希望将语义相关的文本片段放在一起。这听起来很简单，但潜在的复杂性却很大。
