跳转到主内容

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

·阅读时间 35 分钟
Yingfeng Zhang

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

RAG 演进的关键事件​

争论：“RAG 已死，RAG 永生！”​

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

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

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

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

然而，要将其应用于更广泛的场景和企业中，并使其发展与 LLM 的进步保持一致，仍然面临着巨大的技术挑战。参考文献 [29] 和 [30] 概述了应对这些挑战的传统学术方法。虽然一些原则和实践得到了广泛接受，但通过实际分析可以发现，RAG 主要面临三个问题：

  1. 非结构化多模态文档的问答效果不佳：现有的 LLMOps 解决方案仅限于纯文本场景。PDF、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​

这两大事件都涉及排名模型的升级，并要求在数据库层面提供原生的张量支持。对于第一个事件，采用延迟交互模型可以有效地在数据库层面提供类似于重排模型的功能。对于第二个事件，这种方法为企业内部更复杂的文档（如杂志和饼图）释放了更大的商业价值。基于这一观察，我们在今年早些时候开源的专为 RAG 设计的数据库 Infinity 中全面实现了这些功能。尽管这些功能尚未应用于 RAGFlow，但其影响已经开始从前沿领域向整个行业扩散。

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

数据清洗​

确保高质量的输入（Quality In）是实现高质量输出（Quality Out）的必要条件，这是一个自然而然的概念。对于多模态非结构化文档，采用视觉模型解析文档布局可以确保高质量的数据输入。这个问题在学术界早已得到认可，并被广泛称为文档智能（Document Intelligence）。然而，以往的文档智能方法并未与 RAG 紧密联系，并且常常涉及多个缺乏紧密整合的子任务。例如，表格处理有一个专门的任务，称为表格结构识别（Table Structure Recognition, 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]，它针对文本数据，将文本分块步骤置于嵌入之后。换句话说，它首先使用嵌入模型对整个文档进行编码，然后在嵌入模型最终的均值池化步骤之前输出分块边界——因此得名“延迟”。与传统的文本分块方法相比，延迟分块更好地保留了上下文信息。然而，它要求嵌入模型的最终输出是均值池化，而大多数嵌入模型使用 CLS 池化，这使得直接兼容具有挑战性。

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

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

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

大约在同一时间，上海人工智能实验室和北京航空航天大学联合推出了“多粒度混合分块”（Multi-granular Hybrid Chunking）[参考文献 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，而是首先进行查询分析，包括：

  1. 分词后移除停用词和其他无意义的词元。
  2. 为每个词元生成词项权重。
  3. 在第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的背景下，排序涉及两个组件：一个是用于粗筛的部分，即用于向量搜索的嵌入模型；另一个是用于精排阶段的重排模型。重排模型的训练通常与嵌入模型的工作有很多共同之处。嵌入模型通常采用编码器架构，训练目标是在向量空间中将语义相似的文本拉近。相比之下，重排器使用交叉编码器架构，旨在预测查询与文档之间的分数。

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

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

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

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

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

另一方面，由于在查询过程中不涉及复杂的模型引用，其成本远低于交叉编码器或基于 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] 出现了，它为文本召回提供了更细粒度的定义：它使用相似性（similarity）和相关性（relevance）来衡量需求的不同维度。相似性使用向量或全文搜索方法计算文本块之间的语义距离，这正是 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 都可以用下图来说明。此外，我们还融入了图神经网络（GNNs）的元素，因为 2024 年有越来越多的工作旨在利用 GNNs 改进知识图谱问答 [参考文献 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 的典型数据模型可以如下所示：

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

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

Agentic 与记忆​

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] 中，系统包括多个自主智能体，它们可以将复杂的问答任务分解为子任务，每个智能体负责一个特定的功能。这种分工提高了系统的整体效率和准确性。在图中，检测器智能体（Detector Agent）旨在识别可能包含错误假设和前提的查询，这些错误可能会影响 LLM 响应的准确性；思想智能体（Thought Agent）处理和分析所有检索到的信息，综合数据得出结论并生成详细的推理结果；而答案智能体（Answer Agent）则使用思想智能体的输出来生成最终答案，确保多轮对话中的响应受到最新逻辑的影响。

例如，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 年涌现并开始应用。

首先，视觉-语言模型（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，也就是我们前面提到的第一代模型。目前，这两种方法的成功都依赖于多模态模型本身的进步。因此，我们相信这两条路线将长期共存。如果我们将嵌入视为一种“通用”解决方案，那么基于编码器-解码器架构的 OCR 可以被看作是一种“专门”解决方案，因为特定类型的数据仍然需要训练特定的 Transformer 才能有效解决。RAG 总是优先考虑实际应用，因此在特定时期的特定任务中，专门的解决方案可能会优于通用的，但最终它们会趋于融合。

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

以上内容总结了2024年RAG的主要发展趋势和未来展望。本文标题提到了“RAG产业”，从所提供的总结中可以清楚地看到，RAG是一个高度复杂的系统。虽然它没有像LLM那样吸引巨额资金，但在实际应用中却是不可或缺且错综复杂的。我们认为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. 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://hugging-face.cn/SciPhi/Triplex
  17. SiReRAG：为多跳推理索引相似和相关信息 https://arxiv.org/abs/2412.06206
  18. 图神经网络增强的LLM问答检索 https://arxiv.org/abs/2406.06572
  19. 图领域大语言模型综述 SIGKDD 2024
  20. KG-Retriever：用于检索增强大语言模型的高效知识索引 https://arxiv.org/abs/2412.05547
  21. PageRank混合模型：用实时、稀疏的GraphRAG取代长上下文 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://hugging-face.cn/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://hugging-face.cn/answerdotai/JaColBERTv2.5
  37. Jina ColBERT v2 https://hugging-face.cn/jinaai/jina-colbert-v2
  38. Awesome-RAG 2024: https://github.com/awesome-rag/awesome-rag
  39. Self 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://hugging-face.cn/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