模型在 Ollama 里跑起来了，聊天也通了，但一让它回答自己的资料就开始编，这时候才想起来还缺个知识库。这篇不聊原理，只给一条能照着走的路径：先把 Chatbox 和 Ollama 接稳，再把文档喂进去，最后用几个具体问题验证到底是检索没命中还是模型没用好。
Ollama 里模型跑通了，Chatbox 里聊天也正常，但一让它回答你自己的资料就开始编——这是很多人第一次搭本地知识库时遇到的典型场景。问题通常不在模型本身，而在少了一环：把文档变成模型能检索到的内容。这篇不聊 RAG 原理，只给一条能照着走的路径，从接稳链路到验证效果，每一步都配上判断标准。
需要提前说清楚一点：搭本地知识库解决的是「模型查不到你的资料」，并不解决模型本身的幻觉倾向。两件事要分开判断，否则你会在换模型上反复折腾，而真正的问题其实出在检索没召回。下面按接链路、喂文档、做验证、卡住排查四块来走。
第一步：先把 Chatbox 和 Ollama 接稳
这一步的唯一目标是确认纯聊天链路是通的。在 Chatbox 设置里把提供方选成 Ollama，服务地址填本机地址，模型名必须和命令行里列出的一模一样。差一个标签、大小写不一致，都可能拉不到模型，但界面上往往只报一个模糊的连接失败。
- 选提供方并填地址Chatbox 设置里选 Ollama，地址填本机服务地址。本机和局域网访问写法不同，先确认你是在哪台机器上用。
- 核对模型名在终端执行 ollama list，把显示出来的模型名完整复制到 Chatbox，不要手打。
- 跑一句常识题问一句不依赖任何资料的问题，比如让它解释一个通用概念。能正常回，说明链路通，再往下走。
- 连不上时按顺序查先确认 Ollama 服务在跑，再看端口有没有被防火墙拦，最后确认地址写的是本机还是局域网 IP。具体检测口径到 /tools/verify 核对。
- 模型名和 ollama list 输出不一致，是最常见的拉不到模型原因
- 改了服务地址后最好重启一次 Chatbox 再试
- 同一台机器上服务没起来时，界面通常只会提示连接失败，不会告诉你是服务问题
第二步：嵌入模型和文档怎么选、怎么喂
知识库检索靠的是嵌入模型，不是对话模型。对话模型再强，也补不了检索阶段没召回的内容。所以这一步的优先级是：先把嵌入模型选对，再把文档切好，最后才考虑对话模型是否需要换。嵌入模型的对比清单到 /embeddings 对照着看，选中文场景下表现稳的那一类。
| 文档类型 | 处理方式 | 不处理的后果 |
|---|---|---|
| 纯文字 PDF / Word | 按章节或主题切块后导入 | 切得太碎，召回片段缺上下文，答得含糊 |
| 扫描件、图片型 PDF | 先用 OCR 转成文字再喂 | 等于没喂，检索阶段根本读不到内容 |
| 超长技术手册 | 按目录层级切，别按固定字数硬切 | 跨章节问题答不全，召回条数也不够用 |
| 多份同主题文档 | 按主题合并成一组再切块 | 同一问题召回来源分散，回答自相矛盾 |
切块粒度是这里最容易被忽略的一环。一份切得太碎的合同和一份没切的技术手册，检索效果差得很远。宁可按自然章节切，也别按固定字数硬切，后者会把一个完整段落拦腰截断。格式支持范围以 Chatbox 当前版本为准，喂之前先确认你的文件类型在支持列表里。
- 嵌入模型和对话模型是两回事，别拿对话模型的表现推断检索质量
- 扫描件先 OCR，图片型 PDF 同理，否则喂进去只是占空间
- 切块优先按章节、按主题，不要按字数一刀切
- 导入后先看索引状态，确认文档真的被处理了，而不是只显示了个文件名
第三步：用三个问题验证到底有没有生效
文档喂进去不等于检索生效。这一步用三个不同性质的问题来检验，每个问题对应一种失败模式，比随便聊几句有效得多。
| 测试问题类型 | 期望表现 | 答得不对说明什么 |
|---|---|---|
| 资料里独有的问题 | 回答里出现资料里的原话或关键信息 | 召回质量不够，检查切块粒度和嵌入模型 |
| 资料里完全没的问题 | 坦白说不知道，或明确说明没找到 | 检索阈值太松，或知识库根本没接上 |
| 跨多份文档的问题 | 能综合多份资料给出完整回答 | 切块粒度不合理，要回去调整切块和召回条数 |
这三种问题要一起跑，只跑第一种容易被误导：模型可能只是恰好在训练数据里见过类似内容，让你误以为检索生效了。第二种问题最关键，它能区分「检索没命中」和「模型自己在编」这两件完全不同的事。
卡住了怎么排查，以及哪些情况这套方案不适用
效果不对时不要一上来就换模型。按下面这个顺序往下查，每一步都能排除一类原因，比盲目替换省时间。如果查完四步还是不行，问题很可能不在配置，而在方案本身不匹配你的场景。
- 连接通不通回到第一步，用纯聊天模式跑一句常识题，确认链路本身没问题。
- 文档有没有索引成功看导入的文档是否真的被处理，而不是只显示文件名。索引失败时检索自然为空。
- 嵌入模型是不是中文友好中文文档配一个中文场景表现差的嵌入模型，召回质量会明显下降。到 /embeddings 对照当时的选型参考。
- 召回条数够不够问题涉及多点信息时，召回条数太少会答不全。适当调大再试，观察回答是否变完整。
这四步都走完还是不行，就要考虑方案本身是否合适。资料量特别大、需要按人做权限隔离、多人共用同一份知识库，这三种情况下个人版 Chatbox 加 Ollama 的组合就不合适了，该去看独立方案。站内 /stacks/vector-dbs 里列了向量库相关的组合思路，可以按自己的规模对一下。
- 排查顺序：连接通不通 → 文档有没有索引成功 → 嵌入模型是否中文友好 → 召回条数够不够
- 个人版适合资料量不大、单人使用、不需要权限隔离的场景
- 本地知识库只解决查不到自己资料的问题，模型自身的幻觉倾向要另想办法应对
- 多人共用一个知识库时，权限和隔离需求会直接超出这套方案的边界
常见问题
Chatbox 里配 Ollama 做知识库，一定要额外装向量数据库吗？
不一定。Chatbox 自带的知识库功能对个人小规模资料够用，它自己会处理索引。只有文档量大、要跨设备共享、或者要多个人分别控制权限时，才值得单独上一个向量库，否则多装一层只是多一个会坏的环节。
为什么模型明明答对了，但内容跟我的文档对不上？
先确认知识库开关在对话里是打开的，有些客户端要针对单个对话手动启用。其次是切块问题，一段话被从中间切断，检索到的就是半截意思。最后看嵌入模型是不是偏英文，中文资料用英文嵌入模型召回会明显变差。
本地跑知识库，对话模型和嵌入模型谁更吃显存？
两个都占，而且要同时常在。实际体验卡的时候，多半是先被嵌入模型挤掉了对话模型的空间。具体按参数量和量化档位算显存，可以到 /models/deploy 输入你的配置算一遍，比凭感觉猜靠谱。
