RAGFlow

RAGFlow 是由中国 AI 基础设施公司 InfiniFlow 打造的一款开源、端到端的检索增强生成（RAG）引擎。它于 2024 年 4 月 1 日在 Apache 2.0 协议下开源，并已发展成为 GitHub 上最受关注的 AI 基础设施项目之一，截至 2026 年 4 月已获得 79.6k 颗星。与 Haystack 或 LlamaIndex 等框架库不同，RAGFlow 作为一个完整的可部署系统发布：包含文档摄取流水线、分块引擎、向量与全文搜索、LLM 集成、Web UI 以及智能体编排层，所有这些都集成在一个 Docker 部署中。其决定性的技术差异化优势在于 DeepDoc，这是一个内部研发的文档解析子系统，它使用微调的 YOLOv8 布局识别模型、OCR 和表格结构识别技术，在 RAG 开始之前从复杂的企业 PDF 中提取准确的结构化数据。

该平台支持混合搜索，结合了稠密向量检索、BM25 全文搜索和基于张量的重排，通过 InfiniFlow 自家的 Infinity 数据库或可选的 Elasticsearch 9.x 提供支持。截至 v0.25.1（2026 年 4 月 30 日），RAGFlow 已经远远超越了其最初的文档 RAG 定位：它包含一个带有 MCP 集成的智能体工作流构建器、多智能体流水线、用户级记忆存储、语音 I/O、连接到 Confluence、Google Drive、Notion、S3、GitHub、Slack、DingTalk 和 RSS 订阅的数据源连接器，以及智能体流内的沙盒代码执行功能。它支持主流 LLM，包括 GPT-5、DeepSeek v4、Gemini 3 Pro、Claude，以及通过 Ollama 和 Xinference 运行的本地模型。诸如带有来源高亮的带引用、可追溯答案，以及可视化的分块检查 UI 等功能，解决了破坏大多数原生 RAG 实现的“垃圾进，垃圾出”问题。

2026 年 5 月 RAGFlow 的实际功能

RAGFlow 的架构以三层流水线为中心：ETL、检索和生成。ETL 层是 RAGFlow 与更简单的技术栈区分最明显的地方。文档进入系统并穿过 DeepDoc：布局分析识别给定区域是标题、段落、表格、图像还是脚注；OCR 处理扫描文档；表格结构识别保留了标准 PDF 解析器通常会折叠成纯文本的行/列/标题关系。结果是一个语义丰富的分块集合，它保留了文档结构，而不仅仅是原始字符串。

分块模板可按文档类型进行配置。RAGFlow 内置了针对通用文本、问答、学术论文、法律文件、会计文档、人力资源手册和代码的预构建模板，每种模板都应用了适合该格式的启发式规则。用户可以在索引之前在 UI 中直观地检查分块，从而能够在解析错误影响检索质量之前将其捕获。父子分块（在 v0.23.0 中添加）实现了粗粒度检索与细粒度答案生成，减轻了困扰原生分块检索方法的上下文窗口压力。

在检索方面，混合搜索同时运行向量相似度、BM25 关键词匹配和张量重排，并具有可配置的分数权重。基于图的检索（GraphRAG 和 RAPTOR 集成）可用于知识图谱风格的查询。答案包含固定到源文档、页面和分块的内联引用，降低了幻觉风险并使结果具有可审计性。

智能体层在 v0.20.0（2025 年 8 月）进行了大幅重构，支持拖拽式工作流构建、Webhook 触发器、多智能体协调、跨会话记忆（v0.25.0 中添加了用户级记忆存储），以及 2026 年引入的 MCP 工具集成。Agentic RAG 意味着智能体可以决定查询哪些知识库、何时调用外部 API，以及如何将多源结果综合成连贯的响应。

“布局识别模型令人印象深刻。我在一些具有挑战性的表格上对其进行了测试，在这种场景下它的表现优于 AWS Textract。它看起来像是 YOLOv8 的微调版本。” - mpeg，Hacker News，2024 年 4 月

RAGFlow 与 Haystack 和 Dify 的定位对比

deepset 开发的 Haystack 是一个用于在代码中构建 RAG 流水线的 Python 框架。它提供了检索器（Retrievers）、生成器（Generators）、阅读器（Readers）等组件。开发人员使用 Python 将这些组件组合成流水线，从而获得了 RAGFlow UI 优先方法无法比拟的架构控制力。Haystack 没有内置文档解析神经网络模型；团队需要自带解析器（如 PyMuPDF、unstructured 等）。Haystack 在受监管的行业（The Economist、Oxford University Press 以及多个政府机构在生产环境中使用它）表现出色，在这些行业中，代码级可审计性和自定义流水线逻辑是不可妥协的。RAGFlow 相对于 Haystack 的优势在于开箱即用的完整性：无需组装流水线，DeepDoc 自动处理复杂的布局，并且产品自带完整的 UI。Haystack 的优势在于可组合性以及与现有软件栈深度集成的能力。

Dify 是一个更广泛的 AI 应用平台。RAG 只是 Dify 中的一个模块，而不是其核心定位。Dify 的文档处理使用标准的分块策略，没有专用的布局识别神经网络模型，这对于干净的文本文档效果很好，但对于具有复杂表格结构、混合列或嵌入图像的 PDF，效果会下降。Dify 的用户群是希望快速构建由 LLM 驱动的应用程序的产品团队：聊天机器人、工作流自动化和 AI 应用程序。RAGFlow 的用户群是那些首要问题是从杂乱的企业文档中可靠地提取信息的团队。这两个工具可以是互补的：RAGFlow 作为文档知识层，Dify 作为其上的应用层。Quivr 则占据了一个更简单的自托管位置，它以牺牲企业文档保真度为代价来换取部署的简易性。

与针对个人用户和小型团队、在标准分块之上提供简单封装的 AnythingLLM 相比，RAGFlow 属于不同层级的产品。AnythingLLM 是个人生产力工具。而 RAGFlow 是为拥有数千份文档，并对来源引用、访问控制和大规模检索准确性有要求的组织提供的基础设施。

自托管的实际情况

RAGFlow 通过 Docker Compose 运行。最低要求是 4 核以上的 CPU 和 16GB RAM，尽管 FAQ 本身指出，如果“与其他服务共享硬件，16GB 可能会很紧张”。实际部署通常需要 32GB。Docker 镜像从下载大小解压后在磁盘上约占 7GB。该技术栈至少运行两个数据库（Elasticsearch 或 Infinity，加上 Redis 和 MinIO）、一个文档解析工作节点和主应用程序，使其成为开源 RAG 类别中较重的自托管 AI 部署之一。

文档摄取期间的性能故意比简单的分块器慢。FAQ 直接承认了这一点：“文档解析比 LangChain 等一些竞争对手花费的时间更长，因为 RAGFlow 在文档预处理任务（如布局分析、表格结构识别和使用视觉模型的 OCR）上投入了大量精力。”对于文档质量比摄取速度更重要的用例，这种权衡是值得的。但对于快速批量加载干净的文本文档，这种开销就很难证明其合理性了。

“混合使用多个 PDF 解析器且没有明确的默认设置是一个危险信号。pypdf2 并不适合复杂的布局。” - mpeg，Hacker News，2024 年 4 月

智能体层在 2025 年 8 月的 v0.20.0 中引入了一项重大的破坏性变更：早期版本的所有智能体在升级后都需要完全重建。配置了生产智能体的团队不得不重做这项工作。InfiniFlow 清楚地记录了这一变更，但这反映了活跃的开发节奏与生产稳定性期望之间持续存在的紧张关系。

RAGFlow 用户经常遇到的挫折

文档解析期间的内存使用是报告最多的基础设施问题。GitHub Issue #11822（提交于 2025 年）描述了在解析 5MB PDF 时，即使有 62GB RAM 也会出现内存耗尽的情况。一个相关问题（#8490）显示，一台 16 核、128GB RAM 的服务器在同时解析四个文件时冻结。根本原因是 DeepDoc 处理期间 PyPDF 存在内存泄漏，InfiniFlow 承认并跟踪了该问题，但截至 v0.25.1 尚未完全解决。对于基础设施受限的团队来说，这是一个真正的阻碍。

多语言文档处理存在边缘情况，特别是对于带有特殊字符的语言。处理德语文档的用户指出，解析过程中可能会丢失变音符号，并且即使源文档是其他语言，自动生成的问题也默认使用英语。这些都是可以解决的变通方法，但它们需要工程投入，而产品声称的多语言支持并未完全做到开箱即用。

直到 2024 年底，开发和生产镜像配置之间的 Docker 文档差距仍给新用户造成了持续的困扰。一个 GitHub Issue 将此与暗黑模式失效、Linux x64 上的 Infinity 集成困难以及分块编辑窗口检索错误一起进行了记录。该项目快速的发布节奏（大约每两周发布一次）意味着错误会很快浮现并得到修复，但也意味着任何特定版本都可能引入新的边缘情况。

RAGFlow 是为谁构建的

对于拥有杂乱、复杂文档语料库的企业团队来说，RAGFlow 是正确的选择。摄取带有条款表格的合同 PDF 的律师事务所、查询收益报告的金融分析师、将维护手册构建到知识库中的制造公司，以及在 Confluence 和 S3 上构建内部帮助台的 IT 团队，都是天作之合。如果您的文档是干净的 Markdown 文件或没有表格的简单 PDF，那么 RAGFlow 的 DeepDoc 流水线就大材小用了。请使用更轻量级的技术栈。

它是为有本地部署或私有云要求的组织构建的。Apache 2.0 协议允许不受限制的商业使用和修改，完全自托管的部署意味着没有数据会离开您的基础设施。对于数据驻留是合规要求的受监管行业来说，这比设置的简易性更重要。

如果您的单个工具基础设施预算低于 32GB RAM，如果您的团队需要一个可以组合到现有代码库中的 Python 库（请选择 Haystack 或 LlamaIndex），或者如果您正在基于小型文档集构建一个简单的聊天机器人且不需要企业级解析，请跳过 RAGFlow。如果您的团队无法容忍版本之间偶尔出现的破坏性变更，或者如果您需要具有明确的定价和 SLA 的供应商支持的 SaaS，也请跳过它。

RAGFlow 确实非常适合它所设计的解决的问题：在文档质量成为难题时使 RAG 变得可靠。79.6k 的 GitHub 星数以及 GitHub 2025 Octoverse 将其评为按贡献者参与度计算增长最快的 AI 基础设施项目，反映了它在已经触及更简单 RAG 技术栈极限的开发者和企业社区中获得了真正的吸引力。让它运行并保持稳定需要工程投入，但对于那些文档准确性决定了 AI 产品是有用还是不可靠的团队来说，这种投入是值得的。