ollama + 本地知识库

你已经能用 Ollama 跑起本地模型了，但一接上自己的文档就发现答非所问：要么检索回来的片段根本不是答案，要么模型拿着片段也说不清。这篇不讲工具怎么装，而是把「本地知识库」整条链路拆成几段，告诉你每段在干什么、哪段坏了会出什么症状、按什么顺序排查，最后给一份能照着走的落地清单。

你已经能用 Ollama 在本地把模型跑起来了，但一接上自己的文档就发现答非所问。常见两种症状：一种是它引用的原文片段根本不是答案，另一种是片段明明给对了，模型却绕着说不清。这两种毛病出在不同环节，症状不同，排查方向也不同。

这篇不讲工具怎么装，而是把「本地知识库」整条链路拆成几段，告诉你每段在干什么、哪段坏了会出什么症状、按什么顺序排查，最后给一份能照着走的落地清单。想先看各款外壳和工具的情况，可以到 工具目录（/tools） 对照，但别一上来就装工具。

先看清整条链路，别一上来就装工具

本地知识库本质上是四段串起来：文档解析与切分、向量化入库、检索召回、拼进提示词生成。每一段都有独立的失败模式，出了问题先定位是哪一段，再动手改，比换个工具重装一遍快得多。

• 文档量极少、答案基本固定，或者需要跨文档推理的场景，直接塞进上下文可能更省事，不必上 RAG
• 先确认 Ollama 服务本身可用、接口通了，再谈知识库，否则会把链路问题和环境问题混在一起
• 四段要一段一段隔离测试，别同时改切分又换模型，出了结果也不知道是谁的功劳

嵌入模型与切分粒度：决定能不能搜到

嵌入模型要跟聊天模型分开选。对话能力强的模型不代表检索表现好，中文语料优先挑中文检索表现稳的嵌入模型，别直接拿对话模型兼任。具体哪款在中文场景下更稳，到 模型资料库（/models） 看当时的资料再决定。

切分粒度按文档类型定。结构化文档按标题层级切，长段技术文档按语义块切。重叠区间的作用是防止答案正好被切在边界上，但重叠太多会把同一条信息灌进好几个候选里，反而拉低精度。

向量维度

嵌入模型输出的向量长度，换嵌入模型时维度变了，已有向量一般要重建

相似度阈值

低于这个值的候选被丢掉，调高会漏召回、调低会灌进一堆噪音

重排

先多召回一批候选，再用重排模型挑出最相关的几条，术语密集、同义表述多的语料收益明显

• 候选片段多、术语多、同义表述多时，加重排一轮，效果通常比单纯调阈值好
• 扫描件和表格要单独确认文字有没有被正确提取，这是最容易被忽略的失败来源
• 切分策略选定后先固化，调效果时一次只动一个变量

换哪个外壳接 Ollama，按自己的习惯挑

接 Ollama 的外壳大致三类：一体化应用自带上传界面，编排框架适合写自定义流程，纯脚本适合已经有自己数据管线的人。三类没有绝对好坏，看你想花时间在哪。

要清楚外壳只管交互和编排，真正影响效果的是切分和嵌入那两段。答不准时换外壳基本没用，别把时间花在换界面上。还要想清楚数据存哪：向量库是本地的还是外挂的，换工具时已有向量能不能迁走、要不要重建。

• 单机自用优先把效果调好，共用才需要考虑并发和文档权限
• 多人共用时，不同人对不同文档的可见范围要在检索层就过滤掉，不能只在界面上藏
• 换工具前先确认向量格式能不能导出，省得重建一遍索引

答得不对时的排查顺序

1. 看召回把检索到的原文片段打印出来，确认答案到底有没有被捞回来。没捞回来，问题在切分或嵌入，不在模型。
2. 看拼接确认片段有没有因为超上下文长度被截断，提示词里有没有明确要求「只根据给定资料回答，资料里没有就说没有」。
3. 看生成把同一段片段换一个模型再问一遍，如果换模型就对了，说明是生成模型的问题；换模型还是错，基本是检索的问题。
4. 看文档本身扫描件、表格、图片里的文字没被正确解析，是最容易被忽略的一类失败。回到源头确认文字有没有被提出来。

能长期用的几条底线

索引不是建一次就完事。文档更新后要增量重建索引；如果换了嵌入模型、或者改了切分策略，一般必须全量重建，否则新旧向量不在同一个空间里，检索结果会莫名其妙。

上线前至少测三类问题：能直接命中原文的、需要跨段拼的、文档里根本没有的。最后一类专门看它会不会编，如果文档里没写它还一本正经地答，说明提示词的约束没做到位。

• 本地知识库不等于数据绝对不出内网，外挂的嵌入服务、云端解析都可能把内容带出去，选型时对着站内的合规说明核一遍
• 三者分开：文档目录、索引、配置各自独立存放，换模型或换切分策略时不用推倒重来
• 定期抽查一批真实问题，记下哪些是检索漏了、哪些是模型编了，分别对应不同环节去修

想判断具体某款工具或某条链路靠不靠谱，可以到 中转站与工具导航（/sites） 看当时的整理，再到 指南中心（/guides） 找更细的操作步骤，数字和结论都以站内当期资料为准。