随着2024年接近尾声，检索增强生成（RAG）的发展可谓风起云涌。让我们从多个维度全面回顾这一年的进展。
RAG演变中的关键事件
争论：“RAG已死，RAG永生！”
2024年初，一些人将这一年冠以“RAG之年”的称号，尽管这并非普遍接受的说法。然而，贯穿全年的进展无疑印证了这个称谓。在涉及大型语言模型（LLMs）的场景中，RAG持续证明了其不可或缺的作用。然而，自诞生以来，关于RAG的争论从未停止。正如上图所示，2023年“RAG”这个术语并未被广泛使用；相反，临时性的术语如“外部记忆”或“外部知识库”更为流行。那时主要的争论围绕着是采用临时的外部解决方案还是永久性的微调。到2024年初，这场争论基本尘埃落定：RAG在成本和实时性能方面具有明显优势，与微调相比效果差异不大。即使在需要微调的场景中，RAG也常常是必不可少的。
2024年上半年，对行业影响最大的一点是，以OpenAI为代表的商业LLMs与开源LLMs之间的能力差距逐渐缩小。这意味着总结、指令遵循等能力相对于2023年有了显著提升。这一进步促使问答、客服、知识库等基础RAG应用得以广泛落地。同期LLMs的另一个显著进展是长上下文窗口——这个特性在上半年引发了不少争议，但在年中逐渐平息。与之前的争论类似，最终的结论是长上下文窗口和传统方法各有优劣，最好结合使用。
| 长上下文 | RAG |
|---|---|
| 👎准确性随上下文长度增加而下降。 | |
| 👎上下文窗口越长，越容易遗漏遥远的“针”（信息）。 | |
| 👎如果检索到的内容语义相似但不相关，会引入噪音。 | |
| 👎LLM 本质上是“不确定的”。 | |
| 👎仅靠长上下文难以整合企业数据。 | |
| 👎长上下文显著增加了推理成本和延迟。 | |
| 👎不够智能：只能搜索，无法推理或决策。 |
此外，LLMOps等架构的成熟使得企业和个人能够快速搭建自己的定制系统，利用向量数据库、嵌入/重排模型、LLM本身、分块工具和提示词管理等组件，并通过表示数据流动的箭头连接，确保系统可用性。
然而，将其应用于更广泛的场景和企业中，并使其发展与LLMs的进步同步，仍然面临着显著的技术挑战。参考文献[29]和[30]概述了解决这些挑战的传统学术方法。尽管一些原则和实践已被广泛接受，但实际分析表明，RAG主要面临三个核心问题：
-
非结构化多模态文档的问答效果不佳：现有的LLMOps解决方案仅限于纯文本场景。PDF、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
这两大事件都涉及排名模型的升级，并要求数据库层面具备原生的张量支持。对于第一件事，采用延迟交互模型相当于在数据库层面提供了类似于重排模型的能力。对于第二件事，这种方法为企业内更复杂的文档（如杂志和饼图）释放了更大的商业价值。基于这一观察，我们在今年早些时候开源的专门为RAG设计的数据库Infinity中全面实现了这些能力。尽管这些特性尚未应用于RAGFlow，但其影响已开始从前沿向更广泛的行业扩散。
以下从工业界和学术界两个角度，总结了2024年RAG的技术发展。RAG是今年研究的热点。从年初开始，关于RAG的预印本论文频率已达到每周十余篇，有的周甚至达到数十篇。这些论文主要聚焦于RAG的应用、调优和评估等实验性工作，并得出各种结论。本文无意做一篇全面的RAG学术综述，已有很多这样的工作[Reference 27] [Reference 28]，包括蚂蚁集团近期总结的RAG 72篇[Reference 38]。本文从产业界与学术界结合的视角出发，结合实际应用，对这一年的代表性工作进行总结。许多这些贡献并非严格意义上聚焦于RAG的论文所涵盖。我们认为RAG不仅仅是一个简单的应用，而是一个围绕搜索展开的复杂系统，集成了各种数据类型、基础组件，以及大小模型协同工作。每个子问题都有相应的工作，因此不仅需要回顾RAG本身，还需要保持更广阔的视角。
数据清洗
保证数据质量（Quality In）是获得高质量结果（Quality Out）的必然要求，这是一个很自然的理念。对于多模态非结构化文档而言，利用视觉模型解析文档布局，是保障高质量数据输入的基础。这个问题在学术界早已得到认识，并被广泛称为文档智能（Document Intelligence）。然而，之前对文档智能的研究与RAG关联不大，且常常涉及多个缺乏紧密整合的子任务。例如，表格处理有一个专门的任务叫做表格结构识别（TSR），对于公式、流程图、饼图等其他图像类型，也有类似的专门模型。将这些模型统一到一个文档布局识别框架下，是我们利用模型进行数据清洗以支持RAG的第一步。
文档结构识别模型的任务是识别非结构化文档中不同语义区域的坐标。这类模型在一些OCR系统中已有实现，比如知名的PaddleOCR [Reference 1]就具备文档结构识别能力。因此，前述包括表格处理在内的各种任务，常常被称为广义OCR，可以看作是RAG的数据入口。
RAGFlow的DeepDoc模块是业界最早全面实现这些能力的系统之一，这为其开源后迅速增长贡献良多。目前，业界也有MinerU [Reference 2]和Docling [Reference 3]等几个类似系统。将文档智能应用于RAG是一个广阔的发展领域，也促进了该领域的快速迭代。
从方法论上看，文档智能模型可以分为两代：
第一代：包括过去的相似工作和目前主流的开源项目，如RAGFlow的DeepDoc模块。这些工作基于传统的视觉模型构建。它们可以在CPU上运行，但在不同场景下的泛化能力有限。由于需要针对不同上下文和数据进行单独训练，这种技术被俗称为“绣花”。
第二代：当前的OCR技术正朝着生成式AI架构演进。早期的例子包括Meta的Nougat [Reference 4]，以及最新的OCR 2.0 [Reference 5]，它们采用统一的基于Transformer的编码器-解码器架构，通过图像识别生成文本结果。这些发展与后文提到的多模态VLMs有很多相似之处。例如，StructEqTable [Reference 6]直接将类似的网络结构应用于表格重建。RAGFlow的企业版也采用了这种架构进行文档处理。虽然生成式AI模型推理无法在CPU上运行，但它们在各种场景下的泛化能力比传统的视觉模型有了显著提升。利用多模态模型进行文档智能的另一个优势是能够将文本信息融入到文档布局中。今年一项有代表性的工作M2Doc [Reference 23]将BERT集成到基于视觉的编码器-解码器架构中，增强了文本和段落的语义边界识别。
展望即将到来的2025年，基于编码器-解码器架构的研究有望进一步发展。我们可以期待一个统一的多模态文档解析模型的潜在出现，能够准确地将各种非结构化文档转换为文本内容。
以上内容可以视为针对多模态非结构化文档数据的数据清洗。但对于纯文本文档而言，仅仅依赖朴素的文本分块是否足够？答案是否定的。如果文本块只包含文本信息，那么检索时的主要问题就从内容混淆转向了语义鸿沟。这一点我们将在后面详细讨论。这里，我们介绍一些在分块层面进行的修补工作：
今年，Jina发布了“延迟分块”（Late Chunking）[Reference 24]，其针对文本数据，将文本分块步骤放在了嵌入之后。换句话说，它先使用嵌入模型对整个文档进行编码，然后在嵌入模型的最终平均池化（mean pooling）步骤之前输出块边界——因此得名“延迟”。与传统文本分块方法相比，延迟分块能更好地保留上下文信息。然而，它要求嵌入模型的最终输出是平均池化，而大多数嵌入模型使用的是CLS池化，这使得直接兼容存在挑战。
2024年，业界还针对文本数据提出了dsRAG [Reference 25]。其主要贡献在于通过使用大型模型为每个文本块添加上下文信息，从而提供自动上下文，解决了原始文本难以检索的问题。例如，如果文本中包含治疗方案而没有疾病描述，则可能无法检索到相关内容。dsRAG的另一个特点是将文本块聚类成长段落；尽管评估分数不错，但这在实践中可能效果不佳。
LLM提供商Anthropic Claude也在九月推出了“上下文检索”（Contextual Retrieval）[Reference 26]，其中包括一个名为上下文分块（Contextual Chunking）的重要组件。顾名思义，这涉及为每个文本块引入由LLMs生成的特定上下文解释。因此，上下文检索与dsRAG有类似的效果。
十月，人民大学和上海算法创新研究院联合推出了“元分块”（Meta-Chunking）[Reference 45]，旨在识别段落内具有逻辑关联的句子集合边界。这种方法使用LLMs进行分类，判断句子是否属于同一块。然而，与之前的方法不同，它虽然也使用了LLMs，但并未解决语义鸿沟问题。
差不多同一时间，上海人工智能实验室和北京航空航天大学联合推出了“多粒度混合分块”（Multi-granular Hybrid Chunking）[Reference 46]。这种方法将每个文档分割成更小的块，通常包含一到两个句子。这些块被视为图中的节点；在检索时，模型根据查询预测所需的块粒度，并根据此粒度决定在图中遍历的深度——遍历越深，最终获得的块越大。尽管实现复杂，但这种方法并未缓解语义鸿沟问题；它只是动态决定大型模型返回的上下文长度以避免冗余，使其实际价值不如之前的方法显著。
很明显，基于文本分块本身可做的工作有限。今年有价值的贡献集中在为块提供更多上下文信息上，这被证明更为实用；由LLM提供的这类上下文更为可靠。通过使用LLMs来解释块内容并添加诸如标签之类的补充信息，我们可以部分解决由于语义鸿沟导致块无法被召回的问题。在今年版本的RAGFlow中，我们也增加了LLMs从文本块中提取信息以提高召回性能的步骤。
无论是对于多模态数据还是文本数据，分块的结果都显著影响最终效果。展望2025年，我们可以期待该领域更多高质量的工作，最终解决与数据输入质量相关的问题。
混合搜索
2024年4月，IBM研究院发布了一份题为“BlendedRAG”的技术报告[Reference 7]，通过实验证明，采用多种召回方式可以为RAG带来更好的效果。具体而言，结合向量搜索、稀疏向量搜索和全文搜索能够实现最佳召回。这很容易理解，因为向量可以代表语义；一个句子甚至一篇文章可以被一个向量囊括。本质上，向量传达的是文本的“意义”，代表了其在上下文窗口内与其他文本共现的压缩概率。因此，向量无法精确地代表查询。例如，如果用户问：“我们公司2024年3月的财务计划包含哪些组合？”结果可能会返回其他时间段的数据或运营计划、营销管理等不相关的主题。相比之下，全文搜索和稀疏向量主要表达精确的语义。因此，结合这两种方法可以满足我们日常对语义理解和精确性的双重需求。
在RAG框架中，混合搜索通常由专用的数据库来处理。尽管有许多数据库提供各种混合搜索能力，但真正合适的选项很少，因为实现一个强大的全文搜索具有挑战性：
稀疏向量难以复制全文搜索：稀疏向量旨在通过使用标准预训练模型去除冗余词并添加扩展词来替代全文搜索，从而产生固定维度的稀疏向量输出（例如30,000或100,000维度）。这种方法在通用查询任务上表现良好；然而，许多用户查询关键词可能不存在于用于生成稀疏向量的预训练模型中——例如特定的机器型号、手册和专业术语。因此，虽然稀疏向量和全文搜索都服务于精确召回的目的，但它们各有优势，无法相互替代。
全文搜索不仅仅是BM25计算：它还需要考虑短语查询（phrase queries）和相关的性能问题。RAGFlow是首批提供混合搜索的RAG解决方案之一，最初使用Elasticsearch作为其唯一的后端文档搜索引擎。在RAGFlow中，用户查询并非直接发送到Elasticsearch；它们首先经过查询分析，分析内容包括：
- 在分词后移除停用词及其他无意义的词元。
- 为每个词元生成词权重。
- 根据步骤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的上下文中，排名涉及两个组件：一部分用于粗粒度过滤，即向量搜索的嵌入模型；另一部分是在微调阶段使用的重排模型（reranker model）。重排模型的训练往往与嵌入模型有很多共通之处。嵌入模型通常采用编码器（encoder）架构，训练目标是将语义相似的文本在向量空间中拉近。相比之下，重排器使用交叉编码器（cross-encoder）架构，旨在预测查询与文档之间的得分。
如图所示（图未提供），左侧展示了嵌入模型的工作方式：它分别对查询和文档进行编码，然后通过池化输出一个向量，在排名阶段只需计算向量相似度。然而，因为它丢失了查询和文档中词元之间的交互信息，很多语义信息会丢失，这就是向量搜索通常用于粗粒度过滤的原因。交叉编码器作为重排器可以拥有与嵌入模型相同的编码器网络，但通过将查询和文档一起输入，它输出一个单一得分。这使得它能够捕获词元之间的关系，显著提高排名质量。
然而，交叉编码器也有其缺点：对于编码器来说，文档嵌入可以在离线索引阶段完成，在线查询时只需对查询进行编码即可快速检索。相比之下，交叉编码器需要对每个查询-文档对进行交叉编码和模型输出，这会产生较高的计算成本。因此，它们仅适用于重排，且粗粒度过滤结果不能太多；否则，将显著增加查询延迟。
在评估嵌入模型和重排模型时，MTEB排行榜常被引用。2024年上半年，重排排行榜主要被各种交叉编码器占据，而下半年，基于大型语言模型（LLMs）的重排模型越来越多地占据主导地位。例如，当前排名靠前的gte-Qwen2-7B [Reference 31]模型是从Qwen2 7B基础模型微调而来。这种方法不再使用传统的编码器架构，而是采用标准的LLM解码器架构，导致参数量更大，推理成本更高。
考虑到排名效果和成本，一种名为延迟交互模型（late interaction model）的重排方案受到了关注；这涉及到基于张量（tensor）的重排，如下图所示。（图未提供）
具体方法如下：在索引阶段，存储由编码器为每个词元生成的嵌入。因此，一个文档可以用一个张量（或多个向量）表示。在查询时，生成查询中每个词元的嵌入，并计算查询中所有词元与文本块之间的成对相似度。最终的文档得分通过累加这些相似度获得。这种重排方法也捕获了词元之间的交互信息，理论上可以达到与交叉编码器相当的性能。
另一方面，由于查询时不涉及复杂的模型推理，成本显著低于交叉编码器或基于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的论文[Reference 8]，并在年中正式开源，迅速在GitHub上获得了上万颗星。GraphRAG为何如此受欢迎？这与我们之前提到的RAG的第三个痛点紧密相关：语义鸿沟。
解决语义鸿沟的方法有很多。除了分块阶段的改进，预处理阶段还可以做更多工作。一个知名且实用的解决方案是RAPTOR [Reference 9]。RAPTOR首先对文本内容进行预聚类，然后使用大型语言模型（LLM）生成聚类文本的摘要。这些摘要与原始文本一起被发送到搜索系统。由于这些摘要提供了对文本更宏观的理解，它们可以为模糊查询和需要跨越多个文本块的多跳问题提供合适的答案。RAPTOR已在年中集成到RAGFlow中，用于辅助回答复杂问题。
到2024年底，基于RAPTOR的SiReRAG [Reference 17]出现，它提供了更细粒度的文本召回定义：使用相似性（similarity）和相关性（relevance）来衡量不同维度的需求。相似性通过向量或全文搜索方法计算文本块之间的语义距离，这正是RAPTOR本身所做的（图左侧所示，图未提供）。相关性则表示文本块之间的关系；它首先使用LLM从每个块中提取命名实体，然后基于这些实体与其对应块之间的关系构建一个分层树结构（图右侧所示，图未提供）。因此，在召回过程中，多种文本粒度可以提供混合召回，包括实体、实体组和原始文本，进一步增强了对数据的宏观理解，并提高了对模糊意图和多跳查询场景的召回率。
SiReRAG与GraphRAG非常相似，主要区别在于如何进一步处理和组织提取的实体。让我们仔细看看GraphRAG本身：它使用大型模型自动从文档中提取命名实体，并基于这些实体构建知识图谱。在图谱内部，它还使用聚类技术创建实体的“社区”，并利用LLMs为这些社区生成摘要。在召回时，知识图谱中的实体、边和社区摘要与原始文档结合进行混合召回。这些数据形成了文档内部的跨块关联，从而在宏观层面查询和多跳问题上取得更好的效果。GraphRAG可以视为解决语义鸿沟的有效策略和架构。
这里使用“架构”一词，是因为它代表了一种利用LLMs提取知识图谱以辅助复杂问答的范式。除了微软，还有许多其他公司也提出了自己的GraphRAG解决方案，例如蚂蚁集团的KAG [Reference 10]和Nebula的GraphRAG [Reference 11]，各有侧重。例如，KAG强调知识图谱的完整性和可解释性，需要结合人工维护和领域专家知识要素来实现领域特异性。同时，Nebula GraphRAG则强调与LangChain和Llama Index等知名LLM框架深度集成，将它们融入到Nebula Graph数据库中。
GraphRAG架构中一个显著的痛点是巨大的token消耗。因此，自GraphRAG以来，出现了几种变体，包括Fast GraphRAG [Reference 12]、LightRAG [Reference 13]以及微软即将推出的LazyGraphRAG [Reference 14]。Fast GraphRAG也使用LLMs提取实体和关系，类似于微软的方法，但省略了“社区”及其摘要的生成，从而减少了LLM请求的频率。在检索时，Fast GraphRAG根据查询在知识图谱中找到最近的实体，然后利用个性化PageRank在图谱中进行随机游走以获取子图，再用子图生成最终答案。
PageRank是一种值得提及的有效策略，与另一篇2024年关于知识图谱的有影响力的论文——HippoRAG [Reference 15]并行。这篇论文讨论了海马体索引理论以及基于个性化PageRank的随机游走策略，这与人类大脑基于记忆的思考方式非常相似。因此，构建知识图谱后，使用个性化PageRank进行查询可以模拟人类对长文本信息的召回和思考过程。Fast GraphRAG和HippoRAG都可以用下图（图未提供）来说明。此外，我们还加入了图神经网络（GNNs）的元素，因为2024年有越来越多的工作致力于使用GNNs改进知识图谱问答[Reference 18] [Reference 19]。感兴趣的读者可以参考相关文献了解更多信息。由于GNN工作通常需要额外的用户数据进行训练——例如利用现有问答数据增强命名实体的图嵌入表示——这些工作涉及较高的定制成本，超出了本次讨论的主要范围。
LightRAG是GraphRAG的简化版本，移除了社区结构使其更加轻量。微软在2024年末提出的LazyGraphRAG则进一步简化，取消了对LLMs提取知识图谱的依赖。相反，它使用更小的本地模型来提取名词，并基于共现构建社区结构。社区摘要仅在查询时动态生成。降低与GraphRAG相关成本的另一种方法来自模型本身。由于LLM提取成本高昂，微调一个更小的、专门化的模型可以显著降低成本。Triplex [Reference 16]就是一个例子，它利用3B的Phi-3模型进行知识图谱提取。从上述可知，GraphRAG架构有效地利用LLMs为原始文档补充了足够的信息，并以易于连接的图格式组织。在搜索时，这在文本相似性之外，还增加了基于各种实体的辅助召回能力。因此，知识图谱在GraphRAG中的价值不在于供人直接查看，而在于为复杂和模糊的问题提供额外的上下文和证据。尽管知识图谱由来已久，但其应用主要涉及大量可解释性工作，如数据导航，需要人工和领域专家介入。这并非GraphRAG的应用舒适区。即使是LLMs提取的命名实体和关系仍包含相当多的噪音。考虑到LLMs在知识图谱提取方面的局限性，GraphRAG相关的后续工作不仅关注成本降低，还关注如何将实体组织成更有效的结构。年底涌现了两项值得注意的工作：KG-Retriever [Reference 20]和Mixture-of-PageRanks [Reference 21]。前者将知识图谱与原始数据结合，创建了一个多层图索引结构，用于不同粒度的检索；后者则在个性化PageRank基础上引入了基于时间的相关性信息。我们可以期待2025年该领域取得进一步发展，尽管这不会改变GraphRAG类工作的根本性质。
最后，我们考虑GraphRAG的工程实现。为GraphRAG使用图数据库是一个自然的选择；KAG和Nebula Graph都采用了这条技术路线，因为图数据库能更好地表示知识图谱。RAGFlow也在年中将其GraphRAG集成到了系统端到端流程中，但并未采用图数据库，而是依赖于搜索引擎。在GraphRAG内部的数据建模方面，知识图谱中的实体和边以文本形式描述，通过聚类实体得到的社区及其生成的摘要也是如此。一个典型的GraphRAG数据模型如下图所示：（图未提供）
一个功能完备的全文索引不仅应提供相似度得分计算，还应提供关键词过滤能力。因此，通过在上述模式中的`
从数据模式可以看出，通过简单地增加一个type字段，原始文本块可以与其它信息存储在同一张表中，有效地将GraphRAG与RAG结合成一个HybridRAG [Reference 22]。显然，使用具有丰富索引能力的数据库可以显著降低实现GraphRAG的工程挑战。即使是修改图结构的工作，如KG-Retriever和Mixture-of-PageRanks，也可以通过调整索引格式和增强特定的搜索方法来轻松支持。这也是我们从头构建一个专门服务于RAG的数据库的主要动机之一。
Agentic 与记忆
Agentic是2024年RAG行业的一个流行术语，许多媒体宣称2024年是Agent之年。无论这个称谓是否准确，Agent确实显著影响着LLM生态系统。本文并非Agent的回顾，但Agent与RAG之间存在密不可分的关系是显而易见的：RAG本身是Agent的关键组件，使Agent能够访问内部数据；反之，Agent可以增强RAG的能力，从而催生了诸如Self RAG [Reference 39]和Adaptive RAG之类的Agentic RAG。
这种高级形式的RAG允许在更复杂的场景中以可控的方式进行自适应改变。要实现Agentic RAG，Agent框架必须具备“闭环”能力。在吴恩达提出的Agent的四种设计模式中，这种“闭环”能力被称为反射能力（reflective capability）。LangGraph [Reference 40]是早期实现这一功能的框架之一，RAGFlow也在年中引入了类似的功能。
2024年Agent的一个关键特点是工作流（workflows）的广泛应用。无论Agent如何演进，工作流仍然是与各种系统集成并确保Agent以可控方式执行任务的关键。然而，Agent的概念超出了工作流的范畴；它还包括与推理相关的思考和决策。2024年下半年，该领域的研究开始加速。
将RAG与Agent集成可以解锁更多应用场景。例如，在图[Reference 41]所示的配置中（图未提供），系统包含多个自主Agent，它们可以将复杂的问答任务分解为子任务，每个Agent负责特定的功能。这种分工提高了系统的整体效率和准确性。在图中（图未提供），Detector Agent旨在识别可能包含错误假设和前提的查询，这些查询可能影响LLM响应的准确性；Thought Agent处理和分析所有检索到的信息，合成数据以得出结论并生成详细的推理结果；而Answer Agent则使用Thought Agent的输出来生成最终答案，确保多轮对话中的响应受到最新逻辑的影响。
例如，RARE [Reference 42]通过引入蒙特卡洛树搜索（MCTS）框架增强了RAG，该框架通过两个步骤加强推理能力：基于初始问题生成查询，以及查询生成的子问题。通过实施这些步骤，RARE可以在医疗场景中促进复杂和常识性的推理。
随着这种推理能力的发展，RAG与Agent之间的关系变得越来越紧密，交互也更加频繁。因此，RAG需要提供超出先前提到的文档搜索之外的记忆管理功能。这些记忆信息包括用户对话会话和个性化用户数据。Agent不仅需要RAG执行内部数据搜索，还需要实时访问上下文信息。2024年开源项目Mem0定义了一些记忆管理API并迅速获得了大量GitHub星，这体现了这一需求。然而，需要注意的是，当前记忆管理的定义相对简单（主要涉及实时过滤和搜索），而底层基础设施组件已经相当成熟。因此，真正的挑战在于将记忆管理与推理整合，并伴随LLM能力的增长解锁更复杂的企业级场景。在标准化RAG引擎上实现这些功能是一个逻辑选择，它能最大限度地降低成本并提高可用性，使其成为2025年的一个重要趋势。
此时，许多人可能想知道未来的演变是RAG转型成为Agent平台，还是各种Agent平台增强其RAG能力。这个趋势难以预测。正如数字时代一样，人们可能会争论是专注于数据仓库，同时解决中台业务需求，还是深化业务能力以改进数据仓库——这两种方法都有先例。在LLM智能时代，软件生态系统面临着变革性重塑的机会；因此，RAG可以有效地扮演传统数据库的角色，而Agent由于定制化需求降低，有可能成为应用层的标准化产品。未来的发展将在技术深度和快速产品迭代的双重支持下动态演进，各种软件生态系统之间的集成也将更加紧密。例如，年末LangGraph发布了基于LLM的Agent互操作协议，为不同Agent之间生态上游和下游关系带来了更大的潜力。
多模态 RAG
多模态RAG是我们认为将在2025年经历快速增长的另一个领域，因为相关的关键技术在2024年出现并开始应用。
首先，视觉-语言模型（VLMs）的兴起引人注目。如图（图未提供）所示，VLMs之前主要关注简单的图像搜索，但在2024年中期已迅速发展。
这意味着VLMs对图像的理解更加深入，不再仅仅识别日常物体，而是能够全面分析企业级多模态文档。例如，开源的3B模型PaliGemma [Reference 43]就是这种能力的体现。
回到RAG本身，如果我们能够利用RAG，基于用户查询在大批PDF中找到包含答案的图片和文本，然后利用VLMs生成最终答案，这就是多模态RAG的意义所在；它超越了对日常物品的简单图片搜索。
为了实现这一点，一种方法如前所述，是使用模型将多模态文档在索引前转换为文本进行检索。另一种方法，利用VLMs的进步，直接生成向量，绕过了复杂的OCR过程。一个开创性的例子是2024年夏季出现的ColPali [Reference 44]。ColPali将一张图片视为1024个图片块，并为每个块生成嵌入，有效地将单张图片表示为一个张量。
最终的重排使用张量进行。
整个检索流程如下图（图未提供）所示。它需要一个不仅支持基于张量的重排，还能在向量检索阶段容纳多向量索引的数据库。这些结构在我们的Infinity数据库中已经准备就绪。
下图（图未提供）展示了多模态RAG检索的一个排行榜，突出显示了基于张量的延迟交互模型系列占据了许多领先位置。
因此，张量不仅对文本排名至关重要，在多模态RAG中也有广泛应用。问题在于：多模态RAG是应该直接生成嵌入，还是应该先使用通用OCR模型将文档转换为文本？在原始ColPali论文中，作者建议完全放弃OCR，但他们比较的是基于CNN的OCR，即前面提到的第一代模型。目前，这两种方法的成功都取决于多模态模型本身的进步。因此，我们认为这两条路线将长期共存。如果我们将嵌入视为“通用”解决方案，那么基于编码器-解码器架构的OCR可以视为“专用”解决方案，因为特定类型的数据仍然需要训练特定的Transformer才能有效解决。RAG始终优先考虑实际落地，因此在某些特定时期特定任务中，专用解决方案可能优于通用解决方案，但最终它们会趋于融合。
在2025年，我们可以期待多模态RAG的快速增长和演进，我们也将适时将这些能力集成到RAGFlow中。
以上内容总结了RAG在2024年的主要发展趋势和未来展望。本文标题提到了“RAG行业”，从总结中可以看出，RAG是一个高度复杂的系统。尽管它不像LLMs那样吸引了巨额资金，但在实际应用中却是不可或缺且错综复杂的。我们认为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: Indexing Similar and Related Information for Multihop Reasoning https://arxiv.org/abs/2412.06206
- Graph Neural Network Enhanced Retrieval for Question Answering of LLMs https://arxiv.org/abs/2406.06572
- A Survey of Large Language Models for Graphs SIGKDD 2024
- KG-Retriever: Efficient Knowledge Indexing for Retrieval-Augmented Large Language Models https://arxiv.org/abs/2412.05547
- Mixture-of-PageRanks: Replacing Long-Context with Real-Time, Sparse GraphRAG https://arxiv.org/abs/2412.06078
- HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction, Proceedings of the 5th ACM International Conference on AI in Finance, 2024
- M2Doc-A Multi-Modal Fusion Approach for Document Layout Analysis, AAAI 2024
- Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models https://arxiv.org/abs/2409.04701
- dsRAG https://github.com/D-Star-AI/dsRAG/
- Contextual Retrieval https://www.anthropic.com/news/contextual-retrieval
- A Comprehensive Survey of Retrieval-Augmented Generation (RAG: Evolution, Current Landscape and Future Directions https://arxiv.org/abs/2410.12837
- Retrieval-Augmented Generation for Natural Language Processing: A Survey https://arxiv.org/abs/2407.13193
- 12 RAG Pain Points and Proposed Solutions https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
- Searching for Best Practices in Retrieval-Augmented Generation https://arxiv.org/abs/2407.01219
- https://hugging-face.cn/Alibaba-NLP/gte-Qwen2-7B-instruct
- Colbert: Efficient and effective passage search via contextualized late interaction over bert, SIGIR 2020
- Colbertv2: Effective and efficient retrieval via lightweight late interaction, 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: a Multi-Agent Approach of Thought Chain for Retrieval Augmented Generation, SIGKDD 2024
- RARE-Retrieval-Augmented Reasoning Enhancement for Large Language Models https://arxiv.org/abs/2412.02830
- PaliGemma https://hugging-face.cn/spaces/big-vision/paligemma-hf
- ColPali: Efficient Document Retrieval with Vision Language Models, https://arxiv.org/abs/2407.01449
- Meta-Chunking: Learning Efficient Text Segmentation via Logical Perception https://arxiv.org/abs/2410.12788
- Mix-of-Granularity-Optimize the Chunking Granularity for Retrieval-Augmented Generation https://arxiv.org/abs/2406.00456