RAGFlow 1.0 实测：Docker 部署、模板切片与检索边界

RAGFlow 是 infiniflow 维护的开源 RAG 引擎，主打深度文档理解。它先把 PDF、Word、表格和扫描件按版面读懂，再切块、建索引、带引用回答。2026 年 11 月 6 日它发布 v1.0.0 正式版；此前 9 月 29 日的 1.0.0-rc1 已经把整套服务用 Go 重写。这篇按实测顺序讲三件事：Docker 部署要改哪里、模板切片怎么选、检索与资源上有哪些边界。

RAGFlow 是什么，1.0 这次改了什么

它不是向量数据库，也不是聊天前端，而是夹在原始文件和模型之间的一层上下文处理。文档上传后，DeepDoc 做版面分析、OCR 与表格识别，再按所选模板切成可检索的块。回答时附上原文位置，方便人工核对。

1.0 的改动集中在运行形态。消息队列从 Redis 换成 NATS，缓存与检查点交给 Kvrocks，命令行工具也改成 Go 实现。官方发布说明给出的口径是镜像约小 10 倍、启动约快 10 倍、并发约 100 倍。这些数字属于厂商自测，落到自己机器上要看文档类型和并发模型。

检索链路是多路召回加融合重排。全文检索负责编号、型号这类精确词，向量检索负责语义相近，两路结果合并后再交给重排模型打分。数据集层面还有一个 PageRank 权重，可以给特定知识库的命中整体加分。

Docker 部署：常驻容器与三处必改

官方建议的起步配置是 4 核 CPU、16 GB 内存、50 GB 磁盘，Docker 24.0.0 以上，Compose v2.26.1 以上。这组数字只是能跑起来，解析扫描件或跑本地模型都要再加余量。

用默认的 Elasticsearch 作文档引擎时，宿主机得先调内核参数。vm.max_map_count 要不小于 262144，否则容器会反复重启，日志里常看到连不上集群。

启动只有三步：克隆仓库、切到 v1.0.0 标签、在 docker/.env 里确认镜像名，然后执行 docker compose up -d。默认 80 端口对外，数据落在几个命名卷里。

部署到对外可达的机器前，有三处一定要改。

• 默认口令：.env 里 MySQL、MinIO 与 Redis 协议服务用的都是示例密码，换掉再启动。
• 端口映射：网页 80、API 9380、管理端 9381，以及 ES 的 1200、MinIO 的 9000，冲突时逐项改。
• 内存上限：MEM_LIMIT 默认约 8 GB，机器小时要下调，但 Elasticsearch 那一路仍要留足。

Redis 的角色在 1.0 被拆开了。Go 服务走 Kvrocks 和 NATS，compose 里仍留一个 Redis 协议的 Valkey 服务给 Python 侧组件。文档引擎可以换 Infinity、OpenSearch 等，改的是 .env 里的 DOC_ENGINE 与对应 profile。

备份要按全套来做。MySQL 存切片与任务记录，MinIO 存原始文件和解析产物，ES 或 Infinity 存索引，Kvrocks 存检查点，四类缺一类都还原不完整。docker compose down 保留卷，加上 -v 就会把卷删掉。

升级路径有硬约束。容器启动时会把 v0.27.2 的数据自动迁到 1.0 结构，更新日志写明该过程不可回滚；低于 v0.27.2 的实例要先按迁移文档逐级升到基线版本。

模板化切片：先选对模板，再谈调参

RAGFlow 的切片不按固定字符数硬切，而是按文档类型选模板。1.0 把 12 个内置解析器和流水线解析器统一，模板名与解析行为对上了号，具体差异在数据集配置文档里逐条列明。

• General：常规文档，按段落与句子边界切。
• Manual：有清晰章节层级的手册与操作指南。
• Paper：论文与研究报表，按摘要、章节、小节切。
• Book：书籍与长文档，按章节结构切。
• Laws：法规，按条文特征找边界。
• Table：XLSX 与 CSV，通常一行一块。
• Q&A：问答对，一问一答一块。
• Presentation：PDF 与 PPTX，一页一块。
• Picture：图片与视频，靠 OCR 与视觉描述转成文字。
• Audio：WAV、MP3 等，先用 ASR 转写再切。
• Email：EML 与 MSG，抽出发件人、主题与正文。
• One：整篇作为一块，适合短文档。

选错模板的代价要等到检索阶段才显现。财报用 General 切，跨页表格会被拆散；合同用 Book 切，条款边界会对不齐。0.25 起官方给了 7 个可编辑的流水线模板，等于把内置逻辑摊开，处理节点能自己替换。

切片结果在界面里能看到边界并手工修正，这点比较实用。改完切片要重新嵌入，嵌入模型换过一次就不好回头：系统会校验向量维度一致、抽样余弦相似度不低于 0.9，不达标会退回原模型。

Agentic 检索与知识编译：四档之后的新分工

Agentic RAG 在 2026 年 8 月 19 日公布，最初带 Low、Medium、High、Ultra 四档思考深度。到 1.0.0-rc2，四档被单一 Agentic 模式取代；rc3 又引入决策模型，在工具调用循环里判断证据是否够回答。

实际差别在轮次。普通检索是一次召回加一次重排，Agentic 模式会拆问题、多轮检索、核对证据，再决定要不要继续。问题复杂时上下文更完整，代价是模型调用次数和等待时间都上去了。

知识编译是另一条线，同样在 2026 年 8 月 19 日引入。它能把文档或整个数据集编译成 Wiki、图谱、树、PageIndex、思维导图、时间线和技能条目，编译模型与处理规则都能配。它适合把散落资料整理成可复用结构，不适合当实时检索用。

资源占用与几条检索边界

官方口径里的降幅很大，但起步配置没变。16 GB 内存、4 核 CPU 仍是建议的起点，docker/.env 里每个容器的 MEM_LIMIT 默认约 8 GB。真要跑本地嵌入或 OCR，机器还得往上加。

解析是耗时大头。开源版 1.0 的 DeepDoc 只用 CPU 推理，版面分析、OCR、表格识别都在 CPU 上跑，批量处理扫描件时队列会排很久。GPU 版 compose 加速的是嵌入和部分解析，不是全部环节。

另一个常被低估的点是切片粒度。块切得越碎，召回越准但上下文越散；块切得越大，答案更完整却容易夹带无关段落。同一个数据集里按文档类型分别选模板，通常比统一套一个模板更稳。

• 文档引擎按单节点配置，没有内置分片与高可用编排。
• 代码沙箱在 1.0 不再随包提供，需要外接沙箱服务。
• 废弃 API 在 Go 实现里不再兼容，老脚本要改；Python SDK 不受影响。
• macOS 上跑不了 Go 后端，官方建议用 Linux 主机。
• 官方基准成绩属于自测口径，换模型、换语料都会变。

适合谁，以及一条上手顺序

适用场景比较明确：手里有大量格式复杂、需要带引用回答的内部文档，并且能接受自己维护一栈容器。法务、制造、投研这类文档密度高的团队，收益主要在解析这一层。

不太适合只想给模型喂几篇文章的个人。那种需求用单容器方案更省事：站内Docling 那篇只解决解析，Open Notebook 把资料、笔记和对话装进两个容器。要的是流程编排而不是知识库，Dify 的可视化工作流更对路。

上手顺序建议这样。先用一份自己熟的扫描 PDF 跑通模板解析，看切片边界对不对；再配嵌入模型和对话模型，拿十来个真实问题试。

跑顺之后再决定要不要开 Agentic 与知识编译。顺序反过来，容易在调参上耗掉时间。

需要 GPU 吗

不强制。CPU 能跑完整流程，只是解析和嵌入更慢。文档量大、扫描件多时，再考虑 GPU 或把解析拆到另一台机器。

能不能只装一个容器

不行。MySQL、MinIO、文档引擎、Kvrocks、NATS 都是必需依赖，compose 文件把它们拆成了独立服务，少一个都起不来。

旧版数据怎么迁

先确认实例在 v0.27.2，做好全套备份，再启动 1.0 容器让它自动迁移。迁移不可逆，失败只能从备份恢复后重来。

相关地址

以下为文中项目的官方入口，版本号、部署步骤与文档以这些页面为准。

• RAGFlow（GitHub 仓库）：https://github.com/infiniflow/ragflow
• RAGFlow（官网）：https://ragflow.io/
• RAGFlow（更新日志）：https://www.ragflow.io/changelog