ragflow

RAGFlow：让大模型真正读懂你的文档

一、项目背景：从"大海捞针"到精准检索

想象一下，你的企业知识库里有成千上万份合同、技术文档、用户手册。当业务人员向 AI 助手提问"这份合同里的违约金条款是什么"时，传统做法是直接把整个知识库塞给大模型——结果要么上下文超限，要么模型根本找不到关键段落，答非所问。

RAGFlow 正是为了解决这个痛点而生。它由开源向量数据库公司 Infiniflow 开发，2023 年 12 月正式开源，迅速成为 RAG（检索增强生成）领域的标杆项目。截至 2026 年 5 月，已斩获超过 81,000 颗 GitHub Stars，位列全球 AI 开源项目前 30，Fork 数超过 9,200，是目前最活跃的 RAG 引擎之一。

项目背后站着 Infiniflow 这家专注于 AI 推理优化的公司，核心团队来自字节跳动、微软等大厂，拥有深厚的搜索和 NLP 积累。RAGFlow 的诞生源自团队在实际业务中发现：当时市面上的 RAG 方案普遍存在"分块质量差、检索精度低、幻觉严重"的问题，而 RAGFlow 要做的，就是把这三个痛点逐一击破。

二、技术架构：深度文档理解 + Agent 驱动的 RAG 流水线

RAGFlow 的核心技术优势建立在"深度文档理解"之上。与传统 RAG 系统直接将文本按固定长度切块不同，RAGFlow 集成了 DeepDoc 组件，能够识别文档的物理结构——段落层级、表格、标题、列表、图表标题——从而生成语义连贯、逻辑完整的高质量文本块。

这种"智能分块"策略直接决定了检索质量的上限。具体来说，系统支持多种分块模板：

• 语义分块：按自然段落和逻辑结构切分，适合长文章
• 标题树分块：以标题层级为依据，保持上下文连贯性
• 表格分块：将表格作为独立单元处理，避免跨行拆分
• 图表分块：提取图表标题和注释，与图表内容配对存储

在检索侧，RAGFlow 支持多路召回 + 融合重排策略。系统可以同时调用多种向量检索方法（稠密向量 + 稀疏向量），将召回结果合并后再通过重排序模型（Re-ranking）排序，最终将最相关的 Top-K 片段提供给大模型。从架构图可以看到，整个系统分为前端展示层（React）、后端 API 层（Python/Go）、核心推理层（DeepDoc + Agent）和存储层（Elasticsearch/Infinity + MySQL + Redis + MinIO），模块之间解耦清晰，便于扩展和定制。

Agent 能力是 RAGFlow 0.8 版本之后的重点方向。系统内置了可编排的 Agent 工作流，支持多轮对话、工具调用（代码执行、搜索、数据库查询）、记忆管理（MCP 协议支持），开发者可以基于预置模板快速构建复杂的 RAG Agent。2025 年 8 月还新增了 MCP（Model Context Protocol）支持，进一步拓宽了与外部工具生态的集成。

三、核心功能：从上传到回答的全链路体验

RAGFlow 提供了一整套开箱即用的 RAG 能力：

多格式文档支持：Word、PDF、Excel、PPT、扫描件、图片、网页、结构化数据等，通过深度文档理解引擎统一解析，无需手动预处理。

可视化分块预览：上传文档后，用户可以在 Web 界面上实时查看分块结果，手动调整合并或拆分，介入质量控制——这是大多数开源 RAG 工具缺失的能力。

配置化 LLM 和 Embedding：支持接入 OpenAI、Anthropic、DeepSeek、Qwen、Gemini 等主流大模型，以及 BGE、M3E、OpenAI Embedding 等 embedding 模型，通过 service_conf.yaml 灵活配置。

RAG 流水线编排：从文档解析 → 分块 → 向量化 → 检索 → 重排 → 生成，全流程可视化配置，支持自定义预处理和后处理逻辑。

Agent 工作流：支持构建带记忆的对话 Agent，集成代码执行沙箱（gVisor 隔离）、外部 API 调用、Google Drive/Confluence/S3/Notion 数据同步等功能。2025 年底还新增了 Memory 模块，让 Agent 具备跨会话的长期记忆能力。

四、部署体验：Docker 一键启动，生产级就绪

RAGFlow 的部署体验在同类开源项目中属于上乘。官方提供预构建 Docker 镜像（约 2GB），只需四步即可启动：

1. 确保 vm.max_map_count >= 262144（Elasticsearch 依赖）
2. git clone https://github.com/infiniflow/ragflow.git
3. cd ragflow/docker && docker compose -f docker-compose.yml up -d
4. 访问 http://IP_OF_YOUR_MACHINE，配置 LLM API Key

系统默认使用 CPU 执行 DeepDoc 文档解析任务。如需 GPU 加速，只需要在 docker/.env 中添加 DEVICE=gpu 即可。存储后端默认使用 Elasticsearch，但也支持切换到 Infiniflow 自研的 Infinity 向量数据库，在性能和资源占用上更优。

开发者模式也做了充分考虑：后端通过 uv sync 管理 Python 依赖，launch_backend_service.sh 启动；前端通过 npm install && npm run dev 在 5173 端口热重载开发。依赖服务（MySQL、Redis、MinIO、Elasticsearch）统一由 docker-compose-base.yml 管理，无需手动安装。

对于 Kubernetes 环境，官方在 helm/ 目录下提供了 Helm Chart，支持在生产 K8s 集群中部署。

五、技术栈全景

层次	技术选型
前端	React + TypeScript + Vite
后端 API	Python（FastAPI）+ Go（核心推理）
向量检索	Elasticsearch / Infinity
关系数据库	MySQL
缓存	Redis
对象存储	MinIO（S3 兼容）
沙箱隔离	gVisor（代码执行）
文档解析	DeepDoc（自研）
容器化	Docker + Docker Compose + Helm

Python 侧通过 pyproject.toml 管理依赖（uv 支持），Go 侧通过 go.mod 管理，代码库分为 api/（FastAPI 服务）、agent/（Agent 逻辑）、rag/（RAG 核心）、deepdoc/（文档理解）、web/（前端）五大模块，职责清晰。

六、局限与挑战：光环之下的暗面

没有任何项目是完美的，RAGFlow 也不例外：

预构建镜像仅支持 x86 平台：ARM64 用户（如 Apple Silicon Mac）需要从源码自行构建 Docker 镜像，增加了上手门槛。

文档解析深度依赖 DeepDoc：对于非标准格式的文档（如扫描件、复杂表格），DeepDoc 的解析质量仍有波动，可能需要人工审核分块结果。

大量 Open Issues：截至 2026 年 5 月，项目有超过 3,000 个 open issues，说明社区活跃的同时，功能完善度和 bug 修复速度仍面临压力。

资源占用较高：完整的 docker-compose 部署包含 MySQL、ES、Redis、MinIO、后端、前端等 10+ 个容器，对机器配置要求不低，不适合资源受限的环境。

Agent 沙箱依赖 gVisor：代码执行能力需要额外安装 gVisor，增加了可选功能配置的复杂度。

七、行业意义：RAG 赛道的领跑者

RAGFlow 的出现重新定义了"开源 RAG 引擎"的标准。它不只是提供一个向量检索库，而是提供了从文档解析、检索排序到 Agent 编排的端到端解决方案，大幅降低了企业构建知识库 AI 的门槛。

从增长曲线看，项目从 0 到 5 万 Stars 仅用了约 18 个月，增长速度在同类项目中名列前茅。2025 年以来持续高频更新（支持 DeepSeek v4、Gemini 3 Pro、MCP 协议、GPT-5 等），说明团队保持着旺盛的开发节奏。

更重要的是，RAGFlow 带动了"深度文档理解"这一细分方向的发展——越来越多的开源项目开始借鉴其分块策略和 Agent 编排思路。在 RAG 技术从"能用"走向"好用"的过程中，RAGFlow 扮演了关键推动者的角色。

---

适合人群：需要构建企业知识库 RAG 系统的开发者、数据团队负责人、对 Agent 能力有需求的 AI 应用工程师。

不推荐场景：资源极度受限的边缘设备部署、对 ARM64 有强依赖的环境（需自行编译镜像）。