1. 为什么把 Deepseek 装进本地知识库：先想清楚你要解决什么问题

一个很常见的场景：公司内部有一堆制度文件、产品文档、历史项目记录，用通用大模型问，它要么答得泛泛，要么直接胡编。上传到云端服务又担心数据泄密，审批流程走三个月。于是很多人把目光投向“Deepseek + 本地知识库”这个组合——把 Deepseek 模型部署到自己的服务器，再把你的文档切片、向量化、存进本地数据库，让模型先检索你的资料再生成回答。这事的本质是检索增强生成（RAG），Deepseek 负责“能说会道”，本地知识库负责“言之有据”。它适合三类人：有数据隐私要求的企业内部工具开发者、想零成本搭建个人知识管家的技术爱好者、以及准备入门大模型应用但不想被云 API 绑定的工程师。别被“本地部署”四个字吓到，现在的工具链已经磨得相当顺，跟着下面步骤走，半小时能跑通最小可用版本。

2. Deepseek 本地部署：从 Ollama 到 vLLM 的两条路线

2.1 Ollama：零基础最快跑通的最小命令

先说结论：如果你是第一次玩本地部署，别纠结框架，直接上 Ollama。它把模型下载、运行、开放 API 这三件事封装成了几条命令，几乎不需要理解底层推理引擎。

执行 ollama run 后会进入交互式命令行，直接敲问题就能得到回复。 ollama serve 会在本机 11434 端口起一个 OpenAI 兼容的 HTTP 服务，你的知识库后台程序可以通过 http://localhost:11434/v1 来调用模型。这里的 deepseek-r1:7b 是模型标签，常见的有 7b 、 14b 、 32b ，数字越大效果越好但显存需求越高。量化版本还有 q4_0 、 q8_0 这些后缀，默认拉取的是 q4_0 量化，效果和速度比较均衡。想微调温度时用 OLLAMA_API_BASE 环境变量指定服务地址即可，这是后话。

Ollama 的最大价值是“零配置”，适合先跑通业务逻辑。但它也有个明显的软肋：并发高了之后单请求排队严重，而且缺乏批处理优化。如果你的知识库只有三五个人用，Ollama 完全够；如果要做成面向几十人的内部系统，就该换 vLLM 了。

2.2 vLLM：需要并发和高吞吐时的选择

vLLM 是工业界用得最多的推理引擎，它最核心的技术是 PagedAttention——把显存里的 key-value cache 按页管理，避免碎片化浪费，因此能支撑更大的并发吞吐。同样是 7B 模型，vLLM 的单卡并发能力可以到 Ollama 的数倍，这决定了它更适合做正式服务。

这里 --model 参数要填 Hugging Face 上的模型仓库路径， --served-model-name 是给外部调用用的名字，你可以随意起，知识库配置里填这个名字就行。 --gpu-memory-utilization 0.9 表示允许模型用掉 90% 的显存，剩下的留给后续可能加载的嵌入模型。 --max-model-len 8192 很关键：本地知识库检索回来的内容本身就长，加上提示词模板，模型上下文长度设太短会被截断，但设太长又会加大显存压力，8K 是一个兼顾文档长度和显存占用的起步值。

vLLM 对驱动和 CUDA 版本要求偏严，部署时先确认 nvidia-smi 显示的 CUDA 版本和 PyTorch 对应。如果显卡驱动太老，会报一堆“无可用设备”的错，这是最常遇到的翻车点。

2.3 量化版本与显存预算：别让模型撑爆内存

很多人忽略的是：同样叫 Deepseek 7B，不同量化格式的显存需求可能差出两倍。我一般遵循这个估算逻辑：模型显存占用约等于参数数量乘以每个参数字节数。FP16 下 7B 模型约 14GB，INT4 量化后约 4GB，再加上 KV cache 和运行时开销，实际占用要再乘 1.2 左右。下表是常见选择：

如果显存只有 4GB，别硬上 7B 模型，退到 1.5B 版本反而能换来快得多的响应速度。实际业务中，知识库质量对回答准确率的影响远大于模型规模，用 7B 模型配一套好检索策略，效果往往胜过 32B 模型配一个糟糕的切片方案。

3. 搭本地知识库的两种主流路径

3.1 零代码方案：用 AnythingLLM 让非技术人员也能搭

如果你只想先看效果，不想写代码，AnythingLLM 是最合适的入口。它是一个桌面级应用，内置了向量数据库和 RAG 流程，你只需要把它指向本地 Deepseek 的 API 地址。

操作路径大致是：下载安装 AnythingLLM → 配置语言模型类型为“Ollama”或“OpenAI 兼容”，填入 http://localhost:11434 → 创建新的工作区 → 上传 PDF、Docx、TXT 文档 → 点“保存并嵌入” → 开始对话。软件会自动完成切块、向量化、存储三个步骤，界面上的“Chunk Size”和“Chunk Overlap”两个参数就是控制切片粒度的。

这套方案的好处是省时，坏处是黑匣子。你很难看清它到底切了多少块、每块多长、检索时用了什么相似度函数。一旦出现“答非所问”，排查起来只能靠猜。所以我的建议是：AnythingLLM 适合验证想法和给业务方演示；真正要落地成产品，还得走下面这条自己攥线的路子。

3.2 自写 RAG 管线：从文档切片到检索生成的 Python 脚本

自己写 RAG 管线没有想象中难，核心就四步：加载文档、切片、向量化存库、检索后拼 Prompt。下面是一个可以跑通的最小实现，依赖 chromadb 、 sentence-transformers 和 requests 。

这段代码有四个值得解释的细节。第一， PersistentClient(path="./kb_store") 指定了向量库的持久化目录，下次重启还能读，前提是路径不变；很多人随手填个临时目录，重启后所有内容消失。第二， SentenceTransformer("BAAI/bge-m3") 会从 Hugging Face 下载模型，第一次运行需要联网，之后就在本地缓存了；bge-m3 对中文语义的捕捉明显优于通用的 all-MiniLM-L6-v2 。第三，切片用 chunk_size=400 字符、 overlap=50 ，这个组合在大多数中文制度文档上表现稳定，400 字一段既能覆盖完整观点，又不至于太长导致检索时相似度被稀释。第四，调用 Deepseek 时用了 OpenAI 兼容接口的 chat/completions 路径，这是 Ollama 默认提供的，所以你甚至可以把这个脚本里的 URL 换成任何兼容 OpenAI 协议的服务。

3.3 嵌入模型选型与相似度计算：别让向量库拖后腿

整个 RAG 链路里，最容易被低估的是嵌入模型。它负责把文字变成向量，而向量之间的距离直接决定了检索质量。中文场景下我推荐 BAAI/bge-m3 ，它是目前开源里中英文混合效果最稳的选择之一，输出维度 1024，检索时用余弦相似度。另一个备选是 nomic-embed-text-v1.5 ，维度 768，速度快一些，但中文长文本上有些飘。

相似度阈值也要设。Chroma 默认返回距离最小的结果，但不会告诉你“这些结果到底相不相关”。我一般会在代码里拿到距离值，当最小距离大于某个值时（比如 bge-m3 的余弦距离超过 0.6），直接回复“知识库中没有检索到相关内容”，避免模型拿不着边际的上下文硬答。这个阈值需要你在自己的文档上试出来：取十条你确定相关的查询，看平均距离是多少；再取十条不相关的，看上限在哪，取两者的分界线。

4. 应用场景解析：同一套架构在不同场景下的配置差异

4.1 企业内部制度问答：文档权限与增量更新

企业制度的典型特点是更新频繁、权限敏感。比如报销制度一年改三四版，旧文件没删，新旧条款一起被检索到，模型很可能把两版政策混着答。解决方法是给文档打元数据标签，比如 {version: 2025-04} ，检索时在向量库里加过滤条件，只查当前有效版本。Chroma 支持 where 过滤，在上一节的代码里给每条切片额外加一个 metadata 字段即可。另一个痛点是权限：普通员工问薪酬绩效制度，系统不能把高管版的文档答案给出来。常见做法是给知识库按部门分多个集合，调用时根据用户身份选择 collection ，而不是靠提示词说“你只能回答人事制度”。

4.2 科研与技术文档知识库：引文溯源与分段策略

科研场景下的核心诉求不是“答案”，而是“依据”。模型回答物理问题时，你得让它背后引用具体的段落，读者才能复核。这就需要在 Prompt 里强制模型输出引用编号，或者在代码里把检索到的多个片段拼接成带 [1] [2] 标记的上下文。切片策略也要跟着调整：学术论文的长段落经常超过 800 字，如果固定按 400 字切，一个完整论点被切成两半，检索只命中一半，回答就残缺。更好的做法是按段落先拆分，再对超过 500 字的段落做二次切割，并且保留段落标题作为上下文前缀。这样切片自带标题信息，检索时命中率会明显提升。

4.3 代码仓库问答：把 RAG 接到代码上下文

开发者常想用本地模型回答“这个项目里某功能在哪实现的”。代码的切块和自然语言完全不同，按行切会把函数定义和调用拆开，按类切又会把大文件撑爆上下文。我一般用 AST 解析代码，提取出函数签名、文档字符串和函数体前 50 行，作为一个独立切片存库。查询时，先把自然语言问题转成关键词组合，比如问“登录超时怎么处理的”转成 login timeout ，再用 BM25 全文检索加向量检索混合召回。这种场景下，Deepseek 的代码能力足够胜任，但嵌入模型最好别用 bge-m3，它对代码结构的理解偏弱，改用 jina-embeddings-v2-base-code 会好一些。没有条件换模型时，至少要把查询语句中的英文关键词提取出来，拼进原问题里去检索，能缓解不少。

下表汇总了三个场景的推荐参数，方便直接抄作业：

5. 本地 RAG 部署避坑手记：5 个最容易翻车的地方

5.1 模型答非所问，像完全没读过你的文档

现象：无论问什么，模型都在“东拉西扯”，回答内容和你上传的制度文件没有任何关系。

原因：八成是检索环节空手而归，知识库压根没返回相关片段。最常见的情况是嵌入模型第一次加载时下载失败，向量库里存的是全零向量，检索自然什么也查不到。另一种原因是文档本身是扫描版 PDF，里面全是图片，没有可提取的文本。

解决：先抛开 Deepseek，单独跑一次 query 函数，打印 hits["documents"] 看有没有内容返回。如果为空，检查文档源文件能否用 open 读到纯文本；扫描 PDF 需要先 OCR 再入库。如果返回了内容但答非所问，多半是 Prompt 里没有强调“只基于资料回答”，模型自己开了脑洞。

5.2 检索召回的内容全是不相关片段

现象：知识库里明明有正确答案，检索出来的 top3 片段却牛头不对马嘴。

原因：这是嵌入模型和切片策略共同导致的。一是切片过小，一句话的语义被切碎，向量化后失去了上下文；二是查询语句和库里的表达方式差异过大，比如库里的文本写的是“差旅标准”，用户问“出差能报多少钱”，两个向量的余弦相似度很低。

解决：把 chunk_size 从 400 调到 600 试试，同时增加重叠到 80。但更稳妥的办法是给检索加“查询重写”：用 Deepseek 把用户的问题改写成知识库更习惯的说法，再拿去检索。比如原问题“出差能报多少钱”重写成“差旅费报销标准是什么”，命中率立竿见影。这一步用 ollama run deepseek-r1:7b 配合一个极短的 Prompt 就能实现，延迟也就几百毫秒，值得。

5.3 本地模型加载后响应慢得像死机

现象：输入问题后，命令行光标闪烁十几秒才出第一个字，多问几轮甚至直接断连。

原因：显存不足导致模型把权重和缓存换到内存里，推理速度会掉一个数量级。另一个常见原因是启动 vLLM 或 Ollama 时没有限制并发，多个请求同时打进模型，互相抢占显存，每个请求都被拖慢。

解决：查看 nvidia-smi 确认显存占用率。如果显存占用已经超过 95%，换成更小的量化版本，或者把 --max-model-len 从 8192 降到 4096。在 Ollama 里可以通过环境变量 OLLAMA_MAX_LOADED_MODELS=1 强制同时只加载一个模型，避免它为了并行把多个模型塞进显存。如果用的是 vLLM，加上 --max-num-seqs 8 限制同时处理的请求数，让单请求延迟优先。

5.4 中文文档切片把一句话拦腰截断

现象：检索回来的片段经常以“根据公司的”开头，以“，具体如下”结尾，明显不完整。

原因：代码里按固定字符数切分，没有尊重中文句号、感叹号等句子边界。400 个字符可能正好从一句话中间切开，导致语义残破，检索时连相似度计算都会受影响。

解决：在切片前先按句号把文本拆成句子列表，然后按“句子级别的拼接”重新组块。基本思路是：当前块字符数小于目标值时，往里加下一个完整句子；如果加上后超过 chunk_size ，则新起一块。这样每个切片至少由若干个完整句子组成，语义完整性远好于固定字符切分。上面代码里的 load_and_chunk 只是一个演示，真正用时建议改成句子感知的切分器，这一段可以直接照抄某开源项目里的分句逻辑。

5.5 重启后知识库内容全部丢失

现象：昨天上传了几十篇文档，今天启动程序一查，向量库是空的，所有内容要重新传。

原因：向量库的路径在程序里写的是相对路径 ./kb_store ，而运行时工作目录变了，Chroma 在另一个目录下创建了一个新的空库，旧数据还在旧目录里，只是程序没找到。

解决：把向量库路径改成绝对路径，或者用配置文件固定住。更好一点的做法是启动时检查 PersistentClient 的目录是否存在，如果路径变了就主动打印警告，别让旧数据静默失联。另外，向量库和原始文档一定要分开备份，向量库丢了可以从文档重新生成，但原始文档一旦丢失，向量库里的二进制数据基本没法逆向恢复。

6. 把准确率再往上提：评估方法与三个调优技巧

先建一套评估集，否则你永远不知道改参数是变好还是变坏。从你的知识库里挑 20 个真实问题，每个问题标注好正确答案应该引用的文档片段。跑一遍完整流程，统计“检索得到正确答案的比例”和“最终回答正确的比例”。每次改参数都重新跑一遍，记录前后对比，这样才能从玄学变成工程。这套评估集只要 20 条，但能让后面所有迭代都有标尺。

第一个调优技巧是调整 chunk_overlap 。很多人把这个参数理解为“多切出来的冗余文本”，错了，它的真正作用是让同一个语义单元至少完整地落在某一个切片里。比如一段 900 字的流程描述，如果 chunk_size=600 、 overlap=100 ，第一块覆盖 0–600 字，第二块覆盖 500–1100 字，中间 100 字的重复让“审批人”这个关键角色不会只出现在某一块的末尾而失去上下文。中文文档里 overlap 我一般设 50–100，太小会漏语义，太大则让重复内容稀释检索结果。

第二个技巧是混合检索。向量检索擅长语义相似，但字面匹配完全不同的术语就傻了。比如员工问“打车费”，制度文档里写的是“交通补贴”，向量能连上；但问“IPO 准备材料”，文档里只有“上市筹备”这种短句，向量距离可能就远了。常见的补法是同时跑一个 BM25 全文检索，把两种检索结果的 top10 做去重合并，再统一排序。Chroma 本身不带 BM25，你可以用 rank_bm25 这个库自己实现，代码量不到 30 行，效果提升却很明显。

第三个技巧是改提示词模板，强制模型“不知道就说不知道”。在 Prompt 最后加一句“如果资料中没有相关信息，请直接回答‘知识库中暂无相关内容’，不要编造”。这条规则看起来简单，实际能把本地模型胡编的概率降低一大截。原因很直白：中小尺寸模型的固有弱点是没把握时也硬要押一个答案，明确允许它“拒绝回答”，反而给了它一个合理的退路。

我自己在搭建这类系统时，最初也把精力全放在调模型上，后来才意识到检索和切片才是准确率的大头。现在每做一个新场景，第一件事永远是先跑通一条 20 条问题的评估集，再谈效果。这套思路从 Deepseek 本地部署扩展到任何 RAG 项目都适用，希望帮到你。