langchain+deepseek+rag本地部署

想把 DeepSeek 和自建知识库塞进一套能断网跑的服务，翻了一圈教程发现全在讲原理，没人说超时设多少、检索挂了怎么退回、日志记哪几个字段。这篇按工程顺序给一份落地清单，从服务拆分到上线前自检，每一步都能照着做。

想把 DeepSeek 和自建知识库塞进一套能断网跑的服务，翻一圈教程发现全在讲原理，没人说超时设多少、检索挂了怎么退回、日志记哪几个字段。这篇按工程顺序给一份落地清单，从服务拆分到上线前自检，每一步都能照着做。

先说清楚适用范围：这套做法适合单机或小集群自部署、团队五到二十人、知识库以内部文档为主的场景。如果追求高并发在线服务、或者语料每天大量增量更新，下面的单机拆分思路会不够用，得直接上分布式检索和独立推理集群。

先把服务拆成三块，别一锅炖

最常见的翻车是接口、检索、生成全挤在一个进程里。检索层一卡，整个服务就假死，重启一次所有请求全断。拆成三块之后，任一层出问题只换那一层，其他部分照常跑。

1. 先画请求路径从用户点击到答案返回，把每一跳标注清楚，标出哪些跳可能超时、哪些跳能缓存。画完再动手拆服务，避免拆完发现某一层其实没必要独立。
2. 确认内存分配把向量库、嵌入模型、主应用三者的常驻内存估算出来，和机器实际可用内存对一遍，留出三成余量再上线。
3. 跑一次断网演练拔掉外网，看服务哪些环节报错、报错文案是否可读，把这次记录当成兜底路径的验收标准。

检索链路的配置项：切片、召回数、拼装顺序

检索质量基本由这几个参数决定，别直接抄别人的数字，得拿自己的语料跑一遍看召回。上线前要把它们固化进配置文件，改一次就重跑一次评测。

超时、重试与降级：本地部署最容易翻车的地方

本地部署最容易忽略的是超时。只设一个全局超时，结果就是检索慢的时候把生成也一起掐了，用户看到的是一条莫名其妙的超时报错。

1. 分开设三类超时连接、检索、生成各自独立，别共用一个值；设完用 /tools/speed-test 量一次本机到各服务的延迟基线，超时值从基线往上推。
2. 重试只对幂等请求开加指数退避；生成到一半断流不要自动重跑整条链，先返回已生成的部分再让用户决定；参数分档参考 /guides/api-timeout-tuning。
3. 设兜底路径向量库连不上退关键词检索，模型调不通返回缓存答案或明确报错文案，别让前端一直转圈。
4. 并发按上游额度压本地机器并发不等于模型服务能接住的并发；限流与排队的取舍看 /guides/429-concurrency-backoff。

日志与评测：让它出问题时能复盘

本地私有化场景没法依赖云端可观测性，日志得自己管。每次请求至少记几个固定字段，出问题才追得下去；再配一份离线日志，断网时照样写本地文件。