2024年 RAG 的兴起与演进：年度回顾

2024年12月24日阅读时长 37 分钟

洞察

随着 2024 年接近尾声，检索增强生成 (RAG) 的发展可谓风起云涌。让我们从多个角度全面回顾这一年的进展。 

RAG 演进中的关键事件

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

在 2024 年初，这一年被一些人称为“RAG 之年”，尽管这一标签并未得到普遍认可。然而，全年的进展无疑证明了这一称号的合理性。在涉及大语言模型 (LLM) 的场景中，RAG 一直被证明是不可或缺的角色。然而，自诞生以来，关于 RAG 的争论从未停止。如上图所示，“RAG”一词在 2023 年并未被广泛使用；相反，诸如“外部存储”或“外部知识库”之类的临时术语更为流行。当时的争论主要集中在是使用临时外部解决方案还是永久微调。到 2024 年初，这场辩论基本尘埃落定：RAG 在成本和实时性能方面具有明显优势，而在有效性方面与微调仅有细微差别。即使在需要微调的场景中，RAG 往往仍然至关重要。

2024 年上半年，对行业产生最重大影响的事件之一是以 OpenAI 为首的商业 LLM 与开源 LLM 的逐渐趋同。这意味着与 2023 年相比，总结和指令遵循等能力已显著提高。这一进步使得基础 RAG 应用（如问答、客户服务和知识库）得以广泛采用。这一时期 LLM 的另一个显著进步是长上下文窗口——这一特性在整个上半年引发了争议，但到年中逐渐平息。与之前的争论类似，结论是长上下文窗口和传统方法各有千秋，最好结合使用。

长上下文	RAG
👎 准确度随着上下文长度的增加而降低。
👎 上下文窗口越长，越容易漏掉远处的“针”（关键信息）。
👎 如果检索到的内容语义相似但与答案无关，会引入噪声。
👎 LLM 天生具有“不确定性”。
👎 仅靠长上下文难以整合企业数据。
👎 长上下文会显著增加推理成本和延迟。
	👎 不够聪明：仅能搜索，无法进行推理或决策。

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

然而，在更广泛的场景和企业中应用 RAG，并使其发展与 LLM 的进步保持同步，仍面临重大的技术挑战。参考文献 [29] 和 [30] 概述了应对这些挑战的传统学术方法。虽然某些原则和实践已得到广泛认可，但实际分析表明，RAG 主要面临三大问题：

非结构化多模态文档问答效率低下：现有的 LLMOps 解决方案局限于纯文本场景。PDF、PowerPoint (PPT) 或图文结合的文档无法释放其全部商业潜力。而这类文档往往占据企业数据的大部分。
纯向量数据库导致的低召回率和命中率：仅依赖向量数据库会导致召回率和命中率低下，阻碍了有效的实际问答。这是由于向量表示无法精确呈现准确信息，且在检索过程中存在语义损失。
搜索的根本挑战：RAG 的核心依赖于搜索能力。只有能够根据用户的查询“搜索”到答案，它才能工作。然而，这一前提在面对缺乏明确意图的模糊查询或需要综合多个子问题进行解答的“多跳”问题时往往会失败。在这种情况下，提出的问题与检索到的答案之间存在巨大的语义鸿沟，使得传统搜索方法失效。

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

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

BM25 与混合搜索的出现

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 中全面实现了这些能力。Infinity 是我们专门为今年早些时候开源的 RAG 设计的数据库。虽然这些功能尚未应用到 RAGFlow 中，但它们的影响已开始从前沿传播到整个行业。

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

数据清洗

确保数据质量（Quality In）是获得优质结果（Quality Out）的基础，这是一个自然的概念。对于多模态非结构化文档，采用视觉模型解析文档布局可确保高质量的数据输入。这一问题在学术界早已得到公认，并被广泛称为“文档智能”（Document Intelligence）。然而，之前的文档智能方法并未与 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 的 Encoder-Decoder 架构，从图像识别中生成文本结果。这些发展与后面提到的多模态 VLM 有许多相似之处。例如，StructEqTable [参考文献 6] 直接将类似的网络结构应用于表格重构。RAGFlow 的企业版也使用这种架构进行文档处理。虽然生成式 AI 模型推理无法在 CPU 上运行，但与传统的视觉模型相比，它们在各种场景中的泛化能力已显著提高。使用多模态模型进行文档智能的另一个优点是能够将文本信息整合到文档布局中。今年的一项代表性工作 M2Doc [参考文献 23] 将 BERT 集成到基于视觉的 Encoder-Decoder 架构中，增强了对文本和段落语义边界的识别。

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

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

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

2024 年，行业还为文本数据引入了 dsRAG [参考文献 25]。其主要贡献是通过使用大模型为每个文本块添加上下文信息来提供自动上下文，从而解决原始文本检索困难的问题。例如，如果一段文本包含治疗方案但没有疾病描述，检索可能会失败。dsRAG 的另一个特点是将文本块聚类成较长的段落；虽然评估分数不错，但这在实践中可能并不见得有效。

LLM 提供商 Anthropic Claude 也在 9 月推出了“上下文检索”（Contextual Retrieval）[参考文献 26]，其中包含一个名为上下文分块的重要组件。顾名思义，这涉及引入由 LLM 生成的每个文本块的特定上下文说明。因此，上下文检索的效果与 dsRAG 类似。

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

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

显而易见，基于文本分块能做的工作有限。今年有价值的贡献集中在为分块提供更多上下文信息，这被证明更实际；LLM 提供的此类上下文更可靠。通过使用 LLM 解析分块内容并添加标签等补充信息，我们可以部分解决由于语义鸿沟导致的分块无法被召回的问题。在今年版本的 RAGFlow 中，我们还添加了 LLM 从文本块中提取信息的步骤，以提高召回性能。

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

混合搜索

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

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

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

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

分词后去除停用词和其他无意义的标记。
为每个标记生成词项权重。
根据步骤 2 后的二元组（bigram）结果生成短语查询。这些短语查询连同步骤 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 的语境下，排序涉及两个组件：一个是用于粗过滤的部分，即向量搜索的嵌入模型；另一个是微调阶段使用的重排序模型（reranker）。重排序模型的训练通常与嵌入模型共享许多工作。嵌入模型通常采用编码器（encoder）架构，其训练目标是在向量空间中拉近语义相似的文本。相比之下，重排序模型使用交叉编码器（cross-encoder）架构，旨在预测查询与文档之间的分数。

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

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

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

考虑到排序效果和成本，一种被称为延迟交互（late interaction）模型的重排序方案引起了关注；这涉及基于张量的重排序，如下图所示。

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

另一方面，由于查询期间不涉及复杂的模型推理，其成本明显低于交叉编码器或基于 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 年底，基于 RAPTOR 的 SiReRAG [参考文献 17] 出现了，它提供了更细粒度的文本召回定义：它使用相似性和相关性来衡量不同维度的需求。相似性使用向量或全文本搜索方法计算文本块之间的语义距离，这正是 RAPTOR 本身所做的（如图左侧所示）。相关性表示文本块之间的关系；它首先使用 LLM 从每个块中提取命名实体，然后根据这些实体与其对应块之间的关系构建层级树结构（如图右侧所示）。因此，在召回期间，多个文本粒度可以提供混合召回，包括实体、实体组和原始文本，进一步增强了对数据的宏观理解，并提高了对模糊意图和多跳查询场景的召回率。

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

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

GraphRAG 架构的一个重大痛点是巨额的 Token 消耗。因此，自 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 的典型数据模型如下所示：

一个功能齐全的全文本索引不仅应提供相似度分数计算，还应具备关键词过滤能力。因此，通过在上述 schema 中的 <source entity name, target entity name> 字段建立全文本索引，就可以轻松执行基于边和实体的子图检索。此外，如果数据库能无缝整合全文本索引与向量索引，就能为 GraphRAG 实现非常便捷的混合搜索。所有的边、实体和社区描述都可以纳入全文本搜索范围，结合向量索引提供基于 GraphRAG 的双重混合召回。

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

Agentic 与记忆

Agentic 是 2024 年 RAG 行业的一个热门词汇，许多媒体宣布这一年为“Agent 之年”。抛开这一称呼，Agent 确实显著影响了 LLM 生态系统。本文并非对 Agent 的回顾，但显而易见，Agent 与 RAG 之间存在不可分割的关系：RAG 本身是 Agent 的核心组件，使其能够访问内部数据；反之，Agent 可以增强 RAG 的能力，从而产生了所谓的 Agentic RAG，如 Self RAG [参考文献 39] 和 Adaptive RAG。

这种高级形式的 RAG 允许在复杂场景中以受控方式进行自适应变化。为了实现 Agentic RAG，Agent 框架必须具备“闭环”能力。在吴恩达提出的 Agent 四种设计模式中，这种“闭环”能力被称为反思能力（reflective capability）。LangGraph [参考文献 40] 是最早实现这一特性的框架之一，RAGFlow 也在年中引入了类似的功能。

2024 年，Agent 的一个关键特征是工作流（workflows）的广泛使用。无论 Agent 如何演进，工作流对于与各种系统集成并确保 Agent 以受控方式执行任务仍然至关重要。然而，Agent 的概念超越了工作流；它还涵盖了与推理相关的思考和决策。在 2024 年下半年，这一领域的研究开始加速。

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

例如，RARE [参考文献 42] 通过引入蒙特卡洛树搜索 (MCTS) 框架增强了 RAG，该框架通过两个步骤加强了推理能力：根据初始问题生成查询，并查询生成的子问题。通过执行这些步骤，RARE 可以促进医疗场景中复杂且具有常识性的推理。

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

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

多模态 RAG

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

首先，视觉语言模型 (VLM) 的兴起引人注目。如图所示，VLM 之前主要专注于简单的图像搜索，到 2024 年年中已迅速演变。

这意味着 VLM 对图像的理解已经加深，不再仅仅是识别日常物品，而是全面分析企业级多模态文档。例如，开源的 3B 模型 PaliGemma [参考文献 43] 就体现了这种能力。

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

为了实现这一目标，一种方法如前所述，涉及在索引检索之前使用模型将多模态文档转换为文本。另一种方法利用 VLM 的进步直接生成向量，绕过复杂的 OCR 过程。这方面的一个开创性例子是 2024 年夏季出现的 ColPali [参考文献 44]。ColPali 将一幅图像视为 1024 个图像块，并为每个块生成嵌入，从而有效地将单幅图像表示为一个张量。

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

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

下图展示了一个多模态 RAG 检索排行榜，突出显示了基于张量的延迟交互模型系列已占据了许多领先位置。

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

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

以上内容总结了 2024 年 RAG 的主要发展趋势和未来展望。本文标题提到了“RAG 产业”，从提供的总结中可以清楚地看出，RAG 是一个高度复杂的系统。虽然它没有像 LLM 那样吸引巨额资金，但在实际应用中却是不可或缺且错综复杂的。我们认为 RAG 一词定义明确；它代表了一种架构模式，而非单一产品或应用场景。在某些方面，RAG 类似于过去的数据库——外部接口简单但内部复杂。它不仅包含数据库本身，还包含各种小模型以及连接它们的工具。本质上，它代表了企业搜索引擎在大模型时代的进化，同时又远远超出了传统搜索引擎的范畴。在 2025 年，我们将继续迭代 RAGFlow，欢迎大家持续关注，我们努力成为最好的 RAG 产品！https://github.com/infiniflow/ragflow

参考文献

PaddleOCR https://github.com/PaddlePaddle/PaddleOCR/
MinerU https://github.com/opendatalab/MinerU
Docling https://github.com/DS4SD/docling
Nougat https://github.com/facebookresearch/nougat
GOT-OCR https://github.com/Ucas-HaoranWei/GOT-OCR2.0
StructEqTable https://github.com/UniModal4Reasoning/StructEqTable-Deploy
Blended RAG: Improving RAG (Retriever-Augmented Generation) Accuracy with Semantic Search and Hybrid Query-Based Retrievers, https://arxiv.org/abs/2404.07220 , 2024
From local to global: A graph rag approach to query-focused summarization, https://arxiv.org/abs/2404.16130 2024
Recursive Abstractive Processing for Tree Organized Retrieval, https://arxiv.org/abs/2401.18059 2024
KAG https://github.com/OpenSPG/KAG
Nebula GraphRAG https://www.nebula-graph.io/posts/graph-RAG
Fast GraphRAG https://github.com/circlemind-ai/fast-graphrag
LightRAG https://github.com/HKUDS/LightRAG
LazyGraphRAG https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
HippoRAG https://arxiv.org/abs/2405.14831
Triplex https://hugging-face.cn/SciPhi/Triplex
SiReRAG：针对多跳推理索引相似及相关信息 https://arxiv.org/abs/2412.06206
图神经网络增强的 LLM 问答检索 https://arxiv.org/abs/2406.06572
图大型语言模型综述 SIGKDD 2024
KG-Retriever：检索增强型大型语言模型的高效知识索引 https://arxiv.org/abs/2412.05547
Mixture-of-PageRanks：用实时稀疏 GraphRAG 替代长上下文 https://arxiv.org/abs/2412.06078
HybridRAG：整合知识图谱与向量检索增强生成以实现高效信息提取，第五届 ACM 国际金融 AI 会议论文集，2024
M2Doc-一种用于文档布局分析的多模态融合方法，AAAI 2024
Late Chunking：使用长上下文嵌入模型的上下文分块嵌入 https://arxiv.org/abs/2409.04701
dsRAG https://github.com/D-Star-AI/dsRAG/
上下文检索 (Contextual Retrieval) https://www.anthropic.com/news/contextual-retrieval
检索增强生成 (RAG) 全面综述：演进、现状与未来方向 https://arxiv.org/abs/2410.12837
自然语言处理中的检索增强生成：综述 https://arxiv.org/abs/2407.13193
RAG 的 12 个痛点及建议解决方案 https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
探索检索增强生成的最佳实践 https://arxiv.org/abs/2407.01219
https://hugging-face.cn/Alibaba-NLP/gte-Qwen2-7B-instruct
Colbert：通过 BERT 上的上下文晚期交互实现高效且有效的段落检索，SIGIR 2020
Colbertv2：通过轻量级晚期交互实现有效且高效的检索，arXiv:2112.01488, 2021.
RAGatouille https://github.com/AnswerDotAI/RAGatouille
Vespa https://github.com/vespa-engine/vespa
JaColBERT https://hugging-face.cn/answerdotai/JaColBERTv2.5
Jina ColBERT v2 https://hugging-face.cn/jinaai/jina-colbert-v2
Awesome-RAG 2024: https://github.com/awesome-rag/awesome-rag
Self RAG https://arxiv.org/abs/2310.11511
LangGraph https://github.com/langchain-ai/langgraph/
TCAF：一种用于检索增强生成的思维链多智能体方法，SIGKDD 2024
RARE-针对大型语言模型的检索增强推理增强 https://arxiv.org/abs/2412.02830
PaliGemma https://hugging-face.cn/spaces/big-vision/paligemma-hf
ColPali：利用视觉语言模型的高效文档检索，https://arxiv.org/abs/2407.01449
Meta-Chunking：通过逻辑感知学习高效的文本分割 https://arxiv.org/abs/2410.12788
Mix-of-Granularity：优化检索增强生成的分块粒度 https://arxiv.org/abs/2406.00456