ollama 本地部署 ragflow

很多人把 ollama 装好、RAGFlow 也起来了，一到「把两边接上」就卡住：模型列表里看不到本地模型，文档传上去解析报错，问答答非所问。这篇不重复部署教程，只讲两个组件怎么对接、参数怎么配、哪一步出问题该怎么按顺序查。

把 ollama 装好、RAGFlow 也拉起来，这两件事本身都不难，真正卡人的是中间那一步：让 RAGFlow 把 ollama 当成模型提供方来用。表现通常很一致——模型下拉框里看不到本地模型、填了地址保存报错、文档传上去解析失败，或者好不容易问答跑通了一问三不知。这篇不重复两边的安装教程，只讲对接链路、参数怎么定、以及出问题时按什么顺序查。

先说结论：这套组合能跑通，靠的不是某个神奇参数，而是把三段链路分别验证过——模型服务本身可用、RAGFlow 所在环境能访问到它、索引确实建好了。任何一段跳过不验，后面就会在完全错误的地方调参。全篇的判断标准和资源对照，如果站内已经整理过，直接去站内模型资料库页面核对当时的数字即可，不要凭记忆拍脑袋。

先分清谁管什么：RAGFlow 要的其实是三样东西

很多人一上手就去 RAGFlow 后台翻配置项，翻完还是不知道自己在配什么。其实这里的关系很简单：RAGFlow 不内置模型，它只是调用外部模型服务来完成对话成文、向量化、以及可选的召回重排。ollama 在整个链路里只扮演一件事——模型服务提供方。

对话模型

把检索到的片段和你的问题拼在一起，生成最终回答；它决定了表述质量，不决定能不能找到答案

嵌入模型

把每个文档块和用户问题转成向量用于相似度检索；它决定召回质量，是检索效果的地基

重排模型

对初筛出来的候选片段重新排序，可选；加上通常召回更准，代价是显存和一次额外调用

这三者可以来自不同地方，也完全可以只把嵌入模型放本地、对话走外部接口，反过来也行。建议动手前先在纸上写清楚这三个位置各放什么，因为嵌入模型一旦定了并建过索引，换它就意味着已入库文档全部要重建向量，之前的时间基本白花。

• 文档解析、切分、检索召回、引用拼装这些活，全部在 RAGFlow 侧完成，不要指望 ollama 帮你管知识库；
• 三个模型位置先定稿再传文档，顺序颠倒就是返工；
• 小规模场景可以直接省略重排模型，流程少一环就少一个出错点；
• 如果只是拿一两个文件问答，其实用带文件对话的客户端更省事，本地知识库的收益要在文档量上来之后才明显。

模型准备：对话、嵌入、重排要各挑一个

模型不是随便拉几个就行。对话模型和嵌入模型虽然都由 ollama 提供，但它们承担的职责完全不同，挑的时候看的指标也不一样：对话模型看中文表达是否通顺、是否会胡编，嵌入模型看中文语义相似度检索是否靠谱。后者才是检索型应用的地基，很多人反过来把精力全花在换对话模型上，答得不好就再换一个，其实问题一直出在前一步。

量化档位是另一个容易忽略的点。压低精度的量化版本省显存，但语义精度会有损失，而检索场景对精度比对话更敏感——对话模型偶尔措辞差一点你能看出来，嵌入模型精度掉了是悄无声息的，表现就是「召回的东西总差那么一点」。显存够就别压太狠。具体某个模型的显存测算和中文效果对比，去站内模型资料库和部署测算页面看当时的数据更靠谱。

让 RAGFlow 能访问到 ollama：地址怎么写是第一个坑

这是最高频的卡点，而且现象往往有迷惑性：你在自己电脑的浏览器里打开模型服务地址是通的，RAGFlow 里就是连不上。原因八成是「从哪访问」这件事被搞混了。判断标准只有一条——谁去发请求，就以谁的位置写地址。

• RAGFlow 跑在容器里、ollama 跑在宿主机：容器内的本机回环地址指向容器自己，不是宿主机，必须换成宿主机的容器可达地址；
• 两者都在宿主机直接跑：可以用本机地址，但要确认模型服务监听的不是只绑回了本机网卡；
• 两者都在同一个容器网络里：用服务名或容器名互访，比写 IP 更稳；
• 改完监听配置一定要重启服务，光改文件不重启是白改。

验证方式别偷懒，用一次最简单的模型列表请求去测，通了再去 RAGFlow 里填。另外提醒一句：本地联调只需要容器网络内互通，不要图省事把模型服务暴露到公网，暴露面越大越容易被扫描和滥用，而这个服务本身几乎没有鉴权。

RAGFlow 侧的填写顺序：先存再测，别一次全填完

配置界面里项目不少，一次性全填完再点保存，出错了根本不知道是哪一项的问题。更稳的做法是分层提交：先把提供方和密钥那一栏存下来、确认连接测试通过，再去分别配置三个用途的模型。这样任何一步失败，排查范围都被限制在一层里。

1. 第一步，存连接信息填好模型服务地址和密钥后先保存，看连接测试是否通过；不通过就别往下走，问题在连通性上
2. 第二步，分别指定用途对话、嵌入、重排分属三个不同的配置位置，逐个填入模型名；填错位置的表现是流程能跑但检索结果全空
3. 第三步，锁定嵌入模型嵌入模型一旦建过索引就不宜再换，确认无误后再传文档，避免清库重建
4. 第四步，传一篇小文档试跑先用一篇短文档走通完整链路，再批量导入，缩小第一次排错的变量

文档进来之后：解析、切分、检索三段各有可调项

链路接通只是开始，接下来三段各有自己的旋钮，而且它们影响的症状很容易被混为一谈。粗分一下：解析决定内容有没有被读出来，切分决定召回粒度，检索决定最终喂给模型的是什么。

纯文字类文档用轻量解析就够；带复杂表格或扫描件的文档需要更强的版面解析能力，代价是处理时间明显变长，这一点在做资源规划时要提前算进去。切分参数没有万能值，判断标准是打开召回的片段看一眼：如果一段里塞了三个不相干的话题，说明块太大；如果一句话被从中间截断，说明块太小或者重叠不够。

• 建索引是异步的，显示上传成功不等于能提问，要等解析完成状态；
• 先看召回的片段是否相关，再看最终回答，顺序颠倒会误判问题所在；
• 答得差先怀疑召回，别急着去换更大的对话模型；
• 批量导入前用单篇文档确认参数，一旦定稿再批量传，减少重建次数。

联调不通的排查顺序：从下往上，一次只动一层

联调阶段的效率差别，几乎全在排查顺序上。原则是自下而上、一次只动一层，每层验证通过再往上走。最常见的浪费是：地址还没通就去调切分参数，或者召回明显不相关却一直换对话模型。

1. 第一层，模型服务本身直接对模型服务发一次最简单的推理请求，能返回内容说明服务是活的；不通就在这一层解决
2. 第二层，网络可达性从 RAGFlow 所在的环境去访问那个地址，而不是从你自己的电脑；命令能通才说明容器能通
3. 第三层，模型是否被识别在 RAGFlow 的模型列表里能不能选中目标模型；选不中就说明前两层还有遗留问题
4. 第四层，检索质量单独看召回的片段是否相关，最后才看最终答案；这一步之前不要动任何切分参数

一个实用技巧：每次只改一个变量然后重测。同时改地址、换模型、调切分参数，问题解决了你也不知道是哪个起了作用，下次遇到同类问题还得从头猜一遍。

显存、并发与延迟：本地知识库真正的瓶颈在哪

很多人以为本地知识库的瓶颈是显卡，其实要分开看：对话模型和嵌入模型如果同时常驻，两者会一起占显存，显存不够时表现往往是回答中途中断或直接报错，而不是「慢一点」。而文档解析阶段主要吃 CPU 和内存，跟 GPU 关系不大，解析卡住的时候加显卡没有用。

• 并发不高时让模型常驻内存能明显减少首次响应等待，代价是这部分显存被长期占住；
• 同时跑对话和嵌入两条链路时，先算总量再决定是否加载重排模型；
• 解析慢先看 CPU 和内存占用，不要盲目归因到显卡；
• 具体该配多少资源，用站内部署测算页按模型和量化档位算一遍，比凭经验猜靠谱。

什么情况下别用这套组合

这套方案适合个人或小团队自建私有知识库，但有几类场景它会明显不划算，提前识别能省不少时间。判断标准不是「技术上能不能做」，而是「做完之后谁来维护、维护成本有多高」。

把这套组合搭通的时间，八成花在「知道该查哪一层」上，剩下的才是调参数。