背景与痛点
去年“618”大促，公司客服通道被挤爆，平均响应时间飙到 38 秒，差评率直接翻倍。复盘发现，人工坐席 + 关键词机器人根本扛不住三种典型场景：
- 用户一句话里塞了 3 个意图：改地址、查优惠券、催发货
- 跨会话追问：“刚才说的优惠券还能用吗？”
- 同义词爆炸：口红/唇膏/唇釉在知识库里被当成 3 个 SKU
传统 FAQ 匹配或简单 NLP 方案，只能做“关键词 <=> 答案”的单点映射，一旦用户跳出模板，系统秒变“智障”。
于是我们把目光投向生成式大模型，最终用 SpringBoot + DeepSeek 在 4 周内上线一套“能听懂、记得住、答得快”的智能客服，峰值 QPS 从 300 提到 2 k，首响时间压到 1.2 s，人工拦截率降到 18%。下面把踩过的坑和调优笔记全盘托出。
技术选型：为什么不是 GPT-3 或 BERT？
| 维度 | DeepSeek-7B | GPT-3.5-Turbo | BERT+Classifier |
|---|---|---|---|
| 中文 SFT 厚度 | 高（32B 中文语料） | 中（翻译腔味重） | 低需自训 |
| 私有化成本 | 单卡 3090 可跑 | 按 Token 收费 | 训练+推理双成本 |
| 多轮记忆 | 原生支持 4 k 上下文 | 同左 | 需外部存储 |
| 知识召回 | 可外挂向量库 | 同左 | 需额外拼接 |
| 时延（RTF） | 0.09 | 网络 IO 不可控 | 0.05 分类+检索 |
结论：ToB 私有化、数据不出机房、预算有限，DeepSeek 是“能落地”而不是“能 demo”的最优解。
系统架构一览
- Gateway：Spring Cloud Gateway 做统一限流、鉴权
- Chat-Service：SpringBoot 3.2 + WebFlux，无阻塞 IO
- Cache：Redis 集群缓存热点知识
- LLM-Serving：DeepSeek-7B 基于 vLLM 部署，张量并行 2 卡
- VectorDB：Milvus 存储商品/政策向量，支持语义召回
核心实现
1. SpringBoot 与 DeepSeek 集成
DeepSeek 兼容 OpenAI 接口，直接复用spring-ai社区库即可，但生产环境建议自封装短连接池，减少 JSON 解析开销。
关键依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> <dependency> <groupId>com.squareup.okhttp3</groupId> <artifactId>okhttp</artifactId> <version>4.12.0</version> </dependency>配置类：
deepseek: api-base: http://llm-serving:8000/v1 model: deepseek-7b max-tokens: 512 temperature: 0.32. 意图识别 & 多轮对话
采用“先召回后生成”的 Pipeline，避免大模型幻觉：
- 用户 query → 向量检索 Top5 知识片段
- 拼接历史 3 轮上下文 + 召回片段，构造 Prompt
- DeepSeek 生成答案
- 正则提取结构化字段（订单号、手机号）落库
Prompt 模板片段：
【系统】你是商城客服助手，请依据下列知识片段回复用户，若无法回答请转人工。 【历史】 User: {{history}} 【知识】 {% for doc in docs %} {{doc.title}}:{{doc.content}} {% endfor %} 【当前问题】 {{query}}3. 上下文管理策略
- 会话级：Spring Session + Redis 存储 userId ↔ chatId
- 模型级：DeepSeek 4 k 窗口，超限时做摘要 滑动截断
- 业务级：对“改地址”等需工单号意图，把结构化槽位写回 DB，防止刷新页面丢数据
代码示例：REST API 与异步处理
@RestController @RequestMapping("/api/v1/chat") @RequiredArgsConstructor public class ChatController { private final ChatService chatService; /** * 异步发送消息，避免阻塞 WebFlux 线程 */ @PostMapping("/send") public Mono<ChatResp> send(@Valid @RequestBody ChatReq req) { return chatService.chat(req) .subscribeOn(Schedulers.boundedElastic()) .timeout(Duration.ofSeconds(8)); } } @Service public class ChatService { private final DeepSeekClient deepSeekClient; private final VectorService vectorService; private final RedisTemplate<String, List<String>> redisTemplate; public Mono<ChatResp> chat(ChatReq req) { // 1. 召回知识 List<String> docs = vectorService.search(req.getQuery(), 5); // 2. 拼接历史 List<String> history = redisTemplate.opsForList() .range("chat:" + req.getSessionId(), 0, -1); String prompt = PromptBuilder.build(docs, history, req.getQuery()); // 3. 调用大模型 return deepSeekClient.generate(prompt) .map(answer -> { // 4. 写回 Redis redisTemplate.opsForList() .rightPush("chat:" + req.getSessionId(), "U:" + req.getQuery()); redisTemplate.opsForList() .rightPush("chat:" + req.getSessionId(), "A:" + answer); return new ChatResp(answer); }); } }性能优化三板斧
缓存热点 Prompt
把“发货政策”“退换货流程”等高频知识预生成 Embedding，放 Redis Hash，QPS 提升 40%。异步 + 背压
WebFlux 的onBackpressureBuffer结合 Sentinel 限流，防止突发流量把 vLLM 打挂。负载均衡 & 分片
DeepSeek 推理采用 vLLM + Ray，两卡并行；上层通过 Kubernetes HPA 按 GPU 利用率 70% 扩容，实测峰值支持 2 k 并发，RT 稳定在 1 s 内。
避坑指南
- 重复惩罚调太高 → 答得太短，用户满意度降 10%，建议 repetition_penalty=1.05
- 知识片段 > 512 token 时，向量召回精度骤降，可先做 LLM Summary 再 Embedding
- 会话 Key 未加租户前缀，导致测试环境冲掉生产缓存，血泪教训
- OkHttp 默认连接池 5 个，高并发下出现 ConnectionPool exhausted，调到 200 解决
安全考量
- 数据脱敏：手机号、地址走正则掩码，日志落盘前用 FPE 加密
- 接口鉴权：Gateway 层集成 OAuth2 + JWT，细粒度到 scope=chat:query
- 内容审计：DeepSeek 输出同步到阿里绿网 API，涉黄涉政直接转人工，合规审计留痕 15 天
可扩展思考
- 插件化意图：把“取消订单”“申请售后”做成 Tool Call，让大模型自动调用内部 Dubbo 接口，实现“对话即工单”。
- 多模态：用户上传照片识别“开胶/破损”，直接走视觉大模型，返回售后方案。
- 边缘部署：把 4-bit 量化模型下到门店盒子，外网断开也能本地问答，适合连锁零售。
小结
SpringBoot 集成 DeepSeek 做智能客服，核心不是“调接口”而是“搭链路”：召回 → 上下文 → 生成 → 缓存 → 限流，每一步都要为生产级别留余量。
把上述模板跑通后，我们仅用 4 周就把差评率压回基线，同时释放了 60% 人力坐席。
下一步，你会先尝试插件化工具，还是直接上多模态？欢迎留言交流踩坑实录。
