Agentic APP 技术栈总结 - RAG

RAG

我们都知道 LLM 会有幻觉，当遇到它不会的问题时，可能会胡编乱造，答非所问。LLM 会出现幻觉的根源是训练数据会存在以下问题：

数据过时：LLM 训练使用的数据不可能有在训练开始时间点后产生的数据。
数据范围局限：LLM 虽然使用了大量语料数据进行训练，但也不可能包含所有数据，并且还有大量数据是非公开。
LLM 自身能力不足：训练时相关数据出现频率较低；训练与推理流程差异； RLHF 训练数据人类标注不当。

幻觉极大的降低了 LLM 生成质量，主要是缺少问题相关的信息。导致生成产生了偏差，无法正确回答。思考一下我们遇到不了解的问题时会如何做。一般通过搜索引擎，查阅书籍，或者与他人沟通，获取到相关信息，然后总结推断出答案。同样的处理方式也适用于 LLM 。所以这种通过检索相关信息，增加到 prompt 中，与问题一起输入 LLM ，从而得出正确回答的方式叫做 RAG (Retrieval-Augmented Generation) ，中文名：检索增强生成。

RAG 的概念最早出现在 Facebook AI Research 的论文 [2005.11401] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 中。其通常集成了外部知识库（Corpus ）、信息检索器（Retriever）、生成器（Generator，即大语言模型）等多个功能模块，针对不同的业务场景和需求，可以设计不同的系统架构来组合、协调这些模块，以优化RAG的性能。

大模型检索增强生成(RAG)高质量报告 - 知乎

综述

[2312.10997] Retrieval-Augmented Generation for Large Language Models: A Survey

RAG 通过将来自语言模型的参数化知识与来自外部知识库的大量非参数化数据相集成，在增强 LLM 能力方面取得的重大进展。RAG 框架内的三种开发范式：Naive、Advanced 和 Modular RAG，每种都标记为对其前身的逐步增强。高级 RAG 范例通过合并复杂的架构元素（包括查询重写、块重新排序和提示摘要），超越了 Naive 方法。这些创新带来了更加细致和模块化的架构，增强了LLM的性能和可解释性。 RAG 与微调和强化学习等其他人工智能方法的技术集成进一步扩展了其功能。在内容检索中，利用结构化和非结构化数据源的混合方法正在成为一种趋势，提供更丰富的检索过程。 RAG 框架内的前沿研究正在探索新的概念，例如LLM的自我检索和信息检索的动态定时。

尽管 RAG 技术取得了长足的进步，但在提高其稳健性和管理扩展上下文的能力方面仍有很多研究机会。 RAG 的应用范围也正在扩展到多模态领域，调整其原理来解释和处理不同的数据形式，例如图像、视频和代码。此次扩展凸显了 RAG 对人工智能部署的重大实际影响，吸引了学术界和工业界的兴趣。以 RAG 为中心的人工智能应用程序的增加和支持工具的持续开发凸显了 RAG 生态系统的不断发展。然而，随着 RAG 应用领域的扩大，迫切需要完善评估方法以跟上其发展的步伐。确保绩效评估保持准确和代表性对于充分了解 RAG 对人工智能研究和开发社区的贡献至关重要。

RAG 模型微调

RAG 的信息检索器需要一个 embedding 模型，生成器需要一个 LLM 大语言模型。两个模型需要协同工作方式可以从模型微调的角度进行分类。

1. 无微调

无微调架构是所有 RAG 架构中形式最简单的。该架构中，检索器 embedding 和大语言模型经过分别独立的预训练后参数不再更新，直接组合使用。这种架构对计算资源需求较低，方便实现且易于部署，适合于对部署速度和灵活性有较高要求的场景。In-Context RALM [2302.00083] In-Context Retrieval-Augmented Language Models 是该框架下的代表性方法。其直接将检索器检索到的文档前置到输入问题前作为上下文。In-ContextRALM 包括检索和生成两个阶段。在检索阶段，输入的问题或部分句子作为查询从知识库中检索出相关文档。在生成阶段，这些检索到的文档被直接拼接到 Prompt 中的上下文部分，然后将 Prompt 输入给大语言模型。一个RAG任务可能涉及多次执行检索和生成。例如，在一个长文本生成任务中，每生成一定量的文本后，模型就可能会执行一次检索，以确保随着话题的发展，后续生成的内容能够持续保持与话题相关。

In-Context RALM 在使 RALM 系统更加强大和普及方面可以发挥两个重要作用。首先，由于其简单的阅读机制，In-Context RALM 可以作为开发专门针对 LM 任务的文档检索方法的清晰探测器。这反过来可以用于改进In-Context RALM 和其他目前利用通用检索器的更复杂的 RALM 方法。其次，由于与现成的 LM 兼容，In-Context RALM 可以帮助推动RALM系统的更广泛部署。

使用现成的 LM 进行文档阅读，而无需对 LM 进行进一步的训练。
关注如何选择文档以提高 LM 性能

2. Embedding 模型微调

为了进一步提升效果，可以采用 Embedding 模型微调架构对检索器 Embedding 模型进行微调。在 Embedding 模型微调架构中，大语言模型的参数保持不变，仅用其输出指导 Embedding 模型的微调。这种架构下的 Embedding 模型能更好地适应大语言模型的需求，从而提高 RAG 的表现。

REPLUGLSR [2301.12652] REPLUG: Retrieval-Augmented Black-Box Language Models 是检索器微调框架的代表性方法。使用大语言模型的困惑度分数作为监督信号来微调检索器，使其能更有效地检索出能够显著降低语言模型困惑度的文档。其微调检索器的过程中采用 KL 散度损失函数来训练检索器，目的是对齐检索到的文档的相关性分布与这些文档对语言模型性能提升的贡献分布。

训练 推理生成

3. LLM 大语言模型微调

仅微调语言模型指的是检索器作为一个预先训练好的组件其参数保持不变，大语言模型根据检索器提供的上下文信息，对自身参数进行微调。RETRO 是仅微调语言模型的代表性方法之一。该方法通过修改语言模型的结构，使其在微调过程中能够将从知识库中检索到的文本直接融入到语言模型中间状态中，从而实现外部知识对大语言模型的增强。此外，SELF-RAG 通过在微调语言模型时引入反思标记，使语言模型在生成过程中动态决定是否需要检索外部文本，并对生成结果进行自我批判和优化。这些方法不仅提高了生成内容的质量和事实准确性，还增强了模型的知识整合与应用能力。

以 RETRO [2112.04426] Improving language models by retrieving from trillions of tokens 为例。RETRO 首先将知识库中的文本进行切块，然后用 BERT 对每个文本块生成嵌入向量。在微调模型时的自回归过程中，每当模型生成一段文本块后，就去知识库中检索出与之最相似的嵌入向量。然后将这些嵌入向量和模型注意力层的输出一起被送入一个外部的 Transformer 编码器进行编码。得到的编码向量直接输入给模型的块交叉编码器的键（key）和值（value），以捕捉外部知识的关键信息。通过交叉编码，模型能够结合检索到的相关信息来生成新的文本块

通过上述方式微调后的 RETRO 模型能够充分整合检索到的信息，生成连贯且富含信息的文本。面对用户查询时，模型能展现出优秀的理解能力和知识整合能力，大幅提升了生成的质量和准确性，尤其在处理复杂任务时，其表现更为突出。

4. Embedding 与 LLM 协同微调

Embedding 模型和 LLM 大语言模型协同微调的架构中，Embedding 模型和 LLM 大语言模型的参数更新同步进行。这种微调的方式使得 Embedding 模型能够在检索的同时学习如何更有效地支持语言模型的需求，而语言模型则可以更好地适应并利用检索到的信息，以进一步提升RAG的性能

Atlas [2208.03299] Atlas: Few-shot Learning with Retrieval Augmented Language Models 是该架构的代表性工作。与 REPLUG LSR 类似，其在预训练和微调阶段使用 KL 散度损失函数来联合训练检索器和语言模型，以确保检索器输出的文档相关性分布与文档对语言模型的贡献分布相一致。不同之处在于，Atlas在预训练和微调过程中，Embedding 模型和 LLM 大语言模型参数同步被更新，Embedding 模型学习向 LLM 大语言模型提供最相关的文档，而 LLM 大语言模型则学习如何利用这些文档来改善其生成内容。为了确保检索结果与模型最新状态保持同步，Atlas 同样需要定期更新语料库文档的向量编码，从而维持检索的准确性。

知识库

RAG 检索的信息来源是外部知识库，是 RAG 系统的根基。只有构建了全面、优质、高效的知识库，检索才能有的放矢，检索效果才能有保障。在 RAG 系统中，知识库构建主要涉及数据采集及预处理与知识库增强两个步骤。

数据来源有搜索引擎爬虫，内部 wiki 文档，数据库。数据格式可以有 html, pdf, 视频，音频，图片。数据采集则需要支持多种来源和格式的采集能力。这一步可以使用过往的各类成熟方案。

在采集到相应的数据后，还需通过数据预处理来提升数据质量和可用性。在构建文本型知识库时，数据预处理主要包括数据清洗和文本分块两个过程。数据清洗旨在清除文本中的干扰元素，如特殊字符、异常编码和无用的HTML标签，以及删除重复或高度相似的冗余文档，从而提高数据的清晰度和可用性。

1. 文本分块

文本分块是将长文本分割成较小文本块的过程，例如把一篇长文章分为多个短段落。对长文本进行分块有两个好处：

一是为了适应检索模型的上下文窗口长度限制，避免超出其处理能力；
二是通过分块可以减少长文本中的不相关内容，降低噪音，从而提高检索的效率和准确性。

文本分块的效果直接影响后续检索结果的质量。如果分块处理不当，可能会破坏内容的连贯性。因此，制定合适的分块策略至关重要，包括确定切分方法（如按句子或段落切分）、设定块大小，以及是否允许块之间有重叠。文本分块的具体实施流程通常开始于将长文本拆解为较小的语义单元，如句子或段落。随后，这些单元被逐步组合成更大的块，直到达到预设的块大小，构建出独立的文本片段。为了保持语义连贯性，通常还会在相邻的文本片段之间设置一定的重叠区域。

[2401.07883] The Chronicles of RAG: The Retriever, the Chunk and the Generator 该论文提出了 Relative Maximum Score 最大相关性得分的量化指标平文档分块的质量。通过将文档分割成 N 个 Chunks ，使用 LLM 基于文档分块生成一系列 chunk: {question, Answer} 组合的数据集，使用 LLM 评估数据集 QA 和 chunk 组合正确性时的得分，则是 Relative Maximum Score。

2. 知识增强

知识库增强是通过改进和丰富知识库的内容和结构，以提升其质量和实用性。这一过程通常涉及查询生成与标题生成等多个步骤，以此为文档建立语义"锚点"，方便检索时准确定位到相应文本。

[2404.05825] LLM-Augmented Retrieval: Enhancing Retrieval Models Through Language Models and Doc-Level Embedding

检索器优化

微软的知识库增强语言模型KBLaM

2410.10450 目前支持 llama-3-8B, llama-3.2-1B. Phi-3-mini-4k github.com/microsoft/k...

GitHub - microsoft/KBLaM: Official Implementation of "KBLaM: Knowledge Base augmented Language Model"

CoT RAG

[2501.14342] Chain-of-Retrieval Augmented Generation

HippoRAG

vbnet 复制代码

https://github.com/OSU-NLP-Group/HippoRAG 
From RAG to Memory: Non-Parametric Continual Learning for Large Language Models
https://arxiv.org/pdf/2502.14802

From RAG to Memory: Non-Parametric Continual Learning for Large Language Models

Modular RAG

[2407.21059] Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks

RAG 产品

GraphRAG

Welcome - GraphRAG GitHub - microsoft/graphrag: A modular graph-based Retrieval-Augmented Generation (RAG) system

microsoft.github.io/graphrag/

lightRAG

GitHub - HKUDS/LightRAG: "LightRAG: Simple and Fast Retrieval-Augmented Generation"

lightRAG (github.com/HKUDS/Light...%25E6%259D%25A5%25E5%25AF%25B9%25E6%25AF%2594%25EF%25BC%258C%25E5%2585%25B6%25E6%259D%25A5%25E8%2587%25AA%25E4%25BA%258Enano-graphra(https%3A%2F%2Fgithub.com%2Fgusye1234%2Fnano-graphrag)%25EF%25BC%258C%25E5%2585%25B6%25E5%25AE%259E%25E5%25B0%25B1%25E6%2598%25AF%25E5%25BE%25AE%25E8%25BD%25AFGraph%25E7%259A%2584%25E7%25AE%2580%25E5%258C%2596%25E7%2589%2588%25E6%259C%25AC%25EF%25BC%258C%25E5%25B0%2586%25E7%25A4%25BE%25E5%258C%25BA%25E3%2580%2581%25E7%25A4%25BE%25E5%258C%25BA%25E5%25AE%2585%25E6%2591%2598%25E8%25A6%2581%25E8%25BF%2599%25E4%25BA%259B%25E7%258E%25AF%25E8%258A%2582%25E5%2581%259A%25E4%25BA%2586%25E5%258E%25BB%25E9%2599%25A4%25EF%25BC%258C%25E8%25BF%2599%25E7%25A7%258D%25E5%258E%25BB%25E9%2599%25A4%25E6%2598%25AF%25E5%25A5%25BD%25E7%259A%2584%25EF%25BC%258C%25E4%25B8%258D%25E4%25BC%259A%25E5%25A4%25AA%25E9%2587%258D%25EF%25BC%258C%25E5%25AF%25B9%25E4%25BA%258E%25E7%259F%25A5%25E8%25AF%2586%25E6%259B%25B4%25E6%2596%25B0%25E4%25B9%259F%25E6%259B%25B4%25E5%25BF%25AB%25EF%25BC%259B "https://github.com/HKUDS/LightRAG，https://lightrag.github.io/，https://arxiv.org/pdf/2410.05779，https://microsoft.github.io/graphrag/)%E6%9D%A5%E5%AF%B9%E6%AF%94%EF%BC%8C%E5%85%B6%E6%9D%A5%E8%87%AA%E4%BA%8Enano-graphra(https://github.com/gusye1234/nano-graphrag)%EF%BC%8C%E5%85%B6%E5%AE%9E%E5%B0%B1%E6%98%AF%E5%BE%AE%E8%BD%AFGraph%E7%9A%84%E7%AE%80%E5%8C%96%E7%89%88%E6%9C%AC%EF%BC%8C%E5%B0%86%E7%A4%BE%E5%8C%BA%E3%80%81%E7%A4%BE%E5%8C%BA%E5%AE%85%E6%91%98%E8%A6%81%E8%BF%99%E4%BA%9B%E7%8E%AF%E8%8A%82%E5%81%9A%E4%BA%86%E5%8E%BB%E9%99%A4%EF%BC%8C%E8%BF%99%E7%A7%8D%E5%8E%BB%E9%99%A4%E6%98%AF%E5%A5%BD%E7%9A%84%EF%BC%8C%E4%B8%8D%E4%BC%9A%E5%A4%AA%E9%87%8D%EF%BC%8C%E5%AF%B9%E4%BA%8E%E7%9F%A5%E8%AF%86%E6%9B%B4%E6%96%B0%E4%B9%9F%E6%9B%B4%E5%BF%AB%EF%BC%9B")

搜索优化引入Drift_search动态搜索（microsoft.github.io/graphrag/qu...) ，但并没有对索引的部门进行优化，依旧成本居高不下。

所以，到后面，Lazy版本的GraphRAG就出来了。而在本质上说，GraphRAG和LazyGraphRAG是两种不同的图增强检索与生成（RAG）方法，在数据处理和查询性能上有显著区别：

在数据处理方面，GraphRAG使用大LLM提取和描述实体及其关系。对每个实体和关系的所有观察进行总结。使用图统计优化实体图并提取层次社区结构。但LazyGraphRAG使用NLP名词短语提取概念及其共现关系。使用图统计优化概念图并提取层次社区结构。延迟LLM的使用，直到查询时才进行相关处理。

在查询机制 方面，全局搜索上 ，GraphRAG在使用社区结构确保考虑整个数据集的广度，而LazyGraphRAG全局搜索上通过迭代加深的方式结合最佳优先搜索和广度优先搜索。在局部搜索上，GraphRAG直接使用原始查询，而LazyGraphRAG通过文本块嵌入和社区关系进行排序，并使用LLM进行相关性评估。

所以可以看到，在成本上，GraphRAG数据索引成本较高，因为需要进行复杂的LLM处理和社区结构提取。 LazyGraphRAG的数据索引成本与向量RAG相同，远低于完整GraphRAG。查询成本低，适合一次性查询和流数据处理。

总结

虽然 RAG 的目的是解决 LLM 的幻觉，提示生成内容的质量。但目前还在发展中，也就是说目前还并没有完美解决幻觉的方案，以上介绍都是思路和探索。具体问题具体解决。

有一句话叫"RAG demo5分钟，上线上一年"

年货：24年最火的RAG论文都在这了 (99+ 封私信 / 80 条消息) RAG（检索增强生成）会不会消亡呢？ - 知乎

最佳实践

[2407.01219] Searching for Best Practices in Retrieval-Augmented Generation

RAG之前先做query分类

不是每个query需要召回增强，有些可以直接用大模型回答，例如摘要、续写、翻译等。query分类的目的是过滤和分流，把需要RAG的query送入RAG，把不需要RAG的query直接送入大模型。query分类不仅能提升RAG效果，还能降低平均延迟，几乎是立竿见影的效果。

分类器可以选BERT，也可以是更简单的模型如TextCNN、fastText等，取决于对性能的细微要求。我的建议是直接上BERT，因为分类耗时在整个RAG流程中不占大头，但分类效果对RAG影响很大。
chunking方法很重要

固定大小chunking是最常见的方法，但是可能破坏上下文的连续性，截断语义的情况时有发生。加上滑动窗口效果会好很多。要注意chunk size：大chunk能提供充分的上下文，小chunk能增加召回。我常用的chunk size是512，这是性能和效率权衡的经验值。

按照论文实验结果，当chunk size增大到2048时，系统的忠实性（生成回复和召回文档之间的匹配度）和相关性（生成回复、召回文档和query之间的匹配度）都会大打折扣。利用标点符号按句chunking或按段落chunking也是简单好用的方法，能保留相对完整的语义。如果对语义完整性要求特别高，而且不太在乎耗时，应该把所有句子向量化一遍，然后按语义chunking。
选择支持混合检索的向量数据库

有时关键词召回效果强于向量召回，比如短query。所以混合检索至关重要。一般我推荐Milvus和ES。Milvus专为向量检索而生，支持多种向量索引，同时也具备一些混合检索能力，例如标量过滤。不仅如此，Milvus还支持多向量检索，例如同时检索文本特征和图像特征，刚好顺应多模态趋势。

相比Milvus，ES能索引的数据类型要多得多，混合检索毫无压力，关键词和向量都不在话下。最大的问题可能是ES只支持hnsw向量索引，而且扩展工作节点时ES为了优化索引数据分布而重新分片，比较耗时。相比之下，Milvus扩展比较轻松。
用文档检索文档能提升召回效果

传统提高召回效果的方法是query改写，但是改来改去，query和文档之间的相似度也比不上文档和文档之间的相似度。一个有效提高召回的方法是：先让大模型按照query生成一篇伪文档，然后拼接伪文档和query做混合检索（HyDE方法基本思路）。文档对文档的检索效果总体上强于query对文档。最后对各路检索的相关性得分加权计算总分，决定最终召回结果。但是，如果系统对响应时间有要求，就不要用HyDE方法了，直接用混合检索也能得到不错的效果。
文档重排效果显著

当前最常用的是基于深度语言模型（DLM）的reranker，比如BERT reranker，MonoT5 reranker等。它们的基本思路都是把query和文档拼起来输入模型，让模型判断二者是否相关：BERT对CLS的embedding做分类，输出概率作为相关性得分；T5把输出"true"和"false" 的logits取出来做归一化，然后把输出"true"的概率作为相关性得分。这些reranker效果很好，但是计算量比较大。

如果对效率有较高要求，可以考虑另一类基于query似然模型（QLM）的reranker。它们的基本思路是把文档输入一个语言模型，模型生成query的概率当作相关性得分，例如TILDE或TILDEV2，它们都基于BERT，但是提前计算和保存了query term和文档之间的相关性，推理时直接查找，无需重复计算，所以能提速。

重排也是重装（repacking）的基础。所谓"重装"，就是把文档以一定方式重新组织起来，例如按照重排的相关性得分升序或降序排列文档。需要重装的原因是大模型对输入的中间部分理解效果最差，对输入的开头或结尾理解效果最好，即所谓的"lost in the middle"。所以重装时一般把重排中相关的文档放在开头或最后。
如果召回量很大，记得先摘要再生成

RAG要把召回的上下文拼接到prompt，大量召回让prompt变得极长，可能超过大模型的输入上限。即使不超限，也会让大模型推理变慢。解决办法是先摘要再拼接。RAG场景一般需要query-focused摘要（QFS），即摘要时要考虑特定query。RECOMP既能做抽取式摘要，也能做生成式摘要，效果不错，可以作为首选方法。但是它需要训练，需要准备训练数据。相比之下，LLMLingua或LongLLMLingua等直接用大模型压缩prompt的方法更加方便。
微调时混合相关和无关文档可以提升生成效果

这里的"微调"是指微调生成模型，即RAG中的"G"。有时通用大模型很难从大量上下文中找到关键答案，这时就需要微调。有个trick是在训练样本的上下文中同时掺杂query相关和无关文档，例如上下文中有一篇相关文档和一篇无关文档。这种混合上下文比较贴近实际场景，所以要强制模型学到过滤噪声生成答案的能力。但是，并非所有场景都需要微调，毕竟耗时耗力，应该先评估收效，量力而行。

七宗罪

[2401.05856] Seven Failure Points When Engineering a Retrieval Augmented Generation System

第一罪(FP1) ：内容缺失（Missing Content）。提问的问题，无法在被检索文档库中找到，最准确的答案是缺失的。理想情况下，RAG系统回应应该是"抱歉，我不知道答案"。然而，对于检索内容相关但没有相关答案的问题，系统可能被误导，给出一个respone。
第二宗罪(FP2)：检索的TopK内容缺失(Missed the Top Ranked Documents)。问题的答案在文档库中，但排名得分不够高，无法返回给用户。理论上，检索过程中所有文档都会被排名得分。然而，在实际操作中，会返回排名前K个文档，为了提高召回率，K不可能设置的无限大，必须基于LLM大模型的能力，折中选择的一个值。
第三宗罪(FP3) ：未在上下文中（Not in Context） - 整合策略局限性。从数据库中检索到了包含答案的文档，但在生成答案的过程中，这些文档并未被纳入上下文。当数据库返回许多文档时，会进行整合过程以获取答案，此时会发生这种情况。
第四宗罪(FP4)：未提取（Not Extracted）答案存在于上下文中，但大型语言模型未能提取出正确的答案。通常，这是因为上下文中存在太多噪声或矛盾信息。简而言之，Retrival命名是对的，但是LLM根据Retrival回答问题出错。睁眼说瞎话的概率明显大于用户可以接受的概率（用户一般只能接受0.1%的错误概率）
第五宗罪(FP5)：错误格式(Wrong Format)。问题涉及以某种格式（如表格或列表）提取信息，而大型语言模型忽略了这一指示。
第六宗罪(FP6)：错误的特异性(Incorrect Specificity)。返回的答案包含在响应中，但不够具体或过于具体，无法满足用户需求。这种情况发生在RAG系统设计者对某个问题有期望的结果，例如教师对学生。在这种情况下，应该提供具体的教育内容和答案，而不仅仅是答案。当用户不确定如何提问并过于笼统时，也会出现特异性错误。
第七宗罪(FP7) ：不完整（Incomplete）。不完整的答案并非错误，但缺少一些信息，尽管这些信息存在于上下文中并可供提取。