RAGFlow 0.21.0 特性总览——Ingestion Pipeline、长上下文 RAG 及后台管理 CLI

RAGFlow 0.21.0 版本正式发布

继前一个大版本重点完善了在线 Agent 能力之后，本次更新重新回归数据层，致力于从源头提升系统的易用性与对话效果。

在当前 RAG 技术面临数据预处理、长上下文理解等挑战的背景下，0.21.0 版本带来了一系列关键增强：

我们引入了可编排的 Ingestion Pipeline，让数据注入流程前所未有的灵活可控；

推出了长上下文 RAG 技术，有效解决复杂文档的语义断裂问题；

并提供了全新的命令行管理工具，为系统运维保驾护航。

这些改进共同构成了 RAGFlow 新一代数据管线的核心，旨在通过更坚实的数据基座，为用户构建更强大、更可靠的 RAG 应用。

可编排的 Ingestion Pipeline

如果说之前的 Agent 主要解决了在线数据的编排（如 Workflow 与 Agentic Workflow），那么 Ingestion Pipeline 则基于同一套技术体系，实现了对离线数据注入流程的编排。它的推出，使用户能够借助统一框架构建高度自定义的 RAG 数据管道，不仅显著提升了定制化开发的便利性，也更贴合“RAGFlow”这一产品名称。

典型的 RAG 数据写入流程通常包括文档解析（Parsing）、文本分块（Chunking）、向量化与索引构建等关键阶段。回顾 RAGFlow 在 2024 年 4 月刚刚开源时，就已内置了一系列先进的工具链，包括基于 DeepDoc 的文档解析引擎和模板化分块机制。这些在当时处于 SOTA 水平的技术方案，为 RAGFlow 的早期流行打下了坚实基础。

然而，随着行业技术的快速演进与实际应用的深入，我们也观察到一些新的变化与需求：

1. 多模态视觉语言模型（VLM）日趋成熟，基于这些 VLM 微调得到的各类文档解析模型不断涌现，针对复杂版式、图文混排等非结构化文档的解析能力愈发精准。

2. 在文本分块环节，越来越多的用户希望引入更灵活的定制策略。面对多样化的知识库场景，RAGFlow 原有内置的分块模板已难以覆盖所有细分情况，一定程度上影响了最终问答效果的准确性。

为此，RAGFlow 在 0.21.0 版本中正式引入了 Ingestion Pipeline 功能，其核心特性包括：

1. 支持可编排的数据注入流程：底层复用 Agent 框架能力，用户现在可以创建多样化的数据注入流水线。每个 Pipeline 可采用不同策略连接数据源与最终索引，将原先以内置 Agent 形式存在的数据写入方式，转变为用户可自定义的流程，使用户能够以更灵活、更贴合业务逻辑的方式完成数据注入。

2. 实现数据上传与清洗的解耦：通过架构层面的分离，为后续支持批量传输的各类数据源预留了标准接口，也为数据预处理流程的扩展提供了坚实基础。

3. 重构文档解析算子：重新设计了 Parsing 算子接口，使其具备良好的扩展性，为未来接入 DeepDoc 之外更多先进的文档解析模型做好了技术准备。

4. 提供可自定义的 Chunking 接口：通过将分块环节解耦，使用户能够根据实际场景灵活嵌入自定义 Chunker，更好地适应不同知识结构下的分块需求。

5. 优化复杂 RAG 任务的执行效率：针对 GraphRAG 、RAPTOR 等 IO/计算密集型任务进行了重构。在原有非 Pipeline 架构下，每新增一个文档都会触发全量计算，导致执行缓慢。引入 Pipeline 后，这类任务转为批量执行模式，显著提升了数据处理吞吐量与整体运行效率。

如果说 ETL/ELT 是现代数据栈中处理结构化数据的标准管线，诸如 dbt、 FiveTran 等工具为数据仓库和数据湖提供了统一且灵活的数据集成方案，那么 RAGFlow 的 Ingestion Pipeline 正致力于成为非结构化数据领域的等效基础设施。

两者在架构定位上的对比如下图所示：

具体来看，ETL/ELT 流程中的 “Extract” 阶段主要负责从各类数据源抽取数据，而 RAGFlow Ingestion Pipeline 在此基础上专门增强了 “Parsing” 环节，以解决非结构化数据的信息提取难题。该环节集成了以 DeepDoc 为代表的多种解析模型，专注于将多模态文档（如图文混排内容）转化为适合处理的单模态表示。

在 “Transform” 阶段，传统ETL/ELT侧重于数据清洗和业务逻辑转换，而 RAGFlow 则构建了以 LLM 为核心的各种 Agent 算子。这些算子专门针对检索过程中的语义缺失问题进行优化，其核心目标可以概括为：一切为了增强召回效果和排序准确性。

最后，在数据加载环节，ETL/ELT 将处理结果写入数据仓库或数据湖，而 RAGFlow 则通过 “Indexer” 模块将处理后的内容构建成适合检索的索引格式。这是因为 RAG 引擎的底层是基于多种检索方式的融合架构，需要支持全文检索、向量检索乃至未来的张量检索等技术来确保最佳的召回效果。

因此，现代数据栈服务于结构化数据的业务分析，而具备 Ingestion Pipeline 的 RAG 引擎则专注于非结构化数据的智能检索——为 LLM 提供高质量的上下文信息。两者在各自领域占据着等效的生态位。

至于结构化数据的处理，这并非 RAG 引擎的核心职责，而是通过在 RAG 引擎之上构建的 “Context Layer” 来实现。该层借助被称为 “AI时代TCP/IP” 的 MCP（Model Context Protocol）协议及配套的 Context Engineering，实现所有类型上下文的自动填充——这也正是 RAGFlow 下一步重点研发的方向之一。

下边初步展示 0.21.0 版本的 Ingestion Pipeline，更进一步的使用指导会在后续文章带来。

我们在 Agent 画布中引入解析、切片等与处理非结构化数据相关的节点，使用户能够自由编排解析流程：

通过编排 Ingestion Pipeline，可以让文件被自动解析、按长度切块，再利用大模型生成摘要、关键词、问题甚至元数据（Metadata）。过去这些 Metadata 都得用户手动填写，如今只需一次编排，就能大幅降低维护成本。

除此之外，Pipeline 过程同时具备可观测性，可记录并展示 Pipeline 解析文件的完整处理日志：

0.21.0 版本只是 Ingestion Pipeline 的初步实现，在下个版本，将会围绕它做进一步增强，包括：添加更多的数据源，提供更多的 Parser 选项，以及提供更灵活的 Transformer 算子用来编排更丰富的语义增强模板。

长上下文 RAG

进入 2025 年之后，RAG 技术本身收到了诸多挑战，这主要是由以下几个原因导致的：

1. 传统 RAG 方案在部分场景下很难保证对话效果。以切分后的分片作为主要召回单元的检索方式，很容易受到分片质量的影响，从而因缺乏足够的上下文信息而降低回答质量。例如，一段完整的语义如果被切分到不同的 Chunk 中，就会导致召回内容不全；如果 Chunk 本身缺乏全局信息，也会影响上下文的质量——尽管可以通过自动识别层级标题并将其添加到 Chunk 中来补充全局语义，但这仍然受到标题识别不准、标题语义不全等限制。

2. 以 GraphRAG、RAPTOR、Context Retrieval 等为代表的预处理技术，其本质都是借助 LLM 为原始数据添加额外的语义信息，以解决搜索命中率不高、复杂提问召回不准的问题。但这些方法普遍面临性价比低、效果不可控等问题。具体来说：

   1. 对于 GraphRAG，Token 消耗往往达到原文的数十倍，而自动化构建的知识图谱质量却不尽如人意。其在复杂多跳问答中的辅助召回效果，也因推理路径不可控而受限，这主要是因为知识图谱作为一种在 Chunk 之外新增的召回手段，相比原文会丢失部分上下文信息。

   2. RAPTOR 借助 LLM 为原始文本添加聚类后的摘要信息，这些摘要作为独立的 Chunk 被召回，自然也会缺乏对应原文的细节信息，因此同样存在上下文不足的问题。

   3. Context Retrieval 则是借助 LLM 为原始 Chunk 添加关键词、可能的提问等额外语义信息。其实现方式主要有两种：一种是基于全文和当前 Chunk 反复请求 LLM 为每个 Chunk 补充语义，效果较好但 Token 消耗可达原文数倍，成本较高；另一种是仅基于当前 Chunk 请求 LLM 生成语义信息，虽然节省成本，但对全局上下文的补充不足，效果提升有限。

针对以上问题，近年来也出现了一些新的 RAG 方案，例如：

1. 不引入 Embedding 或索引，直接让 LLM 阅读文档，以规避 Retrieval 不准的问题，换句话说，彻底放弃 Retrieval。具体做法是根据 LLM 的上下文窗口长度将文档切分为 Chunk，并采用多阶段搜索：先由 LLM 判断问题与哪个全局文档相关，再确定问题与哪些具体分块相关，最后加载对应分块生成回答。该方案虽然缓解了召回不准的问题，但在响应延迟、并发能力以及大规模数据处理（包括规则过滤等方面）完全丧失了 Retrieval 的优势，因此实际落地难度较大。

2. 放弃 Embedding 或索引，直接使用 Grep 等工具，并将 RAG 演进为 Agentic RAG。随着应用场景的复杂化和用户提问的多样化，将 RAG 与 Agent 结合已成为必然趋势，因为只有 LLM 才能将原始提问转化为结构化的检索指令。在 RAGFlow 中，这一能力早已实现。然而，放弃索引转用 Grep 仅是为了简化 Agent 开发而在个人或小型场景中做出的折衷，在企业级应用中，强大的 Retrieval 引擎仍然是不可或缺的。

综上所述，RAGFlow 在 0.21.0 版本中推出了“长上下文 RAG”技术。它与 GraphRAG、RAPTOR、Context Retrieval 等同属一类——均借助 LLM 为原始文本增强语义信息，以改善召回效果。与前述完全放弃 Retrieval 的方案不同，长上下文 RAG 仍基于索引与搜索机制。作为已存在二十多年的技术，检索在 LLM 时代不仅未被削弱，反而焕发出新的生命力。

长上下文 RAG 模仿人类查阅信息的行为方式：

针对问题，首先根据目录定位相关章节，继而翻至具体页码获取详细信息。在实现上，索引阶段通过 LLM 抽取并生成章节信息，并将其添加到每个 Chunk 中，从而补充足够的全局上下文；

检索阶段则先通过搜索获取命中的 Chunk，再依据目录结构补全因 Chunk 断裂而缺失的内容，从而有效解决因上下文信息不足导致的回答质量下降问题。

目前，用户可通过勾选 “TOC” 模板（Table of Contents）体验长上下文 RAG 功能，以下是两个示例：

样例一

刑法第二十条按照 Chunk 大小分块被分开了，搜索无法获得完全内容。分块结果对比如下：

<CHUNK A> 因不满十六周岁不予刑事处罚的，责令其父母或者其他监护人加以管教；在必要的时候，依法进行专门矫治教育。 第十七条之一已满七十五周岁的人故意犯罪的，可以从轻或者减轻处罚；过失犯罪的，应当从轻或者减轻处罚。 第十八条精神病人在不能辨认或者不能控制自己行为的时候造成危害结果，经法定程序鉴定确认的， 不负刑事责任，但是应当责令他的家属或者监护人严加看管和医疗；在必要的时候，由政府强制医疗。 间歇性的精神病人在精神正常的时候犯罪，应当负刑事责任。 尚未完全丧失辨认或者控制自己行为能力的精神病人犯罪的，应当负刑事责任，但是可以从轻或者减轻处罚。 醉酒的人犯罪，应当负刑事责任。第十九条又聋又哑的人或者盲人犯罪，可以从轻、减轻或者免除处罚。 第二十条为了使国家、公共利益、本人或者他人的人身、财产和其他权利免受正在进行的不法侵害， 而采取的制止不法侵害的行为，对不法侵害人造成损害的，属于正当防卫，不负刑事责任。

<CHUNK B> 正当防卫明显超过必要限度造成重大损害的，应当负刑事责任，但是应当减轻或者免除处罚。 对正在进行行凶、杀人、抢劫、强奸、绑架以及其他严重危及人身安全的暴力犯罪，采取防卫行为， 造成不法侵害人伤亡的，不属于防卫过当，不负刑事责任。 第二十一条为了使国家、公共利益、本人或者他人的人身、财产和其他权利免受正在发生的危险， 不得已采取的紧急避险行为，造成损害的，不负刑事责任。

采用 TOC 模板后，回答结果完整：

采用常规 RAG 方法则回答不完整：

样例二

问题涉及的关键信息遍布在文档多处，就算基于搜索的方式能全部召回所有相关内容也会由于大模型上下文限制而无法得到全面的答案。

下面的例子中，提问是：“列举卷取机故障种类”。而“卷取机”在文档中出现了177次，涉及132个 Chunk，如下图：

采用 TOC 模板之后，可以精而全地拿到关于“卷取机故障”的 Chunk。下图为召回的 TOC 的结构：

[
  {
    "level": "1",
    "title": "08 1#卷取机堆钢故障",
    "ids": [
      "a91b6c81bae7905b"
    ]
  },
  {
    "level": "1",
    "title": "28 卷取机跳电故障",
    "ids": [
      "be0405370ebc82b3"
    ]
  },
  {
    "level": "1",
    "title": "36 1#卷取机禁止进钢故障",
    "ids": [
      "c34d7b993b5de005",
      "aaef58fef967d161"
    ]
  },
  {
    "level": "1",
    "title": "38 2#卷取机漏油故障",
    "ids": [
      "18b6e25c8bcaefbc"
    ]
  },
   ...
]

这是通过采用 TOC 模板得到的回答，全面而有条理：

这个是采用常规 RAG 回答，知识点零碎而不全：

目前 TOC 功能仍处于试用阶段，我们计划在下一个版本中，结合 Ingestion Pipeline 对其进行进一步增强。从当前技术演进可以看出，提升 RAG 能力的关键路径之一，在于合理利用 LLM 增强内容语义，而非轻易放弃 Retrieval 机制。因此，在 Pipeline 中允许用户灵活组装基于 LLM 的内容变换算子，已成为改进 RAG 检索质量的重要方向。

后台管理命令行工具

在之前的版本中，RAGFlow 主要聚焦于核心功能模块的构建与优化，虽然在文档解析、检索增强生成等关键技术路径上取得了显著进展，但在系统基础管理与运维能力方面仍存在一定短板。尤其值得注意的是，旧版本中缺乏对用户账户的有效管理手段，管理员无法直接修改用户密码，也无法执行用户删除操作，这在实际部署和使用过程中为用户管理与系统维护带来了诸多不便。

随着 RAGFlow 0.21.0 版本的发布，这一局面得到了根本性的改善。该版本重点加强了系统底层管理能力的建设，引入了全新的命令行管理工具，为系统管理员提供了集中、便捷的操作入口。目前，通过该命令行工具，管理员能够实现以下核心管理功能：

1. 服务生命周期管理：支持对 RAGFlow 系统内置服务的监控，提升了系统运维的灵活性与可控性。

2. 全面的用户管理：彻底解决了此前版本的管理痛点。现在，管理员可以：

   1. 创建新的注册用户。

   2. 直接修改用户的登录密码，解决了过去无法直接重置用户密码的难题。

   3. 执行用户删除操作，实现了用户账户的全生命周期管理。

   4. 灵活设置用户状态（如启用/禁用）。

   5. 查看所有注册用户的信息。

3. 资源概览：能够列表显示所有注册用户名下创建的知识库和 Agent，方便管理员从系统层面进行资源监控。此次升级标志着 RAGFlow 在追求功能强大的同时，也开始系统性地完善其作为企业级应用所必需的基础管理能力。未来，RAGFlow 团队已规划开发功能更为全面的企业级 Web 管理后台及配套的用户界面，旨在进一步简化管理操作，提升管理效率与最终用户的使用体验，推动产品向更成熟、更稳定的方向演进。

写在最后

RAGFlow 0.21.0 版本的发布，是一次承前启后的重要革新。它标志着融合了检索（RAG）与编排（Flow）的技术体系已初步整合完毕，一个以非结构化数据 ELT 为基座、以全面强大的 RAG 能力为依托、旨在服务 LLM 上下文层的智能引擎初具雏形。

从赋予用户高度自主权的 Ingestion Pipeline，到有效解决语义断裂难题的长上下文 RAG，再到保障系统稳健运维的管理后台工具，本版本的每一项新特性都致力于让 RAG 系统更智能、更灵活、更企业级。这不仅是功能的叠加，更是底层架构的演进，为我们未来的发展奠定了坚实的基础。

接下来的演进将紧紧围绕 LLM 的上下文展开。成为 LLM 强大而可靠的数据基座，服务好所有的 Agent，是 RAGFlow 矢志不渝的目标。

欢迎您持续关注并 Star 我们的项目，一同见证 RAGFlow 的成长。

**GitHub: ** https://github.com/infiniflow/ragflow