ollama + dify 快速搭建本地免费知识库

你可能已经在本机跑起了 Ollama，也听过 Dify 能搭知识库，但一上手就卡在「Dify 里填哪个地址」「用哪个模型做向量化」「文档传上去答非所问」。这篇不讲概念，按顺序给一套可执行的搭建动作和排查路径，顺便说清什么资料量、什么机器配置下这套方案不划算。

本机已经跑起了 Ollama，也听说 Dify 能挂知识库，但真动手时卡点往往很具体：Dify 里那一栏地址到底填什么、嵌入模型该挑哪个、文档传上去为什么答非所问。这篇不谈概念，按能落地的顺序给你一套搭建动作，从服务连通、模型分工，到切分参数和排查顺序，最后说清什么资料量、什么机器配置下这套方案不划算。

先把两个角色分清楚：Ollama 负责把模型跑起来并对外提供接口，Dify 负责把文档切片、向量化、检索再拼给对话模型。两边是串联关系，前一段不通，后面调多久都白搭。所以动作顺序永远是先命令行验证 Ollama，再进 Dify 配置，不要反过来。

先把两件事分开：Ollama 负责出模型，Dify 负责装知识库

1. 验证 Ollama 自己能出话先用命令行直接问它一句，确认能返回内容。返回为空或报连接错误，说明服务没起或者端口被占，这时候别打开 Dify，回去解决推理本身。
2. 确认监听地址和端口Dify 要填的是 Ollama 的服务地址，不是模型名字。同一台机器上跑和 Dify 跑在容器里，地址写法完全不同，这是最常见的卡点。
3. 在 Dify 里加模型供应商填地址、保存，然后点测试连通。测试不过就先查网络层，别急着调参数。
4. 各加一个能跑起来的模型对话一个、嵌入一个，先不管快慢，能通就是胜利，后面再优化。

连通性这一关过了，后面所有问题基本都在「选模型」和「切参数」上，那两件事才是真正决定答得准不准的地方。连不通就调知识库参数，等于在没通电的机器上改设置。

对话模型和嵌入模型别用同一个，各挑各的

• 对话模型管「怎么答」，嵌入模型管「找不找得到」，两者职责不同，没必要用同一个模型硬扛。
• 嵌入模型一旦换掉，已有知识库的向量基本要重建，所以上线前先定好，别边用边换。
• 重排不是必选项，但资料一多、命中飘忽时，加一个重排模型通常比换对话模型更管用。
• 量化档位影响显存占用和响应速度，怎么取舍看你的卡和能忍的延迟，别一上来就上高精度。
• 中文语义匹配这种口径，去站内嵌入模型相关页面按维度对照，比凭感觉挑稳得多。

判断标准很简单：同一个问题，检索出来的片段里有没有正确答案。有答案但回答烂，是对话模型或提示词的事；压根没召回，那就是嵌入模型或切分的事。这两类问题别混着治。

切分和召回参数，决定它答得准不准

分段长度、重叠长度、召回条数这三项要当成一组来调，不能单独拧。段落太长，噪声跟着进来；太短，一句话被切成两半，上下文就断了；重叠就是给跨段句子留的缓冲带，少了它在段边界上容易丢信息。先按文档的平均段落长度估一个值，再拿真实问题去试。

分段长度

单块文本的大小，太长噪声多，太短语义断

重叠长度

相邻块共用的尾巴，给跨段句子留缓冲

召回条数

一次塞给对话模型的片段数量，多了挤上下文

分段标识符

按段落还是按标题切，结构规整的文档优先按标题

• 结构规整的说明书、制度文件，按标题层级切通常比按固定长度切效果好。
• 散乱的会议记录、聊天导出，先人工分主题归档再入库，切分救不了脏数据。
• 检索结果要能在 Dify 里看见原文片段，答得不对时先看召回，而不是先怪模型笨。
• 同一份资料换参数前先备份或另建一个知识库，参数对比要能回滚。

如果你不确定该往哪个方向调，就固定问题、固定文档，只改一个参数看结果差异。一次改三四个参数，出了效果你也不知道是谁的功劳。

答不上来时，按这个顺序排查

1. 先查连通和索引状态模型服务通不通、知识库是否真的索引完成。索引还在跑就提问，等于问一个还没读完书的人。
2. 再查召回内容把检索出来的片段拉出来看，里面有没有正确答案。没有，问题在切分或嵌入，不生成这一层。
3. 最后查生成片段对了但回答跑偏，才轮到换对话模型或改提示词，这时候调参才有意义。

想量出瓶颈到底在哪一段，可以用站内测速工具先量一条模型的基础延迟基线，再对比知识库问答的整体耗时，两者的差值基本就是检索和切分带来的开销。具体数字到站内测速页面看当时的实测，别拿别人的截图当自己的基准。

这套方案不适用的情况也得说清楚：资料量很大、文档天天更新、或者多人同时高频提问时，本机跑模型往往撑不住，检索慢、并发一上来就排队；这种情况下更适合把嵌入或生成挪到托管接口，或者干脆用现成的托管知识库服务。判断线大致是——单机只给自己或小团队偶尔查，本地这套很划算；一旦要对外提供稳定服务，就该重新算账。