ChatGPT 人工智能 GPT4 伦理 生成式 医疗 监管 安全 机器学习 深度学习 神经网络 计算机视觉 强化学习 模型 算法 应用 开发 研究 工具 平台 框架 数据集 训练 部署 安全 合规 培训 投资 LLM,llm AI,ai,Ai 大模型 大语言模型 制图 生图 绘图 文生图 文生视频 生成式AI AGI 世界模型 sora chatGPT,chatgpt,ChatGpt claude openai Llama deepseek midjourney 红熊猫模型 Red panda,panda Stable Diffusion,StableDiffusion,stable DALL- E 3 DALL E DALL Flux,flux 扩散模型 混元大模型 文心一言 通义千问 可灵 Pika PixelDance 豆包 月之暗面 零一万物 阶跃星辰 搜索增强 MiniMax Talkie Agent prompt fastai LangChain TTS 微调 提示词 知识库 智能体
# 热门搜索 #
搜索
写在RAGFlow开源2万星标之际
9270点击    2024-10-21 17:52

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


文章来自于“InfiniFlow”,作者“InfiniFlow”。


关键词: RAG , AI , RAGFlow , 搜索增强
AITNT资源拓展
根据文章内容,系统为您匹配了更有价值的资源信息。内容由AI生成,仅供参考
1
AI工作流

【开源免费】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/(付费)

2
智能体

【开源免费】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

3
知识库

【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。

项目地址:https://github.com/labring/FastGPT

4
RAG

【开源免费】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

5
微调

【开源免费】XTuner 是一个高效、灵活、全能的轻量化大模型微调工具库。它帮助开发者提供一个简单易用的平台,可以对大语言模型(LLM)和多模态图文模型(VLM)进行预训练和轻量级微调。XTuner 支持多种微调算法,如 QLoRA、LoRA 和全量参数微调。

项目地址:https://github.com/InternLM/xtuner