RAG 的总结整理

RAG，全称为 Retrieval-Augmented Generation，即检索增强生成。它是一种结合了检索和生成的技术方法，将传统的基于检索的问答系统和基于自然语言生成的技术相结合，提升了 AI 系统在回答自然语言问题时的准确性和可靠性。

基础背景

优势

RAG 具有多方面的显著优势，使其在自然语言处理领域中占据重要地位。

- 知识更新灵活性高。与传统的微调方法相比，RAG 无需对整个模型进行大规模的重新训练，只需更新知识库中的数据，就能让模型获取到最新的知识信息。例如，在金融领域，市场数据和法规政策不断变化，RAG 系统可以及时将新的股票行情、政策法规等信息纳入知识库，使模型能够快速适应这些变化，为用户提供基于最新信息的准确回答。

- 可扩展性强。RAG 能够轻松应对大规模数据的处理需求，随着检索语料库规模的不断扩大，其性能不会受到明显影响。这是因为它可以灵活地从海量数据中检索出与问题相关的信息，而无需像一些传统模型那样在数据量增加时面临性能瓶颈。以大型电商平台的客服系统为例，随着商品种类和用户数量的不断增加，相关的知识库也在持续扩充，但 RAG 系统依然能够高效地检索和利用这些知识，为用户提供精准的购物咨询服务。

- RAG 在处理复杂任务和开放领域问题时表现出色。它能够从广泛的知识源中检索信息，为模型提供丰富的上下文，从而更好地理解和处理复杂的自然语言任务。无论是多轮对话、长篇文档的理解与生成，还是涉及多个领域知识的综合性问题，RAG 都能通过检索相关信息，为生成准确、全面的回答提供有力支持。例如，在智能写作助手应用中，当用户需要撰写一篇关于科技发展趋势的文章时，RAG 可以从众多的科技文献、新闻报道、行业分析等资料中检索相关信息，并整合到生成的文章中，使文章内容更加丰富、有深度。

不足

- RAG 对文档质量的依赖程度较高。如果知识库中的文档内容不准确、过时、存在噪声或格式不规范，将会直接影响检索的准确性和生成答案的质量。例如，在一个技术文档知识库中，如果部分文档存在错误的技术参数或过时的技术描述，RAG 系统在检索和利用这些文档时，可能会生成错误的技术解答，误导用户。而且，文档的切分粒度也会对模型性能产生影响，如果切分不当，可能导致信息碎片化或关键信息被分割在不同的块中，影响检索效果。

- RAG 还可能产生不准确的回答。即使检索到的文档本身信息准确，但由于模型在整合和生成答案过程中的局限性，仍然可能出现回答不准确的情况。例如，当需要对检索到的多个信息片段进行综合推理和判断时，模型可能会出现失误，导致生成的答案与实际情况不符。此外，如果检索到的文档与问题的相关性判断不准确，也会使生成的答案偏离主题或无法满足用户的需求。

模块化RAG的优化

索引模块优化

Chunk 优化

- 在进行 Chunk 优化时，滑动窗口的设置需要综合考虑多方面因素。如果滑动窗口设置过大，虽然能包含更多的上下文信息，但也可能会引入过多的无关信息，增加检索的负担和噪声；反之，若设置过小，则可能导致信息碎片化，使关键信息被分割在不同的 Chunk 中，影响检索的准确性。例如，在处理一篇科技文献时，如果滑动窗口过大，可能会将多个不同主题的段落包含在一个 Chunk 中，导致检索时相关性判断不准确；而如果过小，可能会把一个完整的实验步骤或理论阐述分割开。因此，需要根据数据的特点和具体的应用场景，通过实验和分析来确定合适的滑动窗口大小，以平衡信息完整性和检索效率。

- Metadata 增强主要有两种方式。一种是直接丰富向量数据库中的 metadata 字段，这种方式可以通过添加诸如数据来源、创建时间、作者等信息，在检索时利用多路检索或混合检索技术，更精准地筛选出符合特定条件的信息。例如，在一个新闻资讯的 RAG 系统中，可以将新闻的发布时间、所属类别等信息作为 metadata，当用户查询特定时间段或特定主题的新闻时，能够快速定位到相关的 Chunk。另一种方式是将需要的信息直接加到文本中，适用于在文本被切分后可能出现信息丢失的情况，如后文使用缩写或代词指代前文内容时。通过将原始信息补充完整，可以提高检索的准确性。例如，一篇医学文献中，首次提到 “新冠病毒（COVID - 19）”，在后续的 Chunk 中可能仅使用 “病毒” 一词，那么在 Chunk 划分时将 “新冠病毒” 的完整信息添加到后续相关 Chunk 中，能避免检索时因信息缺失而导致的误判。

- Small to big 方法的原理在于，检索时先使用较小的 Chunk 进行匹配，确定大致的相关范围，然后再利用该范围前后的 Chunk 进行信息增强。这样可以在保证检索准确性的前提下，获取更丰富的上下文信息。例如，在回答一个关于历史事件的问题时，先通过与问题相关性较高的关键语句所在的小 Chunk 定位到事件的核心内容，再结合前后文的 Chunk，获取事件的背景、起因、影响等更全面的信息，从而为生成更完整、准确的回答提供支持。

结构组织优化

- 结构化存储是将非结构化的数据按照一定的结构进行组织，如构建树结构。在这种存储方式下，每个节点可以存储总结信息，通过分层检索的方式，可以快速定位到相关的信息层次，然后获取详细内容。其优点是检索路径清晰，能够有效减少检索的时间复杂度，适用于数据具有明显层次结构的场景，如企业的组织架构信息、知识图谱中的分类信息等。例如，在一个企业知识管理系统中，将不同部门、不同业务领域的知识按照树状结构进行存储，员工在查询与自己工作相关的知识时，可以先在对应的部门或业务领域节点下进行检索，提高检索效率。但这种方式的缺点是构建和维护结构的成本较高，需要对数据有深入的理解和规划，且当数据结构发生变化时，调整的难度较大。

- 知识图谱存储则是将数据以图结构的形式存储在数据库中，如微软提出的 GraphRAG。通过图检索，可以利用实体之间的关系快速找到相关信息。例如，在一个电影知识图谱中，通过演员、导演、电影类型等实体之间的关联关系，可以快速检索到某个演员参演的所有电影、某个导演执导的作品以及具有特定类型的电影集合等。然而，这种存储方式的代价高昂，无论是数据的存储成本还是检索时的计算成本都较高。后续虽有提出 light GraphRAG 等优化方案，但仍无法彻底解决成本问题。并且，对于复杂的知识图谱，数据的更新和维护也面临挑战，因为一个实体或关系的变化可能会影响到整个图谱的结构和语义。

PS. 业界有一个观点认为图数据并不一定非要存储在图数据库中，有很多公司在这个方面做过尝试了。现在一个比较好的解决方法是将图数据解析为一条条的chunk 然后存储在向量数据库中，可以通过Meta字段增加一些必要的信息

- 多向量存储是一种较为先进的存储方式，以 Jina - ColBERT 为代表，它为每个 token 生成一个向量，并通过 MaxSim 计算得分。这种方式的优势在于逐 token 编码提供了更细粒度的表征，在同领域中具有很高的 MRR@10（头部排序能力）和 Recall@1k（腰尾部召回能力），并且能够提供更好的可解释性。例如，在一个专业文献检索系统中，对于一些特定领域的术语和概念，多向量存储能够更精准地捕捉到其语义细节，提高检索的准确性。在跨领域场景下，特别是处理长尾查询或文档时，由于词粒度的精细表征，模型对于未见过的领域有更好的性能表现，能够更好地应对不同领域知识的多样性和复杂性。但多向量存储的缺点是成本较高，无论是向量生成过程中的计算资源消耗，还是存储这些大量向量所需的空间成本都较大，这限制了它在一些资源受限场景下的应用。

检索前优化

查询修改

- 查询修改是提高检索准确性的重要手段之一。重写和扩写是常见的方法，例如，当用户的查询为单个名词时，如 “苹果”，其意图可能非常模糊，可能是指水果苹果，也可能是苹果公司，或者是与苹果相关的其他概念。通过重写和扩写，可以将其变为 “苹果这种水果的营养价值”“苹果公司的最新产品” 等更具体的查询语句，从而更精准地定位到用户的需求。这样的操作可以帮助检索系统更好地理解用户的意图，克服单一查询的局限性，获得更丰富的检索结果集合。

- HyDE 方法则是借助 LLM 的力量，先根据客户的问题生成一份回答，然后对回答的内容进行 embedding，再检索相关的 Chunk 来修正其中的内容。例如，对于 “如何提高英语口语能力” 的问题，LLM 可能会生成诸如 “多与外教交流、观看英语电影、练习口语对话等” 的回答，然后将这个回答的文本进行 embedding 并检索相关的学习资料 Chunk，对回答进行补充和修正，以提供更准确、详细的信息。

- Step back prompting 逻辑较为独特，它将客户的 query 先抽象成为一个概念化的问题，在得到一个逻辑上的答复后，再根据这个答复的结果来辅助生成答案。比如，对于 “如何解决城市交通拥堵问题” 的查询，先抽象为 “城市交通问题的解决策略”，通过 LLM 得到诸如 “优化交通规划、发展公共交通、限制私家车出行” 等一般性的答复，然后再结合具体的城市情况、交通设施等信息，进一步生成针对该城市交通拥堵问题的详细解决方案。

查询路由

- 查询路由的作用在于根据不同的查询意图，将查询引导到相应的数据库或数据源进行检索，以提高检索的效率和准确性。不同的 prompt 可能涉及不同领域或类型的数据，这些数据可能存储在不同的 DB 中。例如，在一个企业级的信息检索系统中，关于产品销售数据的查询可能需要路由到销售数据库，而关于员工信息的查询则应路由到人力资源数据库。通过识别客户的意图，可以更好地判断应该查询哪个 DB，避免在无关的数据库中进行检索，从而减少检索时间和资源消耗，同时也能提高检索结果的相关性和准确性。实现查询路由的方式通常是基于规则或机器学习模型。基于规则的方法是预先设定一些关键词或查询模式与数据库的映射关系，当查询符合特定的规则时，就将其路由到对应的数据库。机器学习模型则可以通过对大量查询和其对应的正确数据库的学习，自动识别查询意图并进行路由决策。例如，可以使用分类模型，将查询分类到不同的领域或主题类别，然后根据类别与数据库的对应关系进行路由。

查询扩写

- Multi query 是指 LLM 将原始查询重写为多个语义相似的 queries，然后并发地进行检索。例如，对于查询 “人工智能在医疗领域的应用”，LLM 可能会生成 “人工智能在医学影像诊断中的应用”“人工智能在疾病预测中的应用”“人工智能辅助手术的应用” 等多个相似查询，并发地在知识库中检索相关信息。这种方式能够扩展可能不完整或不明确的初始查询，通过合并多个相关查询的检索结果，得到更全面、更丰富的信息集合。但这种方法可能会导致检索到更多的文档，其中可能存在一些冗余和无关的信息，需要在后续的处理中进行去重和筛选，以避免分散 LLM 的注意力，确保其能够有效地利用检索到的信息生成准确的答案。

- Sub query 则是将问题进行拆分，分别对每个子问题进行检索回答，最后将结果结合在一起产生最终的结果。比如对于 “介绍一下中国古代四大发明及其对世界文明的影响” 这个问题，可以拆分为 “中国古代四大发明是什么” 和 “中国古代四大发明对世界文明的影响分别是什么” 两个子问题。分别检索这两个子问题的答案后，再将它们整合起来，形成一个完整的回答。这种方式适用于复杂的问题，可以将其分解为相对简单的子问题，降低检索和回答的难度，提高答案的准确性和逻辑性。与 Multi query 相比，Sub query 更注重问题的分解和分步解决，而 Multi query 更侧重于通过多个相似查询来扩展信息的获取范围。

查询构建

- Text - to - SQL 方法主要应用于与数据库交互的场景，它能够根据用户输入的自然语言 prompt，将其转换为数据库的查询语句，从而精准地查询所需要的信息。例如，在一个电商数据库中，用户查询 “查询销售额大于 100 万的商品名称和销售数量”，Text - to - SQL 方法可以将这个自然语言查询转换为相应的 SQL 语句，如 “SELECT product_name, sales_quantity FROM sales_table WHERE sales_amount > 1000000”，然后在数据库中执行该语句，获取准确的结果。这种方法的优势在于能够充分利用数据库的强大功能进行高效的数据检索，尤其适用于大规模数据的查询和分析。在构建查询语句时，需要对数据库的结构和查询语言的语法有深入的理解，同时要确保转换的准确性和安全性，避免因错误的查询构建导致数据泄露或错误的结果。一些工具和框架，如 SQLAlchemy 等，可以辅助实现 Text - to - SQL 的功能，它们提供了方便的接口和函数，能够将自然语言映射到相应的 SQL 操作，简化了查询构建的过程。

检索后处理优化

重排序

- 重排序在 RAG 流程中起着至关重要的作用。由于向量的 embedding 本质上是对信息的压缩，会丢失大量信息，导致检索结果可能存在与问题相关性不高的情况。例如，JINA 的 embedding model 虽然能支持 8k 的上下文长度，但最终可能压缩到一个 1000 多维度的向量中，在这个过程中许多细节和语义信息被丢失。重排序就是要对检索到的文档进行重新评估和排序，筛选出与客户问题最相近的检索结果。斯坦福的研究人员在 23 年发表一篇paper，可以看到随着 retrieval documents 的增加整个模型回答的准确率其实是呈现一个碗状的，也就是首尾高，但是中间低，也就是所谓的 middle lost，指的就是当回答问题所需要的内容是在整个 prompt 前面时 LLM 最可能会正确回答。例如，在回答一个复杂的问题时，将最关键的信息放在开头的位置，能让 LLM 更好地捕捉到重点，从而生成更准确、更完整的答案。通过重排序，可以提高检索结果的质量，使得 LLM 在生成答案时能够基于更相关、更优质的信息，进而提升生成答案的准确性和可靠性。

压缩

- 在检索后处理中，压缩也是一个重要的环节。由于检索回来的内容可能存在信息过多以及重复的问题，这会给 LLM 的处理带来负担，并且可能影响生成答案的效率和质量。微软提出的 LLM lingua 就是一种有效的压缩方法。它使用一个小型语言模型，如 GPT2 - small 或 LLaMA - 7B，来检测并移除提示中不重要的 tokens。例如，在一篇关于历史事件的长篇检索结果中，可能存在许多描述性的、与核心事件关联不大的语句，LLM lingua 可以识别并去除这些冗余信息，将文本压缩成 LLM 能够更高效处理的形式。它能够实现高达 20 倍的压缩率，同时性能损失最小。LongLLMLingua 则更进一步，在进行压缩时考虑输入查询，移除一般不重要和对查询不重要的 tokens。这使得压缩后的信息更加精准地聚焦于回答问题所需的内容。例如，对于查询 “秦始皇统一六国的时间”，在检索结果中关于秦始皇其他方面的信息，如他的宫殿建设等内容就会被视为对该查询不重要的信息而被移除。

PS. 在使用压缩方法时，如果检索结果中包含关键数字等重要信息，要谨慎处理，避免因压缩而丢失关键数据，影响答案的准确性。

选择

- LLM critique 是检索结果选择常用的方法。它利用大模型来判断检索回来的内容是否需要用于生成答案，并给出一些评价指标，如检索内容与 query 的相关性、检索回来内容与 query 中实体的 recall 值等。例如，在一个问答系统中，对于检索到的关于 “太阳系行星” 的多篇文档，LLM critique 会评估每篇文档与用户查询 “太阳系中最大的行星是哪个” 的相关性，判断文档中是否提到了行星的大小比较等关键信息，以及对 “太阳系行星” 这一实体的召回是否完整。根据这些指标，可以筛选出与问题高度相关、信息完整的检索结果，排除那些相关性较低或信息冗余的文档。这样可以确保提供给 LLM 生成答案的信息是最有价值的，提高生成答案的准确性和质量。通过合理的选择，能够让 LLM 聚焦于关键信息，避免被无关或低质量的信息干扰，从而生成更符合用户需求的答案。

检索器和生成器优化

检索器

在普遍意义上的 retriever（即基于 vector 向量数据库检索文本信息的情况下） 本质上就是 embedding model 了。因为很多的 embedding 的model也是基于 transformer 训练的，所以可以简单的理解为训练集合与实际应用场景的数据分布差别过大，导致embedding效果不好。不同词汇在不同语境下的含义可能不同。所以必要情况下的微调是需要的，将基座模型的参数微调到 domain 数据的分布可以更好的检索回相关信息。当然微调的代价是比较大的，所以这里会有一个偷懒的办法就是在 下游接一个 adapter 来进行微调。

生成器

生成器也是一样的需要垂直领域数据进行微调，才可以更好的回答问题。具体的微调方法就很多了，lora，qlora 等，如果使用post-training 的话，强化学习人类偏好对齐也是必须的。否则可能会产生意想不到的回答。

在生成部分除去微调以外还有一个重要步骤就是验证信息：验证这个地方会比较 tricky 了,这部分其实很多人都有过探索，但是想要完美的实现都是很困难的。

- Knowledge base 的验证： 我个人感觉是只能验证一小部分信息是否合理，或者说根据某些knowledge graph 的数据是否和数据库中一直。但是想要完整的检查是不太现实的，假设我已经可以通过程序的方法检测到需要的内容是否正确了，那么我为什么还需要走 RAG 绕那么大一圈来产生回答呢？直接通过程序，最后format成一段话就好了

- LLM 当judge： 这个是最常见的，这里比较出名的一个工具是 RAGAS，里面包含了各种评价指标，包括刚刚提到的相关性等。在生成阶段，这里能有的指标就更多了，例如回答是否和检索回来内容冲突，回答内容是否和客户提问相关等，但是由于是LLM产生的判断，所以也不敢说100%是正确的。