[知识库/向量存算] RAGFlow : 基于深度文档理解构建的开源 RAG 引擎

1 概述

产品介绍

• RAGFlow 是一款领先的开源 检索增强生成（Retrieval-Augmented Generation, RAG）引擎，由 InfiniFlow 团队开发维护。它将前沿的 RAG 技术与智能体（Agent）能力深度融合，为大语言模型（LLM）构建了一个高质量的上下文层。

作为一款基于深度文档理解构建的开源 RAG引擎，可以为各种规模的企业及个人提供一套精简的 RAG 工作流程，结合大语言模型（LLM）针对用户各类不同的复杂格式数据提供可靠的问答以及有理有据的引用。

RAGflow的核心在于其检索增强型生成算法，这一算法不仅提升了生成内容的准确性，还增强了语言模型生成结果的可靠性。

• 其核心定位是解决企业级知识库问答中的关键痛点：如何让 LLM 准确、可控地从非结构化文档中检索信息并生成可信回答。

• URL

  • https://ragflow.io
  • https://github.com/infiniflow/ragflow
  • 在线体验 (Cloud): https://cloud.ragflow.io
  • 文档: https://ragflow.io/docs/dev/

• 许可协议: Apache 2.0

团队背景：InfiniFlow

团队概览

• InfiniFlow（中文名：英飞流）是一家 AI 基础设施服务商，核心产品包括开源 RAG 引擎 RAGFlow 和 AI 原生数据库 Infinity。下面把团队背景与所属国家梳理清楚。

核心结论：InfiniFlow 是中国公司，核心运营主体位于上海。

• 国内主体：英飞流（上海）信息科技有限公司，法定代表人张颖峰，2023 年 6 月 5 日成立，注册资本 150 万人民币，注册地址位于中国（上海）自由贸易试验区张衡路 200 号 2 幢 3 层。
• 出海架构：2025 年完成架构重组，以红筹方式在香港落地控股主体，为更大规模的出海商业化做准备。
• 海外关联实体：InfiniFlow LLC，注册地为美国内华达州拉斯维加斯（1810 E Sahara Ave Ste 212, Las Vegas, NV 89104）——这是海外/红筹相关安排的载体，不应据此判定 InfiniFlow 是美国公司。
• 融资情况：天使轮由晨晖创投、希扬资本等投资；Pre-A 轮由创新工场、北极光创投合计数百万美元投资；2025 年 4 月完成 A 轮，投资方为创新工场。

---

核心成员：张颖峰（Zhang Yingfeng）—— 联合创始人 & CEO

• 籍贯：甘肃兰州
• 技术底色：连续创业者，技术栈横跨四大领域：
  • 7 年搜索引擎研发
  • 5 年数据库内核研发
  • 10 年云计算基础架构和大数据架构研发
  • 10 年人工智能核心算法研发（广告推荐引擎、计算机视觉、NLP）
• 过往业绩：主导并参与三家大型企业数字化转型，支撑过日活千万、日均两亿动态搜索请求的互联网电商业务
• 产品理念：主张"把做系统的人和做 AI 的人融合在一起去做产品"，认为"开源是商业化的一种策略，为了出海必须开源"

核心成员：金海（Jin Hai）—— 联合创始人

• 教育背景：毕业于上海交通大学
• 技术底色：向量数据库领域的早期建设者
• 职业履历：
  • 曾任 Zilliz 研发负责人，主导 Milvus 1.0 开发——"向量数据库"这个概念某种程度上从那时被做起来
  • 曾任矩阵起源研发副总裁，负责 MatrixOne 开源数据库的设计和研发
  • 现任 InfiniFlow 联合创始人，全面负责 Infinity 和 RAGFlow 的研发与开源工作
• 分工：与张颖峰形成互补——张主外（CEO、商业化、搜索/AI 架构），金主内（产品与技术研发、数据库内核）

其他团队成员

• 根据公开融资材料，InfiniFlow 管理团队还包括 杨希、廖怡然、蔡海梦 等人，但公开渠道对其具体分工与背景披露有限，不再展开

Demo

• 输入的文档

发展历程

时间	里程碑
2023-12-12	项目在 GitHub 上创建
2024 年初	发布首个公开版本，基于 Python 实现
2025-03-19	支持多模态模型，可理解 PDF/DOCX 中的图片
2025-05-23	新增 Python/JavaScript 代码执行器组件（Agent）
2025-08-01	支持 Agentic Workflow 和 MCP（Model Context Protocol）
2025-08-08	支持 OpenAI GPT-5 系列模型
2025-10-15	支持可编排的 Ingest Pipeline
2025-10-23	支持 MinerU & Docling 文档解析方式
2025-11-12	支持数据同步（Confluence、S3、Notion、Discord、Google Drive）
2025-11-19	支持 Gemini 3 Pro
2025-12-26	支持 'Memory' 功能用于 AI Agent
2026-03-24	RAGFlow Skill on OpenClaw — 通过 OpenClaw 访问数据集
2026-04-24	支持 DeepSeek v4
2026-06-15	支持多聊天频道（Feishu、Discord、TG、Line 等）
2026-07+	将后端从 Python 迁移至 Go，性能大幅提升
2026-08-19	发布 v0.27.0：CLI 工具全面重写，Admin Server 功能增强

核心功能

• 深度文档理解（DeepDoc）：基于知识抽取的非结构化数据解析，支持 PDF、DOCX、Excel、PPT、图片、扫描件、网页等数十种格式
• 模板化分块（Template-based Chunking）：智能且可解释的分块策略，提供多种模板选项
• 带引用溯源的回答（Grounded Citations）：可视化文本分块，支持人工干预；关键引用可追溯
• 异构数据源兼容：支持 Word、Slides、Excel、TXT、图片、扫描件、结构化数据、网页等
• 自动化 RAG 工作流：开箱即用的 RAG 编排，支持个人和企业级部署
• 可配置 LLM：兼容 OpenAI、DeepSeek、Qwen、Gemini、Claude、本地模型等
• 多路召回与融合重排序：多个召回策略 + 融合重排序（Rerank）
• Agentic Workflow：可视化拖拽式 Agent 工作流编排，支持代码执行器、MCP 工具调用
• 多聊天频道：支持 Web UI、Feishu、Discord、TG、Line、WhatsApp、DingTalk 等
• 数据同步：支持 Confluence、S3、Notion、Google Drive 自动同步
• CLI 工具：Go 语言编写，支持 Windows/Linux/macOS
• Admin Server：系统管理、模型管理、用户管理

核心优势

1. 「垃圾进，垃圾出」的终结者：DeepDoc 引擎在文档解析精度上显著领先竞品，尤其擅长处理复杂排版、表格、图片
2. 分块策略智能且可解释：模板化分块比纯向量分块更可控，用户可直观理解文档如何被切分
3. 引用溯源机制：每条回答都带原始文档引用和可视化高亮，极大提升可信度
4. Agent + RAG 融合：不仅仅是 RAG 引擎，还能编排 Agent 工作流，执行代码、调用工具
5. 企业级就绪：多租户、RBAC 权限、数据隔离、OAuth 认证、SSO
6. 活跃的开源社区：88K+ Stars、10K+ Forks、2000+ Contributors
7. 多架构支持：CPU/GPU 均可运行，ARM64 也支持
8. 灵活部署：Docker Compose + Docker Swarm 一键部署

主要短板

• 资源消耗较大：默认配置下需要 4 核 CPU、16GB RAM、50GB 磁盘，个人开发者门槛较高
• 中文文档/社区支持仍可加强：虽然项目源于中国团队，但部分文档和社区响应仍需完善
• 部署复杂度：依赖 MySQL、Elasticsearch、Redis、MinIO 等多个中间件，非 Docker 部署较繁琐
• 较新的项目：2023 年底才开始，部分高级功能仍在快速迭代
• Go 迁移过渡期：后端从 Python 迁移至 Go 过程中可能出现 API 不一致或偶发问题

局限性

• 非通用 AI 平台：专注 RAG 和知识库场景，不适合做通用对话机器人或 AI 绘画等
• 深度学习模型依赖：文档解析依赖深度学习模型，GPU 环境下性能更佳
• 大规模并发需额外调优：高并发场景需要调整 Elasticsearch 分片、连接池等参数
• 对中文排版有较高要求：虽然支持中文，但极端复杂的中文排版可能仍有挑战

适用场景

场景	说明
企业知识库问答	将内部文档、手册、规范构建为智能问答系统
智能客服	基于产品文档构建自动化客服机器人
学术/研究辅助	论文检索、文献综述生成、带引用溯源的回答
法律/合规文档审查	法规文档的智能检索与比对
产品说明书智能助手	技术文档、用户手册的智能问答
企业内部数据分析	结合结构化数据 + 非结构化文档的复合查询
Agent 自动化工作流	编排多步骤任务（检索 → 分析 → 生成报告）

同类竞品

项目	Stars	特点	差异点
RAGFlow	88.9K	DeepDoc 深度文档解析、Agent 工作流、引用溯源	文档解析能力最强
LangChain	100K+	通用 LLM 应用框架、工具链丰富	不是开箱即用的 RAG 引擎
QAnything	12K+	阿里通义旗下 RAG 方案	生态绑定阿里云
Dify	60K+	可视化 LLM 应用编排平台	偏对话应用而非文档检索
LlamaIndex	40K+	数据索引框架	偏开发者工具而非企业级产品
MaxKB	12K+	开源知识库问答系统	轻量级但文档解析能力弱
FastGPT	20K+	开源 AI 知识库平台	功能全面但文档解析不如 RAGFlow

发展趋势

• Star 增长：从 2023 年底创建，2 年半内达到 88.9K Stars，增长曲线极陡，2025-2026 年增速显著加快

• Fork 趋势：10.4K Forks，有大量开发者二次开发或贡献

• 贡献者活跃：2000+ 贡献者，核心贡献者 cike8899（1297 commits）、KevinHuSh（1047 commits）、JinHai-CN（545 commits）

• 开发趋势：后端从 Python 迁移至 Go（性能导向），CLI 工具持续完善，Admin Server 能力增强

总结：RAGFlow 从单纯的 RAG 引擎向 「RAG + Agent + 企业级平台」三位一体 高速演进

2 工作原理与架构

概念术语

术语	说明
RAG (检索增强生成)	在 LLM 生成前先从知识库检索相关文档片段作为上下文
DeepDoc	自研深度文档理解引擎，从非结构化文档提取结构化知识
Chunk (分块)	文档切分后的基本检索单元，支持模板化分块策略
Embedding	将文本转换为向量表示，用于语义相似度检索
Rerank (重排序)	对初步检索结果进行二次排序，提升检索精度
Agent / Agentic Workflow	可编排的多步骤 AI 任务流，支持条件判断、循环、工具调用
MCP (Model Context Protocol)	模型上下文协议，LLM 与外部工具交互的标准接口
Knowledge Base / Dataset	知识库概念，一个 Dataset 包含一组文档及其向量索引
Ingest Pipeline	文档从上传到可检索的完整处理流水线
Chunk Method	分块方法（Naive、Q&A、Manual、Knowledge Graph 等）
Parser	文档解析器，针对不同格式有专门引擎
Grounding / Citation	溯源机制，回答中标记引用来源
TF-IDF / BM25	关键词检索算法，与向量检索互补

架构与运行原理

系统架构总览

graph TB subgraph User_Access_Layer["用户接入层"] WEB["Web UI (React/TypeScript)"] CLI["CLI Tool (Go)"] API["RESTful API"] CHAT["聊天频道 飞书 / Discord / TG / Line"] end subgraph Service_Layer["服务层"] NGINX["Nginx API Gateway"] ADMIN["Admin Server (Go, 管理/模型/用户)"] PYP["Python Engine (工作流编排)"] GOENG["Go Engine (高性能API)"] end subgraph Core_Engine_Layer["核心引擎层"] DEEPDOC["DeepDoc 文档解析引擎"] CHUNK["Chunking Engine 分块引擎"] EMBED["Embedding Service 向量化服务"] RERANK["Rerank Service 重排序服务"] AGENT["Agent Engine 工作流引擎"] MCP["MCP Server 工具调用协议"] end subgraph Data_Layer["数据层"] ES["Elasticsearch 全文 + 向量检索"] MYSQL["MySQL 元数据管理"] MINIO["MinIO 对象存储"] REDIS["Redis 缓存"] INF["Infinity 高性能向量引擎"] end WEB --> NGINX CLI --> NGINX API --> NGINX CHAT --> NGINX NGINX --> ADMIN NGINX --> PYP NGINX --> GOENG PYP --> DEEPDOC PYP --> CHUNK PYP --> EMBED PYP --> RERANK PYP --> AGENT AGENT --> MCP DEEPDOC --> MINIO CHUNK --> ES CHUNK --> INF EMBED --> ES EMBED --> INF ADMIN --> MYSQL GOENG --> MYSQL PYP --> REDIS ADMIN --> REDIS

• RAGFlow 整体架构分为四层：

用户接入层：Web UI、CLI 工具、RESTful API、聊天频道（Feishu/Discord/TG/Line）
服务层：API Gateway (Nginx)、Admin Server（管理）、Python Engine（编排）、Go Engine（高性能 API）
核心引擎层：DeepDoc（文档解析）、Chunking Engine（分块）、Embedding Service（向量化）、Rerank Service（重排序）、Agent Engine（工作流）
数据层：Elasticsearch（全文+向量检索）、MySQL（元数据）、MinIO（对象存储）、Redis（缓存）、Infinity（高性能向量引擎）

关键运行原理

1. 文档处理流水线（Ingest Pipeline）

用户上传文档 → DeepDoc 引擎解析（OCR、版面分析、表格识别） → 模板化分块（Naive/Q&A/Manual/KG） → Embedding 向量化 → 写入 Elasticsearch/Infinity 索引

2. 检索-生成流程（Query Pipeline）

用户提问 → Query 分析（重写/扩展） → 混合检索（BM25 + 向量检索） → 多路召回融合 → Rerank 重排序 → 注入 LLM Context → LLM 生成带引用的回答

3. Agent 工作流

可视化拖拽式 Agent 编排，支持：检索组件、代码执行器（Python/JavaScript）、MCP 工具、LLM 组件、条件判断/循环、Switch/Branch 分支路由

4. 灵活的向量数据库支持

引擎	说明
Elasticsearch（默认）	全文检索 + 向量检索，成熟稳定
Infinity	InfiniFlow 自研高性能向量引擎
OceanBase	蚂蚁集团分布式数据库，支持向量检索
OpenSearch	AWS 开源的 ES 分支
GaussianDB / SeafileDB	其它支持的引擎

3 使用指南

安装部署

前置条件

• CPU >= 4 核
• RAM >= 16 GB
• 磁盘 >= 50 GB
• Docker >= 24.0.0 & Docker Compose >= v2.26.1
• Python >= 3.13（如需从源码开发）
• gVisor（如需使用代码执行器沙箱功能）

Docker Compose 快速部署（推荐）

# 1. 克隆仓库
git clone https://github.com/infiniflow/ragflow.git
cd ragflow

# 2. 切换到最新稳定版
git checkout v0.27.0

# 3. 启动（CPU 模式）
docker compose -f docker/docker-compose.yml up -d

# 4. 检查日志
docker logs -f docker-ragflow-cpu-1

# 5. 打开浏览器访问 http://<服务器IP>
#    默认账号: ragflow@infiniflow.com / Infiniflow@2024

GPU 加速: 设置 DEVICE=gpu 环境变量后启动
ARM64: ARM64 设备需从源码构建 Docker 镜像

Windows 部署

1. 安装 Docker Desktop for Windows，确保 WSL2 已启用
2. PowerShell 执行:

git clone https://github.com/infiniflow/ragflow.git
cd ragflow
git checkout v0.27.0
docker compose -f docker/docker-compose.yml up -d

3. 访问 http://localhost

从 v0.27.0 起，Windows 用户可直接使用 ragflow-cli-v0.27.0-windows-amd64.exe CLI

关键操作

配置 LLM 模型: Web UI → 系统管理 → 模型提供商 → 填入 API Key 和 Endpoint
创建知识库: Web UI → 知识库 → 创建数据集 → 选择分块方法 → 上传文档
开始问答: Web UI → 聊天 → 关联知识库 → 开始提问

API 使用示例

# 获取 Token
curl http://localhost:9380/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"ragflow@infiniflow.com","password":"Infiniflow@2024"}'

# 创建知识库
curl http://localhost:9380/api/v1/datasets \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"name":"My KB"}'

# 上传文档
curl http://localhost:9380/api/v1/datasets/<DATASET_ID>/documents \
  -H "Authorization: Bearer <TOKEN>" \
  -F "file=@/path/to/doc.pdf"

# 问答
curl http://localhost:9380/api/v1/chats \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"dataset_ids":["<DATASET_ID>"],"question":"你的问题?"}'

Z FAQ for RAGFlow 进阶面试篇

Q: RAGFlow 与 Dify 的区别？*

• RAGFlow 专注文档深度解析 + RAG + Agent；Dify 偏 LLM 应用编排平台。两者定位互补。

• Dify 的向量知识库的文档解析、Chunk分块等方面确实比较弱。（实际使用体验：20260820）

Q: 上传文档大小限制？

默认单文件上限 1GB，可通过 .env 中的 MAX_CONTENT_LENGTH 调整。

Q: 如何更换向量数据库？

• 修改 docker/.env 中的 DOC_ENGINE 变量（可选 elasticsearch、infinity、oceanbase、opensearch 等），重启容器。

Q: RAGFlow 支持的向量数据库（文档引擎）有哪些？ *

• RAGFlow 中负责向量检索、全文检索和混合排序的组件在官方语境里叫 Doc Engine（文档引擎），通过 docker/.env 中的 DOC_ENGINE 环境变量切换，并由 Docker Compose 的 profile 机制自动拉起对应服务。

官方原生支持的后端

• 截至当前 main 分支（v0.27.0 前后），DOC_ENGINE 的可用选项如下：

选项	说明	默认
elasticsearch	Elasticsearch 8.x，生产级成熟度最高	✅ 默认
infinity	InfiniFlow 自研的 AI 原生数据库，RAGFlow 推荐向量库
opensearch	OpenSearch，ES 的衍生开源版本
oceanbase	OceanBase 文档引擎
seekdb	OceanBase 旗下的 SeekDB
gaussdb	GaussDB 集中式/分布式（Centralized / Distributed）

• 源码层面，RAGFlow 通过统一的 DocStoreConnection 抽象类实现上述五种后端（ES、Infinity、OpenSearch、OceanBase、SeekDB），运行时按 DOC_ENGINE 动态实例化。

官方"推荐"与"仅满足混合检索要求"的两个后端：ES or Infinity

• 虽然配置项有 5–6 个，但 RAGFlow 官方 FAQ 明确表态：

⚠️ "Currently, only Elasticsearch and Infinity meet the hybrid search requirements of RAGFlow. Most open-source vector databases have limited support for full-text search, and sparse embedding is not an alternative to full-text search. Additionally, these vector databases lack critical features essential to RAGFlow, such as phrase search and advanced ranking capabilities. These limitations led us to develop Infinity, the AI-native database, from the ground up."

也就是说，只有 Elasticsearch 和 Infinity 真正满足 RAGFlow 对混合检索（向量 + BM25 全文 + 高级排序）的全部要求。其他几个后端（OpenSearch、OceanBase、SeekDB、GaussDB）虽然在配置里可选，但在混合检索能力的完整度和官方推荐度上都不如前两者。

• 官方对两者的定位差异：

  • Elasticsearch：默认选项，生产可用性验证最充分，BM25 全文索引久经考验，但与 Infinity 相比资源占用更高

  • Infinity：InfiniFlow 自研的 AI 原生数据库，专为 RAG 工作负载优化，支持语义检索和结构化数据，资源占用比 ES 更低，是官方推荐向量数据库

Milvus 是否被支持？不被官方原生支持

• 目前 Milvus 不是 RAGFlow 官方原生支持的文档引擎。

• Milvus 官方文档明确说明：

"RAGFlow currently uses a search engine backend and Infinity as its primary vector database backends, as they are the only open-source systems meeting RAGFlow's hybrid search requirements... Integration with other vector databases like Milvus is an active area of community interest—there is an open feature request for Milvus support on GitHub (issue #7749)"

要将 Milvus 与 RAGFlow 结合，目前可行的两条路：

1. 旁路双写架构：RAGFlow 仍用 ES/Infinity 做主检索，同时把向量数据写到独立的 Milvus 集群，在应用层做结果融合
2. 贡献连接器代码：参照 RAGFlow 的 DocStoreConnection 抽象接口，自行实现 Milvus 连接器——需要注意的是 Milvus 原生缺乏全文检索能力，通常需要配对一个搜索引擎后端来处理 BM25 查询。

网上有一些"RAGFlow 集成 Milvus"的教程（如设置 VECTOR_DB_TYPE: milvus），但这些并非来自 RAGFlow 官方配置体系——官方用的是 DOC_ENGINE 而非 VECTOR_DB_TYPE，且官方 .env 的 DOC_ENGINE 可选项里没有 milvus。这类教程本质上是基于特定 fork 或自研补丁的实践，生产环境使用前需自行评估稳定性。

如何选择？

graph TD A[选择 DOC_ENGINE] --> B{生产环境?} B -->|是| C{资源充足?} B -->|否/测试| D[elasticsearch<br/>默认, 最稳] C -->|是| D C -->|否, 想省资源| E[infinity<br/>官方推荐, 资源占用低] A --> F{必须用某特定向量库?} F -->|Milvus 等| G[官方未原生支持<br/>需旁路架构或自研连接器] F -->|OpenSearch/OceanBase| H[配置可选<br/>但混合检索能力不如 ES/Infinity]

决策建议：

• 绝大多数场景 → elasticsearch（默认，最稳）
• 资源受限或想用 InfiniFlow 生态最佳适配 → infinity（官方推荐向量数据库）
• 企业已统一运维 OpenSearch/OceanBase/GaussDB → 可选对应后端，但需自测混合检索效果
• 必须用 Milvus → 走旁路双写，或等 GitHub issue #7749 官方支持落地

推荐文献

• RAGFlow FAQ - Why not use other open-source vector databases? - ragflow.io 官方 FAQ
• Vector and Search Databases - RAGFlow DeepWiki - 源码级架构解析
• What vector databases does RAGFlow integrate with? - Milvus 官方说明

参考文献

• ragflow/docker/.env at main - 官方环境变量定义，DOC_ENGINE 可选项
• RAGFlow FAQ - 官方关于混合检索要求的说明
• Vector and Search Databases - DeepWiki 源码分析
• Configuration Guide - RAGFlow DeepWiki - 配置体系说明
• What vector databases does RAGFlow integrate with? - Milvus 官方参考
• Is data processing like building with lego? - RAGFlow 官方博客，提及支持 Infinity/Elasticsearch/OpenSearch

Q: RAGFlow 的向量数据库更换为 Milvus 的可行性？*

⚠️ 先给结论：

截至当前 RAGFlow 官方 main 分支（v0.26.x），RAGFlow 官方 Docker 编排并未将 Milvus 作为一等公民的内置【向量存储后端】>。官方 docker/.env 和 docker-compose.yml 主要围绕 Elasticsearch / Infinity + MySQL + MinIO + Redis 进行编排，service_conf.yaml.template 中可见 es、infinity、oceanbase 等配置段，但没有 milvus 配置块。

Milvus 官方文档也明确指出：RAGFlow 目前主要以 search engine backend 和 Infinity 作为主向量数据库后端，Milvus 支持是一个活跃的社区需求（GitHub issue #7749），集成需要额外的连接器代码。

因此，"改为 Milvus"这条路要分两种场景来看：

场景判断：需要的是哪种"改"？

场景	可行性	推荐度
A. 生产环境直接用 Milvus 完全替换	官方未原生支持，需自研连接器	不推荐
B. 在支持该配置的版本/分支中通过【环境变量】切换	社区有成功实践	⚠️ 仅测试/特定版本
C. 保留官方 Infinity/ES，额外用 Milvus 做旁路向量检索	应用层双写	✅ 可行但复杂

💡 官方推荐：RAGFlow 的检索质量依赖于全文检索（BM25）+ 向量相似度 + 高级排序的统一索引，这是 Elasticsearch 和 Infinity 才能满足的混合检索要求。Milvus 原生不擅长全文检索，强行替换会导致混合检索能力退化。

方案 B 操作步骤（社区验证版，适用于暴露了 Milvus 配置项的版本）

如果你使用的 RAGFlow 版本/分支确实暴露了 VECTOR_DB_TYPE=milvus 配置（社区有多个成功案例），可按以下流程操作：

第一步：前置条件核对

版本兼容性矩阵（社区实测）：

RAGFlow 版本	Milvus 版本	pymilvus
≥ v1.2.0	2.4.x	≥ 2.4.0
≥ v1.3.5	2.5.x	≥ 2.5.1

⚠️ 当前官方 main 分支的 RAGFLOW_IMAGE 默认为 v0.26.4，并未在官方 .env 中声明 VECTOR_DB_TYPE 变量。如果你的版本 .env 里找不到这个变量，说明该版本不支持一键切换，请直接看方案 C 或打消替换念头。

第二步：部署独立 Milvus 服务

在 docker-compose.yml 中新增 Milvus 服务：

services:
  milvus:
    image: milvusdb/milvus:v2.5.3
    ports:
      - "19530:19530"
    volumes:
      - milvus_data:/var/lib/milvus
      - milvus_conf:/etc/milvus
    environment:
      ETCD_ENDPOINTS: etcd:2379
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9091/healthz"]
      interval: 30s
      timeout: 10s
      retries: 5

  etcd:
    image: quay.io/coreos/etcd:v3.5.14
    environment:
      - ETCD_AUTO_COMPACTION_MODE=periodic
      - ETCD_AUTO_COMPACTION_RETENTION=1h
    volumes:
      - etcd_data:/etcd

volumes:
  milvus_data:
  milvus_conf:
  etcd_data:

第三步：修改 RAGFlow 服务环境变量

在 docker-compose.yml 的 ragflow 服务下添加：

services:
  ragflow:
    environment:
      # ↓↓↓ 关键配置 ↓↓↓
      VECTOR_DB_TYPE: "milvus"
      MILVUS_HOST: "milvus"
      MILVUS_PORT: "19530"
      MILVUS_USER: "admin"
      MILVUS_PASSWORD: "SecureP@ss123!"
      # ↑↑↑ 关键配置 ↑↑↑
    depends_on:
      - milvus
      # 注意：如果改用 Milvus，原先的 es01 依赖可根据需要移除或保留

第四步：创建 Milvus 专用账户

docker exec -it milvus-prod bash
milvus-cli --user root --password milvusroot
CREATE USER 'admin' IDENTIFIED BY 'SecureP@ss123!';
GRANT ALL ON *.* TO admin;

第五步：重启并验证

docker compose down
docker compose up -d
docker logs -f docker-ragflow-cpu-1

看到 RAGFlow 正常启动横幅，且无 Milvus 连接报错，即切换成功。

第六步：网络连通性测试（关键排查点）

在 RAGFlow 容器内执行：

docker exec -it ragflow_container bash
curl -v telnet://milvus:19530
nc -zv milvus 19530

切换后的三大坑（必读）

坑 1：混合检索能力退化

RAGFlow 的检索质量依赖于全文检索（BM25）+ 向量相似度 + 高级排序的统一索引。Milvus 原生擅长向量检索，但全文检索能力弱。集成 Milvus 时，通常需要：

• 将 BM25 查询路由到 search engine backend
• 将向量查询委托给 Milvus
• 在应用层做结果融合（如 Weighted Reciprocal Rank Fusion）

这意味着你得到的检索质量会低于官方默认的 Infinity/ES 方案。

坑 2：Embedding 维度必须严格匹配

Milvus 集合的向量维度必须与 Embedding 模型输出维度完全一致：

Embedding 模型	维度
BAAI/bge-large-zh-v1.5	1024
BAAI/bge-base-en-v1.5	768
all-MiniLM-L6-v2	384
text-embedding-ada-002	1536

维度不匹配会导致数据插入失败。

坑 3：已有知识库数据需重建

从 Elasticsearch/Infinity 迁移到 Milvus 不是透明切换——原有向量数据无法直接迁移，需要：

1. 从原向量库导出数据（如从 Chroma 导出）：

from chromadb.api import ClientAPI
client = ClientAPI()
collections = client.list_collections()
for col in collections:
    data = col.get(include=["embeddings", "metadatas"])
    # 保存到文件

1. 重新上传文档到 RAGFlow，让 RAGFlow 向 Milvus 写入新数据
2. 或者编写迁移脚本，直接用 pymilvus 写入（需严格匹配 RAGFlow 的 schema）

方案 C：生产环境推荐做法

如果你确实需要用 Milvus（比如公司统一运维要求），更稳妥的架构是：

graph TD A[RAGFlow 主服务] --> B[Infinity/ES<br/>官方支持的混合检索引擎] A -.旁路.-> C[Milvus 集群<br/>大规模向量检索] C --> D[应用层融合结果]

即：RAGFlow 仍用官方支持的 Infinity 或 ES 做主检索，同时将数据双写到 Milvus 用于其他业务场景的大规模向量检索。这样既不破坏 RAGFlow 的检索质量，又能享受 Milvus 的横向扩展能力。

决策建议

• 个人/测试/中小团队：直接用官方默认的 Infinity，不要换 Milvus。Infinity 是 InfiniFlow 自研、专为 RAG 优化的引擎，支持语义检索和结构化数据，是 RAGFlow 的推荐向量数据库。
• 公司强制统一向量库：评估方案 C（旁路双写），或参与社区 issue #7749 推动官方原生支持。
• 海量数据（TB 级）+ 分布式需求：Infinity 也有分布式能力，优先考虑横向扩展 Infinity，而非换成 Milvus。

💡 Milvus 官方文档明确说明：将 Milvus 与 RAGFlow 集成需要连接器代码来转换 RAGFlow 的查询语义到 Milvus API，并处理原生全文检索的缺失问题。在官方原生支持落地前，生产环境请慎重。

推荐文献

• RAGFlow GitHub 仓库 docker 目录 - 官方 docker 编排与 .env 配置
• RAGFlow 集成 Milvus 向量库操作指南 - 社区实践，含版本兼容性矩阵
• What vector databases does RAGFlow integrate with? - Milvus 官方说明 RAGFlow 当前向量库支持状态

参考文献

• infiniflow/ragflow docker/.env - 官方环境变量定义
• infiniflow/ragflow docker/service_conf.yaml.template - 官方服务配置模板
• RAGFlow 集成 Milvus 向量库操作指南 - 社区部署实践
• What vector databases does RAGFlow integrate with? - Milvus 官方参考
• RAGFlow VPS 部署教程 - 含 DOC_ENGINE 切换说明
• RAGFlow 安装与运行全流程指南 - 百度智能云教程

Q: 请简述 RAGFlow 是什么？它和普通 RAG 框架（如 LangChain）的本质区别？*

A: RAGFlow 是一款基于深度文档理解（DeepDoc）构建的开源 RAG 引擎，由 InfiniFlow 团队主导开发，结合 LLM 能为各种复杂格式数据提供可靠的、带引文溯源的问答能力。

与普通 RAG 框架的本质差异在三个层面：

• 文档理解优先级不同：LangChain / LlamaIndex 等框架把 PDF 当作"文本流"处理，固定长度切片；RAGFlow 把"文档理解"前置到切片之前，用 DeepDoc 先做版面分析 + OCR + 表格结构识别，再进行模板化分块。
• 分块可控可解释：RAGFlow 提供 General / Paper / Book / Q&A / Manual / Table / Naive 等多种分块模板，分块边界可视化、可人工调整；普通框架的分块是黑盒。
• 答案有据可查：RAGFlow 的每条回答都带引文快照，可点击跳转到原文确切位置，最大程度降低幻觉。

💡 定位总结：RAGFlow = DeepDoc 深度解析 + 模板化分块 + 多路召回 + 有引文生成的 RAG 引擎，而非通用 LLM 应用框架。

Q: RAGFlow 的系统架构分为哪几层？各层职责是什么？*

A: RAGFlow 采用四层管道架构，每层解决 RAG 流水线中的一个具体问题：

graph LR A[Document Ingestion<br/>多源数据接入] --> B[Knowledge Processing<br/>DeepDoc解析+模板分块] B --> C[Retrieval Engine<br/>向量+BM25+重排] C --> D[LLM Layer<br/>外接大模型生成带引文答案]

1. Document Ingestion（文档接入层）：接受 PDF、Office、Markdown、网页、图片等，归一化为通用格式。
2. Knowledge Processing（知识处理层）：DeepDoc 执行 OCR + TSR（表格结构识别）+ DLR（版面识别），按所选模板切分为 chunk，附加页码、标题、版面位置等元数据。
3. Retrieval Engine（检索引擎层）：构建在 Elasticsearch 或 Infinity 之上，并行执行【向量检索】 + 【BM25 关键词检索】，融合后再经 Rerank 模型重排。
4. LLM Layer（大模型层）：把 Top-K chunk 送给外接 LLM，生成的答案每条 claim 都带引文，可点击溯源。

底层依赖 PostgreSQL（元数据）、Redis（任务队列）、ES / Infinity（向量+倒排）、MinIO（对象存储）。

Q: 什么是 DeepDoc？它的三大视觉模型分别解决什么问题？*

A: DeepDoc 是 RAGFlow 的文档解析内核，运行三类视觉模型，让机器"像人一样读文档"：

• OCR（光学字符识别）：从扫描件、图片、影印件中提取文本，支持多语言多字体。
• TSR（Table Structure Recognition，表格结构识别）：识别表格的行列结构、表头、单元格合并关系，把表格转为保留结构的文本块——这是 RAGFlow 区别于普通 RAG 的核心差异化能力。
• DLR（Document Layout Recognition，版面识别）：识别标题、段落、图注、页眉页脚等版面元素，保证多栏排版按正确顺序读取。

⚠️ 面试加分点：DeepDoc 让"表格不被切断、标题与正文不分离、图注与图片不脱节"，这是传统固定长度切片做不到的。

Q: RAGFlow 的模板化分块有哪些类型？General 和 Naive 的区别是什么？*

A: RAGFlow 提供多种分块模板，核心包括：

模板	适用文档	分块逻辑
General	混合内容、默认选择	标题感知切分，尊重段落边界，含 OCR
Naive	纯文本、简单文档	固定 token 窗口 + 重叠，无 OCR
Paper	学术论文 PDF	摘要/章节/参考文献感知
Book	长篇文档、手册	章/节层级保留
Q&A	FAQ、问答对	一个问答对 = 一个 chunk
Table	表格、CSV、XLSX	行级粒度
Resume	HR 简历	实体感知（姓名、技能、日期）

• General vs Naive 的实战差异：一份含季度指标表的 PDF——

  • 用 General：表格作为完整结构化 chunk传递给 LLM，列标题和行标签都保留。

  • 用 Naive：同一张表可能被从中间切断，数字失去列上下文，语义不完整。

建议：大多数场景 General 是正确默认；语料主要是学术 PDF 时切到 Paper；处理 FAQ 导出时用 Q&A。

Q: 什么是父子分块（Parent-Child Chunking）？它解决了什么检索痛点？*

A: 父子分块机制在 v0.25.0 引入，其核心思想是：

• 父块（Parent Chunk）：大的语义单元（段落、章节），语义完整。
• 子块（Child Chunk）：小的、精确的子单元，被索引用于检索。

工作流程：查询匹配到子块 → 系统返回更广的父块上下文给 LLM。

解决的痛点：传统 RAG 的常见失败模式——"检索到了相关句子，但因缺乏周边上下文，答案不完整"。父子分块让检索精确性与上下文完整性两者兼得。

graph TD Q[用户查询] --> R[检索匹配子块] R --> P[返回父块完整上下文] P --> L[LLM 生成完整答案]

Q: RAGFlow 的检索机制是怎样的？为什么要用"多路召回 + 重排"？*

A: RAGFlow 的检索引擎会并行执行3种检索：

1. Vector Search（向量检索）：捕获语义匹配——"revenue" 能找到 "sales" 和 "income"。
2. BM25 关键词检索（∈全文检索）：捕获精确匹配——产品编码、法律术语即使 embedding 模型语义上不理解也能命中。
3. Rerank 重排：对合并结果用专用重排模型重新排序，把最相关的 chunk 推到顶端。

• 为什么要多路召回：单一向量检索在"精确词很重要"的查询上会 miss；单一关键词检索在"语义相近但措辞不同"的查询上会 miss。两者互补 + 重排，才能在真实业务文档上拿到高精度的 Top-K。

Q: RAGFlow 如何"最大程度降低幻觉"？引文机制是如何实现的？*

A: RAGFlow 通过两层机制降低幻觉：

第1层： grounded answers（有据答案）

• 每个回答的每条 claim 都指向具体的 chunk
• 每个 chunk 都指向源文档的具体位置（页码、坐标）
• 用户点击引文即可看到原文确切段落，幻觉易于核查

第2层：可视化切片 + 人工干预

• 文本切片过程可视化，支持手动调整边界
• 答案提供关键引用的快照、并支持追根溯源

💡 面试视角：RAGFlow 的"降幻觉"不是靠 prompt 技巧，而是靠架构级的引文溯源——让 LLM 的每句话都可被审计。

Q: RAGFlow 部署的硬件要求和平台限制是什么？ARM 平台能跑吗？*

A: 最低硬件要求：

资源	要求
CPU	≥ 4 核（x86 架构）
内存	≥ 16 GB
磁盘	≥ 50 GB
Docker	≥ 24.0.0
Docker Compose	≥ v2.26.1

平台限制（高频考点）：

• 官方仅维护和提供 x86 架构的预构建 Docker 镜像
• ARM64 平台（Apple Silicon Mac、树莓派、鲲鹏）无法直接拉取官方镜像，必须按官方文档自行构建 Docker 镜像
• GPU 加速仅支持 Nvidia GPU（通过设置 DEVICE=gpu 启用）

其他部署要点：

• 需设置 vm.max_map_count ≥ 262144（ES 需要）
• Docker 镜像下载约 2GB（压缩），解压后约 7GB
• 默认 HTTP 端口 80，API 服务端口 9380
• RAGFlow 只是 RAG 引擎，必须外接 LLM 才能问答；支持 OpenAI、DeepSeek、通义千问、Ollama、Xinference、LocalAI 等

Q: 如何通过 API / SDK 集成 RAGFlow？给出一个最小可运行的代码示例 *

A: RAGFlow 提供 Python SDK（ragflow-sdk）、RESTful API、OpenAI 兼容接口三种集成方式。

最小闭环示例（Python SDK）：

from ragflow_sdk import RAGFlow

# 连接本地 RAGFlow 实例（注意 API 端口是 9380）
rag = RAGFlow(
    api_key="<YOUR_API_KEY>",       # Web UI 的 Settings → API 中获取
    base_url="http://localhost:9380"
)

# 1. 创建知识库（General 模板）
dataset = rag.create_dataset(
    name="quick_start_kb",
    chunk_method="general",
    embedding_model="BAAI/bge-large-zh-v1.5"
)

# 2. 上传 PDF 文档（异步解析）
with open("sample.pdf", "rb") as f:
    dataset.upload_documents([{"name": "sample.pdf", "blob": f.read()}])

# 3. 创建聊天助手并绑定数据集
assistant = rag.create_chat(name="doc_qa", dataset_ids=[dataset.id])

# 4. 发起会话并提问
session = assistant.create_session()
response = session.ask(question="这份文档的主要内容是什么？")
print(response.content)

⚠️ 面试踩坑提示：

• 上传后解析是异步的，需等待解析完成再提问
• Web 端口是 80，但 SDK/API 端口是 9380，别搞混
• 必须先配好 LLM 的 API Key 和 System Model Settings，否则无法生成答案

Q: RAGFlow 在生产落地中有哪些主要短板？如何做生产级调优？*

A: 主要短板：

• 资源消耗较大：CPU ≥ 4 核、内存 ≥ 16 GB、磁盘 ≥ 50 GB 是最低要求，生产环境建议 32GB+ 内存
• x86 绑定：官方仅维护 x86 镜像，ARM 平台需自行构建
• 镜像体积大：解压后约 7GB，加上 ES/Redis/Milvus 等依赖容器，磁盘占用显著
• 配置链路长：LLM API Key、Embedding 模型、系统默认模型都需手动配置
• 本身是引擎不是 LLM：必须外接模型服务

生产级调优方向：

1. 分块策略调优：根据文档类型选对模板；对超长文档开启父子分块
2. 检索调优：向量 + BM25 + Rerank 三路并行；根据业务调整 Top-K 和 Rerank 阈值
3. 模型选型：Chat 模型按业务选 DeepSeek / GPT / 通义千问；Embedding 用 BAAI/bge 系列
4. 资源规划：生产环境建议 32GB+ 内存、100GB+ SSD、Nvidia GPU 加速 DeepDoc
5. Ingestion Pipeline：v0.21.0 引入的可视化 ETL，可接入 MinerU、Docling 等外部解析模型

Z FAQ for RAGFlow 部署与基础使用

Q: RAGFlow 的定价如何？

开源版完全免费。官方云服务（cloud.ragflow.io）有免费额度。企业版提供额外功能。

Q: RAGFlow 需要 GPU 吗？

不需要。CPU 模式即可运行全部功能。但 GPU 可加速文档解析（OCR、版面分析）和 Embedding 生成。

Q: RAGFlow 支持哪些 LLM？

OpenAI、Qwen、DeepSeek、Gemini、Claude、VolcEngine、Bailian，以及 Ollama 本地模型和兼容 OpenAI API 格式的自定义网关。

Q: RAGFlow 的 WEB UI 支持多语言吗？

Web UI 已支持英文、中文（简/繁）、日文、韩文、法文、阿拉伯文、土耳其文、俄文、葡萄牙文、印尼文等。

Q: ARM 架构（Apple Silicon、树莓派）能直接跑吗？

A: 不能直接跑。官方仅提供 x86 预构建镜像，ARM64 平台需参考官方文档自行构建 Docker 镜像 。

Q: 内存 16GB 是硬性要求吗？低于 16GB 能跑吗？

A: 16GB 是官方给出的最低要求。低于此配置可能出现 ES 索引构建失败或解析进程 OOM。生产环境建议 32GB 以上 。

Q: 必须要配置外部 LLM 的 API Key 吗？能用本地模型吗？

A: 是的，RAGFlow 只是 RAG 引擎，必须外接 LLM。除云端 API 外，官方也支持通过 Ollama、Xinference、LocalAI 部署本地模型 。

Q: 如何切换完整版（含嵌入模型）和 slim 版？

A: v0.22.0 起官方仅发布 slim 版本（不含嵌入模型），需要通过配置外部 Embedding 模型服务（如 BAAI/bge 系列、Ollama 本地嵌入等）来提供向量化能力。修改 docker/.env 中的 RAGFLOW_IMAGE 变量可切换版本 。

Q: 父子分片（Parent-Child Chunking）怎么开启？

A: 在数据集的 Configuration 页面找到 "Child chunk are used for retrieval" 开关，开启后设置子块的 delimiter 即可 。该特性自 v0.23.0 引入 。

Y 推荐文献

• RAGFlow 官方文档

RAGFlow Quickstart 官方文档

• RAGFlow GitHub

• RAGFlow Cloud 在线体验

• RAGFlow 2026 Roadmap

• RAG 原理解读

• Agentic Context Engine 介绍

• DeepDoc 文档解析引擎

• RAGFlow Explained: Build Production RAG Applications - DataCamp

• RAGFlow: Self-Host a Deep-Document RAG Engine - Dev.to

• RAGFlow 中文文档 - ragflow.com.cn

• 1+1>2｜Dify中调用Ragflow知识库超详细步骤 - Bilibili

X 参考文献

• Ragflow构建本地智能体平台 - Zhihu
• RAGFlow - GitHub
• RAGFlow - 官方网站
• RAGFlow Releases
• Docker Hub - infiniflow/ragflow
• RAGFlow Discord 社区
• InfiniFlow GitHub 组织

• RAGFlow Quickstart - ragflow.io
• RAGFlow 中文社区 - ragflow.org
• RAGFlow: Self-Host a Deep-Document RAG Engine - Dev.to
• Chunking Methods in RAGFlow - DeepWiki
• RAGFlow Explained: Build Production RAG Applications - DataCamp
• RAGFlow 之 DeepDoc 深度文档理解技术 - CSDN
• RAGFlow: 基于 OCR 和文档解析的下一代 RAG 引擎 - 火山引擎开发者社区