chatbox ollama 本地知识库

你手上有几百份内部文档，不想传到任何云上，于是装了 Ollama 拉了个本地模型，又装上 Chatbox 想直接问自己的资料——结果发现它只能聊天，文档一多就答非所问。这篇不讲原理，只讲顺序：资料怎么整理、知识库和对话模型分别该看什么规格、检索不准时按什么步骤排查。

先确认这套组合到底解决什么、不解决什么

先把分工说清楚：Chatbox 是壳，管的是界面、会话列表、上下文怎么拼；Ollama 是发动机，管的是把模型跑在你自己的机器上。真正决定知识库答得准不准的，是切分和检索这两步——文件怎么切成块、问题来了怎么捞回相关的块，这两件事跟聊天界面长什么样一点关系都没有。很多人调不好，一直在换界面、换提示词，其实是切分和检索没弄对。

怎么快速判断该不该上这套组合？拿你最常问的那类问题，自己先想一下：不用打开任何文件，你脑子里能不能说出答案大概在哪份文档的哪个位置。能，说明是事实查找，这套组合合适；不能，而且需要通读或对比多份材料才能回答，那它就不是对的路子，别在这上面耗时间。这个自查三十秒就能做完，比装完再发现不对省事得多。

• 资料已经躺在本地，不想往云端传，隐私是硬约束
• 问题类型以「有没有、在哪、具体怎么写」为主
• 文档量级在几十到几百份，还在人工能维护切分规则的范围
• 能接受第一次准备时连网拉模型和依赖，之后可以完全不联网使用
• 愿意花时间调切分粒度和检索条数，而不是指望装完就准

关于离线，有个常见误会要提前说清：这套组合跑起来之后确实可以拔网线用，但第一次装模型、下依赖、装运行环境这些步骤都是要联网的。所以别在完全断网的环境里从零开始装，先把模型和依赖拉全，验证能正常跑一轮，再断网测试。断网之后如果还能正常回答，说明本地这条链路是通的。

如果你还在纠结选哪套本地组合，先别急着装。到 /ai-nav/category/ai-note 把同类笔记类工具的分工看一遍，重点看它们各自把力气花在界面、推理还是检索上。看完你会更清楚：你要的到底是换一个更好看的壳，还是把切分和检索这两步做扎实——后者才是这套组合能不能用的分水岭。

资料先整理再入库：切分粒度比模型更影响结果

很多人第一次搭本地知识库，把力气全花在换模型、调参数上，结果回答还是跑偏。回头一查，八成不是模型的锅，是喂进去的资料本身就乱：一份 PDF 带着页眉页脚、目录页、每页重复的版权声明，模型检索到的那段文字根本没法用。所以入库前先做一次整理，收益比换个更大的模型明显得多。

• 统一转纯文本：不管原始是 PDF、Word 还是网页，先想办法转成不带排版的纯文本，图片里的字要么单独做 OCR，要么直接放弃这一页；
• 删掉重复模板：页眉、页脚、页码、公司落款、每页都出现的免责声明，这些内容看着无害，但会在检索时反复命中，把真正有用的段落挤掉；
• 剔除无内容章节：目录页、封面、修订记录、空白页不要入库，它们不承载知识，只增加噪声；
• 检查转换质量：转完之后随便挑几页读一遍，确认没有把段落顺序打乱、没有把两栏排版串成一团；
• 保留一份原始文件：整理后的文本和原始文件对应放好，方便后面发现回答不对时回查是哪个环节出的问题。

整理完就该切分了。切分最忌讳按固定字数硬切，一段话被腰斩成两半，语义就断了。更稳的做法是按语义切：一份文档尽量围绕一个主题，一级标题到下一级标题之间算一块，单块控制在几百字以内。太长的段落自己手动拆一下，拆的时候保证每块本身能读懂，不依赖上一块的上下文。

切完之后，每块都要带上元信息再入库：来源文件名、所属章节标题，如果能顺手写上页码或文档版本就更好。这些信息在检索时不一定直接参与匹配，但在生成回答时能作为出处展示，让你知道这句话是从哪来的。更重要的是排查方便——回答错了，你能直接定位到是哪一块被检索出来并且喂错了，而不是对着一堆没有出处的碎片干瞪眼。

对话模型和嵌入模型分开选，别只盯着对话那个

本地知识库这条链路里，很多人把注意力全放在对话模型上，挑来挑去纠结哪一个更聪明，结果嵌入模型随手选了个默认的。实际用起来，回答答非所问、找不到该找的那段资料，问题往往出在检索那一步，而不是对话那一步。这两个模型各管一段，要分开挑。

对话模型

负责把检索回来的资料组织成一段人话，挑的标准是本地跑得动、中文表达顺

嵌入模型

负责把你的文档和提问都变成向量去比对，挑的标准是中文检索准、召回全

重排模型

在初步召回之后再精排一次，只在你的资料高度相似时才有明显收益

对话模型：先看跑不跑得动，再看中文顺不顺

对话模型的取舍顺序应该反过来：先确认你的显存和量化档位能不能撑住，跑得动是底线，跑不动再聪明也没用。撑住之后再对比中文表达是否自然，尤其是让它照着检索到的资料复述、归纳的时候，会不会出现机翻腔或者漏掉关键限定词。

1. 先定显存预算估一下你能留给模型的显存有多少，把系统和其他进程占用的部分先扣掉，剩下的才是可用额度
2. 挑量化档位同一个模型通常有多个量化档位，档位越低越省显存但表达越糙，先用低档位跑通，再往上试
3. 拿自己的资料实测别只看别人推荐，用你真实的知识库问五到十个问题，看它是否只依据检索结果作答、有没有编内容
4. 规格以站内为准具体有哪些型号可选、各自的参数量和上下文长度，到 /models 看当时列出的规格再定，别照抄别人文章里的清单

嵌入模型：决定你能不能找对那段话

嵌入模型负责把文档切成的片段和你的提问都转成向量，然后按相似度找最接近的一批。它选得不好，后面对话模型再强也救不回来，因为喂给它的资料本身就是错的。中文资料尤其要注意：有些嵌入模型主要用英文语料训练，中文检索时召回会明显偏弱。

换嵌入模型要注意一件事：换了之后，原来已经向量化入库的文档必须重新跑一遍，否则新旧向量不在同一个空间里，检索结果会乱。所以嵌入模型尽量在正式建库之前就定下来，别等装了几千份文档再改。

重排要不要加，看你的资料像不像

重排做的事，是在初步召回的十几条片段里再精确排一次序。它的收益完全取决于你的资料长什么样：如果一批文档翻来覆去讲同一件事，措辞接近、结论也接近，初步召回很可能把几条近似片段都捞上来但顺序不对，这时候加重排能明显把最相关的那条顶到前面。

• 资料高度相似、同一主题有多个版本或多次修订：建议加重排，先小范围测一下排序前后差异
• 资料主题彼此差异大、一份文档只讲一件事：初步召回通常已经够准，重排可以先省掉
• 机器资源紧张、响应速度优先：重排会额外增加一次推理，跑不动就先不加
• 加了重排但回答质量没变化：说明瓶颈不在排序，回去检查切分粒度和嵌入模型

判断顺序建议是：先把嵌入模型和切分方式调好，看初步召回的结果对不对；召回本身就不对，加重排也没用。等召回基本靠谱了，再决定要不要用重排去抠那最后一点排序精度。

检索调不好时的排查顺序

检索效果差，十有八九不是对话模型笨，而是链路上某一环出了偏差。先别动模型，按「召回 → 排序 → 生成」三段往回查，能省掉大量瞎试的时间。

1. 第一步：验召回挑一句你百分百确定答案写在某份文档里的问题去问，最好带上文档里独有的词。如果连相关片段都取不出来，问题在切分粒度或嵌入模型，跟对话模型没关系——换模型也救不回来。
2. 第二步：看排序片段取回来了、但答案没被用上，说明它排在返回条数之外或被挤到后面。先把返回条数调大、加重排，再把相似度阈值放宽一档，看结果有没有变好。
3. 第三步：查生成上下文里明明有正确片段，模型还是答偏，那就是生成侧的问题：换对话模型，或把提问方式改得更直白、限定「只依据给定资料回答」。
4. 第四步：单变量记录每次只改一个变量，改完跑同一批问题记一次结果。同时改切分和条数，你永远不知道是哪个起了作用，下次也没法复现。

• 建完先备一批已知答案的问题当小测集，别拿新问题边问边调；
• 准确率不达标先回去改切分，别急着换模型，换模型通常只影响最后的表达；
• 同一份文档切太碎会丢上下文，切太长又会稀释相似度，两头都要试；
• 每次调完把「改了啥、结果如何」记一行，否则调到最后全靠记忆猜。