你在 Ubuntu 服务器上装好了 Ollama，模型也能跑，但把文档丢进去问它，答案要么答非所问，要么干脆编。这篇不讲概念，按顺序走一遍：先确认环境和磁盘，再确定对话模型与向量模型的分工，然后搭最小可用的检索链路，最后给一套出问题时的排查顺序。每一步都写清什么情况下这套做法不适用。
你在 Ubuntu 服务器上把 Ollama 装好了，模型也能对话，于是把一堆文档丢进去问它。结果要么答非所问，要么干脆编一个看起来很像的答案。多数时候问题不在模型笨，而在中间那条检索链路根本没搭对，或者你压根没验证过召回质量。
这篇按顺序走一遍：先确认环境别急着装，再分清对话模型和向量模型两个角色，然后搭一条最小可用的检索链路，最后给一套出问题时的排查顺序。每一步都写清什么情况下这套做法不适用，别照抄命令。
先做环境自检：别急着装，先确认三件事
- Ollama 服务是否在跑、监听地址是否符合预期，模型存储路径和磁盘余量够不够。路径、端口这类术语别凭记忆猜，可以先去 /ai-dict/category/infra 把口径对齐。
- 这台机器是纯 CPU 兜底，还是有可用的 GPU，显存能装下多大档位的量化模型。先算再下，模型下载和首次加载是整个流程里最耗时间的环节。
- 网络策略要提前定：完全离线，还是允许拉取模型和依赖。离线场景下所有组件必须提前准备好，不能边装边拉，否则装到一半卡住很尴尬。
| 自检项 | 怎么确认 | 不通过时的处理 |
|---|---|---|
| 服务状态 | 查进程和监听端口是否符合预期 | 重新拉起服务，确认配置里端口没被别的程序占用 |
| 存储与磁盘 | 看模型目录所在分区剩余空间 | 换到空间更大的挂载点，或先清理不用的旧模型 |
| 计算资源 | 确认有无可用 GPU 及显存上限 | 按实际显存选量化档位，别硬塞大模型 |
| 网络放行 | 断网试跑一次已有模型 | 离线就提前把模型与依赖包准备好 |
什么情况下这套自检不适用：如果你只是在一台临时机器上做一次性验证，磁盘和网络可以放宽，但服务端口和资源上限还是要看清楚，不然验证结果没参考价值。
模型分两个角色：对话的和做向量的，别混着挑
这是最常见的误区：很多人以为装一个大模型就够了。实际上对话模型负责读检索出来的片段并组织答案，向量模型负责把文档和问题映射到同一语义空间，两者可以完全不是同一个模型，职责也完全不同。
- 对话模型
- 拿到检索到的若干片段后，组织成通顺、准确的回答
- 向量模型
- 把文档段落和用户问题都转成向量，用来判断语义相似度
- 量化档位
- 在体积、速度和效果之间取平衡，档位越高越吃资源
向量模型优先看中文语义检索效果和多语言覆盖，维度大小会影响存储和检索开销，但不是越大越好。各家向量模型的能力口径，可以到 /embeddings 对照站内整理的说明，看当时的口径再决定。对话模型选多大档位，取决于你的文档量和问答深度；文档里术语多、表格多的时候，模型在长片段上的稳定性比参数量更关键。
什么情况下不适用：如果只是做关键词匹配就能满足的固定条目查询，比如查单号、查状态码，上向量检索反而增加维护成本，用简单的字符串匹配就够了。
搭最小可用链路：先跑通一条，再谈优化
- 文档切分按语义边界切，不要按固定字符数硬切。中文技术文档尤其容易被切断表格和代码块，切完抽几条人工看一眼。
- 灌库并留来源每一段都记录来自哪个文件、哪一节，方便答案回溯。切分粒度和重叠长度先取保守值，跑通后再调。
- 提问验证拿三个你自己知道答案的问题去试，先看召回的片段对不对，再看模型有没有在片段之外自由发挥。
验证的时候有个小技巧：故意问一个文档里没有答案的问题，看模型是老实说不知道，还是编一个。这一步能帮你判断后面的检索到底有没有真正约束住模型。
什么情况下不适用：文档量很小、几十页以内的时候，直接把内容塞进上下文可能比搭检索链路更省事，前提是上下文窗口放得下。别为了架构好看而过度设计。
出问题时的排查顺序：从召回查起，别先怀疑模型
- 先看召回。如果检索出来的片段本身就不相关，换多大的对话模型都没用，问题在切分或向量模型。
- 再看上下文拼装。片段顺序、数量、是否超长被截断，都会直接影响回答质量，被截断是隐形杀手。
- 最后才看生成。确认是模型没读懂，还是它在补全自己的知识。回答里出现文档中没有的具体数字时，基本可以判定是编的。
- 常见环境坑：服务端口被占、模型路径权限不对、容器内外网络不通。这类问题可以配合 /tools/speed-test 先量出延迟基线，判断是网络慢还是推理慢。
| 症状 | 先查哪里 | 大概率原因 |
|---|---|---|
| 答非所问 | 召回结果 | 切分或向量模型不匹配 |
| 答案缺一半 | 上下文拼装 | 片段被截断或数量太少 |
| 出现文档外的数字 | 生成环节 | 模型自由发挥，未被约束 |
| 整体很慢 | 环境与网络 | 网络延迟或推理资源不足 |
排查顺序的原则是先便宜后贵：召回和拼装是你能直接看的，生成环节最不可控。先排除前两段，能省下大量瞎试的时间。
上线前记一份自己的对照表
本地知识库这东西，换一次配置就很难回忆起当初为什么这么设。上线前随手记三组信息，后面任何一项改动都能快速回退比对，省下的是你自己下次排查的时间。
- 记录向量模型名称与维度、切分参数、单次问答的片段数量，这三项决定了检索行为。
- 记录一次典型问题的耗时拆解：检索多久、生成多久。本地部署慢的时候，你能立刻定位到是哪一段拖后腿。
- 记录当时用的模型档位和量化方式，换机器或重装时不至于从头试错。
什么情况下不适用：如果这套知识库只服务你一个人、文档也不常更新，那不值得维护复杂配置，保持简单反而更稳。配置越少，出问题时越容易想明白。
下一步模型和向量模型的口径、各家中转与本地方案的对照，站内都有整理。去核对当时的数字，再决定自己该选哪条路，比凭印象拍脑袋靠谱。→常见问题
Ubuntu 上搭本地知识库，最容易卡在哪一步？
多数人卡在文档切分和向量模型，而不是对话模型。切分把表格和代码切断，检索出来的片段本身就残缺；向量模型对中文不友好，语义相似的段落排不到前面。先拿几个已知答案的问题验证召回，比反复换大模型有效得多。
必须要有独立显卡吗？
不是必须，但体验差别明显。没有独显时只能跑小参数量化模型，问答深度和速度都会打折，文档量大时更明显。先按你的文档规模和可接受的响应时间算一遍显存需求，再决定是加卡还是缩小模型。
搭好之后怎么判断它到底有没有用？
拿三个标准测：答案能不能指回原文、不知道的时候会不会承认不知道、同样的问题多问几次结果稳不稳定。三条里有两条不达标，先回去调检索，不要急着换模型或加参数。
