很多人装完 Ollama、跑通一次对话，就想接个界面把公司文档喂进去做本地知识库，结果卡在三个地方：模型列表里找不到刚拉的模型、文档传上去回答还是胡编、换台机器就全乱。这篇按「备模型 → 装工具 → 建库灌料 → 调检索 → 排查」的顺序走一遍，把每步该核对什么写清楚，数字类的东西一律指向站内页面现查。
很多人装完 Ollama、跑通一次对话，就想接个界面把公司文档喂进去做本地知识库。真上手会发现卡点很集中：模型列表里找不到刚拉下来的模型、文档传上去了回答照样胡编、换台机器重装一遍全乱套。这篇按「备模型 → 装工具接上 → 建库灌料 → 调检索 → 排查」的顺序走一遍，每一步该核对什么、出问题先看哪里，都写清楚。
数字类的东西一律不写死，需要对比就去站内对应页面看当时的数字。这样做的原因是模型和显卡的行情变得快，写死的结论过两个月就误导人。
开工前先把模型和显存对齐
Ollama 那边至少要备两类模型，这是整套东西能不能跑起来的底子：一个对话模型负责生成回答，一个嵌入模型负责把文档切块变成向量。只拉了对话模型就去接知识库，检索这一步根本不会启动，界面上可能给不出明显报错，只是回答永远像没看过文档。
- 对话模型
- 负责读检索回来的片段并组织成回答，主要看中文表达和长上下文能力
- 嵌入模型
- 把文档块和用户问题都转成向量，靠向量距离找相关内容，中文语料别默认用英文向模型
- 重排
- 先粗召回一批再精排，文档量大时对命中质量帮助明显，但不是必选项
显存和量化档位别拍脑袋定。按参数量、量化方式、并发人数去站内 部署参考页（/models/deploy） 算一遍，再到 算力配置页（/compute/sizing） 看这套配置合不合理，最后用 显卡对照页（/compute/gpus） 核对具体卡型。嵌入模型单独比较一次，维度、多语言支持、要不要配重排，在 嵌入模型页（/embeddings） 上一起看。
| 先确认的事 | 判断标准 | 对不上时怎么办 |
|---|---|---|
| 模型能不能被外部调用 | 用命令行直接请求一次，能返回内容 | 先修 Ollama 的监听地址，别碰 AnythingLLM |
| 嵌入模型有没有拉到 | 列表里能看到，且是中文或多语言向 | 换一个再拉，不要凑合 |
| 显存够不够 | 加载后不频繁切换、不报显存不足 | 降量化档位或换更小的模型 |
| 并发人数 | 几个人同时问会不会排队 | 按站内配置页重算 |
装 AnythingLLM 并把 Ollama 接上
装之前先决定一件事：AnythingLLM 和 Ollama 是装在同一台机器上，还是装在两台机器上。这个决定直接决定你后面要填的地址是本地回环地址还是局域网地址。同一台机器填回环地址就行；分开部署就得填另一台机器的局域网地址，还要保证那台机器的 Ollama 对外监听、防火墙放行。填错这一步，后面所有问题都表现为连不上。
- 先单独测 Ollama在命令行里直接向 Ollama 发一次请求，确认服务在跑、模型能出结果。这一步不过，装什么都没用。
- 确认监听范围如果要跨机器访问，检查 Ollama 的监听配置是否允许外部连接，再用另一台机器的命令行去请求验证一下。
- 装 AnythingLLM 并进设置在设置里把对话模型和嵌入模型分别指向 Ollama。能刷出模型列表，说明连通性这一关过了。
- 分清两类问题模型列不出来属于连通性问题；能列出但回答质量差属于检索问题。别把这两件事混着调，会来回绕。
建工作区、灌文档、跑通第一条问答
工作区是隔离单位。不同部门、不同主题的文档不要塞进同一个工作区，混在一起检索很容易命中彼此不相关的内容，回答就开始串味。按用途拆开，一个工作区对应一类问题，后面调起来也简单。
灌料之前先看切块设置。块太大会导致检索命中了却塞不进上下文；块太小语义被切碎，向量表达不准。稳妥做法是先拿一小批文档试，观察检索回来的片段是不是完整的一段意思，感觉对了再批量导入。
- 导入后先问你已知答案的问题做基线，答对说明链路通了
- 答错先看命中的片段里到底有没有答案
- 片段里有答案但模型没答对，属于生成侧问题，考虑换对话模型或调提示词
- 片段里根本没有答案，属于检索侧问题，回去调切块或嵌入模型
- 同一份文档别反复导入，会产生近似重复片段挤占命中名额
先确认答案在不在检索回来的片段里，再决定是修检索还是换模型，顺序反了纯属白换。
检索效果不理想时的调整顺序
调整要有顺序，别一次全动，否则你分不清是哪一项起了作用。推荐路径是：先看命中片段质量，再调切块大小与重叠，再考虑换嵌入模型，最后才动提示词和温度参数。前面几项是「能不能找到」，后面几项是「找到了怎么答」，找都找不到的时候调提示词没有任何意义。
| 现象 | 优先怀疑 | 先做的动作 |
|---|---|---|
| 命中的片段完全不相关 | 嵌入模型或切块 | 换多语言嵌入模型试一次 |
| 片段相关但被截断 | 切块过大 | 减小块大小、适当加重叠 |
| 相关片段检索不到 | 块太小或重复太多 | 去重、调块大小 |
| 检索对了回答还是错 | 生成侧 | 换对话模型或改提示词 |
什么情况下这套不适用？文档量很小、问题又都是常识题，检索反而添乱，直接把内容贴进上下文更省事。需要跨多个库联合推理的复杂查询，单工作区 RAG 本来就吃不住，这时候要拆问题或者换架构，别硬调参数。
常见卡点与自查清单
把排查按现象分类，比按模块顺序翻设置高效得多。下面这张清单建议直接照着走，每一项都能自己验证，不依赖别人。
- 连不上确认 Ollama 服务在跑、监听地址对外开放、两边网络能通，最后才回头看工具里的地址配置。
- 答非所问先确认内容真的进了库、检索能命中，再怀疑模型能力。顺序反了会白换模型。
- 速度慢区分是首次加载慢还是每轮都慢。首次慢通常是模型加载，每轮都慢多半和上下文长度、并发人数或显存卸载有关。
- 怀疑服务侧有问题到站内 服务状态页（/ai-status） 看一眼是不是上游本身有波动，别把服务故障当成自己配置错了。
- 准备迁移把模型清单、嵌入模型、切块参数、工作区结构都记下来。缺一样，新机器上就要从头调一遍。
常见问题
AnythingLLM 和 Ollama 是什么关系，必须先装 Ollama 吗？
不是必须，但这是最省事的组合。Ollama 负责把模型跑起来并对外提供调用地址，AnythingLLM 负责文档管理、切块、检索和界面。两者通过接口连接，所以 AnythingLLM 也可以接别家本地或云端接口，只是接 Ollama 时不需要额外配密钥。
文档传进去了，回答还是编，问题出在哪？
按顺序查：先在工具里看检索命中的片段，如果片段里根本没有正确答案，说明问题在切块或嵌入模型，调这两项；如果片段里有答案但模型没照它说，说明问题在生成侧，收紧提示词、降低温度，或换一个更听指令的对话模型。别一上来就换模型。
本地知识库搭好后，回答质量能和云端比吗？
取决于模型规模和任务类型。总结、改写、单文档问答这类任务，本地中量级模型够用；需要跨多份文档做推理、或者文档本身很长的情况，本地小模型的差距会明显。建议先用你自己的真实文档做一轮对照再决定要不要混合云端。
