ragflow 集成 ollama 怎么配

你本地用 Ollama 拉了个模型，想让 RAGFlow 用它做对话或嵌入，结果填完地址一直报连不上、模型列表空的、文档传上去不向量化。这篇不讲 RAG 原理，只讲工程落地：服务怎么暴露、地址怎么写、模型怎么加、加完怎么验、不通按什么顺序查。

你本地用 Ollama 拉了个模型，想让 RAGFlow 拿它做对话或者做嵌入，结果填完地址一直连不上、模型列表空的、文档传上去也不向量化。这篇不讲 RAG 原理，只讲工程落地：服务怎么暴露、地址怎么写、模型怎么加、加完怎么验、不通按什么顺序查。

先把预期放平：这个过程里出问题的地方基本集中在三处——Ollama 对外能不能应答、填给 RAGFlow 的地址在它那个运行环境里能不能通、对话模型和嵌入模型是不是都加上了。按下面顺序走，能省掉大量来回试。

先把 Ollama 这头准备利索：监听地址、模型与显存

Ollama 默认只监听本机回环，容器里的 RAGFlow 按本机回环去访问它，一定是不通的。要么让它监听全部网卡，要么改走宿主机在容器网络里可达的那个地址。改完配置记得重启服务，然后在宿主机上先自测一次模型列表接口，确认它真的换到了新监听地址上。

1. 改监听并重启让它监听全部网卡（或明确指定网卡），保存后重启服务，不要只改环境变量不重启。
2. 拉齐模型把要用的对话模型和嵌入模型都先拉下来，各自跑通一次推理；嵌入模型单独确认能返回向量。
3. 量显存余量按模型体量估一遍显存余量，不确定就在本地连续发几次请求，看响应时间是否稳定、会不会越跑越慢。

地址怎么写：容器、宿主机与端口三件事

第一件事是分清 RAGFlow 跑在容器里还是直接跑在系统里。这一条是最常见的踩坑点：容器内访问宿主机的本地服务，不能用本机回环地址，要用宿主机在容器网络里可达的那个地址。地址格式统一写成带协议和端口的完整形式，端口对不上或者漏写协议头，表现往往是连接被拒或超时，而不是给你一句明确的报错。

填完别急着回配置界面，先做一次最朴素的连通性验证：从 RAGFlow 所在的运行环境里直接请求一次模型列表接口。能拿到返回再回去配，拿不到就说明是网络或监听问题，界面上怎么改都没用。

在 RAGFlow 里添加模型：对话、嵌入与知识库设置

对话模型和嵌入模型通常要在模型供应商配置里分别添加，两类都要加。只加对话模型，界面看着能用，但文档传进去建不了索引、检索不到内容。添加时模型名要和你本地实际拉下来的名字完全一致，不一致时有的界面允许你保存，但调用直接失败，属于静默错误。

• 对话模型和嵌入模型分别添加，别只配一类
• 模型名照抄本地实际拉下来的名字，注意大小写和分隔符
• 填完用模型列表拉一次，确认能看到刚加的模型
• 知识库创建时选定嵌入模型后不要中途换，换意味着已有向量要重建，新旧文档会对不上
• 区分模型类型：把嵌入模型错标成对话模型，调用必失败

加完怎么验：三步验证 + 超时与并发设置

验证按三步走，三步都过才算配好：先用模型列表能拉到、再在对话里问一句常识问题看是否返回、最后传一份小文档做一次完整问答。顺序不要跳，跳步会把问题混在一起，后面很难定位。

本地模型的冷启动明显慢于云端，超时门限要按你机器的实际首字延迟来定，别照搬云端经验值。连续请求时给并发留余量，本地单机通常是串行或小并发，压太高会互相排队，表现为「每个请求都超时」。想知道自己这套配置的延迟基线大概什么水平，可以到 /tools/speed-test 量一遍，再决定超时和批量处理的节奏。

不通时的排查顺序：一张顺序清单

按「服务在不在 → 地址通不通 → 模型有没有 → 调用报什么」四步查，不要一上来就翻日志。日志往往只告诉你最终失败，不告诉你失败在哪一段。

连接类错误优先查监听地址和网络可达性；模型类错误优先查模型名、模型类型有没有配错；文档不向量化则回头查嵌入模型是否真的加上了。这三种错修的地方完全不一样，混着改只会把能用的部分改坏。

把问题定位到「哪一段不通」，比反复改配置快得多。

如果你的 RAGFlow 是跨机器或者跨网段部署，还要多确认一层防火墙和端口开放；这种情况下地址对了也可能不通，现象和监听地址写错几乎一样，靠直接请求接口来区分。