深入解读 RAGFlow：构建可用于生产的 RAG 应用

您有多少次做出一个在几份干净 PDF 上表现完美的 RAG 演示，却无法回答任何来自真实企业文档的问题？

现实情况是：表格被“压扁”、扫描页找不到、幻灯片失去标题层级、分块逻辑把章节标题和正文拆开。一个可用于生产的 RAG 系统远不止是一个带向量数据库的 LLM。它需要文档解析、分块策略、混合检索、重排序、引文跟踪、智能体编排，以及半打其他需要您亲自配置的组件。

RAGFlow 是一个将这些组件整合到同一栈中的开源平台。它在同一个 UI 和 API 背后处理深度文档解析、基于模板的分块、混合检索、智能体工作流和 MCP 集成，这意味着您可以把时间花在知识库本身，而非其他琐事。

本文将带您了解 RAGFlow 的底层原理、架构、与 LangChain 和 LlamaIndex 的对比，以及如何部署它。

如果您需要回顾 RAG 的工作机制，欢迎参加我们的Retrieval Augmented Generation (RAG) with LangChain 课程——一个下午就能掌握基础。

什么是 RAGFlow？

RAGFlow 是由 InfiniFlow 构建的开源 RAG 引擎，于 2024 年 4 月以 Apache 2.0 许可发布。

它面向检索质量决定应用成败的生产级 AI 应用。该项目聚焦于深度文档理解，把解析和分块视为一切的基础。如果您的 PDF、电子表格和幻灯片一团糟，再强的重排序或更大的 LLM 都无济于事——必须先解决文档质量问题。

与多数 RAG 工具不同，RAGFlow 是一整套完整栈。您在一个系统中即可获得文档解析、基于模板的分块、混合检索、重排序、引文跟踪、智能体工作流构建器与 MCP 支持。您无需再挑选向量数据库、配置解析器、接入重排序器并在其上自建 UI——这些都在同一个 Web 界面和 API 背后就绪。

这使得 RAGFlow 更像一个平台，而非框架。

RAGFlow 的工作原理

RAGFlow 遵循标准的 RAG 流水线，但每一步都是可配置的组件，而不是需要您亲自编写的代码。

从您上传文档到 LLM 返回答案，流程如下：

1. 摄取文档： 您上传文件或连接数据源。RAGFlow 支持 PDF、Word、Excel、PowerPoint、Markdown、HTML、图片和扫描件。从 v0.25 起，还可从 Confluence、S3、Notion、Discord 和 Google Drive 同步数据。
2. 解析与结构化内容： DeepDoc 引擎通过 OCR、表格结构识别和版面识别读取每个文件。输出是带有标题、表格、图形与阅读顺序等元数据的结构化内容。
3. 生成嵌入： RAGFlow 将每个分块送入您在配置中选择的嵌入模型。您可以使用 OpenAI、Cohere、Voyage、本地模型或其他受支持的模型。
4. 索引知识： 分块与向量进入文档引擎。默认使用 Elasticsearch，但您也可切换至 Infinity（InfiniFlow 为混合搜索打造的自有数据库）。
5. 检索相关上下文： 查询到来时，RAGFlow 同时运行向量搜索、BM25 关键词搜索与重排序。您将获得附带指向源文档引文的顶级分块。
6. 使用 LLM 生成回答： 检索到的分块进入提示词，LLM 生成答案，RAGFlow 附上引文，便于用户将每条结论追溯到来源段落。

流程顺序并不新颖。关键在于每一步都是可配置的平台组件，且您可以在每个阶段检查输出。

RAGFlow 架构

RAGFlow 的架构由四层组成，每一层解决 RAG 流水线中的特定问题。下面是一个快速的可视化概览：

RAGFlow 架构可视化

接下来逐层说明。

文档摄取

这是入口。RAGFlow 接受 PDF、Word、Excel、PowerPoint 等 Office 文档、Markdown 文件和网页。由于内置 OCR，也支持扫描件与图片。

您可以通过 UI 直接上传、连接云端数据源，或通过 API 推送文档。摄取层会先将一切规范化为通用格式，再进入下一阶段。

知识处理

这一层由 DeepDoc 发挥作用。

解析将原始文件转化为带有标题、段落、表格与图形的结构化内容。分块会基于您选择的模板（General、Paper、Book、Q&A、Manual、Table 或 Naive）将内容切分为检索单元。元数据抽取会为每个分块附加上下文，例如页码、章节标题与页面位置。

该层输出的分块保留结构。这意味着表格仍是表格、标题仍与其章节同在、图注仍与图形绑定。不再像传统 RAG 分块那样“随机”。

检索引擎

检索引擎运行在 Elasticsearch 或 Infinity 之上，具体取决于您配置的文档引擎。

它会并行执行三类搜索：

• 向量搜索，用于语义相似度
• BM25 关键词搜索，用于精确词匹配
• 重排序 覆盖合并结果，将最相关分块推至前列

该层输出少量高质量分块，进入 LLM 提示词。

LLM 层

LLM 层会把检索到的分块发送至您已连接的任意模型——OpenAI、DeepSeek、Gemini、Claude、本地 Ollama 模型，或 RAGFlow 支持的其他模型。

响应会附带引文。答案中的每条陈述都指向一个特定分块，而每个分块又指向源文档中的具体位置。这就是 RAGFlow 所称的“有据可依的回答”——用户可点击引文查看对应原文段落，从而轻松甄别幻觉。

这四层以流水线协作：摄取馈入知识处理，知识处理馈入检索引擎，检索引擎再馈入 LLM 层。

RAGFlow 的关键特性

以下这些特性，在您需要处理真实而凌乱的文档时尤为重要。

高级文档解析

RAGFlow 的解析器名为DeepDoc，也是这个平台存在的核心原因。

DeepDoc 会在每份文档上运行三种视觉模型：用于文本抽取的 OCR、用于表格结构识别的 TSR，以及用于文档版面识别的 DLR。因此它不是把 PDF 当作字符流处理，而是像人一样“阅读”——知道表格在哪、栏分隔在哪里、哪些是标题、哪些是脚注。

这种结构会传递到分块中。表格与其表头保留、多栏版面按正确顺序读取、图形保留图注。

如果您尝试过手动实现，就会知道在多文档类型与规模化场景下把这一步做好的难度。

混合检索

仅靠语义搜索往往会错过那些“精确词很重要”的查询；仅靠关键词搜索又会错过“语义相关但表述不同”的查询。

RAGFlow 同时运行二者：

• 向量搜索 捕捉语义匹配——“revenue” 能找到 “sales” 与 “income”
• 关键词搜索 捕捉精确匹配——产品代码或法律术语即使嵌入模型不理解，也能命中
• 重排序 结合两者结果并用专门模型重新排序，确保前列分块确实最相关

工作流构建器

工作流构建器是一个可视化画布，您在其上配置流水线而非编写代码。

您可以将组件拖拽到画布上——检索、重排、LLM、代码执行、HTTP 调用、迭代、分支——并连接成流程。RAGFlow 提供常见模式的预置模板，如“Retrieve - Rerank - Answer”、深度研究、数据分析等。

对于以非工程师为主的团队，这是他们在一周内做出可用原型的方式。

智能体支持

自 v0.20 起，RAGFlow 在与常规工作流相同的画布上支持完整的智能体工作流。

智能体组件可以规划、反思、调用工具并委派子智能体。您配置提示词与工具列表，智能体在运行时自行决定调用什么工具以及顺序。工具可以是内置组件、您连接的 MCP 服务器或其他智能体。

价值在于对检索知识进行推理。

例如，一个支持智能体可以从知识库检索、调用外部 API 查询工单状态，并决定是否升级处理——这一切都在同一流程中完成，且来自文档的部分会附带引文。

文档解析与知识抽取

检索质量源于解析质量。如果这一步做错，再强的重排序或更大的 LLM 也帮不上忙。

多数 RAG 失败发生在文档层面——例如充满表格的 PDF 被抽取成逗号分隔值，或者幻灯片失去其视觉层级。当这些分块进入向量数据库时，已毫无价值。

RAGFlow 的做法是把解析当作一等公民问题来解决。

表格

表格是文档解析中最难的部分。标准 PDF 解析器会逐行读取表格，将其变为一串没有表头的数字流，从而丢失结构。

DeepDoc 在分块前运行表格结构识别（TSR）。它识别表格边界、表头行、列以及单元格关系。分块器切分文档时，表格与其表头保持完整，每一行都保留其上下文。

图片与扫描件

DeepDoc 使用 OCR 从扫描页提取文本，并且从 v0.19 起，还可以借助多模态视觉语言模型理解 PDF 与 DOCX 文件中的图像。

这意味着示意图、图表或收据照片都能转化为可检索内容。

多栏版面

学术论文与财报常用多栏版式。朴素解析器按从左到右逐行读取，会把多栏内容混在一起，生成毫无意义的文本。

DeepDoc 先用文档版面识别（DLR）确定阅读顺序。它知道第 1 栏先于第 2 栏，且标题可能跨越两栏。

元数据

每个分块都携带元数据，如页码、章节标题、页面位置以及来源文件。

这使得引文成为可能。当 LLM 引用某段内容时，RAGFlow 能精确指回源文档的页面与位置。它也支持分块级过滤——您可以只在特定章节或特定文档内检索。

分块质量

最后一环是分块本身。RAGFlow 采用基于模板的分块，这意味着您选择与文档类型匹配的模板（General、Paper、Book、Q&A、Manual、Table 或 Naive）。

不同模板会应用不同的切分规则。Paper 模板会将摘要、方法、结果分别保留为独立单元；Q&A 模板会让每个问答对保持在一起；Manual 模板会遵循标题与步骤。以此类推。

结果是“自洽”的分块。把它们加入 LLM 上下文窗口时，便足以支撑回答问题。

RAGFlow 中的检索

当文档完成解析与分块后，检索步骤将决定 LLM 是否能看到正确的上下文。RAGFlow 的检索引擎由三部分协同工作。

向量检索

向量搜索负责捕捉语义相似。您用同一模型对查询与各分块进行嵌入，检索引擎返回与查询向量“最近”的分块。

这使得搜索“revenue growth”时，即使没有出现对应词，也能找到关于“sales increase”的分块。RAGFlow 允许您选择嵌入模型——OpenAI、Cohere、Voyage、BGE 或本地模型——并且无需重建整个系统即可更换。

混合搜索

向量搜索并不擅长处理精确术语。例如产品代码或法律引用可能缺乏强语义信号，但精确字符串匹配却非常关键。

RAGFlow 将 BM25 关键词搜索与向量搜索并行运行并合并结果。这样同一查询既拥有嵌入的语义召回，也具备关键词匹配的精确度。

重排序

首轮检索会给出候选集——通常是前 30 或 50 个分块。这对于 LLM 的上下文窗口来说太多了，并且前列往往夹杂噪声。

重排序会读取查询与每个分块，对候选进行重新排序。它判断的是“与查询相关”，而非仅“相似”。重排后的前 5 或 10 个分块才会进入提示词。

上下文选择

最后一步是决定哪些内容进入 LLM 的上下文。RAGFlow 允许设置分块数量、相似度阈值和最低重排序分数。

您还可以使用高级选项，如 RAPTOR（用于多跳问题的分层摘要）或长上下文 RAG（自动生成文档级目录，为 LLM 提供“地图”）。这些选项适用于扁平分块检索不够用的场景。

检索引擎的核心目标是只给 LLM 提供“恰到好处”的上下文。

RAGFlow 与传统 RAG 流水线

传统 RAG 流水线由独立工具拼装而成。您要选择解析器（Unstructured、LlamaParse、PyMuPDF）、分块器（LangChain 文本分割器、自定义代码）、嵌入模型、向量数据库（Pinecone、Weaviate、Chroma、Qdrant）、重排序器（Cohere、BGE）、LLM 客户端与 UI，然后编写整合它们的代码。

这种方式控制力最强，但工程投入巨大。

每个集成点都是需要规划、编写、测试与维护的代码。想要增加引文跟踪，就得自己实现。某个组件 API 变更了，也需要您来修管道。

RAGFlow 采取相反路径。

它是一个集成平台，解析、分块、检索、重排序、引文、工作流编排与 Web UI 开箱即用。您通过 Web 界面配置，而非写代码，且各组件已连通。

代价是灵活性。如果您要更换一种全新的分块算法或研究用的重排序器，需在 RAGFlow 的插件模型内工作，而不是随意写 Python。对大多数生产用例来说这没问题，但在实验场景下会显得受限。

差异总结如下：

两种方式并无绝对优劣。如果您有足够工程时间且需要完全掌控，传统流水线更合适；如果您想专注于知识库本身，RAGFlow 会更快。

RAGFlow 与 LangChain、LlamaIndex

若您开始考虑 RAGFlow，很可能也听过 LangChain 与 LlamaIndex。下面进行对比。

LangChain

LangChain 是用于 LLM 应用的应用框架。其主要职责是编排，把提示、工具、记忆与模型串联成工作流。LangChain 并不太关心您的文档如何解析或检索如何搭建，它更关注检索之后发生的事。

如果您的项目以智能体为主——工具调用、多步推理、分支逻辑、人类参与——LangChain（及其状态机层 LangGraph）是多数团队的选择。

LlamaIndex

LlamaIndex 是面向 LLM 的数据框架，聚焦数据摄取、构建多种索引并进行高质量查询。它提供 160+ 数据连接器、多种索引类型（向量、关键词、树、知识图谱），以及合理的分块与检索默认设置。

如果您的项目以检索为主——文档量大、深度搜索需求强、数据源多样——LlamaIndex 是最强的代码优先选择。

RAGFlow

RAGFlow 是一个集成的 RAG 平台。它不是一个导入到 Python 的库，而是一个需要部署的系统。解析、分块、检索、重排序、引文、工作流、智能体与 Web UI 一应俱全。

如果您的优先目标是在无需从零编写流水线代码的情况下，让凌乱文档上的生产级 RAG 系统尽快运行，RAGFlow 是最快路径。

三者也可混合使用。常见模式是：用 LlamaIndex 做摄取，用 LangChain 或 LangGraph 做智能体编排；当您想要完整、自托管的一体化栈而不是手写代码时，用 RAGFlow。

简要回顾：

用 RAGFlow 构建 RAG 应用

当 RAGFlow 运行起来后，构建 RAG 应用遵循五步流程。同样，您无需编写流水线代码，只需通过 UI 或 API 配置每一步。

摄取文档

首先上传文档。您可以通过 Web UI 添加文件、连接 Google Drive、S3、Notion、Confluence 或 Discord 等数据源，或通过 API 添加文件。

文档摄取示例

RAGFlow 支持大多数常见格式，因此您无需事先转换。

配置知识库

RAGFlow 中的知识库是文档、分块与设置的容器。您选择与文档类型匹配的分块模板（混合内容用 General，科研用 Paper，技术文档用 Manual，工单支持用 Q&A 等），选择嵌入模型，并选择解析器。

知识库配置

请牢记该步骤很重要，合适的模板选择能避免后续大量问题。

选择检索策略

接着决定检索方式。设置返回的顶级分块数量、相似度阈值，以及是否使用混合搜索或仅向量搜索。您也可以开启重排序并选择重排序模型。

在高级场景中，RAGFlow 支持用于分层摘要的 RAPTOR，以及用于基于实体检索的知识图谱。可在知识库配置中启用。

连接 LLM

RAGFlow 不内置 LLM，需您自备——OpenAI、DeepSeek、Gemini、Claude、通过 Ollama 的本地模型，或其他受支持模型。

模型选项

在设置中添加 API 密钥，选择模型并设置系统提示词即可。

测试回答

最后一步是测试。RAGFlow 提供聊天界面，您可以查询知识库并查看附带引文的答案。

点击任意引文，即可定位到源文档中高亮的位置与分块。

多数团队会循环几次才让答案可用。这对任何 RAG 系统都属正常，但在 RAGFlow 中，您是在 UI 里改设置，而不是重写 Python 代码。

聊天配置示例

RAGFlow 的生产实践

RAGFlow 在生产中常用于一组特定场景，多为那些对文档质量与引文追溯尤为看重的用例。

企业知识库

大型企业有成千上万份文档分散在共享盘、Confluence、SharePoint，以及邮件附件里的 PDF 中。员工通常找不到所需内容，直接问 LLM 又容易产生幻觉。

RAGFlow 非常适合这种场景。

陈旧的 PDF、扫描的政策文档、带数据透视表的 Excel、几年前的 PPT——都能解析。借助引文，法务与合规团队可以信任答案；借助 Web UI，非工程师也能维护知识库。

客户支持助手

支持团队有多年的工单、FAQ、产品手册与内部手册。支持助手需要在这些内容中搜索、找到正确段落，并知道何时升级处理。

RAGFlow 的 Q&A 分块模板正是为此而生。您把历史工单给它，它会将每个问答对视为一个检索单元。如果再叠加智能体层、连接订单查询 API，就能让助手处理常规问题，并为棘手问题提供完整上下文。

内部文档搜索

工程团队的运行手册、架构文档、事故复盘与 API 参考散落在 Notion、Confluence 与 GitHub。Grep 对关键词有效，但对“上次这个告警触发时我们如何处理？”这类问题无能为力。

RAGFlow 提供对全量语料的语义搜索，并可回溯至来源引文。工程师一键即可获得原文段落与原始页面链接。

研究助手

研究团队处理论文、专利、报告与内部实验。RAGFlow 的“深度研究”模板专为此设计，具备带链式思维的多轮检索：智能体会拆解问题、检索答案片段并进行综合。

在金融、法律与医药研究中，能将每条结论追溯至来源，是助手可用的前提。

这些用例的共同点是：文档处理是难点。如果您的资料干净简单，多数 RAG 工具都可胜任；若资料凌乱且结构化程度高，RAGFlow 的解析层往往比从零写流水线走得更远。

部署 RAGFlow

RAGFlow 提供三种部署路径。如下所示。

Docker 部署

Docker Compose 是主要方式。克隆仓库，进入 docker 目录，运行 docker compose up -d。这会启动 RAGFlow 服务器以及 Elasticsearch、MinIO、MySQL 与 Redis。

最低规格为 4 核 CPU、16 GB 内存、50 GB 磁盘。实际中，若处理大规模文档集合，建议更多内存，因为 Elasticsearch 与 Infinity 都较吃内存。

Docker 镜像面向 x86。若您使用 Apple Silicon 或其他 ARM64 机器，虽然翻译层可运行，但为更佳性能，建议按照 RAGFlow 文档中的 ARM64 指南自行构建镜像。

本地开发

若您希望修改 RAGFlow 源码，可从源代码运行后端与前端。使用 uv 管理 Python 依赖，运行 docker compose -f docker/docker-compose-base.yml up -d 启动支撑服务（MinIO、Elasticsearch、MySQL、Redis），然后用脚本启动后端，前端用 npm run dev。

此路径仅在参与项目贡献或调试时才值得采用。对多数用户而言，Docker Compose 更快。

云部署

InfiniFlow 在 cloud.ragflow.io 提供托管版本。免费层每月包含 5 个应用与 500 积分，付费层为 $29、$129 以及企业定价。

云版本适合原型与小团队。对于严肃生产与敏感数据场景，多数团队选择在自有基础设施上自托管：小规模部署用单台 VM，大规模则用 Kubernetes 与 Helm Chart。

扩展性考量

RAGFlow 的默认部署将所有组件跑在同一台机器上。这在一定规模内可行，但之后会遇到文档数量、查询负载或团队规模的瓶颈。

可独立扩展的组件包括文档引擎（Elasticsearch 或 Infinity）、对象存储（MinIO）与 RAGFlow 应用本身。更大规模时，需将这些服务拆分至多台机器，使用托管的 Elasticsearch 或兼容 S3 的对象存储，并在负载均衡后运行多个 RAGFlow 实例。

另一个可探索方向是为 DeepDoc 启用 GPU 加速。解析默认很吃 CPU，但在配置中启用 GPU 模式后，大批量文档摄取的速度会有明显提升。

其他都是常规基础设施工作，RAGFlow 并不会妨碍这些实践。

RAGFlow 的优劣与取舍

每个工具都有取舍，RAGFlow 也不例外。使用前需了解以下几点。

优势

• 一体化平台： 无需挑选解析器、向量数据库、重排序器、分块器与 UI 框架并自行写代码，RAGFlow 全部自带。
• 文档处理能力最强： DeepDoc 比多数替代方案更擅长处理 PDF、扫描件、表格与复杂版面。若您的文档凌乱，这一点往往已足够成为选择 RAGFlow 的理由。
• 天生面向生产： 有据可依的引文、分块可视化、智能体工作流、MCP 支持与完善的管理 UI 均内置。
• Apache 2.0 开源： 您可以自托管、修改代码，并在自有基础设施上运行。GitHub 仓库有 80k+ star、活跃开发，项目短期内不会消失。

局限

• 部署没看上去那么简单： 虽然有 Docker Compose，但您仍需和应用一起运行 Elasticsearch 或 Infinity、MinIO、MySQL 与 Redis。迟早会遇到问题，您需要足够的 Docker 知识来修复。
• 基础设施要求： 最低 16 GB 内存与 4 核 CPU 仅适合小负载。真实部署往往需要 32 GB 以上，尤其在使用 Infinity 或大规模摄取时。在 $5 的 VPS 上跑 RAGFlow 基本不可行。
• 学习曲线： 工作流构建器功能强大，但组件众多；选择合适的分块模板与检索设置需要时间。您需要几天来熟悉，之后才能高效产出。

若 RAGFlow 符合您的用例，上述都不是无法接受的缺点。可以将其视为“使用平台而非库”的成本。

谁该使用 RAGFlow？

RAGFlow 并不适合所有项目。以下为其最佳受众与不太合适的人群。

最佳匹配

构建生产级 RAG 的 AI 工程师。 如果您的工作是做出可用的 RAG 应用，而不是再写一个分块库，RAGFlow 能省去大部分管道工作。

企业级 AI 团队。 法务、合规、财务与支持团队需要引文与可追溯性，且让非工程师可用的 UI 也是加分项。

处理复杂文档的开发者。 充满表格的 PDF、扫描件、多栏布局与混合格式，正是 DeepDoc 胜出的场景。若您的素材不是干净纯文本，RAGFlow 的解析质量难以匹敌。

拥有大型文档集合的组织。 一旦文档量过千，就需要能规模化摄取、索引与搜索的系统。RAGFlow 正适合此类任务。

不那么理想

简单的聊天机器人原型。 只需回答几份 Markdown 文件的问题时，RAGFlow 过于重型。LlamaIndex 脚本或简单 LangChain 流水线更快。

非常小的项目。 针对几份 PDF 的个人问答，基础设施成本过高。您会把更多时间花在 Docker 命令上，而不是项目本身。

希望零配置上手的团队。 如果您想 5 分钟注册即用一个 RAG，托管服务或轻量库更合适。RAGFlow 有云版本，但自托管（其价值所在）需要一定配置工作。

简单法则：若“在复杂文档上的检索质量”是项目难点，RAGFlow 值得投入；若不是，请选更轻的方案。

结语

RAGFlow 是一个在真实文档之上构建生产级 RAG 应用的全栈平台。

其最大优势在于：文档处理、检索、重排序与生成在同一工作流中完成，而非由多个工具拼接。您可在同一个 UI 与 API 背后使用 DeepDoc 解析、混合检索、有据可依的引文与智能体工作流。

如果您的文档凌乱且检索质量至关重要，RAGFlow 值得这点部署成本。

从云端免费层或本地 Docker 部署开始，先上传几份“最糟糕”的文档，看看返回的答案。这是判断是否适配您用例的最快方式。

RAG 架构本身简单，但并不妨碍它适配复杂用例。阅读我们的Advanced RAG Techniques 博文，了解稠密检索、重排序与多步推理。