RAGFlow 怎么部署？slim 和 full 镜像怎么选

2026-07-28

数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。

RAGFlow 的部署本身是标准的 Docker 流程，真正会卡住新手的只有一个岔路口：slim 镜像还是 full 镜像。这两者的差别不是”精简版功能少”，而是要不要把嵌入模型一起打进镜像里——你的嵌入模型如果本来就打算调外部服务，slim 就够；你要的是断网也能跑通全流程，才需要 full。想清楚这一点，剩下的部署基本没有决策成本。

先纠正一个常见误解：很多人看到 slim（约 2GB）和 full（约 9GB）的体积差，第一反应是”slim 是阉割版，功能不全，生产环境肯定要用 full”。这个推断方向就错了。按多方资料的一致说法，两个镜像的区别在于是否内置嵌入模型，而不是把解析、检索、工作流这些核心能力砍掉。换句话说，多出来的那部分体积主要是模型权重，不是功能代码。用 slim 跑生产、把嵌入交给外部服务，是完全成立的做法。

下面按实际部署顺序把这件事拆开讲。

一、slim 和 full 的真实差别

多方资料一致提到的两种 Docker 镜像，规格上的对照很简单：

slim 镜像：体积约 2GB，不内置嵌入模型。
full 镜像：体积约 9GB，内置嵌入模型。

理解这个差别，关键是想明白一条 RAG 链路里嵌入模型站在什么位置。文档进来之后要先切块，每一块要被转成向量才能进向量数据库，做这一步的就是嵌入模型。这个模型可以有两种来源：一种是跑在你自己这台机器上（模型文件得在本地），另一种是调远程 API（本地不需要模型文件，但要有网络和密钥）。

full 镜像走的是第一条路，把模型一起打包，开箱即用；slim 镜像走的是第二条路，把”用哪个嵌入模型”这个选择权留给你，在界面里配置外部服务地址和密钥即可。

所以判断标准不是”我是不是生产环境”，而是你的嵌入模型打算从哪来。这个问题回答完，镜像也就选完了。

二、什么情况下选 slim

以下几种情况，slim 通常是更省事的选择：

你已经有在用的嵌入服务。如果团队已经在调某家的嵌入接口，或者自己另外部署了模型推理服务，那 full 镜像里的内置模型对你就是纯粹的冗余，白占几个 G 的磁盘和拉取时间。
服务器磁盘紧张或者拉镜像太慢。2GB 和 9GB 的差距在带宽一般的机器上是很实在的等待时间，反复重建环境的时候尤其明显。
你想灵活切换嵌入模型做效果对比。检索质量很大程度上受嵌入模型影响，如果你打算试几个模型看哪个在自己语料上召回更准，走外部服务反而更方便，不用因为换模型而重新折腾镜像。
只是先跑起来看看界面和流程。评估阶段没必要一上来就拉最大的包。

选 slim 的代价是：首次启动之后你必须先去配置一个可用的嵌入服务，否则知识库建好了也解析不出向量。这一步不配就直接传文件，最常见的现象就是文档卡在解析中或者报模型不可用，而很多人会误以为是部署失败。

三、什么情况下选 full

反过来，这几种情况建议直接上 full：

内网隔离、不能出网。这是 full 最典型的用武之地。既然连不了外部嵌入 API，模型就必须在本地，那么用内置模型的镜像最省心，不用另外再部署一套模型服务。
你不想为嵌入单独维护一个服务。运维人手少的团队，少一个组件就少一处故障点。
想要一条命令跑通全流程做演示。给业务方看效果的场合，full 的”开箱即用”价值最大，不用当场解释为什么还要填一个密钥。

full 的代价也很直白：镜像大、拉取慢、对宿主机内存的占用更高，而且你被绑定在它内置的那个模型上（虽然仍可以在界面里改配置，但打进去的那份权重就浪费了）。

四、部署之前先确认宿主机条件

RAGFlow 是 Docker Compose 部署，它拉起来的不是一个容器，而是一组服务——除了自身的服务端和前端，还包括检索引擎、元数据存储、对象存储这类依赖。所以部署前先看几件事，比出问题再回头查省时间得多：

内存。这是最常见的翻车点。检索引擎那部分对内存比较敏感，机器如果只有很小的内存，容器会起来一半又被杀掉，日志上看是莫名其妙的退出。具体的最低内存、CPU 要求以官方文档当前版本为准，但经验上：别拿最低配的云主机来跑，它不是一个单进程小工具。
内核参数。检索引擎依赖较高的内存映射数量上限，Linux 默认值往往不够，需要按官方文档说明调整对应的内核参数并持久化，否则重启机器后又会失效。
磁盘。镜像本身之外，文档原件、解析产物和向量索引都要占空间，而且是随着知识库增长持续变大的。给数据卷留出余量，别把 RAGFlow 装在一块快满的盘上。
端口占用。默认暴露的端口如果和机器上已有服务冲突，改映射即可，但要记得改完之后访问地址也跟着变。
数据卷持久化。确认数据目录挂到宿主机的持久路径上，不要让重要知识库跟着容器生命周期走。这一条在演示环境里最容易被忽略，等到需要迁移或者重建容器时才发现数据没了。

具体的仓库地址、Compose 文件路径和启动命令，以项目仓库和官方文档的当前版本为准——这类路径在版本迭代中变化比较频繁，抄半年前的教程很容易对不上。

五、镜像选错了还能换吗

能换，而且成本没有想象中高。

两种镜像共用同一套数据。控制用哪个镜像的，是部署目录下环境变量文件里的镜像标签配置（变量名与标签写法以官方文档当前版本为准）。改掉标签、重新拉取、重启这组服务，数据卷里已有的知识库不会因此消失。

但有一个必须提醒的点：换镜像不等于换嵌入模型之后旧数据还能用。如果你从 full 换到 slim 并顺手把嵌入模型换成了另一个，那么之前用旧模型生成的向量和新查询的向量不在同一个语义空间里，检索结果会明显不对。这种情况下，正确做法是把受影响的知识库重新解析一遍，而不是靠调参数硬救。这个坑不限于 RAGFlow，任何 RAG 系统换嵌入模型都要重建索引。

所以”先用 slim 试试，不行再换 full”这个路径是可行的，只是要有心理准备：换的过程中如果动了嵌入模型，重跑解析的时间要算进去。

六、向量存储和检索这一层怎么想

RAGFlow 自带的依赖组件足够把 demo 跑通，很多团队也就一直这么用下去了。什么时候需要考虑单独接一个向量数据库？主要看规模和检索需求。

以常配的 Qdrant 为例，它支持过滤、payload 索引与量化，第三方资料称在 100 万以上向量规模下可以做到 50 毫秒以内的检索（这是第三方基准口径，不是官方承诺的指标，实际表现取决于硬件、索引参数和查询复杂度）。它既可以作为独立二进制运行，也可以用 Docker 容器跑。

我的建议是：别在第一天就纠结这一层。先用默认配置把文档灌进去、把检索质量看一遍，你会发现绝大多数效果问题出在解析和分块上，而不是向量库不够快。等到数据量真的上来、或者出现明确的检索延迟问题时再优化，判断依据也更充分。关于选型的横向对比，可以参考向量数据库怎么选那篇。

七、部署完之后，喂什么料最能体现它的价值

选 RAGFlow 而不是别的方案，通常是冲着它的深度文档理解去的。按第三方资料的说法，它的分块会尊重文档本身的结构，具备版面感知的解析能力，并内置知识图谱构建。落到语料上，它比较适合扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的材料。

反过来说，如果你的语料本来就是干净的 Markdown 或纯文本，那么 RAGFlow 在解析这一环的优势就体现不出来，你付出的部署成本换不回对应的收益。

这里可以补一个更通用的选型思路：按瓶颈选框架，而不是按名气选。整理成四个方向——

瓶颈在解析（烂 PDF、表格、扫描件）：从 LlamaIndex（LlamaParse）或 RAGFlow 入手；
瓶颈在检索（嵌入、混合检索、重排）：LangChain、Haystack、Cognita 这类可调的旋钮更多；
瓶颈在评估（说不清改动到底有没有变好）：在已有框架上加挂 RAGAS；
语料是有链接关系的结构化内容：考虑图检索，RAGFlow 的 GraphRAG 属于这一类。

顺带说一下关注度这件事。按第三方统计的截至 2026 年 1 月的 GitHub star 数，LangChain 约 125,000、Dify 约 114,000、RAGFlow 约 70,000、LlamaIndex 约 46,500、Haystack 约 24,000。这组数字只反映社区关注度，不代表哪个更适合你的场景——star 更多的项目在你的语料上未必解析得更好。各项目当前的真实数据以其仓库页面为准。

还有一点值得说明：这些框架并不互斥。一种常见的生产组合是 LlamaIndex 做数据接入与索引、LangChain 做编排、LangGraph 做 agent 工作流。RAGFlow 同样可以只承担”把难啃的文档变成可检索内容”这一段，后面的编排交给别的东西。想了解编排层怎么设计，可以看Agentic RAG那篇。

八、诚实说局限

几句不太好听但有用的话：

部署跑通 ≠ 效果可用。RAGFlow 装好、文档传进去、能问答了，这只是起点。真正花时间的是调分块策略、看召回结果对不对、处理那些解析出来一团糟的表格。做过企业知识库搭建的人都知道，这部分工作量往往超过部署本身。
它是一组服务，不是一个小工具。资源开销和运维复杂度都比”跑个脚本”高一个量级。如果你的需求只是几十份 Markdown 文档的问答，用轻量方案可能更合适，不必上这套。
自托管有持续成本。服务器、存储、升级、故障处理都是真实开销，评估时别只算许可证是不是免费。这方面的算账思路可以参考自部署成本怎么算。
本文提到的镜像体积、组件构成会随版本变化。这类信息以你实际拉取时的官方文档和仓库说明为准，不要把某一篇教程里的数字当成永久事实。

小结

RAGFlow 部署的核心决策只有一个：slim 还是 full，判断依据是嵌入模型打算从哪来——用外部服务选 slim（约 2GB），要本地内置、内网隔离选 full（约 9GB），两者的功能差别不在核心能力上。部署前把内存、内核参数、磁盘、端口和数据卷这几项确认好，能避开大部分启动失败。镜像选错可以换，但如果连带换了嵌入模型，受影响的知识库要重新解析。真正决定项目成败的不是部署那半天，而是之后调解析和检索的那几周——把预期放在正确的地方，这套系统才用得下去。