RAGFlow 是 infiniflow 开源的 RAG（Retrieval-Augmented Generation，检索增强生成）引擎。它的目标不是只做一个“上传文件然后问答”的知识库外壳，而是把文档解析、切分、检索、重排、引用溯源、模型配置、Agent 能力和 API 集成放进一套完整工作流里。

如果你正在做企业知识库、文档问答、客服助手、内部资料检索，或者想给 LLM 加一层更可靠的上下文来源，RAGFlow 属于值得重点看的开源方案。

01 RAGFlow 解决什么问题

普通 RAG 系统最容易遇到的问题有三个：

1. 文档解析质量不稳定，尤其是 PDF、扫描件、表格、图片、复杂排版文档。
2. 切分策略不透明，命中结果看起来像“搜到了”，但上下文并不完整。
3. 回答缺少可靠引用，用户很难判断答案来自哪里。

RAGFlow 的重点正好放在这些地方。项目 README 里强调了 Deep document understanding、模板化切分、可视化 chunk、引用溯源和多路召回加重排。换句话说，它更关注“高质量数据进入，高质量答案出来”，而不是只把向量数据库和聊天框接起来。

02 核心功能

1. 深度文档理解

RAGFlow 支持从复杂格式的非结构化数据中抽取知识。README 中列出的数据类型包括 Word、PPT、Excel、TXT、图片、扫描件、结构化数据、网页等。

这对企业知识库很关键。真实资料通常不是干净的 Markdown，而是合同、报告、表格、扫描 PDF、产品手册、截图和网页混在一起。如果解析质量不够，后面的向量检索和 LLM 回答都会被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的价值在于：切分策略不是黑盒，可以根据文档类型选择更合适的方式。

例如普通文章、论文、表格、问答文档、图片说明、合同条款，对 chunk 的粒度和边界要求都不一样。模板化切分可以减少“句子被切碎”“表格上下文丢失”“标题和正文分离”这类问题。

3. 可追溯引用

RAGFlow 强调 grounded citations，也就是回答要能追溯到来源片段。它还提供 chunk 可视化，方便人工干预解析和切分结果。

这点对生产环境尤其重要。企业内部问答不是只要“看起来像答案”，还要能查证来源。对于政策、合规、财务、技术文档、客户支持资料来说，引用和溯源几乎是刚需。

4. 自动化 RAG 工作流

RAGFlow 把 RAG 流程做成相对完整的链路：

• 创建知识库
• 上传或同步数据
• 解析文档
• 查看和干预 chunk
• 配置 LLM 与 embedding 模型
• 执行多路召回与重排
• 构建聊天助手
• 通过 API 集成到业务系统

这让它更像一个 RAG 平台，而不是一个单点库。对于团队来说，UI、可视化和 API 都有价值：非研发人员可以维护知识库，研发人员可以把能力接入已有系统。

5. Agent、MCP 与工作流能力

RAGFlow 的近期更新里已经包含 Agentic workflow、MCP、Agent Memory、代码执行组件等内容。这说明它不只想做传统知识库问答，也在向 Agent 场景延伸。

典型方向是：Agent 在执行任务时，可以把 RAGFlow 作为可靠的企业知识上下文层；需要查资料时从知识库召回，生成回答时保留引用，必要时再组合工具调用或工作流。

03 基本使用流程

按照官方快速开始文档，RAGFlow 的常见使用路径可以概括为下面几步。

1. 准备运行环境

官方 README 给出的基础要求是：

• CPU >= 4 cores
• RAM >= 16 GB
• Disk >= 50 GB
• Docker >= 24.0.0
• Docker Compose >= v2.26.1

如果要使用代码执行器的沙箱功能，还需要 gVisor。另外要注意，官方 Docker 镜像主要面向 x86 平台；如果是 ARM64，需要按官方说明自行构建镜像。

2. 拉取项目

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 检查 vm.max_map_count

RAGFlow 部署会依赖 Elasticsearch / OpenSearch 这类组件，因此 Linux 上通常需要确认：

1

sysctl vm.max_map_count

如果数值低于 262144，可以临时设置：

1

sudo sysctl -w vm.max_map_count=262144

如果希望重启后仍然生效，需要写入 /etc/sysctl.conf。

4. 使用 Docker Compose 启动

CPU 模式可以直接启动：

1

docker compose -f docker-compose.yml up -d

如果要用 GPU 加速 DeepDoc 任务，README 中给出的方式是在 .env 中启用 DEVICE=gpu 后再启动：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

启动后查看日志：

1

docker logs -f docker-ragflow-cpu-1

看到服务启动完成后，再通过浏览器访问服务器地址。默认配置下，通常可以直接访问：

1

http://IP_OF_YOUR_MACHINE

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中选择默认 LLM factory，并更新对应的 API_KEY。

实际使用时，你需要根据自己的模型供应商配置：

• 聊天模型
• embedding 模型
• rerank 模型
• 多模态模型（如果要理解 PDF / DOCX 中的图片）

6. 创建知识库并上传文档

服务启动后，典型操作是：

1. 登录 Web UI。
2. 创建 dataset / knowledge base。
3. 上传文档或配置数据源同步。
4. 等待解析完成。
5. 查看 chunk 结果，必要时人工调整。
6. 创建聊天助手，选择知识库。
7. 测试问答效果和引用来源。

如果要接入业务系统，可以继续使用 RAGFlow 的 API 或 SDK，把知识库检索和聊天能力接到自己的应用里。

04 适合哪些场景

RAGFlow 适合这些需求：

• 企业内部知识库问答
• 产品手册、技术文档、FAQ 检索
• 客服助手和售前支持助手
• 合同、报告、制度文件的可追溯问答
• 多格式资料统一整理
• 需要 UI 维护知识库，同时又要 API 集成的团队
• 想把 RAG 能力作为 Agent 上下文层的系统

它尤其适合文档格式复杂、需要引用溯源、希望人工干预解析结果的场景。

05 使用时要注意什么

第一，RAGFlow 不是轻量脚本。它对机器资源有要求，官方建议至少 4 核 CPU、16GB 内存和 50GB 磁盘。如果只是给少量 Markdown 做问答，可能没必要上这么完整的平台。

第二，文档质量仍然重要。RAGFlow 能改善解析和切分，但不能让低质量、过期、互相矛盾的资料自动变得可靠。真正上线前，知识库治理仍然要做。

第三，模型配置会直接影响效果。embedding、rerank、聊天模型、多模态模型的选择，都会影响召回和回答质量。RAGFlow 提供了工作流，但效果仍然要靠数据、模型和参数一起调。

第四，生产环境要关注权限和数据安全。企业知识库里往往有内部资料，部署方式、访问控制、日志、API Key、模型供应商数据策略都要提前设计。

06 简短判断

RAGFlow 的优势在于把 RAG 里最麻烦的部分做成了平台化能力：复杂文档解析、可解释切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 扩展。

如果你要做的是可验证、可维护、可接入业务系统的企业知识库，RAGFlow 比“向量库 + 简单聊天 UI”的方案更完整。反过来，如果只是个人小规模资料问答，或者数据格式非常简单，轻量 RAG 框架可能更省资源。

相关链接

• GitHub 项目：https://github.com/infiniflow/ragflow
• 官方文档：https://ragflow.io/docs/dev/
• 在线 Demo：https://cloud.ragflow.io