ollama+deepseek构建知识库

本地起 Ollama 跑模型不难，难的是把它接成一套真能用的知识库：文档切多大、检索为什么答非所问、显存和并发怎么留余量。这篇按「选模型—切文档—接检索—验收」的顺序，给一份能照着动手的清单，不追求一次到位，先把链路跑通再逐段调。

本地起一个 Ollama 跑模型，这件事本身没什么门槛，真正卡人的是把它接成一套回答靠谱的知识库。文档切多大、检索为什么老是答非所问、显存还剩多少能分给嵌入模型，这些细节决定了它是能用还是只能演示。这篇按「选模型—切文档—接检索—验收」的顺序给一份能照着动手的清单，不追求一次到位，先把链路跑通再逐段调。

先说清一件事：Ollama 只是管模型进程的那一层，它不负责文档切分、不负责向量化、也不负责检索。很多人把它当成整套方案，结果卡在「模型明明跑起来了，但问它文档里的内容答不上来」。心里先把角色分清楚，后面每一步才不会走偏。

先把链路拆成四段，再决定每段用谁

一套本地知识库至少要拆成四段：Ollama 管模型进程、对话模型负责生成、嵌入模型负责把文档变成向量、向量库负责存和查。这四段可以分开换，先别急着一步绑死。尤其对话模型和嵌入模型是两回事，嵌入模型通常要单独拉一个，指望聊天模型兼职做向量化，检索质量会很难看。

模型进程

Ollama 负责拉起对话模型和嵌入模型，管端口、并发和显存占用

对话模型

拿到召回片段后组织成回答，知识库场景对它的要求比编码类低

嵌入模型

把文档块转成向量，中文场景要挑对中文语料训练过的，选法到 /embeddings 核对

向量库

负责存向量和近似检索，量小时本地文件型就能撑，数据上量再换，对照 /stacks/vector-dbs

这一段只定角色，不定具体型号。型号和量化档位随时会变，别照抄别人半年前写的配置，按当期榜单和你的硬件实际情况选，站内榜单和资料库会持续更新。

按你的卡定模型与量化档，别按别人的配置抄

选模型的第一步不是看哪个强，是先量自己的卡：显存多少、能不能整卡独占、量化档位塞不塞得下。DeepSeek 系本地跑要区分蒸馏小尺寸和完整权重，前者消费卡有机会碰，后者不是一张消费卡的事，先确认自己属于哪一类。知识库场景对生成质量的要求低于编码类，宁可用小一档换来更长的上下文和更低的延迟。

具体档位和测算方式到 /models/deploy 和 /compute/sizing 核对当时的数字，别用记忆里的配置。显存吃紧时优先降对话模型的档，嵌入模型尽量保住，因为检索不准比生成啰嗦更致命。

切分与检索：答不准八成不是模型笨

答非所问的时候，大多数人第一反应是换个更强的模型，其实问题八成出在切分和检索。切分粒度先粗后细，段落级起步，遇到答案被拦腰截断再考虑带重叠切。表格和代码块要单独处理，混在正文里切碎了两边都用不了。

• 嵌入模型是否适合中文：用英文语料为主的模型做中文检索，命中率会明显掉，换模型再试
• 查询是否该改写：用户口语提问和文档书面表述差得远，先做一次查询改写再检索
• 召回条数是不是太少：条数偏少会让答案缺上下文，偏多又会挤掉生成模型的上下文预算
• 是否给了引用出处：让模型只依据召回片段说话，能明显减少编造，原理参考 /ai-dict/category/tech

还有一个常见误区：想用微调替代检索。这两者解决的问题不同，微调改的是模型的行为风格和领域表达，检索解决的是「模型没见过的私有文档怎么查出来」，分界到 finetune-vs-rag-choice 看，别混着上。

切分与检索的排查顺序

1. 先固定一组测试问题挑十个文档里明确有答案的问题，答案和出处都记下来，后面每次改配置都跑同一组
2. 单独测检索不看生成把召回片段直接打出来，看正确片段在不在里面。不在，问题在嵌入或切分；在，问题在生成侧
3. 调切分再调召回先动切分粒度，再动召回条数，一次只改一个变量，改完重跑测试问题
4. 最后才动生成模型前面都确认没问题了，回答还是啰嗦或偏题，再考虑换对话模型或调提示词

验收与调优：给自己定几条能复现的检查

调优最怕凭感觉，改完配置说一句「好像变好了」没法复现也没法回退。准备一组已知答案的问题，每次改配置都跑一遍，记录命中与否。这样至少能知道你这次改动是真的有效还是心理作用。

延迟要拆成检索耗时和生成耗时两段量，哪段慢改哪段，别一锅端。基线可以用 /tools/speed-test 量，并发上来后先看显存和显存外的内存，再看磁盘 IO，排查顺序参考 /vram-full-troubleshoot-guide 的思路。

最后提醒一句：链路里的每一段都别绑死。模型会换代、向量库会上量、嵌入模型可能因为中文效果不满意要换，留好替换口，下次调优才不用推倒重来。