第 8 篇：RAGFlow 私有化套件实战——基于 RAGFlow 搭建企业级私有知识库

本文为「从零到落地：RAG 检索增强生成实战系列」第 8 篇，完整系列持续更新中。

RAGFlow 官方文档：https://ragflow.io/docs/（英文） | https://ragflow.com.cn/docs/（中文）

GitHub 仓库：https://github.com/infiniflow/ragflow

前言

本篇聚焦 RAGFlow 一体化私有部署实战，从 Docker 部署到深度文档解析、知识库搭建、API 调用，完整走一遍企业级私有 RAG 系统的搭建全流程。

在前面几篇里，你已经用原生 Python、Dify、LangGraph、LlamaIndex 分别跑通了 RAG。这些方案各有侧重，但都有一个共同前提：数据需要经过外部 API 或本地服务中转。

如果你的场景是——企业内网、涉密文档、数据绝对不能出网——那就需要一个一体化私有部署套件：把所有组件（文档解析、向量检索、大模型调用、可视化管理）全部跑在自己的服务器上，一套系统搞定全部流程。

RAGFlow 就是目前最热门的开源方案之一。它内置深度文档解析（PDF 布局分析、表格提取、图片 OCR）、模板化分块、混合检索、Rerank 重排，从 0.25 版本开始还支持 Agent 工作流和 RAPTOR 层次化摘要索引，功能覆盖面已经远超一个”RAG 知识库”的范畴。

本篇学完你将掌握：

  • RAGFlow 的完整部署流程（Docker Compose 一键启动）
  • 模型接入配置（API 方式 + 本地 Ollama 两种方式）
  • 深度文档解析能力（PDF/表格/图片，支持 DeepDoc/MinerU/Docling 三种解析器）
  • 知识库搭建、分块策略配置、检索参数调优
  • RAPTOR 层次化摘要索引的使用场景和配置方法
  • Agent 工作流的基本用法
  • API 调用方式（Python 代码示例）
  • RAGFlow 与 Dify 的选型对比

一、RAGFlow 是什么

RAGFlow 是一款开源的一体化 RAG 引擎，由 InfiniFlow 团队开发，GitHub 上已有 50k+ Star。和 Dify 这类”低代码 AI 应用平台”不同，RAGFlow 的核心定位是专注 RAG 的全流程套件——从文档解析到检索增强生成，所有环节都内置在一个系统里。

1.1 核心特性

特性 说明
深度文档解析 内置布局分析模型，支持 PDF 表格提取、图片 OCR，另支持 MinerU、Docling 解析器
模板化分块 提供多种分块模板（通用、论文、法律、代码等），分块结果可视化、可手动修正
混合检索 + Rerank 向量检索 + 关键词检索融合，支持 Rerank 重排，检索精度高
RAPTOR 层次化索引 自动构建文档层次化摘要树，提升长文档和跨段落问答效果
Agent 工作流 可视化 Agent 编排，支持代码执行、浏览器组件、MCP 工具调用
完全私有化 Docker 一键部署到内网，数据全部自持，源码可控

1.2 系统架构

RAGFlow 的后端由以下组件构成：

1
2
3
4
5
6
7
8
前端 UI（React）
    ↓
后端 API（Python Flask）
    ↓
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ Elasticsearch│    MinIO     │    Redis     │    MySQL     │
│  （向量+全文） │ （文件存储）  │  （缓存）    │  （元数据）  │
└──────────────┴──────────────┴──────────────┴──────────────┘

💡 提示：RAGFlow 默认使用 Elasticsearch 9.x 作为文档引擎，同时存储向量和全文索引。MinIO 用于存储上传的原始文件，MySQL 存储用户和知识库元数据，Redis 用于任务队列和缓存。

1.3 和 Dify 的区别

简单说一下定位差异，后面第七节有详细对比：

  • Dify：低代码 AI 应用平台，RAG 只是其中一个功能模块，还支持 Workflow、Agent、多模型管理等
  • RAGFlow：专注 RAG 的一体化套件，文档解析深度和检索精度是核心优势，0.25+ 版本也开始支持 Agent 能力

1.4 适用场景与规模评估

一个常见的问题：RAGFlow 能支撑多大规模？这里给你一个具体的参考评估。

场景假设：企业内部知识库，200+ 员工同时访问，文档量 1000+ 份。

结论：完全支持，但服务器配置要到位。

核心瓶颈分析：

环节 压力评估 说明
文档检索 低 Elasticsearch 9.x 设计目标是亿级文档，1000 份文档的向量检索完全轻松，毫秒级响应
文档解析 低 解析是异步任务，不占用在线服务资源
Web 服务 中 RAGFlow 后端可以多 worker 部署，200 人在线无压力
LLM 调用 高（核心瓶颈） 每次提问都调 LLM，200 人同时提问是最大压力点

💡 提示：200 人“同时在线”≠ 200 人同时提问。实际并发 QPS 通常在 20-50 左右（不是所有人同时按回车）。商用 LLM API（如 DeepSeek）支持 500+ RPM，完全够用；本地模型（如 Ollama + Qwen2.5-7B）单卡只能处理 5-10 个并发，需要多卡才能支撑。

服务器配置建议（按规模）：

规模 CPU 内存 磁盘 LLM 方案建议
小型（10-50 人，100 文档） 4 核 16 GB 50 GB 单卡本地模型或 API
中型（50-200 人，1000 文档） 8-16 核 32-64 GB 200 GB SSD 商用 API 或多卡本地模型
大型（200+ 人，万级文档） 16-32 核 64-128 GB 500 GB+ SSD 商用 API + 分布式部署

💡 建议：如果你的团队规模在 200 人左右、文档量在 1000 份级别，推荐 16 核 / 64GB 内存 / 200GB SSD 的服务器，LLM 优先用商用 API（DeepSeek 性价比最高）。用本地模型的话至少需要一张 24GB 显卡（如 RTX 4090）才能撑住并发。

二、环境准备与部署

2.1 硬件和软件要求

环境项 最低要求 推荐配置
CPU 4 核 8 核+
内存 16 GB 32 GB+
磁盘 50 GB 100 GB+（文档多时需要更多空间）
Docker >= 24.0.0 最新版
Docker Compose >= v2.26.1 最新版

⚠️ 注意：RAGFlow 的 Docker 镜像目前仅支持 x86 架构，ARM64（如 Apple Silicon Mac）需要自行构建镜像，参考官方文档。

2.2 前置配置：vm.max_map_count

Elasticsearch 要求系统的 vm.max_map_count 参数不小于 262144。Linux 系统需要手动配置，Windows/Mac 的 Docker Desktop 通常已默认满足。

1
2
3
4
5
6
7
8
9
# 查看当前值
sysctl vm.max_map_count

# 如果小于 262144，临时修改（重启失效）
sudo sysctl -w vm.max_map_count=262144

# 永久修改（推荐）
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

2.3 克隆仓库并配置镜像

1
2
3
4
5
6
7
8
# 克隆 RAGFlow 仓库
git clone https://github.com/infiniflow/ragflow.git
cd ragflow

# 切换到目标版本（确保代码与 Docker 镜像版本一致）
git checkout -f v0.25.0

cd docker

打开 .env 文件，确认 RAGFLOW_IMAGE 变量指向目标版本：

1
2
# .env 文件中的关键配置
RAGFLOW_IMAGE=infiniflow/ragflow:v0.25.0

💡 提示：如果国内网络无法从 Docker Hub 拉取镜像，可以修改 .env 中的 RAGFLOW_IMAGE 为国内镜像源：

  • 阿里云：registry.cn-hangzhou.aliyuncs.com/infiniflow/ragflow:v0.25.0
  • 华为云：swr.cn-north-4.myhuaweicloud.com/infiniflow/ragflow:v0.25.0

2.4 启动服务

1
2
3
4
5
6
7
# CPU 模式启动（默认，适合大多数场景）
docker compose -f docker-compose.yml up -d

# GPU 加速模式（可选，加速文档解析中的 DeepDoc 任务）
# 先修改 .env：DEVICE=gpu
# 再执行：
# docker compose -f docker-compose.yml up -d

💡 提示：从 v0.22.0 开始，RAGFlow 只发布 slim 版本镜像（不含内置 Embedding 模型），镜像大小约 2GB。Embedding 模型需要在系统内外部接入，第三节会讲。

2.5 验证部署成功

1
2
# 查看 RAGFlow 容器日志
docker logs -f docker-ragflow-cpu-1

看到以下输出说明启动成功：

1
2
3
4
5
6
7
____   ___    ______ ______ __
/ __ \ /   |  / ____// ____// /____  _      __
/ /_/ // /| | / / __ / /_   / // __ \| | /| / /
/ _, _// ___ |/ /_/ // __/  / // /_/ /| |/ |/ /
/_/ |_|/_/  |_|\____//_/    /_/ \____/ |__/|__/

* Running on all addresses (0.0.0.0)

在浏览器输入 http://你的服务器IP（默认端口 80），首次访问会进入注册页面，创建管理员账号即可进入后台。

踩坑记录：部署常见问题

问题一：vm.max_map_count 不足导致 ES 启动失败

现象：Elasticsearch 容器反复重启，日志报 max virtual memory areas vm.max_map_count [65530] is too low

原因：ES 要求系统 vm.max_map_count >= 262144，Linux 默认值通常只有 65530

解决方案：按 2.2 节命令修改后重启容器

问题二：国内拉取镜像超时

现象：docker compose up 卡住或报 Error response from daemon: Get https://registry-1.docker.io/v2/... timeout

原因：Docker Hub 在国内访问不稳定

解决方案：修改 .env 中的 RAGFLOW_IMAGE 为阿里云或华为云镜像源（见 2.3 节）

问题三：端口 80 被占用

现象：启动时报 Bind for 0.0.0.0:80 failed: port is already allocated

原因：本机 80 端口已被其他服务占用（如 Nginx）

解决方案：修改 docker-compose.yml 中的端口映射，将 80:80 改为 <你的端口>:80，如 8080:80

三、模型接入配置

RAGFlow 的镜像不含内置 Embedding 模型，部署完成后第一步是接入 LLM 和 Embedding 模型。

3.1 接入 LLM

方式一：API 接入（OpenAI 兼容接口）

进入后台 → 右上角用户头像 → Model providers → 添加模型提供商。

以 OpenAI 兼容接口为例（也适用于国内各家大模型的 OpenAI 兼容 API）：

配置项 填写说明
提供商 OpenAI-API-Compatible（兼容接口）
Base URL 你的 API 地址，如 https://api.deepseek.com/v1
API Key 你的 API Key
模型名称 如 deepseek-chat、gpt-4o 等

💡 提示：国内推荐用 DeepSeek、通义千问、智谱 GLM 等有 OpenAI 兼容接口的模型，配置方式完全一样，只需替换 Base URL 和 API Key。

方式二：本地 Ollama（完全离线）

如果你的服务器完全不能访问外网，可以用 Ollama 部署本地模型：

1
2
3
4
5
# 安装 Ollama（Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 拉取模型（以 Qwen2.5 7B 为例）
ollama pull qwen2.5:7b

在 RAGFlow 后台添加模型时：

配置项 填写说明
提供商 Ollama
Base URL http://host.docker.internal:11434（Docker 内访问宿主机）
模型名称 qwen2.5:7b

⚠️ 注意：Docker 容器内访问宿主机的 Ollama，地址要用 host.docker.internal（Windows/Mac）或宿主机局域网 IP（Linux），不能写 localhost。

3.2 接入 Embedding 模型

Embedding 模型决定了向量检索的精度，建议用外部专业 Embedding 模型而非 LLM 自带的。

推荐配置：

Embedding 模型 接入方式 适用场景
BGE-large-zh-v1.5 本地 Ollama 或 HuggingFace API 中文场景首选，开源免费
text-embedding-3-small OpenAI API 英文为主，精度高
通义千问 Embedding 阿里云 API 国内商用，中文适配好

在 Model providers 页面，切换到 Embedding 标签页，按同样方式添加即可。

3.3 设置默认模型

添加完模型后，进入 系统设置 → 设置默认的 LLM 和 Embedding 模型。后续创建知识库和应用时会自动使用默认模型，也可以在具体应用里单独覆盖。

3.4 系统参数调优

RAGFlow 的 service_conf.yaml.template 文件控制后台服务的各项参数，几个关键配置项：

参数 说明 建议值
并发 worker 数 后端服务的工作进程数 生产环境设为 CPU 核数（如 8）
任务队列并发 文档解析的并发任务数 根据内存调整，16GB 内存建议 4，32GB 建议 8
LLM 超时时间 大模型调用的超时时长 默认 120s，长文档生成可适当增大到 300s
ES 内存 Elasticsearch 分配内存 建议 8GB+，知识库大时适当增加

💡 提示：大多数情况下默认参数已经够用，只有在并发压力较大或文档量很多时才需要调整。修改完参数后需要重启服务生效：docker compose -f docker-compose.yml up -d

四、知识库搭建（核心）

知识库是 RAGFlow 的核心模块，也是它相比其他方案最有优势的部分——深度文档解析能力。

4.1 创建知识库

进入 知识库 → 新建知识库，填写名称和描述。

创建后进入知识库设置页，最重要的两个配置：

配置项 说明 建议
解析模板 决定文档用什么方式分块 通用文档选”General”，论文选”Paper”，法律文档选”Laws”
Embedding 模型 文档向量化的模型 用前面配置的默认模型即可

4.2 文档上传与深度解析

RAGFlow 支持多种文档格式：PDF、Word、PPT、Excel、Markdown、TXT、图片等。

点击 上传文件 → 选择文档 → 系统自动开始解析。

RAGFlow 的文档解析有三种引擎可选：

解析器 特点 适用场景
DeepDoc（默认） 内置布局分析模型，支持表格提取、图片 OCR 大多数场景，开箱即用
MinerU 矿大开源，学术论文解析效果优秀 学术论文、复杂排版 PDF
Docling IBM 开源，多语言支持好 多语言文档、扫描件

💡 提示：对于包含复杂表格和图片的 PDF，DeepDoc 的解析效果通常优于普通 PDF 解析器。解析完成后可以在”Chunk”视图里逐个查看每个切片的识别结果，发现识别不准的地方可以手动修正。

4.3 分块策略配置

分块（Chunking）是 RAG 效果的关键环节。RAGFlow 提供了多种分块模板：

分块模板 说明 适用文档类型
General 通用分块，按段落 + Token 数切分 产品文档、FAQ、操作手册
Q&A 问答对格式，自动识别问题和答案 FAQ 文档、客服话术库
Paper 论文专用，按章节结构切分 学术论文、技术报告
Laws 法律文档专用，按条款结构切分 法律法规、合同
Code 代码专用，按函数/类结构切分 代码文件、技术文档
Table 表格专用，按行/列结构化 Excel、CSV 数据

核心参数：

参数 说明 建议值
Token 数 每个切块的最大 Token 数 256-512（中文文档建议 300 左右）
重叠 Token 相邻切块的重叠 Token 数 32-64（防止语义被截断）

💡 建议：Token 数不要设太大。块太大，检索精度下降（噪声多）；块太小，语义不完整。中文文档从 300 Token 开始试，根据效果调整。

4.4 解析结果检查与手动修正

文档解析完成后，点击文档进入 Chunk 视图，可以看到每个切片的完整内容。

RAGFlow 的分块过程完全可视化，支持：

  • 查看每个切片的文本内容和对应的原文位置
  • 手动编辑切片内容（修正 OCR 错误、补充信息）
  • 删除无关切片（广告页、页眉页脚等噪声）
  • 手动添加新切片

核心价值：这种”可视化 + 可修正”的分块方式，是 RAGFlow 相比代码框架（LangChain/LlamaIndex）的一大优势——你能直观看到 RAG 检索到的每一段内容是什么，而不是黑盒。

五、应用创建与对话测试

5.1 创建对话应用

进入 Chat → 新建对话助手，填写名称，绑定刚才创建的知识库（可绑定多个）。

5.2 Prompt 模板编写

RAGFlow 提供了系统 Prompt 配置，建议按以下模板编写：

1
2
3
4
你是 {公司名称} 的内部知识助手。
请根据知识库中检索到的内容回答用户问题。
如果知识库中没有相关信息，请明确告知用户"根据现有资料暂时无法回答"，不要编造答案。
回答时引用原文出处，格式为【文档名-页码】。

5.3 检索参数调优

在应用设置里，有几个直接影响检索效果的参数：

参数 说明 建议值
Top-K 每次检索返回的最相关切片数 5-8（知识库小可设 5，大库设 8）
相似度阈值 低于此分数的切片不返回 0.3-0.5（太高会漏召回，太低会引入噪声）
向量检索权重 向量检索 vs 关键词检索的权重分配 0.7（向量为主）+ 0.3（关键词补充）
Rerank 模型 对检索结果重排，提升相关性 建议开启，用 BGE-reranker 或 Cohere Rerank

💡 建议：混合检索（向量 + 关键词）是生产环境标配，纯向量检索在专有名词、产品型号等精确匹配场景下表现不如关键词检索，两者互补效果最好。

5.4 对话测试与检索溯源

在对话界面提问，RAGFlow 会在回答下方展示引用来源——点击可以看到具体是哪个文档的哪个切片，原文内容一目了然。

这个溯源能力在企业场景非常重要：用户需要知道答案来自哪里，不能只给一个”AI 说”的结论。

5.5 开启 Rerank 重排

Rerank 是提升检索精度的关键步骤。原理是对初次检索返回的 Top-K 个切片，用专门的 Rerank 模型重新打分排序，把真正最相关的内容排到前面。

在应用设置中开启 Rerank，选择一个 Rerank 模型（需要在 Model providers 里提前添加，如 bge-reranker-v2-m3）。

六、高阶配置

6.1 API 调用

RAGFlow 提供完整的 RESTful API，可以把知识库问答能力集成到企业内部系统。

进入 API 页面 → 创建 API Key，然后用 Python 调用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import requests

# RAGFlow API 配置
RAGFLOW_URL = "http://你的服务器IP/api/v1"
API_KEY = "你的API_KEY"

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

# 创建对话会话
session_resp = requests.post(
    f"{RAGFLOW_URL}/chats/<chat_id>/sessions",
    headers=headers,
    json={"name": "测试会话"}
)
session_id = session_resp.json()["data"]["id"]

# 发送问题
chat_resp = requests.post(
    f"{RAGFLOW_URL}/chats/<chat_id>/completions",
    headers=headers,
    json={
        "question": "你们公司的产品A有什么特点？",
        "session_id": session_id,
        "stream": False
    }
)

print(chat_resp.json()["data"]["answer"])

💡 提示：<chat_id> 是你在 Web UI 创建对话助手后生成的 ID，可以在 API 页面查看。RAGFlow 从 v0.25.1 开始逐步将 API 迁移为 RESTful 规范，升级最新版后可以获得更统一的接口体验，旧版接口仍然兼容。

外部系统对接示例：把 RAGFlow 接入企业微信/钉钉/飞书机器人，只需要在机器人的后端服务里调用 RAGFlow API——员工在群里@机器人提问，机器人调用 RAGFlow 检索知识库并返回答案，整个过程不需要员工登录 RAGFlow 后台。同理也可以接入企业 OA、工单系统、客服系统等任何支持 HTTP 调用的平台。

6.2 多知识库联动检索

一个对话应用可以绑定多个知识库，RAGFlow 会在检索时同时查询所有绑定的知识库，合并结果后送入大模型。

适用场景：企业有多个部门（产品、技术、HR）的文档，每个部门一个知识库，但对话助手需要跨部门检索。

6.3 权限管理与团队协作

RAGFlow 支持多用户和团队管理：

  • 管理员：可以管理所有知识库和用户
  • 普通成员：只能访问被授权的知识库
  • API Key 隔离：每个 API Key 绑定特定应用，权限独立控制

6.4 RAPTOR 层次化摘要索引

RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）是 RAGFlow 从 v0.25.3 开始引入的层次化摘要索引能力。如果你使用的是 v0.25.0，需要升级到 v0.25.3+ 才能使用此功能。

核心思路：对文档构建一棵层次化的摘要树——底层是原始切片，上层是逐层聚合的摘要节点。检索时可以同时命中细粒度切片和粗粒度摘要，解决”跨段落信息分散”的问题。

适用场景：

场景 说明
长文档问答 单个问题涉及文档多个段落的信息
跨文档综合 需要从多份文档中汇总信息得出结论
概括性提问 “这篇报告的主要结论是什么？”等宏观问题

开启方式：在知识库设置中开启 RAPTOR 选项，系统会在文档解析完成后自动构建摘要树。

💡 提示：RAPTOR 构建摘要树需要消耗 LLM Token，文档量大时构建时间较长。建议先在小规模知识库上验证效果，再决定是否全量开启。最新版的 Ψ-RAG（AHC 模式）相比早期 GMM 模式，索引构建速度更快、召回率更高。

6.5 Agent 工作流

从 v0.25.0 开始，RAGFlow 支持可视化 Agent 编排，可以把 RAG 能力和工具调用结合起来，构建更复杂的业务流程。

Agent 核心组件：

组件 说明
Retrieval 从知识库检索相关内容
Generate 调用 LLM 生成回答
Code 执行 Python/JS 代码（需配置沙箱）
Browser 自主浏览网页（最新版新增，v0.25.6+）
Iteration 循环处理数组数据
MCP 工具 通过 MCP 协议调用外部工具

典型场景：

  • 用户提问 → 检索知识库 → 如果知识库没有答案 → 调用 Browser 组件搜索网页 → 综合回答
  • 用户上传数据文件 → Code 组件分析数据 → 生成图表 → 返回结论

💡 提示：Agent 能力是 RAGFlow 近期发展的重点方向，如果你只需要基础 RAG 知识库，用 Chat 功能就够了；如果需要复杂业务流程编排，可以深入探索 Agent 模块。

七、RAGFlow vs Dify：怎么选

两者都支持私有化部署，但定位有明显差异：

对比维度 RAGFlow Dify
核心定位 专注 RAG 的一体化套件 低代码 AI 应用平台
文档解析 深度解析（布局分析、表格、OCR、MinerU/Docling） 基础解析（文本提取，无布局分析）
分块策略 多种模板（通用/论文/法律/代码等），可视化修正 基础分块（按 Token 数），配置较简单
检索能力 混合检索 + Rerank + RAPTOR，精度更高 向量检索为主，支持 Rerank
Agent 能力 有（v0.25.0+），功能持续完善 有（Workflow + Agent），生态更成熟
上手难度 中等（配置项较多） 较低（界面更友好）
适用场景 企业内网知识库、文档解析要求高的场景 快速原型、多模型管理、AI 应用开发
社区生态 专注 RAG 社区，垂直深耕 通用 AI 平台社区，生态更广

选型建议：

  • 选 RAGFlow：你的核心需求是”把企业内部文档变成可问答的知识库”，对文档解析精度要求高，文档类型复杂（PDF/表格/扫描件），数据绝对不能出网
  • 选 Dify：你的需求更综合——不只是知识库，还需要多模型切换、Workflow 编排、对外 API 服务，团队非技术人员也要操作
  • 两者都用：用 RAGFlow 做深度文档解析和检索，通过 API 把检索结果接入 Dify 做上层应用编排，也是可行的组合方案

八、常见问题踩坑汇总

Q：Docker 容器启动后，浏览器访问显示”网络异常”？
A：RAGFlow 服务还没完全启动完成。用 docker logs -f docker-ragflow-cpu-1 查看日志，等到出现 RAGFlow Logo 和 Running on all addresses 再访问。

Q：上传 PDF 后解析状态一直卡在”Parsing”？
A：检查 Elasticsearch 容器是否正常运行（docker ps 查看 es01 容器状态）。ES 内存不足或 vm.max_map_count 配置不对会导致解析任务卡住。

Q：检索结果不准确，回答和问题不相关？
A：依次排查：①检查 Chunk 视图，确认分块质量（分块是否截断了语义）；②调整 Top-K（适当增大）和相似度阈值（适当降低）；③开启 Rerank 重排；④确认 Embedding 模型是否适合你的文档语言（中文建议用 BGE 系列）。

Q：Ollama 本地模型接入后，调用时报连接失败？
A：Docker 容器内无法直接访问宿主机的 localhost。Windows/Mac 用 host.docker.internal:11434，Linux 用宿主机的局域网 IP。同时确认 Ollama 已设置 OLLAMA_HOST=0.0.0.0 允许外部访问。

Q：知识库文档很多，检索速度变慢？
A：①确认 Elasticsearch 有足够的内存分配（建议 8GB+）；②考虑切换文档引擎为 Infinity（在 .env 中设置 DOC_ENGINE=infinity，注意会清空已有数据）；③对大规模文档（百万级），考虑分库或引入分布式向量检索方案。

总结与回顾

知识点 关键要点
RAGFlow 定位 专注 RAG 的一体化开源套件，深度文档解析是核心优势
部署方式 Docker Compose 一键启动，镜像约 2GB（slim 版本）
模型接入 LLM 支持 API 和本地 Ollama 两种方式，Embedding 必须外部接入
文档解析 DeepDoc（默认）/ MinerU / Docling 三种解析器，支持布局分析和 OCR
分块策略 多种模板可选，Token 数建议从 300 开始调，结果可视化可修正
检索调优 混合检索（向量 + 关键词）+ Rerank 是生产环境标配
RAPTOR 层次化摘要索引，适合长文档和跨段落问答（需升级至 v0.25.3+）
Agent 能力 可视化编排，支持代码执行、浏览器、MCP 工具调用
与 Dify 对比 RAGFlow 专注 RAG 深度，Dify 专注 AI 应用广度，按需选择

下篇预告

第 9 篇：RAG 全链路增强技术——五维增强体系，把基础 RAG 优化到生产级 —— 五篇实战跑完，你已经有了一个能跑的 RAG 系统。但“能跑”和“好用”之间还有一段距离。下一篇按五大维度系统讲解 14 种增强策略：查询增强（假设问题法/HyDE/子查询/回溯提示）、索引增强（自动合并/分层索引/混合检索）、检索器增强（句子窗口/元数据过滤）、生成器增强（提示压缩/块顺序调整）、管道增强（自我反思/查询路由），帮你把 RAG 从“能用”优化到“好用”。

本文为「从零到落地：RAG 检索增强生成实战系列」第 8 篇，完整系列持续更新中。