前面我们介绍过很多的关于大模型和RAG相关的技术《RAGFlow：基于OCR和文档解析的下一代 RAG 引擎》，通过其关注程度足以看到市场上对RAG框架和成熟产品的迫切需求，因为想要个人独立从0开始实现一个RAG产品并非易事，虽然有相当多的RAG或者知识库开源产品，大部分其实很难应用于实际生产环境，很多都只能算是一个简单的演示 demo 的基本实现，并没有针对不同行业不同场景实际的需求进行覆盖和完善，光一个文档深度学习和内容解析，在面对各种复杂的文档格式，有些不规则的文档内容、以及一些包括复杂表格和图片的文档，如何有效的将其内容完整的提取出来输入给大模型本身就存在非常多的困难和挑战需要突破，就算使用目前通用的 GPT-4o 和 Gemini Pro 等超大模型，其效果和准确率也是有限的。

然而，现有的 RAG 系统，即 RAG 1.0，大多依赖简单的语义相似度搜索，在处理海量、复杂的企业级数据时，面临着效率和准确性的双重挑战，同时还存在检索召回率低、缺乏精确检索能力。这导致了所谓的“垃圾输入，垃圾输出”（GIGO）问题：如果输入数据质量不高，即使 LLM 能力再强，生成的答案也难以令人满意，也就是我们上面讲到的高质量文档数据输入问题。

正是在这种完全依赖大模型解决GPU算力成本还太高且又有很多迫切需求的背景下，开源界传来了好消息，RAGFlow 应运而生，它致力于打造一个以搜索为中心的端到端优化系统，从根本上解决 RAG 1.0 的局限性。RAGFlow 的设计理念是“高质量输入，高质量输出”，它通过深度文档理解技术，智能识别文档结构和内容，确保数据的高质量输入，为 LLM 提供更精准、更可靠的答案。

2024 年 4 月 1 日，RAGFlow 正式开源，这一消息在技术界引起轰动。开源不到一周时间，RAGFlow 在 GitHub 上就已收获 2900 颗星，而不到 4 个月的时间，这一数字已飙升至 13600，足以说明其受欢迎程度。虽然很多小伙伴在实际体验了 RAGFlow 产品之后反馈目前的版本还是存在非常多的 bug 未修复，相信按 RAGFlow 现在的发展和迭代速度，估计迭代俩版本就能稳定下来了，让我们拭目以待。

RAGFlow v0.9 版本于两天前正式发布，从发布日志中可以看到令人期待的新功能和体验升级。该版本不仅标志着 RAG 系统迈向知识图谱增强的RAG 2.0 时代，还针对之前版本用户的反馈，修复了大量bug，进一步提升了稳定性和易用性。

此次更新的一大亮点是对 GraphRAG 的正式支持，为 RAG 系统注入知识图谱的强大能力，显著提升了答案的精准度和可解释性。此外，v0.9 版本还新增了关键词提取、百度/DuckDuckGo/PubMed/Wikipedia/Bing/Google 搜索等 Agent 运算符，扩展了信息检索渠道。用户现在还可以使用 ASR 语音转文本功能，方便地输入音频文件。

为了满足用户多样化的需求，RAGFlow v0.9 兼容了 Gemini、Groq 等更多 LLMs，并集成了 xinference reranker，进一步提升答案质量。同时，该版本还增加了对 LM Studio/OpenRouter/LocalAI/Nvidia API 等推理框架/引擎/服务的支持，为用户构建和部署 RAG 系统提供更多便利。

早期的 RAG 系统，即 RAG 1.0，主要依赖于语义相似度搜索技术。其工作原理是将文档分割成数据块，并利用嵌入模型将其转换为向量表示，存储在向量数据库中。当用户提出问题时，系统会将问题转换为向量，并在数据库中搜索语义最相似的文档块，将其作为 LLM 的参考信息。

1. 召回率低： RAG 1.0 通常采用简单的文档分块策略，忽略了文档内部细粒度的语义结构，导致许多包含关键信息的文档块无法被检索到，从而降低了答案的召回率，很多开源知识库项目基本上就是采用的这种方案。
2. 缺乏精确检索能力： 语义相似度搜索只能找到与查询内容“大致相关”的信息，而无法满足用户对时间、主题、实体等方面的精确检索需求，尤其是在处理一些需要精确匹配的专业问题时，RAG 1.0 往往难以胜任。
3. 过度依赖嵌入模型： RAG 1.0 的检索效果与嵌入模型的选择密切相关，而通用嵌入模型在特定领域的性能往往难以令人满意，这限制了 RAG 系统在专业领域的应用。
4. 忽略文档结构： RAG 1.0 简单的文档分块方法忽略了文档本身的结构信息，例如章节标题、表格数据、图片注释等，这些信息对于理解文档内容、提取关键信息至关重要，而 RAG 1.0 的处理方式无疑会导致信息丢失，影响答案质量。
5. 缺乏用户意图识别： 用户的问题表述往往与其真实意图存在差异，而 RAG 1.0 缺乏对用户意图的深度理解，只能进行简单的关键词匹配，导致检索结果与用户预期存在偏差。
6. 无法处理复杂查询： 现实场景中的许多问题都需要进行多轮推理才能得到答案，而 RAG 1.0 仅限于处理简单的单轮问答，无法满足复杂查询的需求。

为了解决 RAG 1.0 的局限性，新一代 RAG 架构，即 RAG 2.0，应运而生。RAG 2.0 将 RAG 系统视为一个以搜索为中心的端到端流程，并将其细化为四个关键阶段：信息提取、文档预处理、索引构建和检索。

与 RAG 1.0 不同的是，RAG 2.0 强调对数据处理流程的精细化控制，每个阶段都围绕模型和算法进行优化，以确保最终答案的质量。例如，

• 在信息提取阶段：RAG 2.0 采用更精细的文档解析和信息抽取技术，保留更多关键信息
• 在文档预处理阶段：RAG 2.0 引入了知识图谱构建、文档聚类等技术，为检索提供更丰富的上下文信息
• 在索引构建阶段：RAG 2.0 支持向量搜索、全文搜索、张量搜索等多种混合搜索方式，提升检索效率和精度
• 在检索阶段：RAG 2.0 引入了查询重写、意图识别等技术，优化检索策略

• 深度文档理解： RAGFlow 采用先进的文档解析和信息抽取技术，能够处理各种复杂的文档格式，并提取关键信息，为后续的知识图谱构建、索引构建等环节提供高质量的数据基础。
• 混合搜索： RAGFlow 集成了多种搜索技术，包括向量搜索、全文搜索和张量搜索，能够根据不同的数据类型和查询需求，灵活选择最优的搜索策略，提升检索效率和精度。
• 知识图谱增强： RAGFlow 支持 GraphRAG 等知识图谱构建技术，能够自动从文本数据中抽取实体和关系，构建知识图谱，为 LLM 提供更丰富的上下文信息，提升答案的精准性和可解释性。
• 查询优化： RAGFlow 引入了查询重写、意图识别等技术，能够根据用户的查询意图，动态调整检索策略，提高答案的精准度和相关性。

因此，RAG 2.0 相比 RAG 1.0 会复杂很多，其核心是数据库和各种模型，需要依托一个平台来不断迭代和优化，这就是我们开发并开源 RAGFlow 的原因。它没有采用已有的 RAG 1.0 组件，而是从整个链路出发来根本性地解决 LLM 搜索系统的问题。当前，RAGFlow 仍处于初级阶段，系统的每个环节，都还在不断地进化中。由于使用了正确的方式解决正确的问题，因此自开源以来 RAGFlow 只用了不到 3 个月就获得了 Github 万星。当然，这只是新的起点。

在 RAGFlow 体系中，我们对下一代 RAG (RAG 2.0) 的定义更加完整：它是一个以搜索为中心的端到端优化系统。RAG 2.0 共分为四个阶段，其中索引与检索阶段通常需要专用数据库提供支持，而前两个阶段，即数据抽取和预处理，则扮演着至关重要的角色。

数据抽取阶段，我们利用各类文档模型，例如强大的大型语言模型 (LLM)，来确保被索引数据的质量，避免出现“垃圾输入，垃圾输出”(Garbage In, Garbage Out) 的情况。

在数据进入数据库之前，我们还可以选择性地进行一些预处理，包括文档预聚类和知识图谱构建等。这些预处理步骤主要用于解决多跳问答和跨文档提问等复杂场景。

GraphRAG 作为一种面向下一代 RAG 的解决方案应运而生。在 RAG 2.0 的体系中，它可以被视为整个流程中的一个重要单元。从 RAGFlow 的 0.9 版本开始，我们已经将 GraphRAG 集成到系统当中。

那么，为什么选择引入 GraphRAG？它与微软提出的 GraphRAG 又有哪些区别和联系？

知识图谱对提升 RAG 的效果至关重要。传统的 RAG 系统只能根据提问检索答案，找到的往往是与提问相似的结果，而非精准答案。例如，对于一些需要总结归纳的问题，简单的关键词匹配显然无法满足需求。

这类问题本质上是一种聚焦于查询的总结 (Query Focused Summarization, QFS)。利用知识图谱可以很好地解决这类问题。知识图谱能够根据文本相关性将内容聚合，在对话过程中根据这些聚合信息生成总结，从而精准地回答用户问题。目前，很多专用 AI 搜索引擎都在采用这种方法。

之前的 RAGFlow 版本提供的 RAPTOR 功能也是对文本进行聚类，与上述原理类似。但相比之下，以知识图谱为中心的方法可以构建以命名体实体节点为中心的层次化结果，在处理 QFS 查询时，能够提供更准确、更系统的答案。

不仅如此，在其他一些场景中，知识图谱也能改善 RAG 的返回结果。它能够为返回结果添加更丰富的上下文信息，使 LLM 可以生成更具解释性的答案。

大量研究工作已经证明了知识图谱在 RAG 中的有效性。因此，GraphRAG 一经推出就迅速获得了社区的广泛关注。

当然，利用知识图谱进行问答并非新鲜事。早在 RAG 出现之前，KGQA 就已经存在多年。但这些工作一直面临着一个瓶颈：如何实现知识图谱构建的自动化和标准化。这也阻碍了基于知识图谱的问答系统在企业级场景中的大规模应用。

随着 LLM 和 RAG 的出现和普及，使用 LLM 自动构建知识图谱成为了一种可行的方案，GraphRAG 就是其中的佼佼者。

然而，GraphRAG 在实际应用中也面临一些挑战。例如，在实体抽取过程中，可能会出现多个同义词对应同一个实体的情况，影响知识图谱的准确性。此外，GraphRAG 需要多次调用 LLM， 尤其是在处理大规模数据集时，会不可避免地消耗大量的 Token，增加使用成本。

• 实体去重: 为了解决 GraphRAG 在实体抽取过程中可能出现的同义词问题，RAGFlow 引入了实体去重机制。它利用 LLM 的语义理解能力，自动识别和合并表示相同实体的不同名称，例如将 “2024” 和 “2024 年” 合并为同一个实体，从而提高知识图谱的准确性。
• 降低 Token 消耗: GraphRAG 在构建知识图谱的过程中，需要多次调用 LLM，这在处理大规模数据集时会消耗大量的 Token。为了降低使用成本，RAGFlow 对 GraphRAG 的流程进行了优化，尽可能减少 LLM 的调用次数，并通过缓存机制避免重复计算，从而有效降低 Token 的消耗量。

简而言之，GraphRAG 对知识图谱的抽象和构建进行了简化，使其更易于工程化和标准化，推动了基于知识图谱的问答系统在实际应用中的落地。RAGFlow 借鉴了 GraphRAG 的实现，并在其基础上进行了一系列改进，例如引入去重步骤、降低 Token 消耗等，使其更加高效和实用。

RAGFlow v0.9 的发布，标志着知识图谱增强型 RAG 系统 (RAG 2.0) 的全新时代正式开启。GraphRAG 作为其中的先行者，展现了 LLM 驱动下的知识图谱构建技术所蕴含的巨大潜力。它不仅为 RAG 系统注入了更强大的语义理解和知识推理能力，也为智能问答、语义搜索、知识发现等领域的应用打开了新的大门。

GraphRAG 之所以能够取得成功，很大程度上得益于它对传统知识图谱构建流程的简化，使其更容易在实际工程中落地。然而，我们必须认识到，这仅仅是知识图谱与 RAG 结合的开始，未来还有广阔的探索空间。

现有的 GraphRAG 主要面向能够构建知识图谱的结构化和半结构化数据， 但在实际的企业级应用中，还有大量数据并不适合构建知识图谱， 也有一些场景需要考虑成本因素，无法对所有数据进行知识图谱构建。

因此，如何将知识图谱的优势应用到更广泛的数据类型上，如何在成本可控的情况下构建和利用知识图谱，将是未来 RAGFlow 需要着重解决的问题。

• 突破数据限制，构建跨文档知识图谱: 未来的 RAG 系统需要具备处理更复杂数据的能力。RAGFlow 将探索构建跨越多个文档的知识图谱， 以捕捉更复杂的语义关系， 提升系统对复杂问题的理解和推理能力，打破数据之间的壁垒。
• 深入挖掘语义信息，实现知识图谱驱动的查询改写: 为了进一步提升检索的精准度， RAGFlow 将探索利用知识图谱中的语义信息，对用户查询进行改写和扩展， 帮助系统更准确地理解用户意图， 返回更符合用户需求的结果。
• 拓展知识维度，实现多模态知识融合: 未来的 RAG 系统需要能够理解和处理更加多元的信息。RAGFlow 将探索将文本、图像、视频等多模态信息融入知识图谱，构建更全面的知识表示，支持更丰富的问答场景，例如结合图片和文字进行问答等。

• Text2SQL: 支持用户使用自然语言进行数据库查询，方便用户从结构化数据中获取信息，降低使用门槛。
• 多模态代理: 支持 TTS (语音合成) 和类似 Perplexity 的搜索代理， 为用户提供更便捷、更自然的交互体验。
• OpenAI 兼容 API: 提供与 OpenAI 兼容的 API，方便开发者将 RAGFlow 集成到现有应用中， 降低开发成本。
• 更丰富的文件格式支持: 支持解析 eml 等更多类型的文件， 扩展系统的应用场景， 满足更多用户的需求。