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

Rifx.Online
Generative AI , Machine Learning , Data Science
27 Dec, 2024

随着2024年的结束，检索增强生成（RAG）的发展可谓波澜起伏。让我们从多个角度全面回顾这一年的进展。

RAG演变中的关键事件

辩论：“RAG已死，RAG万岁！”

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

开源 LLM 对行业的影响

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

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

然而，在更广泛的场景和企业中应用，并将其发展与 LLM 的进步对齐，仍然面临重大技术挑战。参考文献 [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 的全面学术调查；已经有许多此类工作 [Reference 27] [Reference 28]，包括蚂蚁集团最近的 RAG 72 总结 [Reference 38]。本文采取了结合行业与学术的视角，基于实际应用总结了年度代表性工作。许多贡献并未严格涵盖在专注于 RAG 的论文中。我们认为 RAG 不仅仅是一个简单的应用；而是一个围绕搜索的复杂系统，整合了各种数据类型、基础组件以及一系列大大小小的模型协同工作。每个子问题都有相应的工作，因此不仅要回顾 RAG 本身，还要保持更广泛的视角。

数据清洗

确保数据质量（质量输入）对实现高质量结果（质量输出）至关重要，这是一个自然的概念。对于多模态非结构化文档，采用视觉模型解析文档布局可以确保高质量的数据输入。这个问题在学术界早已得到认可，广泛被称为文档智能。然而，以前的文档智能方法与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推出了“晚期分块” [参考文献 24]，它通过将文本分块步骤放在嵌入之后来针对文本数据。换句话说，它首先使用嵌入模型对整个文档进行编码，然后在嵌入模型的最终均值池化步骤之前输出分块边界——因此称为“晚期”。与传统的文本分块方法相比，晚期分块更好地保留了上下文信息。然而，它要求嵌入模型的最终输出为均值池化，而大多数嵌入模型使用CLS池化，使得直接兼容变得具有挑战性。

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

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

在十月，人民大学和上海算法创新研究院推出了“元分块” [参考文献 45]，旨在识别段落中具有逻辑连接的句子集合的边界。这种方法使用LLM进行分类，以确定句子是否属于同一个分块。然而，与之前的方法不同，它尽管也使用LLM，但并没有解决语义差距问题。

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

显然，基于文本分块的工作非常有限。今年的有价值贡献集中在为分块提供更多上下文信息，这被证明更为实用；LLM提供的上下文更可靠。通过使用LLM解释分块内容并添加标签等补充信息，我们可以部分解决阻止分块被检索的语义差距问题。在今年的RAGFlow版本中，我们还增加了一个步骤，让LLM从文本分块中提取信息以提高检索性能。

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

混合搜索

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

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

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

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

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

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

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

另一方面，为了确保召回，全文搜索默认使用关键词之间的“或”关系而不是“与”，这对查询性能构成了重大挑战。因此，合格的全文搜索还必须提供与各种查询（包括短语查询）兼容的动态剪枝技术。因此，符合这些要求的全文搜索选项很少。除了广泛使用的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 [Reference 31]是从Qwen2 7B基础模型微调而来的。这种方法不再使用传统的编码器架构，而是采用标准的LLM解码器架构，导致参数数量增加和推理成本提高。

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

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

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

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

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

语义差距

在2024年上半年，微软发布了一篇关于GraphRAG的论文[参考文献8]，并在年中正式开源，迅速在GitHub上获得了超过一万颗星。是什么导致了GraphRAG的受欢迎呢？这与我们之前提到的RAG的第三个痛点——语义差距密切相关。

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

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

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

这里使用“架构”一词，因为它代表了一种使用LLM提取知识图谱以辅助复杂问题回答的范式。除了微软，许多其他公司也提出了自己的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也使用LLM提取实体和关系，类似于微软的方法，但省略了“社区”和其摘要的生成，从而减少了LLM请求的频率。在检索过程中，Fast GraphRAG根据查询在知识图谱中找到最近的实体，然后利用个性化PageRank随机遍历图谱以获得子图，这些子图随后用于生成最终答案。

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

LightRAG是GraphRAG的简化版本，去除了社区结构，使其更轻量。微软于2024年底提出的LazyGraphRAG进一步简化，消除了对LLM提取知识图谱的依赖。相反，它使用较小的本地模型提取名词，并基于共现构建社区结构。社区摘要仅在查询时动态处理。

减少与GraphRAG相关成本的另一种方法来自模型本身。由于LLM提取成本昂贵，微调一个较小的专用模型可以显著降低成本。Triplex[参考文献16]就是一个例子，利用3B Phi-3模型进行知识图谱提取。

从以上可以看出，GraphRAG架构有效地使用LLM为原始文档补充足够的信息，并以易于连接的图形格式组织。在搜索过程中，这为各种实体提供了基于文本相似性的辅助召回能力。因此，GraphRAG中知识图谱的价值不在于直接供人类查看，而在于为复杂和模糊的问题提供额外的上下文和证据。

尽管知识图谱已经存在很长时间，但其应用主要涉及大量可解释的工作，例如数据导航，需要人类和领域专家的干预。这并不是GraphRAG应用的舒适区。即使是LLM提取的命名实体和关系仍然包含相当大的噪声。鉴于LLM在知识图谱提取中的局限性，围绕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的数据库的主要动机之一。

代理与记忆

“代理”是2024年RAG行业的一个热门术语，许多媒体将其称为代理之年。无论这一称谓如何，代理在LLM生态系统中都具有重要影响。本文并不是对代理的回顾，但显然代理与RAG之间存在着不可分割的关系：RAG本身是代理的一个关键组成部分，使其能够访问内部数据；反过来，代理也能增强RAG的能力，形成所谓的Agentic RAG，例如Self RAG [Reference 39]和Adaptive RAG。

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

在2024年，代理的一个关键特性是工作流的广泛使用。无论代理如何演变，工作流仍然是与各种系统集成和确保代理以受控方式执行任务的基本要素。然而，代理的概念超越了工作流；它还包括与推理相关的思维和决策。在2024年下半年，这方面的研究开始加速。

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

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

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

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

多模态 RAG

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

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

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

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

为此，如前所述，一种方法是使用模型将多模态文档转换为文本，然后进行索引以便检索。另一种方法则是利用 VLMs 的进步，直接生成向量，绕过复杂的 OCR 过程。一个开创性的例子是 ColPali [Reference 44]，它在 2024 年夏季出现。ColPali 将图像视为 1024 个图像块，并为每个块生成嵌入，有效地将单个图像表示为张量。

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

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

下面的图表展示了多模态 RAG 检索的排行榜，突显出基于张量的晚期交互模型在许多领先位置上占据优势。

因此，张量不仅对文本排名重要，而且在多模态 RAG 中也有广泛的应用。问题随之而来：多模态 RAG 应该直接生成嵌入，还是应该先使用通用的 OCR 模型将文档转换为文本？在原始的 ColPali 论文中，作者建议完全放弃 OCR，但他们将其与基于 CNN 的 OCR 进行了比较，这就是前面提到的第一代模型。目前，这两种方法的成功都依赖于多模态模型本身的进展。因此，我们相信这两条路线将长期共存。如果我们将嵌入视为“通用”解决方案，那么基于编码器-解码器架构的 OCR 可以被视为“专业”解决方案，因为特定类型的数据仍然需要训练特定的 Transformer 以有效解决。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. Blended RAG: Improving RAG (Retriever-Augmented Generation) Accuracy with Semantic Search and Hybrid Query-Based Retrievers, 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. Fast GraphRAG 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: Indexing Similar and Related Information for Multihop Reasoning https://arxiv.org/abs/2412.06206

18. 图神经网络增强的问答检索 https://arxiv.org/abs/2406.06572

19. 大规模语言模型在图上的调研 SIGKDD 2024