RAGFlow自2024年4月1日正式开源,时至今日,不到7个月时间已经站在了Github 2万星标的台阶之上。在6月底Github 1万星标的时候,我们曾经写了一篇文章,提出RAG 2.0的口号(参考文献1),论述了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开源达到万星的时候,我们撰文提出了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系统变成一个普适性的平台。
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
文章来自于“InfiniFlow”,作者“InfiniFlow”。
【开源免费】n8n是一个可以自定义工作流的AI项目,它提供了200个工作节点来帮助用户实现工作流的编排。
项目地址:https://github.com/n8n-io/n8n
在线使用:https://n8n.io/(付费)
【开源免费】DB-GPT是一个AI原生数据应用开发框架,它提供开发多模型管理(SMMF)、Text2SQL效果优化、RAG框架以及优化、Multi-Agents框架协作、AWEL(智能体工作流编排)等多种技术能力,让围绕数据库构建大模型应用更简单、更方便。
项目地址:https://github.com/eosphoros-ai/DB-GPT?tab=readme-ov-file
【开源免费】VectorVein是一个不需要任何编程基础,任何人都能用的AI工作流编辑工具。你可以将复杂的工作分解成多个步骤,并通过VectorVein固定并让AI依次完成。VectorVein是字节coze的平替产品。
项目地址:https://github.com/AndersonBY/vector-vein?tab=readme-ov-file
在线使用:https://vectorvein.ai/(付费)
【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。
项目地址:https://github.com/Significant-Gravitas/AutoGPT
【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。
项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md
【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。
项目地址:https://github.com/labring/FastGPT
【开源免费】graphrag是微软推出的RAG项目,与传统的通过 RAG 方法使用向量相似性作为搜索技术不同,GraphRAG是使用知识图谱在推理复杂信息时大幅提高问答性能。
项目地址:https://github.com/microsoft/graphrag
【开源免费】Dify是最早一批实现RAG,Agent,模型管理等一站式AI开发的工具平台,并且项目方一直持续维护。其中在任务编排方面相对领先对手,可以帮助研发实现像字节扣子那样的功能。
项目地址:https://github.com/langgenius/dify
【开源免费】RAGFlow是和Dify类似的开源项目,该项目在大文件解析方面做的更出色,拓展编排方面相对弱一些。
项目地址:https://github.com/infiniflow/ragflow/tree/main
【开源免费】phidata是一个可以实现将数据转化成向量存储,并通过AI实现RAG功能的项目
项目地址:https://github.com/phidatahq/phidata
【开源免费】TaskingAI 是一个提供RAG,Agent,大模型管理等AI项目开发的工具平台,比LangChain更强大的中间件AI平台工具。
项目地址:https://github.com/TaskingAI/TaskingAI
【开源免费】XTuner 是一个高效、灵活、全能的轻量化大模型微调工具库。它帮助开发者提供一个简单易用的平台,可以对大语言模型(LLM)和多模态图文模型(VLM)进行预训练和轻量级微调。XTuner 支持多种微调算法,如 QLoRA、LoRA 和全量参数微调。
项目地址:https://github.com/InternLM/xtuner