自开源以来，RAGFlow 一直持续受到社区的广泛关注。其核心模块 DeepDoc 利用内置的文档解析模型，为多种业务场景提供了智能化的文档分片能力，确保 RAGFlow 在检索和生成阶段都能提供准确、高质量的回答。目前，RAGFlow 预集成了十余种文档分片模板，覆盖了各类业务场景和文件类型。

然而，随着 RAGFlow 在生产环境中的应用日益广泛，原有的十余种固定分片方式已难以满足所遇到的复杂多样的数据源、文档结构和文件类型。具体挑战包括：

• 需要根据特定业务场景，灵活配置不同的解析和分片策略，以适应多变的文档结构和内容逻辑。
• 文档解析和录入不仅涉及将非结构化数据分割成文本块，还包含一系列关键的预处理步骤，以弥合RAG检索过程中的“语义鸿沟”。这通常需要利用模型为原始内容丰富语义信息，如摘要、关键词和层次结构。
• 除了本地上传的文件，大量的数据、文件和知识源于各种渠道，包括云盘和在线服务。
• 随着多模态视觉语言模型（VLM）的成熟，涌现出像 MinerU 和 Docling 这样在解析复杂布局、表格和图文混排文档方面表现出色的模型。这些模型在不同应用场景中展现出独特的优势。

为应对这些挑战，RAGFlow 0.21.0 推出了开创性的 Ingestion Pipeline。该流水线重构了非结构化数据的清洗流程，允许用户根据特定业务需求构建定制化的数据处理流水线，并实现对异构文档的精准解析。

Ingestion Pipeline 本质上是一个为非结构化数据量身定制的可视化 ETL 流程。它基于 Agent 构建，将一个典型的 RAG 数据录入工作流——通常包含文档解析、文本分块、向量化和索引构建等关键阶段——重构为三个不同的阶段：Parser、Transformer 和 Indexer。这些阶段分别对应文档解析、数据转换和索引构建。

• 文档解析（Document Parsing）：作为数据清洗的关键步骤，该模块集成了多种解析模型，DeepDoc 是其中的代表。它将原始的非结构化数据转换为半结构化内容，为后续处理奠定基础。
• 数据转换（Data Transformation）：目前提供两类核心算子，包括 Chunker 和 Transformer。该阶段旨在将清洗后的数据进一步处理成适合各种索引访问方式的格式，从而确保高质量的召回性能。
• 索引构建（Index Construction）：负责最终的数据写入。RAGFlow 内在采用多路召回架构以保证检索效果。因此，Indexer 集成了多种索引方法，允许用户灵活配置。

下面，我们将通过一个具体示例来演示 Ingestion Pipeline 的构建和使用。

首先，在“Agent”页面点击“创建Agent”。您可以选择“从空白创建”来从头构建一个 Ingestion Pipeline。

或者，您也可以选择“从模板创建”，利用预配置的 Ingestion Pipeline 模板。

接下来，我们将开始编排流水线所需的各种算子。从零开始创建时，初始画布上仅显示 Begin 和 Parser 算子。随后，您可以从现有算子的右侧拖拽并连接具有不同功能的其他算子。

首先，需要配置 Parser 算子。

解析器 (Parser)

Parser 算子负责读取和解析文档：识别其布局、提取其结构和文本信息，并最终获得结构化的文档数据。

这是一种“高保真、结构化”的提取策略。Parser 能够智能地适应并保留不同文件的原始特征，无论是 Word 文档的层级大纲、电子表格的行列布局，还是扫描版 PDF 的复杂版式。它不仅提取正文，还完整保留标题、表格、页眉和页脚等辅助信息，并将它们转化为适当的数据形式，具体内容将在下文详述。这种结构化的区分至关重要，为后续的精细化处理提供了必要的基础。

目前，Parser 算子支持 8 大类共 23 种文件类型的输入，总结如下：

使用时，只需在 Parser 节点内点击“添加 Parser”并选择所需的文件类别（如 PDF、Image 或 PPT）。当 Ingestion Pipeline 运行时，Parser 节点会自动识别输入文件，并将其路由到相应的解析器进行解析。

在此，我们对几种常见文件类别的解析器作进一步说明：

• 对于 PDF 文件，RAGFlow 提供了多种解析模型选项，统一输出为 JSON 格式：

  1. 默认 DeepDoc：这是 RAGFlow 的内置文档理解模型，能够识别布局、分栏和表格。它适用于处理扫描文档或格式复杂的文档。
  2. MinerU：目前业界优秀的文档解析模型之一。除了解析复杂的文档内容和布局外，MinerU 还为数学公式等复杂文件元素提供了出色的解析能力。
  3. Naive：一种不使用任何模型的纯文本提取方法。它适用于没有复杂结构或非文本元素的文档。

• 对于 Image 文件，系统将默认调用 OCR 从图像中提取文本。此外，用户还可以配置支持视觉识别的 VLM（视觉语言模型）来处理它们。
• 对于 Audio 文件，需要配置一个支持语音转文本的模型。Parser 将从音频中提取文本内容。用户可以在首页的“模型提供商”页面配置支持此类解析的模型提供商的 API 密钥。之后，他们可以返回 Parser 节点并在下拉菜单中选择它。这种“先配置后选择”的逻辑也适用于 PDF、Image 和 Video 文件。
• 对于 Video 文件，需要配置一个支持多模态识别的大模型。Parser 将调用此模型对视频进行全面分析，并以文本格式输出结果。
• 在解析 Email 文件时，RAGFlow 提供了字段选项，允许用户仅选择所需字段，如“主题”和“正文”。Parser 将精确提取这些字段的文本内容。

• Spreadsheet 解析器会以 HTML 格式输出文件，完整保留其行列结构，确保表格数据在转换后依然清晰可读。
• Word 和 PPT 类型的文件将被解析并输出为 JSON 格式。对于 Word 文件，文档的原始层级结构，如标题、段落、列表、页眉和页脚，都将被保留。对于 PPT 文件，内容将逐页提取，区分每张幻灯片的标题、正文和备注。
• Text & Markup 类别会自动剥离 HTML 和 MD（Markdown）等文件的格式标签，只输出最纯净的文本内容。

分块器 (Chunker)

Chunker 节点负责将上游节点输出的文档分割成 Chunk 片段。Chunk 是 RAG 技术引入的一个概念，代表召回的单元。用户可以根据需要选择是否添加 Chunker 节点，但通常建议使用它，主要有两个原因：

1. 如果将整个文档作为召回单元，最终生成阶段传递给大模型的数据可能会超出上下文窗口限制。
2. 在典型的 RAG 系统中，向量搜索是一种重要的召回方法。然而，向量本身存在语义表示不准确的问题。例如，用户可以选择将单个句子转换为向量，或将整个文档转换为向量。前者丢失了全局语义信息，而后者丢失了局部信息。因此，选择一个合适的片段长度，使其在用单个向量表示时能达到较好的平衡，是一种必要的技术手段。

在实际工程系统中，Chunk 的切分结果往往显著影响 RAG 的召回质量。如果包含答案的内容被分割到不同的 Chunk 中，而检索阶段无法保证所有这些 Chunk 都被召回，就可能导致答案生成不准确和产生幻觉。因此，Ingestion Pipeline 引入了 Chunker 节点，允许用户更灵活地切分文本。

当前系统内置了两种切分方法：基于文本 token 和标题的切分。

按 token 切分是最常见的方法。用户可以自定义每个片段的大小，默认设置为 512 个 token，这是一个为检索效果和模型兼容性优化的平衡值。在设置片段大小时，必须考虑权衡：如果片段 token 数仍然过大，超出模型限制的部分仍会被丢弃；如果设置得太小，可能会导致原文中连贯的语义被过度分割，破坏上下文并影响检索效果。

为了解决这个问题，Chunker 算子提供了片段重叠功能，它允许前一个片段的末尾部分被复制为下一个片段的开头，从而增强语义连续性。用户可以增加“重叠百分比”来提高片段之间的关联性。

此外，用户可以通过定义“分隔符”来进一步优化切分规则。系统默认使用 \n（换行符）作为分隔符，这意味着切分器将优先尝试沿着自然段落进行分割，而不是在句子中间突然截断，如下图所示。

如果文档本身具有清晰的章节结构，按 token 切分文本可能不是最佳选择。在这种情况下，可以选择 Chunker 中的 Title 选项，根据文档的标题进行切分。这种方法主要适用于具有技术手册、学术论文和法律条款等布局的文档。我们可以在 Title 节点中为不同级别的标题自定义表达式。例如，一级标题（H1）的表达式可以设置为 ^#[^#]，二级标题（H2）的表达式可以设置为 ^##[^#]。基于这些表达式，系统将严格按照预定义的章节结构对文档进行切分，确保每个片段都代表一个结构完整的“章节”或“小节”。用户还可以在配置中自由添加或减少标题级别，以匹配文档的实际结构，如下图所示。

注意：在当前的 RAGFlow v0.21 版本中，如果同时配置了 Chunker 的 Token 和 Title 选项，请确保 Title 节点连接在 Token 节点之后。否则，如果 Title 节点直接连接到 Parser 节点，对于 Email、Image、Spreadsheet 和 Text&Markup 类型的文件可能会出现格式错误。这些限制将在后续版本中进行优化。

转换器 (Transformer)

Transformer 算子负责转换文本内容。仅仅解决文本解析和切分的准确性并不能保证最终的检索准确率。这是因为用户的查询与包含答案的文档之间总是存在所谓的“语义鸿沟”。通过使用 Transformer 算子，用户可以利用大模型从输入文档内容中提取信息，从而弥合“语义鸿沟”。

当前的 Transformer 算子支持摘要生成、关键词生成、问题生成和元数据生成等功能。用户可以选择将该算子加入其流水线，以这些内容补充原始数据，从而提升最终的检索准确率。与其他涉及大模型的场景类似，Transformer 节点也为大模型提供了三种模式：即兴（Improvise）、精确（Precise）和平衡（Balance）。

• 即兴模式（Improvise）鼓励模型展现更大的创造力和联想思维，非常适合生成多样化的问题。
• 精确模式（Precise）严格约束模型，确保其输出高度忠实于原文，适合生成摘要或提取关键词。
• 平衡模式（Balance）在两者之间取得平衡，适用于大多数场景。

用户可以选择这三种风格之一，或者通过自行调整 Temperature 和 Top P 等参数来实现更精细的控制。

Transformer 节点可以生成四种类型的内容：摘要（Summary）、关键词（Keywords）、问题（Questions）和元数据（Metadata）。RAGFlow 还将每种内容的提示词（prompt）公开，这意味着用户可以通过修改系统提示词来丰富和个性化文本处理。

如果需要实现多种功能，例如同时总结内容和提取关键词，用户需要为每个功能配置一个独立的 Transformer 节点，并在流水线中将它们串联起来。换句话说，一个 Transformer 节点可以紧接在 Parser 之后，处理整个文档（例如，生成全文摘要），也可以连接在 Chunker 之后，处理每个文本片段（例如，为每个 Chunk 生成问题）。此外，一个 Transformer 节点可以连接在另一个 Transformer 节点之后，以级联方式执行复杂的内容提取和生成。

请注意：Transformer 节点不会自动从其前置节点获取内容。它实际处理的信息来源完全取决于用户提示词（User prompt）中引用的变量。在用户提示词中，必须通过输入 / 符号来手动选择和引用上游节点输出的变量。

例如，在一个 Parser - Chunker - Transformer 的流水线中，尽管 Transformer 在视觉上连接在 Chunker 之后，但如果用户提示词中引用的变量是来自 Parser 节点的输出，那么 Transformer 实际上将处理整个原始文档，而不是 Chunker 生成的块。

同样，当用户选择串联多个 Transformer 节点时（例如，第一个生成摘要，第二个生成关键词），如果第二个 Transformer 引用了第一个 Transformer 生成的摘要变量，它将处理这个摘要作为“新的原文”进行进一步处理，而不是处理更上游 Chunker 的文本块。

索引器 (Indexer)

前面的 Parser、Chunker 和 Transformer 节点处理了数据流入、切分和优化。然而，流水线中最终的执行单元是 Indexer 节点，它负责将处理后的数据写入检索引擎（RAGFlow 目前支持 Infinity、Elasticsearch 和 OpenSearch）。

检索引擎的核心能力是为数据建立各种类型的索引，从而提供搜索能力，包括向量索引、全文索引以及未来的张量索引能力等。换句话说，它是 RAG 这个术语中“检索”（Retrieval）的最终体现。

由于不同类型索引的能力各不相同，Indexer 同时提供了创建不同索引的选项。具体来说，Indexer 节点内的“搜索方法”（Search method）选项决定了用户数据如何被“找到”。

全文（Full-text）指的是传统的“关键词搜索”，这是精确召回的必要选项，例如搜索特定的产品编号、人名或代码。而嵌入（Embedding）则代表了现代由人工智能驱动的“语义搜索”。用户可以用自然语言提问，系统可以“理解”问题的含义并检索内容上最相关的文档块。同时启用两者进行混合搜索是 RAGFlow 的默认选项。有效的多渠道召回可以平衡精确度和语义，最大限度地发现答案所在的文本片段。

注意：在 Indexer 节点内无需选择特定的嵌入模型，因为它会自动调用创建知识库时设置的嵌入模型。此外，RAGFlow 中的聊天（Chat）、搜索（Search）和 Agent 功能支持跨知识库检索，这意味着一个问题可以同时在多个知识库中进行搜索。但是，要启用此功能，必须满足一个先决条件：所有同时选择的知识库必须使用相同的嵌入模型。这是因为不同的嵌入模型会将相同的文本转换为完全不同且不兼容的向量，从而无法进行跨库检索。

此外，通过“文件名嵌入权重”（Filename embedding weight）和“字段”（Field）选项可以实现更精细的检索设置。文件名嵌入权重是一个微调滑块，允许用户将文档的“文件名”视为语义信息的一部分，并为其分配特定权重。

而“字段”选项则决定了要索引的具体内容和检索策略。目前提供了三种不同的策略选项：

• 处理后的文本（Processed Text）：这是默认选项，也是最直观的。它意味着 Indexer 将对来自前置节点的处理后的文本块进行索引。
• 问题（Questions）：如果在 Indexer 之前使用了 Transformer 节点来生成“每个文本块可以回答的潜在问题”，那么这些问题可以在这里被索引。在许多场景中，匹配“用户问题”与“预生成的问题”比匹配“问题”与“答案”（即原文）产生的相似度要高得多，从而有效提高检索准确率。
• 增强上下文（Augmented Context）：这涉及使用摘要（Summaries）代替原文进行检索。它适用于需要快速进行广泛主题匹配而不想被原文细节干扰的场景。

将 Ingestion Pipeline 关联到知识库

构建好 Ingestion Pipeline 后，下一步是将其与相应的知识库关联起来。在创建知识库的页面，找到并点击“Ingestion pipeline”选项卡下的“选择流水线”选项。随后，从下拉菜单中选择已创建的 Pipeline 以建立关联。一旦设置，此 Pipeline 将成为该知识库的默认文件解析流程。

对于一个已经创建的知识库，用户可以随时进入其“Ingestion pipeline”模块，重新调整和选择关联的解析流程。

如果用户希望为单个文件调整 Ingestion pipeline，也可以通过点击“解析位置”来进行调整。

最后，在弹出的窗口中进行调整并保存更新。

日志 (Logs)

Ingestion Pipeline 的执行可能需要相当长的时间，因此可观测性是不可或缺的能力。为此，RAGFlow 为 Ingestion Pipeline 提供了日志面板，记录了每个文件解析操作的全链路日志。对于通过 Ingestion Pipeline 解析的文件，用户可以深入了解每个处理节点的操作细节。这为后续的问题审计、流程调试和性能洞察提供了全面的数据支持。

下图是一个步骤日志的示例图。

案例参考

创建 Pipeline 时，您可以选择“Chunk Summary”模板作为构建的基础，当然您也可以选择其他模板作为后续构建的起点。

“Chunk Summary”模板的编排设计如下：

接下来，将 Transformer 节点中的大模型切换为您希望使用的模型，并将“结果目标”字段设置为“元数据”。此配置意味着大模型对文本块的处理结果（如摘要）将直接存储在文件的元数据中，为后续的精确检索和过滤提供能力支持。

点击右上角的“运行”并上传文件以测试流水线。

您可以点击“查看结果”来检查测试运行的结果。

总结

以上内容全面介绍了当前 Ingestion Pipeline 的使用方法和核心能力。展望未来，RAGFlow 将在数据导入和解析的清晰度方面持续演进，包括以下具体增强：

1. 扩展数据源支持：除了本地文件上传，我们将逐步集成各种数据源，如 S3、云存储、电子邮件、在线笔记等。通过自动和手动同步机制，我们将实现数据无缝导入知识库，并自动应用 Ingestion Pipeline 完成文档解析。
2. 增强解析能力：我们将在 Parser 算子中集成更多文档解析模型，如 Docling，以覆盖不同垂直领域的解析需求，全面提升文档信息提取的质量和准确性。
3. 开放自定义切片功能：除了内置的 Chunker 类型，我们将逐步开放底层的切片能力，允许用户编写自定义切片逻辑，实现更灵活可控的文本组织。
4. 加强语义增强的扩展性：在现有总结、关键词提取和问题生成能力的基础上，我们将以可编程的方式进一步支持可定制的语义增强策略，为用户提供更多优化检索和排序的技术手段。

通过这些增强，RAGFlow 将不断提升检索准确率，为向大模型提供高质量上下文提供坚实支持。

最后，感谢您的关注与支持。欢迎您在 GitHub 上为 RAGFlow 点亮星星，与我们共同见证大模型技术的持续演进！

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