写在RAGFlow开源2万星标之际

RAGFlow自2024年4月1日正式开源，时至今日，不到7个月时间已经站在了Github 2万星标的台阶之上。在6月底Github 1万星标的时候，我们曾经写了一篇文章，提出RAG 2.0的口号【参考文献1】，论述了RAG作为一种以搜索为中心的系统，为保证最终的对话效果，需要端到端的在每个环节来解决RAG面临的问题，这包含数据的信息抽取、文档预处理、以及数据的检索和排序。此时此刻，我们回首过去，是时候来做一番总结，并同时展望未来。

我们的总结和展望，来自如下几个层面：

1. 老生常谈，长久以来关于RAG本身的争论，它究竟是否真的只是一种临时方案。

2. RAGFlow做对了什么，接下来会从哪些方面改进。

3. RAG和Agent，工作流之间到底是什么关系。

4. 多模态RAG是当下，还是未来已来。

一、关于RAG本身

RAG自从2020年由Meta提出，并在2023年春Nvidia GTC大会后火热之后，就一直争论不断。有趣的是，这种争论，大都来自媒体，咨询公司，或者一些研究机构，而来自企业端的声音很少，在国内一些常见的AI技术峰会，RAG分论坛的人气通常都是最高的之一。这反应了一个事实，RAG已经是一种事实上的落地标准架构，尽管它面临这样那样的问题，但确实没有其他方案可以取代。

这些争论，大体上可以分为两个阶段：

第一个阶段集中于2023年，主要争议来自微调对比RAG。这个争议持续到2023年底已经基本偃旗息鼓，因为结论很明显，从成本和实时性角度，RAG具有压倒性优势，而效果上相差也并不大，即使需要微调介入的场景，RAG通常也不可或缺。

第二个阶段集中于2024年上半年，主要争议来自长上下文LLM对比RAG。这个争议到如今也接近偃旗息鼓，结论同样很清晰，两者是天然的组合，在能力上取长补短。来自多方面的研究已经证实，单纯就AI能力来讲，长上下文LLM依然面临在上下文段落增加时准确率不断下降的事实，因此，在任何情况下，提供高精度的搜索系统（RAG）都是极有价值的。这如同一个类比，我们不能因为某个人聪明和记忆好，就要让他去回答一切问题而不给他提供任何工具。

下图是我们针对LLM和RAG在各自能力的演进上对过去做的一个总结，以及对未来的展望。我们在第四部分会再次回顾这张图。

相比于一些机构和媒体针对大模型落地不佳，还有大模型泡沫破灭的的悲观论调，我们始终坚定的认为，这些都只是人们对过去AI过高期待带来的回调，随着大模型能力按照以上能力逐渐进化，我们可以看到，不论是个人还是企业端，它们普遍受益于大模型的时代并不遥远，AI已经重塑了整个软件生态，我们不知道AGI什么时候发生，但如果这都不叫革命，那什么才是呢？

二、关于RAGFlow

在RAGFlow开源达到万星的时候，我们撰文提出了RAG 2.0，指出要解决好RAG的问题，需要从数据抽取、数据预处理，以及检索和排序来端到端地解决这个搜索难题。

在这些步骤中，对最终对话影响最大的，就是第一个阶段数据抽取，因此，常常是一个好的数据入口，决定了后续Pipeline的最终输出质量。事实上，RAGFlow开源星标迅速增长的第一个原因，就是RAGFlow内置的组件DeepDoc，它能够对用户的非结构化文档进行布局检测，确保文字能够在保持语义的前提下再进行Text Chunking。进一步的，对于一些图表类数据，还借助于专用的表格结构识别模型来把表格提取出来，方便用户对表格进行问答。用一张图来示意，就是如下的流程。

DeepDoc诞生于2023年底，我们在面临复杂文档时，尝试了各种模型，包括当时的多模态文档大模型，专门用于表格解析的Table Transformer，乃至专门用于解析非结构化数据的Unstructured等等，在无法得到理想的结果后，我们不得不尝试来自己训练模型，结果发现，采用简单的卷积网络，将文档结构识别和表格结构识别都定义为一个目标检测问题，这样训练出来的模型效果居然超过了其他更为复杂的模型。

站在一年后的今天，随着技术的演进，我们的认知也发生了变化。DeepDoc，伴随着RAGFlow的开源，在面临更大量的用户场景时，泛化能力不佳的情况也越来越多，这促使我们也早早开启了更进一步的研究。在我们当前的实践中，基于 Encoder-Decoder 架构的Transformer网络，表现出了更胜一筹的准确度和泛化能力，它将成为未来企业级DeepDoc的标准配置。以上工作，在近期一篇很知名的工作OCR 2.0【参考文献2】也有相同的结论。在过去，我们一直试图解释DeepDoc并不是一个OCR模型，它的主要目标是文档布局，表格布局的检测与识别，而识别文字的OCR，DeepDoc一直都是调用开源的PaddleOCR，自己没有做任何相关工作。但在OCR 2.0的定义中，它把这一切都纳入了OCR框架，并且用一个Transformer网络解决所有问题，尽管在垂直场景下表现未必是SOTA，但这已经证明了一个统一的网络，如何把所有复杂文档数据都准确解析的技术价值。

数据预处理，在我们对RAG 2.0的定义中，主要就是指GraphRAG，它的核心目标，是解决在RAG中的一个典型痛点，就是问题和答案之间的语义鸿沟，根据问题无法搜索到答案所在的地方。微软在7月初开源了GraphRAG之后，在RAG社区引起了广泛关注，尽管GraphRAG的论文在年初就已经发表。事实上，利用知识图谱来改进RAG的对话效果，一直是个确定性的事情，但困难就在于这件事情的非标准化——大量的人工被用于校对知识图谱的准确性上。而GraphRAG的价值在于，它让知识图谱构建这件事变成自动化和标准化——它依赖于通过大模型来抽取文档中的命名实体和实体之间的关系。当然，这并不意味着，这种自动化构建的知识图谱，可以像人工构建的那样，在数据可视化上提供较大的参考意义，这是因为，没有校对的知识图谱，依然存在大量错误，包括实体重复，实体关系缺失，实体抽取错误等等，然而，即便这样，自动生成的知识图谱，再结合原文做混合搜索，确实可以相当程度上缓解语义鸿沟的问题。这符合我们通常在解决搜索系统的时候，遇到各种查询的bad case，需要引入查询意图一样。举例来说，我们输入查询“手机”，如何避免返回手机配件，这需要在查询的过程中，自动识别用户的意图是手机或者消费电子设备这样的分类。因此，查询意图，本质上就是对用户的查询来补充语义和Tag信息，而知识图谱，同样是给被搜索的文档数据，补充语义和Tag。这种自动化构建知识图谱的方式简单有效，因此RAGFlow在8月的版本，就迅速把GraphRAG 加到了项目中，并且会持续迭代。GraphRAG代表了利用大模型对数据做增强的一种标准手段，类似的方式和场景还有很多，例如RAGFlow早先加到系统的RAPTOR，它是先对文档做聚类，然后让大模型针对聚类生成摘要，这些信息连同原始文本共同做混合搜索，给出答案。从原理上来说，它一样可以起到弥补问题和答案之间语义鸿沟的用途。还有一些特定场景，需要根据用户的特定需要获取特定答案，这同样也依赖用大模型从原始文本抽取辅助内容，再利用这些内容辅助原始文本做混合搜索。在2023年大模型火热的时候，知乎上曾经有提问，有了大模型，是否NLP就已经消亡，从某种程度来讲，确实如此，因为但凡涉及到自动语义信息抽取和加工的任务，例如摘要生成，实体抽取，知识图谱，对话意图，等等，这些都需要依赖大模型来提供额外的素材，然后再伴随着原始数据一并做搜索召回。这就提出了一个新的挑战，就是Token消耗惊人，为了降低成本，这又引发了对小的各类微调后的较小的大语言模型的各种需求。针对特定行业的知识图谱或者命名实体抽取的小模型，可以极大降低Token消耗。因此，一个高精度的RAG系统，越来越离不开搜索和各种模型的交叉运用。

在我们对RAG 2.0的定义中，同样提到了我们专门为下一代RAG设计的AI原生数据库Infinity，它提供了功能最为强大，同时性能也是最高的混合搜索（多路召回）能力。来自社区的同学一直在关心一个问题，就是RAGFlow为什么只采用Elasticsearch，而没有采用其他向量数据库，同时也很关心Infinity到底什么时候可以被集成到RAGFlow当中。针对前一个问题，因为Elasticsearch是开源数据库当中，为数不多可以兼具全文搜索和向量搜索两路混合召回能力的数据库（具备类似能力的云数据库Rockset，刚刚被OpenAI收购不久）。对于RAG来说，全文搜索不是一个可选项，这一点在当下也开始逐渐成为共识。那么，RAGFlow为什么不一直采用Elasticsearch作为首选，而重新开发一款数据库呢？这主要包含多方面的考虑：

其一、Elasticsearch并不是专门为RAG设计的数据库，只是正好满足了企业级RAG的初步需求。一些特定的能力，并不好用。举例来说，RAGFlow对于全文搜索，分别采用了两种分词，然后做联合查询。为了支持这一点，数据不得不保存了三份：其一是原始数据，其二是采用策略一的分词，其三是采用策略二的分词。因为采用Elasticsearch，无法用两种分词对一个字段进行联合查询。这是很大的冗余；再比如：Elasticsearch的向量搜索能力，不够强大，不仅性能不足，而且内存占用高，向量定义受限（不支持各种向量类型，不支持单文档多向量等较为复杂的向量数据建模）；再例如：Elasticsearch只能提供一些标准和通用的分词和排序，例如RAGFlow并没有用Elasticsearh内置的分词，而是采用Python实现，这种方式固然灵活，但在算法固定后，很容易受到效率的挑战。这些组件，都应该根据实际应用的效果，把能力都下沉到数据库中；再例如：Elasticsearch是一款采用Java实现的基础组件，这跟以Python为主的AI社区，搭配非常不便。当前的Infinity，甚至已经提供了嵌入式的版本，开发者可以直接pip install安装Infinity，这对于各种端侧场景，非常必要。

其二、Infinity除了全文搜索和向量搜索，还包含了其他两类搜索方式，一种是稀疏向量，一种是张量。前者同样是针对RAG的一种有效搜索方式，后者的意义，可以看我们之前写的一篇文章【参考文献3】。简单总结一下，就是基于张量的重排序，不仅可以让数据库具备等同于重排序模型一样的能力，并且由于性能的大大提升，可以在更大的范围内做重排序，这大大提升了最终的召回效果，它的意义，甚至要大于前者。更加重要的是，只有引入张量，我们才能真正提供多模态RAG，这会在本文的第四部分会进一步谈及。

其三、Agent需要管理记忆体，记忆体保存的数据，包含对话历史，行为轨迹，文档数据，等等。记忆体数据是非常灵活多样的，它们既需要被搜索，也需要被管理（包括各种过滤分组点查询）。事实上，OpenAI收购Rockset的另一层考虑，除了混合搜索之外，还在于它schemaless的访问能力，这种能力对于高性能查询多样化的记忆数据非常有价值。Agent的记忆体还是个不断迭代的事物，我们需要让Infra随时跟进这种变化。

其四、来自知识图谱等的需求，它未必需要一个完整的图数据库能力，但却需要必备的图计算能力，例如子图检索和删除，这些能力是多样化的。我们同样需要让Infra随时跟进这种由文档数据预处理带来的各种变化。

其五、来自各种联合查询的需求。根据社区的反馈，RAGFlow已经把Text2SQL加了进来。也就是说，针对非结构化数据和结构化数据的联合访问需求，已经开始出现。诚然，当前Text2SQL是可以连接其他的关系型数据库，但当用户在一个知识库当中上传了大量数据，既包含PDF/Word，也包含Excel，他既需要对Excel做分析，还需要让Excel和其他文档一起提供对话能力，并且包含对Excel的计算结果。因此，一个知识库，可能会涉及到几百张表，每个Excel都是一张表，同时它还需要跟其他文档一起被搜索。这样的需求，想起来就挺复杂的，而且也同样来自社区用户的反馈。

在Infintiy的最新0.4版本中，基本已经实现了RAGFlow用到的Elasticsearch的那些能力，我们将很快把Infinity放到RAGFlow中，它将首先会作为备选方案存在，在经过一段时期后，会作为首选。因此，Infinity跟RAGFlow是共生的关系，它既能帮助RAGFlow解锁新的场景，又能根据RAGFlow开源遇到的新情况，把需要的能力下沉到数据库，解决效率和可用性的问题。

以上，我们谈论了RAG 2.0在RAGFlow的实现情况，也对RAGFlow下边的一些工作进行了总结。可以看到，RAG 2.0是一个非常复杂的平台，它是一个Infra和各种模型协同工作的平台。这里的模型，包含来自数据抽取的文档解析模型，也包含各种知识图谱、命名体抽取模型，还包含Embedding和排序模型，更包含未来的多模态模型。这些模型，有的来自我们自身，有的来自开源，有的需要微调，有的则是从零开始训练。如何让这样的复杂系统协同工作，这需要一个标准化的平台，这越来越离不开核心引擎的持续建设，这也正是我们开源开放RAGFlow并持续迭代的根本原因。因此，RAGFlow并不是依靠某个独门秘籍来吸引社区，而是依靠正确的架构和演进方向，最终把这样的RAG系统变成一个普适性的平台。

三、关于Agent

RAGFlow在7月的时候推出了Agent功能。自从大模型火热以来，软件生态层面，Agent的概念比RAG更普及，与此同时，还有各种流行的LLMOps软件提供了工作流功能，它们也同时得到了大量用户的喜好，那么这些概念，究竟有什么区别和联系呢？

工作流并不是一个新概念，它的历史跟企业信息系统几乎一样长。而工作流跟大模型的结合，引发了对企业软件生态层面的重塑。工作流，本质上可以看作是以指令驱动数据流的系统，例如在大数据平台中，工作流可以体现为ETL数据管道；在RPA平台中，工作流可以体现为各种数据抓取和数据规则填充的配置和定义平台；在各类无代码和低代码平台中，工作流体现为对于各业务场景规则的定义和Knowhow。当结合大模型之后，工作流可以解锁的场景就很多了，因为它解决的是保证数据和指令以可控的方式流动的问题，而大模型则不仅可以参与到指令和数据的流动过程，还可以作为指令的发起者，因此这让工作流可以以更加自动化和智能化的方式来执行。举例来说，定义一个工作流，让大模型以可控的方式，按照模板来生成固定格式的企业文档；定义一个工作流，让大模型按照业务事先定义的场景，来引导用户提问的范围；定义一个工作流，让大模型根据内容来判断，是否符合要求从而触发下一步的行为；定义一个工作流，让从信息系统获取到的销售线索，以符合业务定义的方式触发外呼系统并管理外呼内容；等等，由于大模型可以像人一样产生各种判断，因此它赋予了工作流定义以生命。

RAG跟工作流的关系在于，它是工作流环节的一环，大多数工作流，都会需要RAG参与其中。在这个过程中，大模型的角色，除了RAG必备的内容生成，还有一个关键环节——作为决策的发起者。例如工作流中的意图判断，或者更简单来定义，就是分类器。通过让大模型来判断提问，或者生成的内容的分类，来决定下一步的数据和指令如何流转。这在问答，客服，外呼，文案生成，合规检查，等等场景都是必不可少的环节。

Agent从开始被提出，更多被赋予自主决策的角色。所以它常常伴随这些字眼：记忆管理——代表Agent交互过程的上下文信息。过去的数月里，一个相对轻量级的项目【参考文献4】，只是定义了这些记忆管理的API，或者说就是如何来存放对话上下文信息的接口，就获得大量关注，因此，Agent天然就是自带流量和关注的；决策和Reasoning能力——代表Agent和大模型之间，Agent和Agent之间，采用什么策略让提问更加有目标，驱动大模型给出最终答案。这个角度来看，Agent跟它的定义起源——强化学习有着密不可分的联系。吴恩达给出了四种 Agent 模式：分别是反思、工具、规划、以及多 Agent 协同。反思可以跟RAG产生联系，例如通过反思机制，让大模型来判断RAG搜索的质量，并改写查询进一步搜索，最终提升RAG答案生成的质量。工具和规划则跟工作流有着密切的联系，我们甚至可以说，工作流就是Agent的一部分，因此在RAGFlow当中，我们把Agent和工作流看做一回事，当然这并不影响在其他产品中把两者分开定义。 至于多Agent，通常用于角色扮演，这在行业应用中还处于较早期阶段，OpenAI近期开源用于实验性的swarm【参考文献5】，就是个多Agent框架。

在当前的AI应用生态中，场景最多的，都是工作流类应用。而带有记忆管理，和辅助决策的Agent，会在医疗、金融、法律、游戏、推荐系统等领域有深入应用。因此，把记忆管理纳入RAGFlow，也是接下来的工作。站在RAGFlow的视角，在Agent这件事情上，RAGFlow的定位从来都很清晰，RAG作为一个核心技术组件，它要解决的问题是RAGFlow的核心。如何使用RAG，这就是Agent层面的事情，可以把RAGFlow当作一个App Store那样来使用这个市场里的各种App（Agent），也可以采用外部的Agent/工作流工具来编排RAGFlow，这一切取决于用户自己的方便程度。

四、关于多模态

多模态的定义其实并没有统一标准。当前的一些大模型，已经普遍具有了一些多模态能力，例如给定图片，它们可以产生对应的文字描述信息，因此，利用这些描述信息建立文本索引，就可以实现一种简易的多模态RAG，这在当下的RAGFlow就已经提供。

更广义来看，RAGFlow的DeepDoc组件，它本质上就是来解决多模态数据的一种通用范式，因为企业内的非结构化文档，如下图所示，本质上就是一大类多模态文档，如何解锁这些内容的商业价值，本身就是RAG的一大类应用场景。

所以，采用深度文档理解模型，或者说广义意义上的OCR 2.0，将这些文档变成不损失语义信息的文字，是应对这样的多模态文档的一种标准解决方案。

另一种方案，是直接借助于VLM（Vision Language Models）视觉语言模型。今年大模型的进展，在VLM上尤其突出，参见下图，VLM的能力，已经从早期的以图搜图，进展到了理解图片本身的语义信息。

以Google开源的PaliGemma【参考文献6】为例，我们可以看到，它已经可以对文档内的图片，进行深度解读，这只是一个3B的VLM模型，就可以做到如此效果：

而在近期公开的ColPali【参考文献7】，则是把PaliGemma用于多模态RAG的里程碑工作，借助于Tensor和延迟交互模型，解锁下边的场景，已经不是未来，而是当下——把来自企业的各种多模态PDF，采用ColPali或者其他延迟交互模型，生成Tensor，然后用Infinity数据库基于这些Tensor做召回，得到的结果交给具备VLM能力的大模型，就可以得到内容包含在多模态数据内的答案。

这条路线，跟RAGFlow当前的DeepDoc，有什么关系呢？可以参见下图：

我们可以采用传统的目标检测，来把多模态文档转成文字，也可以采用广义的OCR 2.0，这种基于Encoder-Decoder架构的Transformer网络，来更好的把多模态文档转成文字。而基于VLM的多模态RAG，它们只是用这种类似的架构，没有Decode生成文本的步骤，而是直接生成图像（Patch）的Embedding和Tensor。从技术上来说，这两种并无绝对的优劣之分，但在一定周期内，都存在各自表现更好的场景。而RAGFlow，则会同时支持这两种使用场景——这也是为何我们需要尽快把Infinity集成到RAGFlow的源动力之一，挖掘企业内部海量非结构化文档的商业价值，从现在起，已经不是未来，而是当下。

2024年在开年的时候曾被称作是大模型落地和RAG的元年。站在接近年底的时候回顾2024，不论是技术论坛的火热程度，还是各种媒体技术文章，都印证了这一点。RAG技术，在争议不断中持续进步，它始终都是大模型落地的标准架构。在当下，几乎所有人都已经认识到了RAG想要满足业务需求，是多么不容易做到，它不得不依赖各种定制（技术定制而非业务定制），按下葫芦浮起瓢，在特定的场景首先用起来。而RAGFlow始终在坚持走标准化建设的路线，走Infra和模型紧密交互的路线，坚持开源，而社区也用2万星标体现了这样的坚持。来自社区的反馈，不论是技术还是场景，都构成RAGFlow前进的动力。我们看到，大量的用户对于RAG，都已经从观望走向实践，不论是大型企业，还是中小用户，甚至政府部门，用户对于RAG的熟悉和认知让我们惊讶，对于场景的理解和应用边界的拓展，都大大超出了我们在7个月前开源时所认知的范围。2万星标，对于RAGFlow来说，只是迈出的一小步，大量需要改进和完善的特性都排成了长队，未来的迭代，从以上文字中，也可以看到我们的后续规划。欢迎大家持续关注RAGFlow：https://github.com/infiniflow/ragflow

参考文献

1. https://www.jiqizhixin.com/articles/2024-07-08-5

2. General ocr theory: Towards ocr-2.0 via a unified end-to-end model. https://arxiv.org/abs/2409.01704

3. https://www.jiqizhixin.com/articles/2024-08-05-2

4. https://github.com/mem0ai/mem0

5. https://github.com/openai/swarm

6. https://github.com/google-research/big_vision/tree/main/big_vision/configs/proj/paligemma

7. ColPali: Efficient Document Retrieval with Vision Language Models. https://arxiv.org/abs/2407.01449