ragflow ollama 本地知识库

很多人把 RAGFlow 和 Ollama 都装上了，卡在最后一步：RAGFlow 里填完地址拉不到模型、上传文档解析不动、问问题要么超时要么答非所问。这篇不讲原理，只给一套从连通验证到效果评测的操作顺序，帮你判断哪一环出了问题、下一步该动哪里。

RAGFlow 管解析、切片、检索和编排，Ollama 管本地推理，两个人各装一半，最容易卡在中间那根管线上。典型症状就三种：地址填了但拉不到模型、文档传上去解析不动、问一句要么转圈超时要么答得驴唇不对马嘴。这三个症状对应的问题完全不在一个层面，所以别一上来就换模型或者调提示词。

下面按工程落地的顺序走：先定机器和分工，再验连通，再挑模型，再进料，再调运行时，最后才是排查和评测。每一步都给你判断标准和动作，走到哪一步卡住就停下解决，别跳步。

先把机器和分工定下来，别装完再返工

装之前先想清楚三件事各自负责什么。RAGFlow 负责文档解析、切片、向量化调度、检索召回和最终编排，Ollama 只负责把 token 生成出来。向量库和文件存储是 RAGFlow 自己带的依赖，跟 Ollama 没关系。很多人把它们当成一个整体去调，一出问题就不知道打哪。

再判断你到底适不适合本地跑。只有两种情况值得：资料不能出内网，或者日常调用量大到走外部接口不划算。如果只是偶尔问几句，本地这套的维护成本——显卡占用、模型更新、解析报错——往往比省下的调用费更贵。这是个常见的误判点。

镜像有完整版和精简版，功能和体积不一样，选之前先确认你要用的解析能力在不在你选的那个版本里。具体支持哪些依赖、向量库怎么选，到站内 /tools 工具目录和技术栈相关页面按你的系统对一遍，别照着某篇教程一路复制。

连通性先跑通，再谈效果

「填了地址连不上」绝大多数不是地址写错，而是 Ollama 默认只监听本机回环地址，跑在容器里的 RAGFlow 根本访问不到宿主机上的它。这是本地部署里被重复踩最多次的坑。

1. 第一步：宿主机上确认服务活着在装 Ollama 的那台机器上直接拉一次模型列表，能返回就说明服务本身没问题。
2. 第二步：容器里访问同一个地址进 RAGFlow 所在的容器，用它看到的宿主机地址再拉一次模型列表。这一步失败，问题就在网络层，不要去改界面配置。
3. 第三步：界面里能列出模型名前两步都通过后，回到 RAGFlow 的模型设置里，看下拉框能不能列出你拉下来的模型。
4. 第四步：量一次响应时间拿一条短问题走一遍完整链路，记下耗时，作为后面判断「慢不慢」的基线。

容器访问宿主机要用容器网络里宿主机对应的地址，不是教程里那个本机回环地址，两者不是一回事。地址栏填的是基础路径，末尾多一个斜杠、少一个版本段，都会直接返回找不到。写完先用命令行验一遍再进界面。

如果你对「本地推理响应该是多少」没概念，可以到站内 /tools/speed-test 接口测速页量一遍，后面判断是网络慢还是模型慢才有参照。这个基线不建，后面所有「太慢了」的判断都是凭感觉。

生成模型和嵌入模型要分开挑

这两类模型职责完全不同。嵌入模型决定「能不能找对片段」，生成模型决定「话说得顺不顺」。很多人检索都没命中就开始换生成模型，怎么调都没用，因为错在上一层。

• 嵌入模型优先看多语言覆盖和维度是否明确，中文资料多就重点看它对中文的支持
• 生成模型优先选参数适中、能在你显存里把上下文跑满的档位，硬上大参数频繁换页反而更差
• 换嵌入模型必须重建索引，只换生成模型不用重建，这一步搞反是最隐蔽的坑
• 两类模型的选型都别只看公开分数，你的语料形态和榜单语料往往不是一回事

具体哪些模型能在你那张卡上跑起来、量化之后大概占多少显存，不要凭网上的说法判断，到站内模型库和部署测算相关页面按你的显卡规格对一遍。参数大小和显存占用不是线性关系，上下文长度也吃显存。

进料阶段决定上限，解析和切片别偷懒

知识库效果的上限在解析这一步就定死了，后面的模型再强也救不回来。先把文档分三类：纯文字、带表格、扫描件。扫描件不先做文字识别，进去的全是空切片，检索当然什么都找不到。

切片粒度按内容形态定。条列式文档切小一点命中准，叙述性长文切大一点保上下文，没有一组参数能通吃所有资料。切太小会丢上下文，切太大召回不精准，这个权衡要拿你自己的资料试。

1. 拿一份最有代表性的文件先跑单篇选你资料里结构最复杂的那份，单独导入，看解析结果是否完整。
2. 人工翻几条切片重点看有没有把标题和正文切断、有没有把页眉页脚当正文收进去、表格有没有被拆散。
3. 确认无误再批量导入批量失败时你很难定位坏在哪一篇，先单篇验证能省掉大量返工。
4. 导入后抽查检索随便问几个你知道答案的问题，看召回的片段对不对，这才是解析质量的真实检验。

超时、并发和降级：跑起来之后才遇到的坑

首次提问特别慢是正常的，模型要从磁盘加载进显存。把首次调用和后续调用分开计时，别拿第一次的耗时判断性能，否则你会误以为整个方案不可用。

本地推理的并发能力和云端接口差得远。同时几个人提问就会排队甚至超时，这时正确做法是在前端或网关层限并发，而不是加机器硬扛。限流对象从服务商换成了你自己的显卡，思路是一样的。

• 超时分两层设：检索层短一些，生成层长一些，一刀切会让你分不清慢在哪一层
• 准备降级路径：本地超时太长时能不能切到外部接口顶上
• 降级前要确认嵌入模型是否一致，不一致会导致检索结果对不上
• 排队和退避的做法可以直接沿用站内 429 与并发分档的排查思路

并发、排队、退避这套东西站内 /tools/speed-test 和接口限流相关页面讲得比本地场景更细，本地只是把限流对象换成了自己的硬件。真想清楚「这一台机器能扛几个人同时提问」，得自己压一遍，别人的数字没有参考价值。

出问题时的排查顺序，照着走别乱试

排查最忌讳乱试。下面五步是从底层往上层走的，哪一步不过就停下解决，不要跳到下一步去调模型，顺序颠倒会浪费大量时间。

1. 一、看服务是否活着Ollama 进程在不在、模型列表拉不拉得到。这一步不过，后面全是白搭。
2. 二、看网络是否通从 RAGFlow 容器里访问一次模型服务地址，区分「服务没问题但网络不通」和「服务本身挂了」。
3. 三、看解析日志文档没进库、切片数为零，多半是解析失败而不是检索失败，先看解析任务状态和报错。
4. 四、看检索结果把问题原样输进去，先看召回了哪些片段。命中的片段不对，就不用往下调生成。
5. 五、才看生成质量确认检索对了之后再改提示词和换模型。前面四步没走完就调生成，是效率最低的做法。

怎么知道它到底好不好用

别靠感觉判断。先建一套自己的小测题：从你的资料里挑若干条能明确回答的问题，再加几条资料里根本没有的问题。后者用来验证它会不会硬编答案，这一步很多人跳过，结果上线才发现它什么都敢答。

• 记录每次问答的召回片段和最终回答，出问题能回溯是哪一层错的
• 关注三类指标：找不找得到、答得对不对、答不出来时会不会瞎说
• 三者权重按场景定，客服场景里第三条往往比前两条更重要
• 换模型、改切片、加资料之后拿同一套测题重跑，判断是变好还是变差

站内评测榜单和众测雷达可以作为选型参考，但要清楚公开分数是在别人的语料上跑出来的，跟你的资料没有直接关系。选型阶段可以看榜单缩小范围，最终判断必须回到你自己的小测题上。