ollama ragflow 部署本地知识库

很多人卡在第一步就开始怀疑人生：Docker 镜像拉不动、RAGFlow 起来但页面打不开、Ollama 明明在跑 RAGFlow 却连不上、文档传进去检索却是空的。这篇不重复讲 RAG 原理，只讲怎么把这两套东西装到一台机器上并跑通，出问题时按什么顺序查，以及哪些机器配置下这条路本身就不划算。

本地知识库这件事，最容易劝退的不是 RAG 原理，而是部署本身。镜像拉不动、RAGFlow 页面打不开、Ollama 明明在跑 RAGFlow 却连不上、文档传进去检索结果是空的——这四个坑基本覆盖了新手九成的时间消耗。

这篇不讲向量检索怎么算相似度，只讲怎么把 Ollama 和 RAGFlow 装到同一台机器上跑通，接模型时两条配置分别配什么，以及上线后出问题按什么顺序查。同时会说清楚：哪些机器配置下这条路本身就不划算，早点放弃比硬撑更省事。

先判断这条路值不值得走

先想清楚动机。资料不能出院、想断网跑、不想为按量调用持续付费，这三种情况本地部署是合理的。反过来，如果是要多人同时高频问答，或者要处理一大批扫描件和复杂表格而机器又没有独显，那本地这条路大概率会让你后悔——托管方案虽然花钱，但省下来的是你反复调参和等待解析的时间。

1. 盘机器底账记录四项：可用内存、磁盘剩余、有没有可用 GPU、Docker 是原生还是走 WSL。这四项直接决定后面用哪个镜像、要不要开加速、能不能跑得动你想要的模型。
2. 估模型开销到 /models/deploy 按你打算跑的模型规模估一遍显存和内存占用。估出来不够就先别动手，装上去也是频繁被系统杀掉进程。
3. 确认检索方案到 /stacks/vector-dbs 对一遍 RAGFlow 自带的向量检索能力和自建向量库的差别。想开箱即用就用它内置的，想自己接一套就得提前规划好数据流。

Windows 上用 Docker 打底：把坑提前填掉

Windows 上跑这套东西，Docker Desktop 基本是绕不开的选项，而它的默认资源配额往往同时喂不动容器和模型进程。第一件事不是急着装，而是确认虚拟化已开、WSL 后端可用，然后把内存和磁盘配额手动调上去。

• 确认虚拟化已开、WSL 后端可用，再手动提高 Docker Desktop 的内存与磁盘配额
• 用 docker compose 起服务，端口映射和挂载目录都要显式写，数据卷落到宿主机固定路径
• 镜像拉不动先换镜像源或离线导入，别反复重试；拉取失败和启动失败是两类问题
• 页面打不开按「容器是否 running → 端口是否被占用 → 宿主机防火墙 → 访问地址写法」顺序查
• 到 /tools/speed-test 先测本机网络延迟基线，后面判断慢是推理慢还是网络慢才有参照

数据卷这条最容易吃亏。容器是「用完可以重建」的东西，知识库数据必须落在宿主机上。如果挂载目录用了默认的匿名卷，某天你重建一次容器，之前传的文档和向量索引就全没了，而且你还不一定第一时间发现。

# 起服务示例（目录按自己情况改）\ndocker compose up -d\n# 看状态\ndocker compose ps\n# 看日志，排查启动失败用\ndocker compose logs -f --tail=100\n# 看端口有没有被占\nnetstat -ano | findstr 你的端口

接上模型：对话模型和嵌入模型要分开配

这是新手最容易踩的一处：RAGFlow 里对话模型和嵌入模型是两条独立的配置。只配了对话模型没配嵌入模型，页面看起来一切正常，但检索结果永远是空的，因为文档根本没被向量化。

对话模型

负责把检索到的内容和你的问题组织成回答，可以不本地跑

嵌入模型

负责把文档切片转成向量，决定检索能不能命中，换一次就要重跑全量

容器访问宿主机

Ollama 跑在宿主机、RAGFlow 跑在容器里时，容器内不能用 localhost 指宿主机

切片参数

文档进库前的切分粒度，切得太碎召回不全文，切得太大噪声多

混合搭配的时候要留意两边的请求格式差异。Ollama 有兼容层写法，具体怎么填可以对照 /ai-dict 里的相关词条确认。另外嵌入模型换一次就得把所有文档重新向量化一遍，不同嵌入模型产出的向量不能混用，换模型等于旧索引直接废掉，所以选型尽量一次定下来。

文档进库前还要做清洗。扫描件、复杂表格如果不做 OCR 或结构化处理就直接喂进去，解析出来的切片本身就是乱的，这时候召回质量差怪不到模型头上。如果你的资料里这类文件占比高，回到上一节重新评估一下要不要本地做。

上线后的自检清单与排查顺序

跑通不等于能用。上线后按固定顺序自检，出问题才能快速定位是链路问题、性能问题还是并发上限。

1. 验链路问一个你确认写在文档里的问题。答不上来先去看解析结果里的切片切成了什么样，多数时候是切片或嵌入没配好，不是模型不行。
2. 验延迟把慢拆成三段记录：解析慢、检索慢、生成慢。分别计时，别笼统说「很慢」，否则没法判断该优化哪一块。
3. 验并发本地机器基本只能串行服务少数几个请求，几个人同时提问就会排队。这是机器上限，不是配置调错了。
4. 定维护动作定期备份数据卷，把当前用的嵌入模型和切片参数记下来。换任何一项都要重新走一遍上面的自检。

想长期跑，日志要留下来。至少记三个字段：请求时间、命中的切片数量、生成的 token 数量。这三项能帮你区分是检索没命中还是生成截断了，出问题时才有得复盘，而不是靠感觉猜。