ollama+qwen+ragflow

本地知识库最容易翻车的不是模型选型，而是接上以后：检索卡住、生成超时、并发一上来就排队、出问题还查不到是检索的锅还是模型的锅。这篇按落地顺序走一遍，从 Ollama 暴露接口、把 Qwen 注册进 RAGFlow，到流式与超时的参数取舍、出问题时的排查顺序，每一步都给判断标准，不承诺跑分。

本地知识库最容易翻车的不是模型选型，而是接上以后：检索卡住、生成超时、并发一上来就排队、出问题还查不到是检索的锅还是模型的锅。这篇按落地顺序走一遍，从 Ollama 暴露接口、把 Qwen 注册进 RAGFlow，到流式与超时的参数取舍、出问题时的排查顺序，每一步都给判断标准。

先说清一个前提：这套组合里，Ollama 负责把模型跑起来并提供接口，Qwen 是其中的生成模型，RAGFlow 负责分块、检索、拼上下文和调用生成。三者谁出问题表现都差不多，都是「答得不对」或「不回答」，所以后面每一节都会带上怎么区分是哪一层的办法。

先把服务这一层跑稳：Ollama 暴露接口、模型常驻与显存账

Ollama 装好之后默认只监听本机。而 RAGFlow 通常跑在容器里，容器里的 localhost 指的是容器自己，不是宿主机。所以注册 Base URL 时不能写 localhost，要写宿主机在容器网络里的地址。改完监听范围和端口，先在容器里 curl 一次，能通再进下一步。

# 在 RAGFlow 容器内验证能否访问宿主机的 Ollama
curl -s http://<宿主机在容器网络的地址>:11434/api/tags
# 能看到模型列表才算通，超时或拒连就回头查监听和防火墙

生成模型

Qwen 系列，负责根据检索到的上下文写回答，换它影响的是措辞和推理，不影响召回

嵌入模型

单独挑一个向量模型，负责把文本转成向量；必须和建库时用的是同一个，维度也要一致

模型常驻

让常用模型留在显存里不反复加载，能显著降低首字延迟，但会一直占着显存

显存不够时的判断顺序是有讲究的：先降并发，再降上下文长度，最后才考虑换更小的量化版本。原因很直接，前两个是可逆的配置，换量化版本会牵动回答质量和评测基线。不适用的情况是文档极长且必须整段进上下文，那就得先做分块拆解，而不是靠调低参数硬扛，硬扛只会让模型丢中间的细节。

把 Qwen 接进 RAGFlow：模型注册、分块与召回参数怎么对齐

1. 注册模型在 RAGFlow 的模型供应商里选 Ollama 类型，填 Base URL 和模型名，保存后点测试。测试通过只说明网络和接口通，不代表召回质量好，这点要记住。
2. 定嵌入模型在建知识库之前就把嵌入模型定下来，之后建库选它。一旦建库完成再换嵌入模型，等于整个库的向量全部作废，要重嵌。
3. 调分块先按嵌入模型的可用上下文给一个保守的块大小，跑一遍检索看命中的块是不是完整语义单元；块太大会被截断，太小会把一句话切两半。
4. 调召回条数先给一个较小的召回条数，然后拿真实问题去问，答不全就加一条再加一条。给太多会把上下文挤爆，生成端反而开始丢信息。

嵌入和生成完全可以拆到不同机器上跑，一台专心做向量，一台专心做生成。但前提是两边的模型版本要固定住，随便升级一边都会让检索结果出现漂移，而漂移往往很难第一眼察觉。想知道自己这条链路大概什么水平，可以到 /tools/speed-test 量一遍延迟基线，跟后面调整做对照。

超时、并发与降级：让它在自己的机器上别把自己拖死

本地推理没有云端那种弹性，请求一多不是自动扩容，而是直接排队或者把显存打爆。所以并发数要按显存和卡的算力压着设，宁可让请求排队，也不要让显存爆掉。先量一遍单请求耗时，再决定能放几个并发进去，这个顺序不能反。

• 超时分两段配：检索段和生成段分开设，生成段要吐字，给得比检索段长
• 前端已有整体超时时，让后端超时略小于前端，避免用户侧先断、后端还在跑
• 降级路径提前定：本地模型超时就回落到更小的本地模型，或只返回检索结果不生成
• 两种降级都要写进配置并在日志里标记，不要等线上出问题临时拍脑袋
• 并发上限写死在配置里，别依赖运行时动态判断，动态判断在压力下最不可靠

还有一个容易被忽略的点：模型常驻虽然省加载时间，但会把显存长期占住，如果同时还要跑嵌入模型，就要算清楚两边加起来够不够。不够的话，要么让嵌入模型按需加载，要么把它挪到另一台机器上。

日志与评测：出问题能定位到是哪一段的锅

每次问答至少记下四个字段：命中的文档块 id、拼进上下文的字符数、生成耗时、是否走降级。没有这几项，事后排查只能靠猜。这四个字段不占多少存储，但能让你一眼看出是根本没召回，还是召回了没拼进去，还是拼进去了模型没用好。

1. 建小评测集挑十几条你真实会问的问题，每条附上期望命中的文档。不用多，但要稳定，每次改配置都跑一遍。
2. 分两类失败检索没召回是一类，召回对了但答错是另一类。前者换文档或调召回，后者调提示词或换生成模型，混在一起改就是瞎改。
3. 让答案带来源要求模型在回答里带上来源块编号，用户一眼能看出是资料里没有，还是模型自己编的。
4. 定期回归改分块、改召回条数、换模型、升级任意一边的模型版本，都跑一遍评测集，别凭感觉判断有没有变差。

这套流程不需要多高深，难的是坚持。本地知识库的体验差距，往往就藏在这几个字段和这十几条问题上。想对比不同中转或官方渠道的当前情况，可以到 /price-watch 看价格追踪，再回 /sites 核对可信度检测的结论。