deepseek本地部署+本地知识库

你已经把 DeepSeek 权重拉到本地、也能对话了，但一接上自己的文档就开始出问题：答非所问、引错段落、换台机器就跑不起来。这篇不讲榜单也不劝你自建还是调 API，只走一遍完整链路——先算清卡和量化，再定切分与检索，最后把问答跑通并验一遍。

你已经能把 DeepSeek 的权重拉到本地，也能对话，但一接上自己的文档就翻车：答非所问、引错段落、换台机器起不来。问题多半不在模型，而在整条链路——显存算没算过、切分粒度合不合适、检索是不是只做了向量一层、提示词有没有约束来源。这篇不讲榜单也不劝你自建还是调 API，只把从选卡到上线验证这一遍流程走完，你照着对一遍，能省掉不少来回试的时间。

先说清边界：本地 RAG 适合资料不能出内网、或者长期要压住调用成本、又愿意有人维护索引的场景。如果只是想让模型读懂三篇文档，别搭这套；如果资料每周大改、要理解图表扫描件，维护成本会明显上升。下面按顺序来：先确认需求类型，再算硬件，然后切分、检索、服务化，最后验一轮。

先确认你搭的是哪一类知识库

同样叫「本地知识库」，三类需求的验收标准完全不同。纯内网资料问答，只要模型能说清大意、不泄露外网就算合格；带引用的客服或文档助手，回答必须能点回原段落，召回率要求高一截；给内部工具当接口调的，第一看响应延迟稳不稳、第二才看准确率，因为上层会重试。动手前先给自己归个类，后面所有取舍才有依据。

纯内网资料问答

重点是资料不出内网，回答允许带点概括，召回率要求中等

带引用的文档助手

回答必须标出处，检索召回不上去就是不合格，对切分和元信息要求最高

对内接口服务

拼的是延迟稳定和并发，准确率可以靠上层重试和人工兜底补

• 先写下这类问题的验收标准：能答、不能答（该说不知道）、容易混的，各列几条例子
• 确认资料能否出内网。不能出，本地部署是硬约束，别再纠结调用 API 更省事
• 确认有没有人长期维护索引和提示词。没有的话，先做小范围试点，别直接铺开
• 确认资料规模是否长期增长。增长快的话，索引重建方案要在第一天就设计好

选模型档位：先看显存，再看质量损失

顺序别搞反：不是先挑一个心仪的模型再想办法塞进卡里，而是先看手头卡有多少显存，再决定能上哪个参数量级、哪个量化档位。量化档位越高越省显存，但语义细节和长文理解会掉，专有名词密集的资料上掉得更明显。稳妥做法是先用较低量化把全链路跑通，再拿同一批问题逐步升档对比，别一上来就冲最高精度。

上下文长度这一项特别容易被忽略。你要支持整篇长文档投喂，显存占用会随上下文线性上涨，参数量挑小了卡照样爆。具体每个型号的规格、支持的长度和量化格式，到 模型库（/models） 对照；显存和并发的换算别拍脑袋，先到 部署测算（/models/deploy） 按你的卡和模型算一遍再下单或换卡。

跑推理的运行时怎么挑

运行时选型看你的使用场景，不是看谁名气大。单机个人用、要快速换模型试效果，社区推理工具够用，改个参数就能起；要给多个内部用户提供稳定接口，就得考虑带批处理和并发调度的服务化框架，否则几个人同时问就排队。挑的时候只盯三件事：支不支持你要的量化格式、能不能把模型稳定驻留显存、对外接口协议兼不兼容你现有的调用方。

• 先看量化格式支持，格式对不上，再好的框架也用不了
• 再看显存驻留：模型反复换进换出，延迟会抖得没法用
• 最后看接口协议，业务接进来才改协议，返工成本最高
• 提前用一条真实请求走通全流程，别等上线才发现缺接口

框架之间的差异、各自适合什么场景，可以翻 Agent 框架与 SDK 目录（/stacks/frameworks） 和 基础设施术语速查（/ai-dict/category/infra），把名词对齐了再选，能少走弯路。选型判断换个角度：如果你的调用方只有你自己，优先挑启动快、改配置方便的；如果有三个以上内部用户，优先挑并发调度稳的。

文档处理与切分：决定召回上限的一步

切分是整条链路里最容易被低估的一步，检索召回的上限在这里就定了。先把资料转成纯文本再谈切分，扫描件、带复杂表格的文档要在这一步就单独标记出来，走另一条处理路径，否则后面怎么调检索都救不回来。清洗环节别省：页眉页脚、目录、导航文字这些噪声会让检索命中一堆看着相关其实没用的片段，白白挤占上下文。

1. 转纯文本把原始文档转成文本，标注哪些是扫描件、哪些含复杂表格。验证方式：随便抽十篇，看转换后有没有乱码和大段丢失
2. 按结构切分条款类按条切，说明书类按小节切，别按固定字数硬切。验证方式：抽查几十段，看有没有断句断在关键处
3. 补元信息每段带上来源文件、章节、页码。验证方式：随便挑一段，能不能只看元信息就定位回原文
4. 设置重叠区重叠区不要一刀切，按文档类型调。验证方式：找几个被切成两半的知识点，看检索能不能把两段都召回
5. 人工抽查切完别直接进索引，先人工过几十段。验证方式：统计有多少段是导航文字、目录残留这类噪声

元信息的重要性在于：回答里的引用全靠它，用户点开引用能不能回到原文，直接决定这套东西可不可信。切分粒度也别迷信某个固定字数，同一个知识点被切成两半、前半段和后半段各召回一半，是答非所问的高频原因。切完不人工看几十段，你根本不知道自己的切分到底行不行。

检索与提示词：把上下文喂对

检索别只做向量一层。稳妥的是两步：先向量召回取一批候选，再用重排模型把最相关的排到前面。只做向量召回，在专有名词密集的资料上很容易翻车，因为语义相近但答案不对的片段会挤掉真正相关的。中文资料建议用中文语义检索表现稳的嵌入模型，具体怎么选、各自适合什么资料，到 嵌入模型（/embeddings） 里的对照看，别随手拿个通用模型凑数。

提示词里要写清三条规则，这三条能挡掉大部分胡编：只依据给定片段回答；片段里没有就直说不确定；回答末尾标出来源。把检索到的原文片段原样带进提示词，不要让模型自己回忆。上下文放几段、每段多长，会同时影响准确率、显存占用和首字延迟，这几个参数要一起调，别单独拉满一个。

把问答跑成能给同事用的服务

要给人用，就得包一层服务接口，把检索、拼提示词、调模型三步串起来，对外只暴露一个问题入口。这样以后换模型或换检索策略，改的是内部实现，上层调用方不用动。首次提问特别慢，通常不是模型的问题，是嵌入模型和索引没预热，做一次启动预热，把常用索引加载进内存，第一问的延迟会正常很多。

• 对外接口只暴露问题入口，内部三步实现藏起来，方便以后替换
• 启动时预热嵌入模型和索引，避免第一问超时
• 日志里记下每问命中的片段和最终回答，出问题是唯一能回溯的凭据
• 并发上不去先进日志分清是显存卡住还是检索排队，两者优化方向完全不同
• 延迟基线先量一遍再谈优化，没基线就没法判断改动有没有效果

并发问题要分清是显存卡住还是检索环节排队。显存卡住的话，调量化、减上下文、限并发；检索排队的话，是索引结构或重排模型太慢，优化点完全不同。想有个客观基线，到 接口测速（/tools/speed-test） 把当前延迟量一遍，记下来，后面每次改动都有对照。

上线前怎么验、上线后怎么改

准备一份二三十条真实问题清单，覆盖三类：能答的、不能答的（该说不知道）、容易混的。每次改切分、换模型、调检索参数，都重跑这份清单做对比，否则你改完根本不知道是变好还是变坏。看结果时把两项指标分开：检索有没有把正确片段召回，以及模型拿到正确片段后有没有答对。混在一起看，会永远定位不到问题出在哪一层。

抽查时点开引用核对，这一步能抓出大部分看起来流畅实则编造的回答。资料更新后，索引重建要能增量做，别每次全量重跑；把索引版本和文档版本对应记下来，出问题能快速回退到旧版本。这些动作都不复杂，难的是坚持每次都跑一遍。

什么情况下这套方案要改路线

别一条路走到黑。资料规模很小、问题范围固定，直接在提示词里塞全文可能比搭检索链路更省事也更准；需要理解表格、扫描件、流程图，本地纯文本 RAG 不够用，要另配文档解析或多模态模型，成本会上一台阶；对准确率要求极高、不能容忍错误，就不能只靠模型自答，检索后要加规则校验或人工复核。

判断本地 RAG 值不值得做，看的不是技术能不能实现，而是有没有人愿意长期维护索引和提示词。

还有个现实条件：团队里没人长期维护。这种情况本地部署很容易变成一次性项目，上线时热闹，三个月后没人更新索引，回答越来越旧。更稳的做法是先小范围试点，用真实问题清单跑一段时间，看维护成本能不能接受，再决定要不要扩到全团队。此外，如果只是短期项目、资料几个月后就不用了，搭这套链路的投入很难回本，直接调用更划算。