deepseek本地部署+数据投喂

很多人把 DeepSeek 拉到本地跑通了，却发现它对自己公司的手册、合同模板、内部规范一问三不知，于是想「投喂数据」。但投喂不是把文件夹拖进去就完事，选错路线、切错粒度、不做验证，效果可能比不喂还差。这篇按决策、准备、入库、验证、排错的顺序，把每一步的动作和判断标准写出来。

本地把 DeepSeek 跑起来，其实只是第一步。真正让人抓狂的是下一幕：你问它公司报销上限是多少、合同模板里违约金怎么写，它一本正经地给你编一个。于是很自然想到「投喂数据」。但投喂不是把文件夹拖进去就完事，路线选错、切块切乱、不做验证，效果可能比不喂还差——因为它会用更自信的语气说错话。

这篇按决策、准备、入库、验证、排错的顺序走，每一步都给动作和判断标准。你不需要一开始就搭一套很重的东西，但需要知道自己在哪一步、卡在哪一步。涉及模型选型、向量库、框架这类会变的对比数据，别记死结论，到站内页面看当时的数字更靠谱。

先分清三条投喂路线，别一上来就动手

「投喂」这个词被用得太泛，导致很多人把三件完全不同的事混成一件。检索、微调、提示词，各自解决的问题不一样，成本和适用场景也差很远。先想清楚你的资料是不是经常变、要不要给出处、问题范围有多宽，再决定走哪条路。

• 判断口径一：资料每周都在改，而且要能说出「这话出自哪份文件」，走检索。
• 判断口径二：只想让它按你们公司的格式写周报、写会议纪要，风格和习惯的活才考虑微调。
• 判断口径三：两三条规定、十几页手册能解决问题，先用提示词试，别急着搭系统。
• 一点提醒：检索和微调可以叠加，但别指望一条路解决全部问题，先解决最痛的那个。

数据准备：先清洗再切块，这步偷懒后面全白干

这一节最枯燥，但决定了整套系统的上限。很多「检索不到」的问题，追根到底不是模型不行、也不是向量库不行，而是文档里全是页眉页脚、目录、水印，或者一块关键信息被硬切成了两半。别跳过。

1. 把各种格式转成纯文本PDF、Word、网页、表格先转文本，去掉页眉页脚、页码、目录和水印；扫描件如果识别出来是乱码，宁可重扫也别硬塞。表格单独抽成结构化文本，别当段落处理。
2. 按语义切块，不按字数硬切一份制度按条款切，一份手册按小节切，代码文档按函数切。块与块之间留一点重叠，避免答案正好跨在两块的边界上被切断。
3. 给每块挂上元信息来源文件名、章节路径、生效时间，至少这三样。否则检索回来一段话，你根本不知道它出自哪份文件的哪一版，出了错也无从追溯。
4. 做一遍敏感数据分级内部资料和内网资料不要混进同一个索引。要脱敏的先脱敏，要分权限的先分好，别等上线了再补，那时候已经不好拆了。

切块粒度没有万能值，规律大致是：条款类文档切小一点，叙事类手册可以稍大。不确定就先试一轮，看召回效果再调，这个后面验证环节还会讲。

环境这块你只要确认三件事

别被工具清单吓到。不管外面有多少新框架，你只需要确认三件事能对上，整条链就通了。至于具体选哪个向量库、用哪套编排框架，这类东西更新快，到站内对照当时的情况更合适。

模型服务

本地推理服务能稳定响应，先单独用几个问题确认它能答、延迟能接受，再接知识层

嵌入模型

负责把文本变成向量，建库和查询必须用同一个，否则检索结果会莫名其妙地不相关

向量库与编排层

存向量、做检索、把结果拼进提示词的那一层，选型可到 /stacks/vector-dbs 和 /stacks/frameworks 对照

• 先单独测模型服务：问一两个通用问题，确认能答、不卡死，再接知识层，出了问题好定位。
• 模型服务和知识层放同一台机器还是分开，提前定；分开要注意网络连通和鉴权，别把服务裸奔在公网上。
• 嵌入模型换语言场景要留心：中文资料用只擅长英文的嵌入模型，命中率会掉得很难看。

入库与检索：把「查得到」变成「查得准」

入库就是把切好的块转成向量存进去。存完别急着庆祝，做一次抽样自检，随手挑几个你熟悉的问题，看召回的块是不是真的相关。这一步花不了多少时间，却能提前暴露大部分问题。

• 召回数量宁少勿滥：先取少量高相关块，不够再考虑加重排序，一上来取一大堆只会把噪音一起喂给模型。
• 问题先改写再检索：口语化的提问直接去匹配书面文档，命中率会明显下降，把问题补全成书面表达再查。
• 提示词里强制约束：要求模型只依据召回的块作答，并且附上来源；找不到就明说找不到，别让它自己编。
• 上线前跑一批问题：常见问法和刁钻问法各准备一些，看召回和答案两头，别只看能不能跳出字来。

还有个容易忽略的点：召回回来的块如果互相矛盾，模型会随机挑一个说，而且说得很确定。这种冲突在切块阶段就该发现，别指望模型自己调和。

效果验证：怎么判断这次投喂到底有没有用

「感觉还行」不算验证。你需要一份小规模评测集，包含问题、标准答案要点、应命中的来源块。数量不用多，但三类问题都要有：能查到的、查不到但相关的、完全没资料的。

两步分开看很关键。检索对、回答错，是提示词或模型的问题；检索就没捞对，后面怎么调都白搭。混在一起看，你根本不知道该改哪边。

• 调优顺序：切块粒度 → 检索数量 → 问题改写 → 提示词约束 → 最后才考虑换嵌入模型。
• 别一上来就换模型，大部分效果问题跟模型本身没关系，换了也未必好。
• 每次调完用同一份评测集跑一遍，不然你分不清是变好了还是感觉变好了。

上线之后：数据会变，流程得能跟着变

投喂不是一次性动作。制度会修订、手册会换版、合同模板会更新，如果没有更新机制，系统过一阵就会开始答旧版本的内容，而且答得一样自信。

• 建增量更新：新文件进来只更新对应块，别每次都全量重建，全量重建既慢又容易中途出错。
• 给每块打生效时间和版本号，旧版本保留但标记失效，避免新旧制度同时被召回、答案来回横跳。
• 记录每次问答的检索结果，定期翻低分和未命中的问题，那是最真实的数据缺口清单。
• 权限做在检索层：不同角色只能召回自己有权看的块，模型本身不认识权限这回事。

什么情况下这套做法不适用

不是所有场景都值得搭检索。判断标准很简单：如果问题本身就那么几个、资料就那几页，直接写进上下文更省事，多搭一层反而多一个出错的地方。

• 需要模型改变推理能力或写作风格的任务，检索帮不上，那是微调的活。
• 数据只有几页、问题范围极窄，直接写进上下文更省事，别为了架构好看硬搭系统。
• 资料本身质量差、口径互相矛盾，先做数据治理；投喂只会把矛盾原样搬进答案，还可能放大。
• 对延迟极度敏感、要求毫秒级响应的场景，多一次检索就多一截等待，得权衡值不值得。

还有一种情况要留意：你的问题答案需要跨很多份文档综合推断，而检索只负责找相关块，不负责推理。这种场景检索能帮上忙，但别期待它一步到位。

排查顺序：出问题按这个顺序走一遍

出问题的时候最忌讳东改一下西改一下。按下面这个顺序走，每步只改一个变量，才能知道到底是哪一环的问题。

1. 答非所问先看检索返回了什么。八成的问题在检索不在模型，看到召回内容是垃圾，就别往下调模型了。
2. 召回为空检查切块是不是把关键信息切散了，再确认嵌入模型跟资料语言是否匹配。
3. 答对但没来源检查提示词里有没有强制引用要求，以及返回结果里有没有带元信息。
4. 越问越慢看向量库规模、单次检索数量和是否每次都在重建索引，通常是索引策略的问题。
5. 换资料后变差先比对新旧切块方式，再检查旧块有没有清干净，残留的旧块会被一起召回。

投喂效果好不好，很多时候不取决于你用了什么模型，而取决于你有没有把切块和验证这两件事当回事。