deepseek 本地部署加知识库怎么搭

你大概已经看过原理文章，一到动手就卡住：模型跑起来了，知识库也入库了，可回答还是胡说、延迟高、显存不够、换批文档就崩。这篇不谈底层原理，只按工程落地顺序走一遍：先定最小可行范围，再搭检索加生成链路，最后把超时、并发、降级、日志和评测补齐。哪里数字要对，就去站内对应页面查当时的实际值。

你大概已经看过原理文章，一到动手就卡住：模型跑起来了，知识库也入库了，可回答还是胡说、延迟高、显存不够、换批文档就崩。这篇不谈底层原理，只按工程落地顺序走一遍：先定最小可行范围，再搭检索加生成链路，最后把超时、并发、降级、日志和评测补齐。

贯穿全文的一个原则是：所有跟硬件规格、行情、榜单口径有关的数字都不在这里写死，需要哪个就回站内对应页面看当时的值，因为这类数字变动很快，抄一个过期的反而害你。下面按四个阶段走。

先划范围：最小可行系统长什么样

把系统拆成四块：模型服务、向量库、切片与入库脚本、问答接口。第一版只做一条能跑通的竖切——一份文档、一个问题、一次检索、一次生成，能端到端返回就算过关。不要一上来就上编排平台、多路召回、Agent 调度，那些是链路跑通之后才有意义的事。

选型只看两件事：硬件能不能扛、文档格式复不复杂。卡规格和租用行情去 /compute/gpus 与 /compute/gpu-rental 核对当时的口径，向量库之间的能力差异去 /stacks/vector-dbs 比。不适用情形也要提前想清楚：如果你文档量很小、问题几乎不用查资料就能答，直接把相关资料塞进上下文更省事，别硬上检索链路给自己加运维负担。

搭建顺序：按依赖关系一步步来

1. 先让模型服务单独可用用最简请求确认能返回内容，先不接知识库。OpenAI 兼容写法和常见的连通性拼写错误，参考站内 related 里的接口类文章对照排查。
2. 再做文档进料清洗掉页眉页脚、扫描噪声和重复段落，再按语义边界切片。切片策略和入库流程可对照 /guides/rag-kb-build-pipeline 的思路，但参数要按你自己的文档调。
3. 接检索，先单路只做一种召回方式先跑通，能稳定返回相关片段就行。混合检索和重排是优化项，不是能不能用的前提。
4. 最后写问答层把检索结果拼进提示词，明确要求带出处、答不出来就说不知道。别让它自由发挥，否则检索做得再好也白搭。

这四步的顺序不能颠倒，因为后一步的调试依赖前一步的输出。模型服务没通就去调检索，出了问题你分不清是模型挂了还是召回空了。每步都用最小的验证动作确认，再进下一步。

上线前必调的四个工程参数

超时

连接、读取、整体超时分开设；本地模型首字延迟波动大，一刀切容易误判成服务挂了

并发

先量出稳定并发数再定上限，超出的请求进队列，别直接打爆推理进程

降级

检索为空或模型超时要有兜底动作，是回退关键词检索还是直接回复找不到，提前定好

日志

至少记请求 ID、命中片段、耗时分段和 token 用量，出问题能复盘是检索差还是生成差

• 超时阈值先按实测的分位数设，别照搬别人的经验值，本地机器差异很大
• 并发上限用压测找，观察排队时间和成功率拐点在哪
• 日志里给每次请求一个 ID，串起检索和生成两段耗时
• 每次改配置都在日志里留一条变更记录，方便回滚时对照

验收与常见坑：怎么算搭好了

验收不看绝对分，看有没有变差。自建一小组固定问题当回归集，每次改切片或提示词都跑一遍，只对比前后结果，别去追某个榜单上的绝对值。效果想横向比，去 /benchmarks 和 /benchmarks/registry 看当时的榜单口径，不同榜单口径不一样，盯着单个数字下结论容易误判。

改完一轮就记一条：改了什么、哪个指标动了、什么情况下又不行了。攒上十几条，你就有了自己的排查顺序，下次出问题不用从零猜。最后提醒一点：这套最小系统能跑通不代表能扛量，真上生产前还得按实际流量压一轮。