2024年即将过去，检索增强生成（RAG）的发展可谓风起云涌。让我们从各个角度全面回顾一下这一年的进展。

RAG演进过程中的关键事件

辩论：“RAG已逝，RAG永存！”

2024年初，有人将这一年称为“RAG之年”，尽管这一称呼并未得到普遍认可。然而，这一年所取得的进展确实配得上这一称号。在涉及大型语言模型（LLM）的场景中，RAG始终证明着自己不可或缺的作用。然而，自其诞生以来，关于RAG的辩论就从未停止过。如上图所示，2023年“RAG”一词并不广泛使用，相反，“外部记忆”或“外部知识库”等临时术语更为流行。当时的辩论主要围绕是使用临时外部解决方案还是永久微调。到2024年初，这场辩论已基本尘埃落定：RAG在成本和实时性能方面具有明显优势，与微调相比，其有效性差异微乎其微。即使在需要微调的场景中，RAG也往往至关重要。

开源LLM对行业的影响

2024年上半年，对行业影响最为显著的是由OpenAI引领的开源LLM与商业LLM的逐渐融合。这意味着，与2023年相比，诸如摘要生成和指令遵循等能力有了显著提升。这一进展促进了基本RAG应用（如问答、客户服务和知识库）的广泛采用。在此期间，LLM的另一项显著进展是长上下文窗口——这一功能在整个上半年引发了争议，但到年中逐渐平息。与以往的辩论相似，人们得出结论，长上下文窗口和传统方法各有优势，最好结合使用。

此外，随着LLMOps等架构的成熟，企业和个人能够利用向量数据库、嵌入/重排序模型、大型语言模型本身、分块工具以及提示管理技术等组件，通过表示数据流的箭头将这些组件连接起来，快速搭建起自定义系统，确保系统的可用性。

然而，将其应用于更广泛的场景和企业中，并使其发展与大型语言模型（LLM）的进步相协调，仍然面临着巨大的技术挑战。虽然一些原则和实践已得到广泛认可，但通过实际分析发现，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已有近30年的历史，但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；已经有许多此类工作，包括蚂蚁集团最近的RAG 72总结。本文结合了工业界和学术界的视角，基于实际应用总结了今年的代表性工作。这些贡献中有许多并不严格包含在专注于RAG的论文中。我们认为，RAG不仅仅是一个简单的应用；相反，它是一个以搜索为中心的复杂系统，集成了各种数据类型、基础组件以及一系列大小模型协同工作。每个子问题都有相应的工作，因此不仅要审查RAG本身，还要保持更广阔的视角。

数据清洗

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

文档结构识别模型的任务是识别非结构化文档中不同语义区域的坐标。这类模型已经在一些OCR（光学字符识别）系统中得到应用；例如，著名的PaddleOCR就包含了文档结构识别功能。因此，前面提到的各种任务，包括表格处理，通常被称为广义OCR，并可以被视为检索增强生成（RAG）的入口点。

RAGFlow的DeepDoc模块是最早全面实现这些功能的系统之一，这对其开源后的迅速增长做出了重大贡献。目前，已经有几个类似的系统，如MinerU和Docling。将文档智能应用于RAG代表了一个广阔的发展空间，推动了这一领域的快速迭代。

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

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

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

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

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

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

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

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

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

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

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

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

混合搜索

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

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

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

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

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

例如，对于问题“Tom取得了什么成果？”，我们可能会得到以下查询：

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

另一方面，为了确保召回率，全文搜索默认在关键词之间使用“或（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是从Qwen2 7B基础模型微调而来的。这种方法不再使用传统的编码器架构，而是采用标准的大型语言模型解码器架构，从而导致参数数量更多，推理成本更高。

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

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

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

基于张量的重排名起源于2020年的早期工作，如ColBERT及其改进版本ColBERT v2。然而，直到2024年初，它才在业界引起广泛关注。当时，由于缺乏必要的数据库支持，它依赖于像RAGatouille这样的Python算法包装器来提供服务。Vespa是首批构建张量能力的数据库系统之一，我们在年中将基于张量的重排名集成到了Infinity数据库中。

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

语义鸿沟

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

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

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

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

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

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

PageRank是一个值得提及的有效策略，另一篇2024年关于知识图谱的重要论文——HippoRAG也讨论了这一策略。该论文讨论了海马体索引理论和基于个性化PageRank的随机游走策略，这与人类大脑基于记忆的思考方式非常相似。因此，在构建知识图谱后，使用个性化PageRank查询它可以模拟人类与长文本信息相关的回忆和思考过程。下面的图表可以说明Fast GraphRAG和HippoRAG。此外，我们还融入了图神经网络（GNN）的元素，因为2024年越来越多的工作旨在使用GNN改进知识图谱问题回答。

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

另一种降低GraphRAG相关成本的方法来自模型本身。由于LLM提取成本高昂，微调一个较小、专门的模型可以显著降低成本。Triplex就是一个例子，它利用3B Phi-3模型进行知识图谱提取。

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

尽管知识图谱已经存在很长时间，但其应用主要涉及大量需要解释的工作，如数据导航，需要人类和领域专家的干预。这不是GraphRAG应用的舒适区。即使是由LLM提取的命名实体和关系仍然包含相当多的噪声。鉴于LLM在知识图谱提取方面的局限性，后续围绕GraphRAG的工作不仅关注成本降低，还关注如何将实体组织成更有效的结构。到年底，出现了两项值得注意的工作：KG-Retriever和Mixture-of-PageRanks。前者将知识图谱与原始数据结合，创建了一个多层次图索引结构，以支持不同粒度的检索；后者基于个性化PageRank引入了基于时间的相关性信息。我们可以期待2025年这一领域会有进一步发展，尽管它们不会改变GraphRAG类型工作的基本性质。

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

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

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

代理性和记忆

代理性（Agentic）是2024年RAG行业中的一个流行术语，许多媒体宣称这一年是代理之年。无论这一称号是否准确，代理都对LLM生态系统产生了重大影响。本文不是对代理的回顾，但很明显，代理与RAG之间存在着密不可分的关系：RAG本身是代理的关键组件，使它们能够访问内部数据；反之，代理可以增强RAG的能力，从而形成所谓的代理性RAG，如Self RAG和Adaptive RAG。

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

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

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

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

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

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

多模态RAG

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

首先，视觉语言模型（VLM）的兴起值得关注。如图中所示，到2024年年中，VLM已从主要关注简单的图像搜索迅速发展。

这意味着视觉语言模型（VLM）对图像的理解更加深入，已经超越了仅仅识别日常物体的阶段，能够全面分析企业级的多模态文档。例如，开源的3B模型PaliGemma就体现了这种能力。

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

为了实现这一点，如前所述，一种方法是使用模型将多模态文档转换为文本，然后再进行索引以便检索。另一种方法则利用VLM的进步，直接生成向量，绕过了复杂的OCR（光学字符识别）过程。2024年夏季出现的ColPali就是这一方法的开创性例子。ColPali将图像视为1024个图像块，并为每个块生成嵌入，从而有效地将单个图像表示为一个张量。

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

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

下图展示了多模态RAG检索的排行榜，突出了基于张量的迟交互模型系列在多个领先位置上稳占一席之地。

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

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

以上内容总结了2024年RAG的主要发展趋势和未来展望。本文标题中提到了“RAG行业”，从提供的总结中可以看出，RAG是一个高度复杂的系统。尽管它还没有像LLM那样吸引大量资金，但在实际应用中，它是不可或缺且错综复杂的。我们认为RAG这一术语定义明确；它代表了一种架构模型，而不是单一产品或应用场景。在某些方面，RAG类似于过去的数据库——外部接口简单但内部复杂。它不仅包括数据库本身，还包括各种小型模型和连接它们的工具。本质上，它代表了大模型时代企业搜索引擎的演进，同时远远超出了传统搜索引擎的范围。