Skip to main content

2024年RAG的崛起与演变 年度回顾

· 35 min read
Yingfeng Zhang

随着2024年接近尾声，检索增强生成（RAG）的发展可谓波澜壮阔。让我们从多个角度全面回顾这一年的进展。

RAG演变中的关键事件​

辩论："RAG已死，RAG万岁！"​

在2024年初，这一年被一些人称为“RAG之年”，尽管这并不是一个普遍接受的标签。然而，全年取得的进展确实证明了这一称号的合理性。在涉及大型语言模型（LLMs）的场景中，RAG一直被认为是一个不可或缺的角色。然而，自其诞生以来，关于RAG的争论从未停止。如上图所示，2023年“RAG”一词并未广泛使用；相反，“外部记忆”或“外部知识库”等临时术语更为普遍。当时的主要争论集中在是使用临时外部解决方案还是永久微调。到2024年初，这一争论大多已经平息：RAG在成本和实时性能方面具有明显优势，与微调相比，效果差异不大。即使在需要微调的场景中，RAG通常仍然是必不可少的。

在2024年上半年，对行业影响最显著的事件之一是开源LLM与由OpenAI主导的商业LLM逐渐融合。这意味着与2023年相比，摘要生成和指令跟随等能力有了显著提升。这一进展使得问答、客户服务和知识库等基础RAG应用得到了广泛采用。在此期间，LLM的另一个显著进展是长上下文窗口——这一特性在上半年引发了广泛争议，但到年中时逐渐平息。与之前的辩论类似，结论是长上下文窗口和传统方法各有优势，最好结合使用。

长上下文RAG
👎随着上下文长度的增加，准确性降低。
👎上下文窗口越长，越有可能错过远处的“针”。
👎如果检索到的内容在语义上相似但与答案无关，则会引入噪音。
👎LLM本质上是“不确定的”。
👎难以单独整合具有长上下文的企业数据。
👎长上下文显著增加了推理成本和延迟。
👎不够智能：只能进行搜索，无法推理或做出决策。

此外，像LLMOps这样的架构的成熟使得企业和个人能够快速建立自己的定制系统，使用诸如向量数据库、嵌入/重排序模型、LLM本身、分块工具和提示管理技术等组件，这些组件通过指示数据流的箭头连接，确保系统的可用性。

然而，在更广泛的场景和企业中应用它，并将其发展与LLMs的进步保持一致，仍然面临着重大的技术挑战。参考文献[29]和[30]概述了这些挑战的传统学术方法。虽然一些原则和实践被广泛接受，但实际分析表明，RAG主要面临三个主要问题：

  1. 对于非结构化多模态文档的无效问答：现有的LLMOps解决方案仅限于纯文本场景。PDF、PowerPoint演示文稿（PPT）或集成了文本和图像的文档无法充分发挥其商业潜力。这些类型的文档通常占企业数据的大部分。

  2. 由于纯向量数据库导致的低召回率和命中率：仅依赖向量数据库会导致召回率和命中率低，阻碍有效的现实世界问答。这是由于向量表示无法精确表示确切信息以及检索过程中的语义损失。

  3. 搜索的基本挑战：RAG的核心依赖于搜索能力。它只有在能够根据用户的查询“搜索”答案时才能工作。然而，这一前提在模糊或缺乏明确意图的查询或需要从多个子问题中综合的“多跳”问题中常常失败。在这种情况下，提出的问题与检索到的答案之间存在显著的语义差距，使得传统的搜索方法无效。

因此，以下里程碑事件围绕着RAG的技术挑战展开。

多模态文档解析工具的兴起​

BM25和混合搜索的兴起使得纯向量数据库作为一个独立类别变得不再必要。

2024年4月1日，我们开源了完整的RAG引擎RAGFlow，截至年底已在GitHub上获得了超过26,000颗星。RAGFlow最初的两个设计亮点已成为RAG架构的通用设计原则：

首先，虽然初级的RAG系统仅提供基于文本的分块工具，RAGFlow引入了针对非结构化数据的语义分块步骤，以确保输入数据的质量。这涉及使用特别训练的模型来解析文档布局，避免简单文本分块工具对不同数据布局造成的干扰。随着开源社区越来越多地使用这些模型来解析各种文档，这种方法已经获得了广泛的认可。

其次，从一开始，我们就坚定地采用企业级搜索引擎作为唯一的后端数据库，以提供混合搜索。通过利用具有BM25功能的全文搜索，我们确保了精确的查询性能。尽管BM25已有近三十年的历史，RAG使这一经典技术焕发了新生。今年，许多向量数据库开始提供BM25；值得注意的是，著名的向量数据库Qdrant甚至提出了一个改进版本，称为BM42，后来发现这是一个错误。尽管许多数据库声称支持BM25，但真正满足RAG基本要求的却很少。然而，BM25的崛起是不可否认的；纯向量数据库不再需要作为一个单独的类别存在，因为混合搜索的概念已经得到了广泛的接受。

RAGFlow 可以被视为这两起事件背后的关键驱动因素之一。

GraphRAG的崛起​

微软年中开源的GraphRAG是一个开创性的事件。作为一个库而非端到端的解决方案，GraphRAG的迅速流行凸显了其解决检索增强生成（RAG）关键问题的能力，特别是语义差距。这个问题长期以来一直是搜索系统开发者的挑战，因为查询和答案往往无法完美对齐。当搜索系统演变为RAG模型时，这个问题被放大了：虽然传统搜索查询由几个关键词定义，但RAG查询是用户的问题。从关键词到问题的转变使得用户意图更加难以辨别，从而加剧了这种语义差距。GraphRAG是一种旨在弥合这一差距的设计。

延迟交互模型的出现，如Col-xxx​

基于VLM和后期交互模型构建的多模态RAG​

这两大事件都涉及排名模型的升级，并需要在数据库级别提供原生张量支持。对于第一个事件，采用后期交互模型有效地提供了类似于在数据库级别重新排名模型的能力。对于第二个事件，这种方法为企业中更复杂的文档（如杂志和饼图）解锁了更大的商业价值。基于这一观察，我们在Infinity中全面实现了这些功能，这是我们今年早些时候专门为RAG开源设计的数据库。尽管这些功能尚未应用于RAGFlow，但它们的影响已经开始从前沿扩展到更广泛的行业。

以下是2024年RAG技术发展的总结，从工业和学术的角度来看。RAG一直是今年研究的热门话题。自年初以来，关于RAG主题的预印本频率已达到每周超过十篇，有些周甚至达到几十篇。这些论文主要关注与RAG应用、调优和评估相关的实验，得出了各种结论。本文并非对RAG的全面学术调查；已经有许多这样的作品[参考27][参考28]，包括蚂蚁集团最近对RAG 72的总结[参考38]。本文采用工业和学术相结合的角度，基于实际应用总结了今年的代表性工作。其中许多贡献并不严格属于专注于RAG的论文范畴。我们认为，RAG不仅仅是一个简单的应用；而是一个以搜索为中心的复杂系统，集成了各种数据类型、基础组件以及一系列协同工作的大大小小的模型。每个子问题都有相应的工作，因此不仅要回顾RAG本身，还要保持更广阔的视角。

数据清洗​

确保数据质量（Quality In）对于获得高质量结果（Quality Out）至关重要，这是一个自然的概念。对于多模态非结构化文档，采用视觉模型来解析文档布局可以确保高质量的数据输入。这个问题在学术界早已被认识到，并广泛被称为文档智能。然而，以前的文档智能方法并未与RAG紧密联系，并且通常涉及多个子任务，缺乏统一的整合。例如，表格处理有一个专门的任务称为表格结构识别（TSR），对于其他类型的图像，如公式、流程图和饼图，也存在类似的专门模型。通过将这些模型统一到一个文档布局识别框架中，我们建立了使用模型进行数据清理以支持RAG的第一步。

文档结构识别模型的任务是识别非结构化文档中不同语义区域的坐标。此类模型已经在一些OCR系统中实现；例如，著名的PaddleOCR [参考1] 包含了文档结构识别的功能。因此，前面提到的各种任务，包括表格处理，通常被称为广义OCR，可以看作是RAG的切入点。

RAGFlow的DeepDoc模块是最早完全实现这些功能的系统之一，这对其开源后的快速增长做出了重要贡献。目前，有几个类似的系统，例如MinerU [参考2] 和 Docling [参考3]。将文档智能应用于RAG代表了一个广阔的发展领域，导致该领域的迭代加速。

从方法论上讲，文档智能模型可以分为两代：

第一代：这包括过去类似的工作和当前主流的开源项目，例如RAGFlow DeepDoc模块。这些努力建立在传统的视觉模型上。虽然它们可以在CPU上运行，但它们在不同场景下的泛化能力有限。因为它们需要针对不同的上下文和数据分别进行训练，所以这项技术被俗称为“刺绣”。

第二代：当前的OCR技术正在向生成式AI架构发展。早期的例子包括Meta的Nougat [参考4]，以及最新的OCR 2.0 [参考5]，它们采用了基于Transformer的统一编码器-解码器架构，从图像识别中生成文本结果。这些发展与后面提到的多模态VLM有许多相似之处。例如，StructEqTable [参考6]直接应用了类似的网络结构来进行表格重建。RAGFlow的企业版也使用这种架构进行文档处理。尽管生成式AI模型的推理不能在CPU上运行，但它们在各种场景下的泛化能力相比传统的视觉模型有了显著提升。使用多模态模型进行文档智能的另一个优势是能够将文本信息整合到文档布局中。今年的一个代表性工作M2Doc [参考23]将BERT集成到基于视觉的编码器-解码器架构中，增强了文本和段落的语义边界识别能力。

在即将到来的2025年，基于编码器-解码器架构的研究预计将进一步推进。我们可以期待一个统一的多模态文档解析模型的潜在发展，该模型能够准确地将各种非结构化文档转换为文本内容。

上述内容可以视为对多模态非结构化文档数据的数据清洗。但对于纯文本文档，仅依赖简单的文本分块是否足够？答案是否定的。如果文本分块仅包含文本信息，检索过程中的主要问题将从内容混淆转变为语义鸿沟。我们将在后面的部分详细讨论这一点。在这里，我们介绍一些在分块级别上的修补工作：

今年，Jina推出了“Late Chunking”[参考24]，它通过将文本分块步骤放在嵌入之后来针对文本数据。换句话说，它首先使用嵌入模型对整个文档进行编码，然后在嵌入模型的最终平均池化步骤之前输出分块边界——因此称为“late”。与传统的文本分块方法相比，Late Chunking更好地保留了上下文信息。然而，它要求嵌入模型的最终输出是平均池化，而大多数嵌入模型使用CLS池化，这使得直接兼容性具有挑战性。

在2024年，行业还引入了dsRAG [参考25]用于文本数据。其主要贡献是通过使用大型模型为每个文本块添加上下文信息，提供自动上下文，解决了从原始文本中难以检索的问题。例如，如果文本包含治疗计划但没有疾病描述，检索可能无法定位相关内容。dsRAG的另一个特点是将文本块聚类为更长的段落；尽管评估分数很好，但这在实践中可能并不有效。

LLM提供商Anthropic Claude也在9月推出了“上下文检索”[参考26]，其中包括一个名为“上下文分块”的重要组件。顾名思义，这涉及为每个文本块引入特定的上下文解释，这些解释由LLM生成。因此，上下文检索与dsRAG具有相似的效果。

10月，中国人民大学和上海算法创新研究院推出了“Meta-Chunking”，[参考45]旨在识别段落内具有逻辑联系的句子集合的边界。该方法使用LLMs进行分类，以确定句子是否属于同一块。然而，与之前的方法不同，尽管它也使用了LLMs，但并未解决语义差距问题。

大约在同一时间，上海人工智能实验室和北京航空航天大学联合推出了“多粒度混合分块”。[参考46] 该方法将每个文档分割成较小的块，通常由一到两句话组成。这些块被视为图中的节点；在检索过程中，模型根据查询预测所需的分块粒度，并根据此粒度决定遍历图的深度——更深的遍历会导致最终块的大小增加。虽然实现复杂，但这种方法并未缓解语义差距问题；它只是动态决定大模型返回的上下文长度以避免冗余，使其实际价值不如之前的方法显著。

很明显，基于文本分块的工作是有限的。今年的宝贵贡献集中在为分块提供更多的上下文信息，这被证明更为实用；由LLM提供的这种上下文更为可靠。通过使用LLMs来解释分块内容并添加标签等补充信息，我们可以部分解决与语义差距相关的问题，这些问题阻碍了分块的召回。在今年的RAGFlow版本中，我们还增加了一个步骤，让LLMs从文本分块中提取信息，以提高召回性能。

无论是多模态数据还是文本数据，分块的结果都会显著影响最终结果。到2025年，我们可以期待在这一领域出现更多高质量的工作，最终解决与数据输入质量相关的问题。

2024年4月，IBM研究院的一份技术报告《BlendedRAG》[参考7]通过实验证明，采用多种召回方法可以为RAG带来更好的结果。具体来说，结合向量搜索、稀疏向量搜索和全文搜索可以实现最佳召回效果。这很容易理解，因为向量可以表示语义；一个句子甚至整篇文章都可以封装在一个向量中。本质上，向量传达了文本的“含义”，代表了其在上下文窗口中与其他文本共现的压缩概率。因此，向量无法精确表示查询。例如，如果用户问：“我们公司2024年3月的财务计划中包含了哪些组合？”结果可能会返回其他时间段的数据或不相关的主题，如运营计划或营销管理。相比之下，全文搜索和稀疏向量主要表达精确的语义。因此，结合这两种方法可以满足我们对语义理解和精确性的日常需求。

在RAG框架中，混合搜索通常由专用数据库处理。虽然有许多数据库提供各种混合搜索功能，但真正合适的选择很少，因为实现一个强大的全文搜索是具有挑战性的：

稀疏向量难以完全替代全文搜索：稀疏向量旨在通过使用标准的预训练模型来消除冗余词汇并添加扩展术语，从而生成固定维度的稀疏向量输出（例如，30,000或100,000维）。这种方法在一般查询任务上表现良好；然而，许多用户查询的关键词可能不在用于生成稀疏向量的预训练模型中——例如特定的机器型号、手册和专业术语。因此，尽管稀疏向量和全文搜索都服务于精确召回的目的，但它们各有优势，无法相互替代。

全文搜索不仅仅涉及BM25计算：它还需要考虑短语查询和相关的性能问题。RAGFlow是最早提供混合搜索的RAG解决方案之一，最初使用Elasticsearch作为其后端文档搜索引擎。在RAGFlow中，用户查询不会直接发送到Elasticsearch；它们首先会经过查询分析，包括：

  1. 在分词后移除停用词和其他无意义的标记。
  2. 为每个标记生成术语权重。
  3. 根据步骤2后的二元组结果生成短语查询。这些短语查询也与步骤2后的结果一起发送到搜索引擎。

例如，对于问题“汤姆交付了什么结果？”，我们可能会得到以下查询：

(results^0.0667) (tom^0.0667) (deliver^0.0667) "results tom"^0.1335 "tom deliver"^0.1335

这个查询相当复杂，但它展示了如何将问答格式转换为包含众多短语的查询。如果没有在倒排索引中存储位置信息，就无法提供这样的查询能力。

另一方面，为了确保召回率，全文搜索默认使用关键词之间的“OR”关系而不是“AND”，这对查询性能提出了重大挑战。因此，一个合格的全文搜索还必须提供与各种查询兼容的动态剪枝技术，包括短语查询。因此，很少有全文搜索选项能满足这些要求。除了广泛使用的Elasticsearch之外，我们的开源RAG数据库Infinity完全支持这些功能。

下图展示了在公共基准数据集上使用Infinity进行评估的结果，比较了单次召回方法（向量、稀疏向量、全文搜索）、双向召回和三次召回。纵轴表示排序质量，显然三次召回取得了最佳结果，充分验证了BlendedRAG的发现。图表的最右侧部分展示了将三次召回与基于张量的重新排序相结合的结果，我们将在接下来的部分进一步讨论。

2024年6月，OpenAI收购了数据库初创公司Rockset。在2023年底发布GPT-4 Turbo之后，知名的向量数据库Qdrant也成为了焦点，但仅仅几个月后，Rockset就被收购了。此次收购背后的一个重要考虑是，Rockset是少数几个可行的Elasticsearch替代方案之一，这与其云原生架构密切相关。因此，作为数据基础设施组件，Rockset与OpenAI的整合可以方便地为各种用户提供基于RAG的SaaS服务。

排名模型​

排名是任何搜索系统的核心。在RAG的背景下，排名涉及两个组件：一个用于粗过滤的部分，即用于向量搜索的嵌入模型；另一个是在微调阶段使用的重新排序模型。重新排序模型的训练通常与嵌入模型共享大部分工作。嵌入模型通常采用编码器架构，其训练目标是在向量空间中使语义相似的文本更接近。相比之下，重新排序器使用交叉编码器架构，旨在预测查询和文档之间的分数。

如图所示，左侧展示了嵌入模型的工作原理：它分别对查询和文档进行编码，然后在池化后输出一个向量，在排序阶段只需要进行向量相似度计算。然而，由于它丢失了查询和文档中标记之间的交互信息，许多语义信息也因此丢失，这就是为什么向量搜索通常用于粗过滤的原因。作为重新排序器的交叉编码器可以具有与嵌入模型相同的编码器网络，但通过同时输入查询和文档，它输出一个单一的分数。这使得它能够捕捉标记之间的关系，显著提高排序质量。

然而，交叉编码器也有其缺点：对于编码器来说，文档嵌入可以在离线索引阶段完成，从而在在线查询时只需对查询进行编码即可快速检索。相比之下，交叉编码器需要对每个查询-文档对进行交叉编码和模型输出，这会带来较高的计算成本。因此，它们仅适用于重新排序，且粗过滤结果不能太多；否则，将显著增加查询延迟。

在评估嵌入模型和重排序模型时，MTEB排行榜经常被引用。在2024年上半年，重排序排行榜主要由各种交叉编码器主导，而在下半年，基于大语言模型（LLMs）的重排序模型逐渐占据主导地位。例如，当前排名最高的模型，gte-Qwen2-7B [参考31]，是从Qwen2 7B基础模型微调而来的。这种方法不再使用传统的编码器架构，而是采用标准的LLM解码器架构，导致参数数量更大，推理成本更高。

考虑到排名效果和成本，一种称为后期交互模型的重新排名解决方案引起了关注；这涉及基于张量的重新排名，如下图所示。

具体方法如下：在索引阶段，编码器为每个标记生成的嵌入被存储。因此，文档可以由一个张量（或多个向量）表示。在查询时，查询中每个标记的嵌入被生成，并计算查询中所有标记与文本块之间的成对相似性。最终文档得分通过将这些相似性相加获得。这种重新排序方法还捕捉了标记之间的交互信息，使其理论上能够达到与交叉编码器相当的性能。

另一方面，由于在查询过程中不涉及复杂的模型引用，成本显著低于交叉编码器或基于LLM的重新排序器。这甚至可以在数据库本身内执行排序。好处包括能够重新排序更多结果，这增加了补偿先前召回不足的可能性，即使初始过滤结果不理想。下图比较了使用Infinity数据库基于单次召回、双次召回和三次召回应用张量重新排序的评估结果。

基于张量的重新排名起源于2020年的早期工作，如ColBERT [参考32] 及其改进版本ColBERT v2 [参考33]。然而，直到2024年初，它才在业界获得了显著关注。当时，由于缺乏必要的数据库支持，它依赖于像RAGatouille [参考34] 这样的Python算法包装器来提供服务。Vespa是最早将张量能力工程化的数据库系统之一，我们在年中将基于张量的重新排名集成到了Infinity数据库中。

目前，基于张量的重排序系统在行业中并未广泛使用；这部分是由于基础设施组件不足和缺乏支持模型。然而，自2024年夏季以来，这一领域明显加速。例如，用于日语的JaColBERT [参考36]和Jina的Jina-colbert-v2 [参考37]多语言模型都提供了从文本数据生成张量的能力。我们稍后还将提到，这些模型极大地促进了多模态RAG。预计随着更多模型的可用，基于张量的重排序将在2025年得到广泛应用。

语义鸿沟​

在2024年上半年，微软发表了一篇关于GraphRAG的论文[参考8]，并在年中正式开源，迅速在GitHub上获得了超过一万颗星。GraphRAG为何如此受欢迎？这与我们之前提到的RAG的第三个痛点密切相关：语义鸿沟。

有许多方法可以解决语义差距问题。除了在分块阶段的改进外，在预处理阶段还可以做更多的工作。一个著名且实用的解决方案是RAPTOR [参考9]。RAPTOR首先对文本内容进行预聚类，然后使用大型语言模型（LLM）生成聚类文本的摘要。这些摘要与原始文本一起发送到搜索系统。由于这些摘要提供了对文本的更宏观理解，它们可以为模糊查询和需要跨越多个块的多跳问题提供适当的答案。RAPTOR在年中集成到RAGFlow中，以协助回答复杂问题。

到2024年底，SiReRAG [参考17] 基于RAPTOR出现，提供了更细粒度的文本召回定义：它使用相似性和相关性来衡量需求的不同维度。相似性通过向量或全文搜索方法计算文本块之间的语义距离，这是RAPTOR本身所做的（如图左侧所示）。相关性表示文本块之间的关系；它首先使用LLM从每个块中提取命名实体，然后基于这些实体及其对应块之间的关系构建层次树结构（如图右侧所示）。因此，在召回过程中，多个文本粒度可以提供混合召回，包括实体、实体组和原始文本，进一步增强对数据的宏观理解，并提高对模糊意图和多跳查询场景的召回效果。

SiReRAG与GraphRAG非常相似，主要区别在于提取的实体如何进一步处理和组织。让我们更详细地看看GraphRAG本身：它使用大型模型自动从文档中提取命名实体，并基于这些实体构建知识图谱。在图中，它还使用聚类来创建实体的“社区”，并利用LLMs为这些社区生成摘要。在召回过程中，知识图谱中的实体、边和社区摘要与原始文档结合进行混合召回。这些数据在文档中形成跨块关联，从而在宏观层面的查询和多跳问题上取得更好的结果。GraphRAG可以被视为解决语义鸿沟的有效策略和架构。

这里使用“架构”一词是因为它代表了一种使用LLMs提取知识图谱以协助复杂问题回答的范式。除了微软，许多其他公司也提出了自己的GraphRAG解决方案，例如蚂蚁集团的KAG [参考10]和Nebula的GraphRAG [参考11]，每个方案都有其侧重点。例如，KAG强调知识图谱的完整性和可解释性，需要结合手动维护和专家知识元素以实现特定领域的专业知识。同时，Nebula GraphRAG强调与知名LLM框架如LangChain和Llama Index的深度集成，将它们整合到Nebula Graph数据库中。

GraphRAG架构中的一个显著痛点是其大量的令牌消耗。因此，自GraphRAG以来，已经出现了几种变体，包括Fast GraphRAG [参考12]、LightRAG [参考13]和微软即将推出的LazyGraphRAG [参考14]。Fast GraphRAG也使用LLMs来提取实体和关系，类似于微软的方法，但省略了“社区”及其摘要的生成，从而减少了LLM请求的频率。在检索过程中，Fast GraphRAG根据查询在知识图中找到最近的实体，然后使用个性化的PageRank随机游走图以获取子图，这些子图随后用于生成最终答案。

PageRank 是一种值得提及的有效策略，与另一篇关于知识图谱的有影响力的2024年论文——HippoRAG [参考文献 15] 并列。这篇论文讨论了海马索引理论以及一种基于个性化 PageRank 的随机游走策略，该策略与人类大脑基于记忆的思考方式非常相似。因此，在构建知识图谱后，使用个性化 PageRank 进行查询可以模拟人类与长文本信息相关的回忆和思考过程。Fast GraphRAG 和 HippoRAG 都可以通过下图进行说明。此外，我们还融入了图神经网络（GNNs）的元素，因为2024年有越来越多的工作旨在利用 GNNs 改进知识图谱问答 [参考文献 18] [参考文献 19]。感兴趣的读者可以参考相关文献以获取更多信息。由于 GNN 工作通常需要额外的用户数据训练——例如利用现有的问答数据来增强命名实体的图嵌入表示——这些努力涉及高定制成本，超出了本次讨论的主要范围。

LightRAG 是 GraphRAG 的简化版本，去除了社区结构以使其更加轻量。微软在2024年底提出的 LazyGraphRAG 进一步简化了这一过程，消除了对 LLMs 提取知识图谱的依赖。相反，它使用较小的本地模型来提取名词，并基于共现构建社区结构。社区摘要仅在查询期间动态处理。 另一种降低 GraphRAG 相关成本的方法来自模型本身。由于 LLM 提取成本高昂，微调一个较小的专用模型可以显著降低成本。Triplex [参考 16] 就是一个例子，它利用 3B Phi-3 模型进行知识图谱提取。 从上述内容可以看出，GraphRAG 架构有效地利用 LLMs 为原始文档补充了足够的信息，并以易于连接的图格式组织。在搜索过程中，这增加了基于各种实体的辅助召回能力，以及文本相似性。因此，GraphRAG 中知识图谱的价值不在于直接供人类查看，而在于为复杂和模糊的问题提供额外的上下文和证据。 尽管知识图谱已经存在很长时间，但其应用主要涉及大量可解释的工作，例如数据导航，需要人类和领域专家的干预。这并不是 GraphRAG 应用的舒适区。即使由 LLMs 提取的命名实体和关系仍然包含大量噪声。鉴于 LLMs 在知识图谱提取中的局限性，围绕 GraphRAG 的后续工作不仅关注成本降低，还关注如何将实体组织成更有效的结构。到年底，出现了两项值得注意的工作：KG-Retriever [参考 20] 和 Mixture-of-PageRanks [参考 21]。前者将知识图谱与原始数据结合，创建多级图索引结构以进行不同粒度的检索；后者基于个性化 PageRank 引入了基于时间的相关性信息。我们可以期待在2025年这一领域会有更多的发展，尽管它们不会改变 GraphRAG 类型工作的基本性质。

最后，让我们考虑一下GraphRAG的工程实现。使用图数据库来实现GraphRAG是一个自然的选择；KAG和Nebula Graph都采用了这种技术路线，因为图数据库可以更好地表示知识图谱。RAGFlow也在年中将GraphRAG端到端地集成到其系统中，但没有使用图数据库，而是依赖于搜索引擎。在GraphRAG中的数据建模方面，知识图谱中的实体和边以文本形式描述，同时还包括通过聚类实体及其生成的摘要得出的社区。GraphRAG的典型数据模型可以如下所示：

一个功能齐全的全文索引不仅应提供相似度评分计算，还应具备关键词过滤能力。因此，通过在上述模式中的字段上建立全文索引，可以轻松地基于边和实体进行子图检索。此外，如果数据库能够无缝集成全文索引和向量索引，将为GraphRAG提供非常方便的混合搜索。所有边、实体和社区描述都可以包含在全文搜索范围内，结合向量索引，提供基于GraphRAG的双重混合召回。

从数据模式中可以看出，通过简单地添加一个类型字段，原始文本块可以与其他信息存储在同一表中，从而有效地将GraphRAG与RAG结合成HybridRAG [参考22]。显然，使用具有丰富索引功能的数据库可以显著减少实现GraphRAG的工程挑战。即使是修改图结构的工作，如KG-Retriever和Mixture-of-PageRanks，也可以通过调整索引格式和增强特定搜索方法来轻松支持。这是我们从头开始构建专门为RAG服务的数据库的主要动机之一。

代理与记忆​

Agentic 是2024年RAG行业中的一个流行术语，许多媒体宣布今年为代理年。无论这一称号如何，代理对LLM生态系统有着显著的影响。本文并非对代理的回顾，但很明显，代理与RAG之间存在着不可分割的关系：RAG本身是代理的关键组成部分，使它们能够访问内部数据；反过来，代理可以增强RAG能力，从而产生所谓的Agentic RAG，例如Self RAG [参考39] 和 Adaptive RAG。

这种高级形式的RAG允许在更复杂的场景中以受控的方式进行自适应变化。为了实现Agentic RAG，代理框架必须具备“闭环”能力。在Andrew Ng的四种代理设计模式中，这种“闭环”能力被称为反思能力。LangGraph [参考40] 是早期实现此功能的框架之一，而RAGFlow在年中引入了类似的功能。

在2024年，代理的一个关键特征是工作流的广泛使用。无论代理如何发展，工作流仍然是集成各种系统和确保代理以受控方式执行任务的关键。然而，代理的概念不仅限于工作流；它还涵盖了与推理相关的思维和决策。在2024年下半年，这一领域的研究开始加速。

将RAG与代理集成可以解锁更多的应用场景。例如，在图中所示的配置[参考41]中，系统包括多个自主代理，这些代理可以将复杂的问答任务分解为子任务，每个代理负责特定的功能。这种分工提高了系统的整体效率和准确性。在图中，检测器代理旨在识别可能包含错误假设和前提的查询，这些假设和前提可能会影响LLM响应的准确性；思维代理处理和分析所有检索到的信息，综合数据以得出结论并生成详细的推理结果；而答案代理则使用思维代理的输出生成最终答案，确保多轮对话中的响应受到最新逻辑的影响。

例如，RARE [参考42] 通过整合蒙特卡洛树搜索（MCTS）框架来增强RAG，该框架通过两个步骤加强推理能力：基于初始问题生成查询并查询生成的子问题。通过实施这些步骤，RARE可以在医疗场景中促进复杂和常识推理。

随着这种推理能力的发展，RAG与代理之间的关系变得越来越紧密，互动也更加频繁。因此，RAG需要提供除了之前提到的文档搜索之外的内存管理功能。这些内存信息包括用户对话会话和个性化用户数据。代理不仅需要RAG执行内部数据搜索，还需要实时访问上下文信息。2024年开源项目Mem0定义了一些内存管理API，迅速获得了众多GitHub星标。然而，需要注意的是，当前的内存管理定义相对简单（主要涉及实时过滤和搜索），而底层基础设施组件已经相当成熟。因此，真正的挑战在于将内存管理与推理相结合，并在LLM能力增长的同时解锁更复杂的企业级场景。在标准化的RAG引擎上实现这些功能是一个合理的选择，可以最大限度地降低成本并提高可用性，这将成为2025年的一个重要趋势。

此时，许多人可能会思考未来的演变是否会看到RAG转变为代理平台，或者各种代理平台增强其RAG能力。这一趋势难以预测。正如在数字时代，人们可能会质疑是专注于数据仓库同时解决中台业务需求，还是深化业务能力以改进数据仓库——这两种方法都有其先例。在这个LLM智能时代，有机会对软件生态系统进行变革性的重塑；因此，RAG可以有效地与传统数据库的角色并行，而代理由于减少了定制需求，有可能成为应用层的标准产品。未来的发展将在技术深度和快速产品迭代的双重支持下动态演变，各种软件生态系统之间的整合将更加紧密。例如，在年底，LangGraph发布了一个基于LLM的代理互操作性协议，使不同代理之间的生态上下游关系具有更大的潜力。

多模态RAG​

多模态RAG是我们认为将在2025年经历快速增长的另一个领域，因为关键的相关技术将在2024年出现并开始应用。

首先，视觉语言模型（VLMs）的崛起引人注目。如图所示，VLMs之前主要专注于简单的图像搜索，到2024年中期已经迅速发展。

这意味着VLMs已经实现了对图像的更深层次理解，超越了仅仅识别日常物体，能够全面分析企业级的多模态文档。例如，开源3B模型PaliGemma [参考43] 展示了这一能力。

回到RAG本身，如果我们能够使用RAG根据用户查询在大量PDF中找到包含答案的图像和文本，那么我们就可以使用VLMs生成最终答案。这就是多模态RAG的意义；它超越了日常物品的简单图像搜索。

为了实现这一点，如前所述，一种方法涉及使用模型将多模态文档转换为文本，然后再进行索引以供检索。另一种方法，利用视觉语言模型（VLM）的进展，直接生成向量，绕过了复杂的OCR过程。一个开创性的例子是ColPali [参考44]，它于2024年夏季出现。ColPali将图像视为1024个图像块，并为每个块生成嵌入，有效地将单个图像表示为张量。

最终的重新排序是使用张量进行的。

整个检索过程如下图所示。它需要一个不仅支持基于张量的重新排序，而且在向量检索阶段还能适应多向量索引的数据库。这些结构已经在我们的Infinity数据库中准备好了。

下图展示了一个多模态RAG检索的排行榜，强调了基于张量的系列后期交互模型已经占据了多个领先位置。

因此，张量不仅对文本排序具有重要意义，而且在多模态RAG中也有广泛的应用。问题出现了：多模态RAG应该直接生成嵌入，还是应该使用通用的OCR模型先将文档转换为文本？在最初的ColPali论文中，作者建议完全放弃OCR，但他们将其与基于CNN的OCR进行了比较，这是前面提到的第一代模型。目前，这两种方法的成功都依赖于多模态模型本身的进步。因此，我们相信这两种路线将长期共存。如果我们将嵌入视为“通用”解决方案，那么基于编码器-解码器架构的OCR可以被视为“专用”解决方案，因为特定类型的数据仍然需要训练特定的Transformers以有效解决。RAG始终优先考虑实际实施，因此在某些时期的特定任务中，专用解决方案可能优于通用解决方案，但最终它们将趋于一致。

在2025年，我们可以期待多模态RAG的快速增长和演变，我们将在适当的时候将这些能力整合到RAGFlow中。

以上内容总结了2024年RAG的主要发展趋势和未来展望。本文的标题提到了“RAG行业”，从提供的摘要中可以清楚地看出，RAG是一个高度复杂的系统。尽管它没有像LLMs那样吸引大量资金，但在实际应用中它是不可或缺且复杂的。我们相信RAG这个术语定义得很好；它代表了一种架构模型，而不是单一的产品或应用场景。在某些方面，RAG类似于过去的数据库——外部接口简单但内部复杂。它不仅包括数据库本身，还包括各种小模型以及连接它们的工具。本质上，它代表了大模型时代企业搜索引擎的演变，同时远远超出了传统搜索引擎的范围。在2025年，我们将继续发展RAGFlow，并邀请大家继续关注，我们努力成为最好的RAG产品！https://github.com/infiniflow/ragflow

参考文献​

  1. PaddleOCR https://github.com/PaddlePaddle/PaddleOCR/
  2. MinerU https://github.com/opendatalab/MinerU
  3. Docling https://github.com/DS4SD/docling
  4. Nougat https://github.com/facebookresearch/nougat
  5. GOT-OCR https://github.com/Ucas-HaoranWei/GOT-OCR2.0
  6. StructEqTable https://github.com/UniModal4Reasoning/StructEqTable-Deploy
  7. 混合RAG：通过语义搜索和基于混合查询的检索器提高RAG（检索增强生成）的准确性，https://arxiv.org/abs/2404.07220，2024年
  8. 从局部到全局：一种基于图RAG的查询聚焦摘要方法，https://arxiv.org/abs/2404.16130 2024
  9. 树结构检索的递归抽象处理, https://arxiv.org/abs/2401.18059 2024
  10. KAG https://github.com/OpenSPG/KAG
  11. Nebula GraphRAG https://www.nebula-graph.io/posts/graph-RAG
  12. 快速图RAG https://github.com/circlemind-ai/fast-graphrag
  13. LightRAG https://github.com/HKUDS/LightRAG
  14. LazyGraphRAG https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
  15. HippoRAG https://arxiv.org/abs/2405.14831
  16. Triplex https://huggingface.co/SciPhi/Triplex
  17. SiReRAG：为多跳推理索引相似和相关信息 https://arxiv.org/abs/2412.06206
  18. 图神经网络增强的检索用于大语言模型的问答 https://arxiv.org/abs/2406.06572
  19. 图的大语言模型调查 SIGKDD 2024
  20. KG-Retriever: 用于检索增强大型语言模型的高效知识索引 https://arxiv.org/abs/2412.05547
  21. 混合PageRanks：用实时稀疏图RAG替换长上下文 https://arxiv.org/abs/2412.06078
  22. HybridRAG: 集成知识图谱和向量检索增强生成以实现高效信息提取，第五届ACM国际金融人工智能会议论文集，2024
  23. M2Doc - 一种用于文档布局分析的多模态融合方法，AAAI 2024
  24. 晚期分块：使用长上下文嵌入模型的上下文分块嵌入 https://arxiv.org/abs/2409.04701
  25. dsRAG https://github.com/D-Star-AI/dsRAG/
  26. 上下文检索 https://www.anthropic.com/news/contextual-retrieval
  27. 检索增强生成（RAG）的综合调查：演变、当前格局与未来方向 https://arxiv.org/abs/2410.12837
  28. 自然语言处理的检索增强生成：综述 https://arxiv.org/abs/2407.13193
  29. 12个RAG痛点及建议解决方案 https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
  30. 搜索检索增强生成中的最佳实践 https://arxiv.org/abs/2407.01219
  31. https://huggingface.co/Alibaba-NLP/gte-Qwen2-7B-instruct
  32. Colbert: 通过基于BERT的上下文后期交互实现高效且有效的段落搜索，SIGIR 2020
  33. Colbertv2: 通过轻量级后期交互实现的有效且高效的检索，arXiv:2112.01488, 2021.
  34. RAGatouille https://github.com/AnswerDotAI/RAGatouille
  35. Vespa https://github.com/vespa-engine/vespa
  36. JaColBERT https://huggingface.co/answerdotai/JaColBERTv2.5
  37. Jina ColBERT v2 https://huggingface.co/jinaai/jina-colbert-v2
  38. Awesome-RAG 2024: https://github.com/awesome-rag/awesome-rag
  39. 自我RAG https://arxiv.org/abs/2310.11511
  40. LangGraph https://github.com/langchain-ai/langgraph/
  41. TCAF: 一种用于检索增强生成的多代理思维链方法，SIGKDD 2024
  42. RARE-检索增强推理提升大型语言模型 https://arxiv.org/abs/2412.02830
  43. PaliGemma https://huggingface.co/spaces/big-vision/paligemma-hf
  44. ColPali：使用视觉语言模型进行高效文档检索，https://arxiv.org/abs/2407.01449
  45. 元分块：通过逻辑感知学习高效文本分割 https://arxiv.org/abs/2410.12788
  46. 混合粒度优化 - 优化检索增强生成的块粒度 https://arxiv.org/abs/2406.00456