由近期 RAGFlow 的火爆看 RAG 的现状与未来

4 月 1 日，InfiniFlow （英飞流）的端到端RAG解决方案 RAGFlow 正式开源，首日即获得了 github 千星，目前已接近 3000 star。在这之前，InfiniFlow 还开源了专门用于 RAG 场景的 AI 原生数据库 Infinity，一个是 AI Infra基础组件，一个是端到端应用，在回答 InfiniFlow 为什么要连续开源这样两款产品之前， 先来总结一下这两款产品应用的主要场景 RAG （基于检索增强的内容生成）、现状以及未来。

RAG 技术从提出到成为共识，经历了不短也不长的时间。它最早浮出水面，是在 2023 年 3 月的英伟达 GTC 大会上，老黄当众点名了向量数据库，紧接着 OpenAI 自身也发布了信息检索插件解锁了让大模型访问私有数据的能力，由此，让向量数据库作为大模型的外挂记忆体存在，提供外挂知识库的产品功能，成为 RAG 最早为大众所知的使用姿势，就是下边这张图展现的应用架构：

在很长一段时间内，RAG 在行业的代名词都叫知识库，上述的应用架构，不仅带火了向量数据库，也带火了以LangChain，LlamaIndex 为代表的中间件，它们负责处理上图中各个箭头背后的工作流。具体包括：

1、把用户的文档进行切分，然后再调用一个 Embedding 模型把切分好的文档生成为向量。

2、把生成好的向量连同原始文档写入到向量数据库中。

3、查询时，将用户的提问也根据相同的 Embedding 模型生成向量，然后查询向量数据库返回 Top K 结果。

4、把 Top K 结果对应的文本拼成提示词交由大模型做最终的摘要和内容完成。

因此，整个架构图里核心部分是两个：

1、向量数据库：负责基于向量对用户的文档进行查询召回。

2、中间件：负责对文档的切分，并转成适合的向量。

采用向量这种形式是因为向量可以提供语义召回，用户只要提问，最终能按照相似度高低返回最接近的答案而无需考虑问题是否真的有哪些关键词匹配到了文档。即使没有匹配，也依然可以根据语义相似度返回答案。之所以需要对用户文档进行切分，是因为向量表征的语义比较含糊，不仅一篇文章可以表征为一个向量，一个单词也可以表征为一个向量，这就导致文字块跟向量对应的粒度很难控制：粒度过粗，用一条向量对应一大段话，对这些文字的细节很难表征；粒度过细，那么一大段文字会对应一堆向量，而每个向量又仅仅代表几个词的语义，因此无法简单根据相似度来找到符合语义的向量。因此，需要对文档进行“恰当”的切分，这就是 LangChain，LlamaIndex 等中间件的核心工作。

那么，如何定义“恰当”呢？通常会采取一些简单的策略：例如先根据文字间的空白将文档切分成不同的段落，这些段落表征的粒度相对比较适合。随后通常会把一些标题（通常需要根据一些规则来判断）跟这些段落合并，让这些只包含局部文字的段落也能体现整篇文章或者部分章节的语义。

因此，有了这类组件就可以快速搭建一套 RAG 系统。不过，自从这种应用架构从 23 年 4 月开始流行，就一直面临一个争论：“把用户的数据微调进大模型直接回答问题更好，而无需 RAG 这一整套基于检索的架构”。这类争论伴随了整个 2023 年。直到今天，这类争论的声音才渐渐淡去。因为，很显然，无论是实时性还是成本等方面， 采用 RAG 是碾压对 LLM 进行微调的方案的。支持微调的拥护者所最看重的问答质量，但更多评测发现，两者差距并不大，而逐渐得出了两者需要搭配使用的结论。并且，这种所谓搭配使用的方案，随着开源 LLM 不断快速迭代推陈出新，也导致实际真正采用微调的已寥寥无几。

上述这种 RAG 架构，也被一些 LLM 厂商所采纳，典型代表是 2023 年 11 月初 OpenAI 推出的 GPT4 Turbo，根据一些出错的日志截图，可以看出 OpenAI 正是可能采用了以向量数据库 qdrant 为基础搭建的 RAG 架构，从而提供了让用户自行上传文档并进行问答的个人知识库服务。

今年 2 月以来， AI 领域连续出了很多重磅热点，除了最火热的 Sora 之外，另一个热点就是长上下文 LLM ，例如 Claude 3、 Gemini 1.5，当然也包含国产的月之暗面。Sora 的本质是针对视频提供更加可控的生成能力，这其实是解锁未来多模态 RAG 热潮的一个必要条件；而长上下文 LLM ，却引发了更多针对 RAG 的争论，因为这些 LLM 可以支持用户随时上传 PDF，甚至上传几十个 PDF，然后针对这些 PDF 提供问答，同时还具备强大的“大海捞针”能力。所谓“大海捞针”测试，就是针对长上下文窗口内的细节进行提问，看 LLM 是否可以准确地回答。

用 RAG 来实现大海捞针是轻而易举的，然而上边列举的这些 LLM，它们不是基于 RAG 来提供这种能力，却也都可以达到很高的召回。长上下文技术在2023年底就已经有很多了，代表工作是 StreamLLM，其本质是滑动窗口，只保留对最近上下文的注意力，窗口滑过，内容即会被逐渐“遗忘”，因此“大海捞针”测试表现不佳。而今年的这些新出现的长上下文 LLM，却彻底解决了这个问题，其中的若干产品，效果确实非常好，上传一个 PDF，甚至可以针对里边的复杂图表给出精确的回答。因此，这引发了新的一轮关于长上下文 LLM 和 RAG 的争论，许多人评价 “RAG 已死”，而 RAG 拥护者则认为，长上下文 LLM 并不能满足用户海量数据的需求，成本高，速度也不够快，也只能针对长文本、图片等数据提问。

随着长上下文 LLM 为更多用户接纳，近期各家国产 LLM 都快速推出了这个产品特性，除月之暗面外，其他家大多基于 RAG 来实现，下表是两者的基本对比：

这里要额外说明一下为何 RAG 派的大海捞针能力一般，这并不是 RAG 本身的问题，而是依靠纯向量数据库去构建 RAG，并不能保证对精确数据和细节的准确召回。以上的对比，其实并没有完全解答 RAG 的必要性，因为至少就目前 RAG 最普遍的场景——个人知识库问答而言，确实很多情况下只需要 LLM 就足够了。至于成本性能等因素，这些问题是会随着时间推演，逐渐得到缓解的。

因此，RAG 的未来，似乎并不是那么乐观。而 InfiniFlow 则认为，LLM 的长上下文能力，对于 RAG 来说是很大的促进。这里先用 OpenAI 联创Andrej Karpathy的一张图做个类比，他把 LLM 比喻为一台计算机的 CPU， 把上下文类比为计算机的内存，那么以向量为代表的数据库，就可以看作是这台计算机的硬盘。

下边进一步来说明，为什么即使有了“大海捞针”能力，RAG 仍然必不可少。RAG 从提出到为业界广泛接纳，经历了一年多时间，当下的 RAG 产品已经并不稀缺，然而在实际应用中，却普遍得出了“ RAG 属于上手容易，但真正落地却很难”的结论。究其原因，这里边主要包含两个方面：

其一是来自 LLM 自身。由于 RAG 的工作流程是针对从数据库返回的结果进行回答，这样的话，对于 RAG 来说，LLM 最基础也是最重要的能力其实包含：

1、摘要能力；

2、可控性：即 LLM 是否听话，是否会不按照提示要求的内容自由发挥产生幻觉；

3、翻译能力：这对于跨语言 RAG 是必备的。

遗憾的是，在过去，国内可以用到的 LLM 中，在这三点上表现良好的并不多。至于所谓高级的能力，例如逻辑推理，以及各类 Agent 要求的自主决策能力等，都建构在以上基础能力之上。基础不好，这些也都是空中楼阁。

其二，则是来自于 RAG 系统本身。在前文中已经可以看到：RAG 系统是一条完整的链路，包括数据准备，数据写入，乃至从数据库查询和返回结果排序。在整条链路中，最大的难点来自于两个方面：一是如何应对复杂多变的数据，这些数据包含各种格式，更复杂的还包含各类图表等，如果在没有理解这些语义的基础之上直接提供 RAG 方案，例如简单的根据文字空白就来切分段落，就会导致语义丢失从而让最终查询的结果也是混乱不堪。二是如何查询和排序。当下的主流 RAG 都是采用向量数据库作为支撑，然而在 InfiniFlow 多次实际的应用中已经看到了单纯依靠向量数据库很难满足 RAG 要求。原因就在于，当下的 RAG 大都是服务面向个人的知识库这样的简单场景的，这些场景的用户数据，基本都是文档，那么个人用户对于文档的提问，大体上都是围绕着摘要来做的，有个看上去差不多的答案就可以了。然而在面向企业端的时候，简单依赖向量的 RAG 就显得力不从心，这是由向量的本质决定的：向量只能表征语义而无法对精确信息召回，更甚者，只有向量是无法跟企业内部的信息系统集成的。举几个典型场景：把符合要求的简历筛出，筛选条件包含工作技能（需要向量 + 全文搜索），某类行业的工作经验（基于向量的分组聚合），期望收入，学历，地域（结构化数据）等；基于对话推荐符合个人要求的产品，可以采用多列向量来描述个人偏好，不同的列代表了用户对不同类目产品的过往使用偏好。在推荐过程中，除了采用基于用户的偏好向量进行搜索之外，还需要结合产品的过滤条件：包括是否过期，是否有优惠券，是否符合权限要求，是否有合规要求，该用户是否近期已经购买或者阅读过，等等。简单地讲，在大多数情况下，都必须引入多路召回和重排序，才能保证数据查询的准确度。

假如不去专注于解决这两类问题，那么就很容易陷入让 RAG 去和长上下文 LLM 反复对比的情况：RAG 仅仅提供数据的简单解析，然后直接转化为向量，最后用单一向量做召回，这除了成本，以及私有化场景里所要求的安全等优势之外，在核心对话能力上并没有显著地跟长上下文 LLM 区分开来，甚至还有所不及。

正是基于这些 RAG 本身的痛点，InfiniFlow 先后推出了两个开源项目，旨在解锁 RAG 面向各类场景的服务能力，在当下长上下文 LLM 能力越来越强的前提下，如果把 RAG 自身的痛点也解决掉，那么就可以让更多企业都真正把 LLM 用起来，而不是总是停留在浅层的知识库对话。

第一个是 AI 原生数据库 Infinity。它解决的是如何解锁 RAG 面临 B 端场景的复杂查询：如何跟企业已有的数据——包括但不限于非结构化的文档、图片，还包括结构化的信息系统来结合，并解决多路召回和最终融合排序的问题。

如下图所示的基于 RAG 的推荐系统，企业内部已有数据包含用户表，日志表，产品描述表等等，这些数据都可以进入 Infinity，但并不是 1:1 同步，而是增加了若干向量列。这些企业数据，如果仅用向量数据库来建模，是无法表征的：向量数据库只包含一些用于过滤的“标量”字段，而这个系统需要的查询，是多向量，多表 + 全文搜索的复杂查询，采用向量数据库，那么产品的开发是极其复杂的：因为这需要引入额外的 ETL，从而产生一些“标量”过滤字段，这带来了维护性，以及更严重的数据一致性的问题。RAG 面临的是最终用户的使用场景，它是需要业务乃至 LLM 发起请求，就立刻得到答案的，因此不能像数据中台一样仅仅为了一张报表就可以搭建一整套数据管道体系去做宽表这种额外逻辑。因此，Infinity 实际上等于向量数据库 + 搜索引擎 + 普通结构化数据查询，并保证三者的高并发和融合排序。

第二个就是端到端的 RAG 引擎 RAGFlow。它解决数据的问题：因为如果不对用户数据加以区分和清洗，识别其中的语义，就容易导致 Garbage In Garbage Out。RAGFlow 包含了如下的完整 RAG 流程，确保数据从 Garbage In Garbage Out 变为 Quality In Quality Out。

具体来说， RAGFlow 的最大特色，就是多样化的文档智能处理，因此它没有采用现成的 RAG 中间件，而是完全重新研发了一套智能文档理解系统，并以此为依托构建 RAG 任务编排体系。这个系统的特点包含：

1、它是一套基于 AI 模型的智能文档处理系统：对于用户上传的文档，它需要自动识别文档的布局，包括标题、段落、换行等，还包含难度很大的图片和表格。对于表格来说，不仅仅要识别出文档中存在表格，还会针对表格的布局做进一步识别，包括内部每一个单元格，多行文字是否需要合并成一个单元格等。并且表格的内容还会结合表头信息处理，确保以合适的形式送到数据库，从而完成 RAG 针对这些细节数字的“大海捞针”。

2、它是一套包含各种不同模板的智能文档处理系统：不同行业不同岗位所用到的文档不同，行文格式不同，对文档查阅的需求也不同。比如：

a. 会计一般最常接触到的凭证、发票、Excel 报表；查询的一般都是数字，如：看一下上月十五号发生哪些凭证，总额多少？上季度资产负债表里面净资产总额多少？合同台账中下个月有哪些应付应收？

b. 作为一个 HR 平时接触最庞杂的便是候选人简历，且查询最多的是列表查询，如：人才库中 985/211 的三到五年的算法工程师有哪些？985 硕士以上学历的人员有哪些？赵玉田的微信号多少？香秀哪个学校的来着？

c. 作为科研工作者接触到最多的可能是就是论文了，快速阅读和理解论文，梳理论文和引文之间的关系成了他们的痛点。

这样看来凭证/报表、简历、论文的文档结构是不一样的，查询需求也是不一样的，那处理方式肯定是不一样。因此 RAGFlow 在处理文档时，给了不少的选择：Q&A、Resume、Paper、Manual、Table、Book、Law、通用等等。当然，这些分类还在不断继续扩展中，处理过程还有待完善。他们也会抽象出更多共通的东西，使各种定制化的处理更加容易。

3、智能文档处理的可视化和可解释性：用户上传的文档到底被处理成啥样了，如：分割了多少片，各种图表处理成啥样了，毕竟任何基于 AI 的系统只能保证大概率正确，作为系统有必要给出这样的空间让用户进行适当的干预，作为用户也有把控的需求，黑箱不敌白箱。特别是对于 PDF，行文多种多样，变化多端，而且广泛流行于各行各业，对于它的把控尤为重要，RAGFlow 不仅给出了处理结果，而且可以让用户查看文档解析结果并一次点击定位到原文，对比和原文的差异，可增可减可改可查，如下图所示：

4、RAGFlow 是一个完整的 RAG 系统，而目前开源的 RAG，大都忽视了 RAG 本身的最大优势之一：可以让 LLM 以可控的方式回答问题，或者换种说法：有理有据、消除幻觉。大家都知道，随着模型能力的不同，LLM 多少都会有概率会出现幻觉，在这种情况下， 一款 RAG 产品应该随时随地给用户以参考，让用户随时查看 LLM 是基于哪些原文来生成答案的，这需要同时生成原文的引用链接，并允许用户的鼠标 hover 上去即可调出原文的内容，甚至包含图表。如果还不能确定，再点一下便能定位到原文，如下图所示：

接下来讲讲，RAGFlow 具体是如何利用文档结构识别模型来处理数据的。所谓文档结构模型，如下所示，是针对文档的布局进行目标识别，然后根据布局再做文字切分。这些布局识别的目标包括文档的标题，段落，语义文字块等等，尤其还会包含文档当中的图表。

在识别出这些目标之后，还需要分别对这些目标做相应处理：对于文字来说，需要首先判断文字的换行信息——这对于文字的语义理解也会产生干扰；其次需要对文字内容进行一些整理，这些整理会随着 RAGFlow 模板的不同有所区分；针对表格来说，还需要进一步识别它的内部结构，这在 AI 领域有个专门的研究课题，叫做 TSR(Table Structure Recognition 表格结构识别) 。

TSR 任务其实相对比较复杂，因为表格的定义是多种多样的，表格内部可能会出现有线条或者没有线条的情况，对于不同行的文字，判断它们是否是一个单元格是存在很大挑战的，单元格判断失误，很可能就会让表格的数字跟表格列的对应关系弄错，从而影响了对单元格内文字和数字语义的理解。因此他们花了很多时间来提升 TSR 的能力，最早是利用现成的 OCR 开源模型，后边也尝试过微软研究院专门针对 TSR 任务的 Transformer 模型，但是发觉这些模型处理 TSR 任务的鲁棒性依然非常不足，最后他们还是训练了自己的模型，从而让 TSR 任务表现良好。这个模型比较简单，就是基于 CNN 的目标检测模型，但是它的效果却比上边提到的其他模型都要好。为了降低对硬件的依赖和开销，甚至切换到用 YOLOv8 来做目标检测，使得仅仅利用 CPU 也可以运行文档结构识别。

关于这些，其实也有很多业内人士建议直接走 LLM 的路子，用 LLM 来做文档语义理解，从长期来看这肯定是个趋势，然而在当下来说，让 LLM 在文档结构识别上表现良好，还需要大量的数据才可以。这从他们放弃了基于 Transformer 的 TSR 模型就可以看出：同样的任务下，基于 Transformer 的模型需要更多的数据才可以表现更好，在有限数据下，不得不退回到传统 CNN 模型，如果是 LLM ，它需要的数据和算力更多——他们之前曾经尝试过基于多模态 LLM 进行识别的努力，相比专用小模型，

它的效果还是差别比较大。

解锁对于非结构化数据的深度语义理解是 RAGFlow 追求的目标之一，InfiniFlow 希望在未来能够将更加 scalable 的文档结构识别模型应用到系统中。不仅如此， RAGFlow 的设计目标是让 RAG 逐渐承接起更多的复杂场景尤其是 B 端场景，因此在未来，它会接入企业的各类数据源，比如 MySQL 的 binlog，数据湖的 ETL，乃至外部的爬虫等。只有这些都被纳入 RAG 的范畴，他们才能实现如下的愿景：

再回过来看 RAG 的未来以及 RAG 跟长上下文 LLM 之争，这种争论其实没有必要，显然两者一定是合作的。长上下文 LLM 当下已经逐步具备了 RAG 最不可或缺的基础能力，随着它自身逻辑推理能力地增强，再结合来自数据库，还有数据方面的改进，一定能加速 LLM 的 B 端场景走出婴儿期的进程。

RAGFlow 近期更新：将提供类似文件管理的功能，这样 RAG 可以跟企业内部文档以更灵活的方式整合。RAGFlow 中期更新，将提供面向企业级数据接入的低代码平台，同时提供问答对话之外的高级内容生成，比如长文生成等等。

Infinity 近期更新：Infinity 将于近期发布第一个正式版本，届时将提供业界最快的多路召回与融合排序能力。

欢迎大家关注他们的开源社区，并提出反馈意见！

项目开源地址：

Infinity : https://github.com/infiniflow/infinity

RAGFlow：https://github.com/infiniflow/ragflow

RAGFlow 在线Demo：https://demo.ragflow.io/