本地知识库的坑通常不在装不装得上，而在装完之后答得慢、答不准、文档一多就卡。如果你已经能跑起 Ollama，想再拉一个 MaxKB 把内部文档变成能问答的界面，这篇按「先定模型、再算资源、最后验效果」的顺序给你一条能落地的路线，并说清哪些环节不该省。
这篇只讲一件事：你已经在本地跑起了 Ollama，现在想再拉一个 MaxKB，把内部文档变成能问答的知识库界面。装不装得上一般不是难点，真正的坑在装完之后——回答慢、答不准、文档一多就卡。所以顺序建议是：先定模型，再算资源，最后验效果，别反过来。
下面每个小节都给可执行动作和判断标准。凡涉及具体参数、显存占用、模型对比数字，一律不写死，去站内对应页面看当时的记录，因为这些东西更新很快，抄一个过期数值只会误导你。
两个模型要分开挑：对话模型和嵌入模型
新手最常见的一个误解是把知识库效果全押在对话模型上。实际上这类系统里有两个甚至三个模型在干活：一个负责把文档和问题变成向量（嵌入模型），一个负责根据召回片段写答案（对话模型），条目多的时候中间还可能加一层重排。这三个是可以分开选的，也可以分开换。
| 角色 | 负责什么 | 选错的典型症状 |
|---|---|---|
| 对话模型 | 读召回片段、组织答案 | 答非所问、啰嗦、答一半就断 |
| 嵌入模型 | 把文档和问题转成向量做召回 | 问A召回B，答案里根本没相关段落 |
| 重排模型 | 对召回的候选段落重新排序 | 相关段落明明在库里，就是排不进前几条 |
- 对话模型先别追大：用一个中等规模、中文表现稳的先跑通链路，链路通了再考虑换大的。
- 嵌入模型优先看中文召回表现，知识库场景里它比对话模型更容易成为瓶颈，换它的收益往往更直接。
- 文档条目一多、相似段落扎堆时，加一层重排通常比换对话模型更能提准确率，但也要多占一份显存。
- 选型时到 /embeddings 看嵌入模型清单，到 /models 看对话模型规格，别凭印象或别人的截图定。
显存和并发的账，先算再装
装之前一定要按同一个时刻三份权重都驻留在显存里来估：对话、嵌入、重排。如果按「先加载一个、用完卸载、再加载下一个」的方式规划，实际用起来会不断在加载和卸载之间来回，响应会明显变慢，用户体验很差。
估显存还要留出上下文长度带来的 KV 缓存余量，上下文开得越长，这部分吃得越多，具体估法参考 /models/deploy。算完之后你大概率会发现：真正卡住你的不是权重本身，而是上下文和并发。
- 第一步：按三份权重同时驻留估底数把对话、嵌入、重排三份加在一起，再乘一个安全系数，得出最低显存需求。低于这个数就别硬塞，先想清楚砍谁。
- 第二步：留 KV 缓存余量按你计划开启的最大上下文长度再留一块，估法见 /models/deploy，别按默认最小值留，那是给单人测试用的。
- 第三步：按真实并发人数复算同一张卡上三个人同时提问和一个人测试完全不是一回事。先写清日常有几个人用、峰值几个人用，再决定要不要加卡或把嵌入、重排拆到另一台机器。
- 第四步：量化档位作为第一个可调项显存紧就降一档量化，但降档之后必须用你自己的问题重跑一遍。降档对长文理解和召回的影响不是均匀的，别默认「降一点没事」。
接线顺序：先通链路，再调效果
本地知识库翻车，十有八九是跳步导致的。一次装完就直接灌几百份文档，出了问题你根本不知道是服务没通、模型没选对、还是切片切坏了。正确的做法是每一步单独验证，确认这一步的输出符合预期再往下走。
- 先起 Ollama 服务确认服务能被本机访问，用命令行直接问一句，看到模型正常回话再继续。这一步不通过，后面全白搭。
- MaxKB 里填服务地址并拉模型列表地址填对、模型列表能刷出来，说明两边通了。刷不出来就是网络或地址问题，先解决这个。
- 选定对话与嵌入模型并建知识库两个角色分别指定，别把同一个模型当成万能。建完之后先在界面上确认模型状态是就绪。
- 小批量试传文档先传三五个文档，确认能切分、能召回、能出答案。这一步是验证切片参数的最便宜时机。
- 建应用并做回归测试准备一组你自己知道标准答案的问题，改一次切片长度、换一次嵌入模型、调一次召回条数，都用同一组问题跑，看的是变化方向而不是单次分数。
小批量通过之后再批量导入全部资料。切片长度这个参数没有通用最优值：太长会把无关内容一起塞给模型，太短会把上下文切碎。只能拿你自己的文档试出来，而且换一批文档类型可能要重新试。
跑通之后最容易翻车的几件事
链路通了只是开始，下面这几件事决定了它能不能长期用下去。
- 文档质量比参数重要：扫描件、复杂表格、多栏排版在切分阶段就糊掉了，这类资料要么先转成规整文本，要么接受它召回不准。
- 答不出来时先分清是没召回到还是召回到了没答对：前者动检索（嵌入模型、切片、召回条数），后者动提示词或换对话模型，修法完全不同，别乱改。
- 版本升级一次只动一个：换 Ollama、换 MaxKB、换模型三件事一起做，出问题无法定位，回退也回不干净。
- 容量规划隔一段时间复核一次：用户数、文档量涨上去之后，原来够用的配置会变得吃紧，参考 /models/deploy 重新估一遍。
- 把回归问题集固定下来并留档，每次改动前后跑同一套，这是唯一能证明你改动有效的方法。
| 现象 | 先查哪里 | 什么时候不是这个原因 |
|---|---|---|
| 回答跟我问的没关系 | 嵌入模型和切片长度 | 文档本身是扫描件或表格，先解决格式 |
| 相关段落存在却没被用到 | 召回条数和是否加重排 | 问题本身表述太模糊，先换问法 |
| 速度慢、多人用时更慢 | 并发人数与显存占用 | 单人也慢则先看模型规模和量化档位 |
| 改了配置但感觉没变化 | 是否真的重启并重建了索引 | 改动本身幅度太小，落在噪声范围内 |
本地知识库的答案是调出来的，不是选出来的。固定一组问题、一次只改一个变量，比反复换模型有效得多。下一步先把模型和嵌入清单核对清楚，再按 /models/deploy 的估法算一遍你自己的显存和并发，接着按小批量验证的顺序跑一遍链路。数字类信息一律以站内当时页面为准，别抄别人文章里的旧值。本站只给判断标准和动作，不承诺任何具体效果。→
常见问题
Ollama 和 MaxKB 到底谁负责什么？
Ollama 负责把模型跑起来并提供本地接口，MaxKB 负责文档切分、向量存储、检索和问答界面。模型能力由 Ollama 那边决定，答得准不准很大程度由 MaxKB 这边的切片和召回策略决定，两边都要调，不能只换模型。
本地知识库要不要联网？
跑通之后日常问答完全可以离线，前提是模型权重、嵌入模型和依赖都已下到本地。装的那一步通常需要联网拉镜像和模型；想彻底断网部署，就得提前把模型文件和依赖包备好再迁进内网，具体断网程度按你的安全要求定。
文档一多就变慢，先动哪里？
先分清是导入慢还是问答慢。导入慢多半是嵌入模型在批量算向量，属于一次性成本；问答慢通常是召回条数开太多、上下文塞太长，或者单卡上并发人数上来了。先把召回条数降下来试，再看要不要换更小的模型或加卡。
