当前位置：首页 > news >正文

基于SpringBoot+LLM+Milvus构建企业级AI智能客服系统：架构设计与生产落地实战

news 2026/5/12 0:05:32

1. 传统客服的三大“老大难”

做ToB客服产品五年，我总结过一张“吐槽清单”，出现频率最高的三条是：

意图识别太傻：关键词+正则，用户换种说法就“对不起，我没听懂”。
多轮对话断片：每次都得重复订单号、手机号，体验像打客服热线。
知识库检索慢：MySQL LIKE '%xxx%'，数据量一上200万条，查询直奔2 s，客服坐席只能让客户“稍等”。

这三点直接带来两个结果：人工坐席成本居高不下；用户满意度常年在及格线徘徊。要破局，就得把“语义理解”和“知识检索”同时做到毫秒级，并且让系统可以横向扩展——这正是本文方案要解决的命题。

2. 技术选型：为什么不是Dubbo+GPT+PGVector？

###选型之前先拉一张对比表，把“业务指标”翻译成“技术指标”：

业务诉求	技术指标	候选方案	结论
周迭代、Java生态友好	开发效率、社区包	SpringCloud/Dubbo	SpringBoot 3.x胜在“一键启动”，学习曲线低
私有化部署、可控可插拔	模型大小、License	GPT-4/ChatGLM3-6B	ChatGLM3-6B 12G显存可跑，Apache-2.0 License，可改可商用
10亿级向量、毫秒延迟	索引召回<50 ms	Milvus/PGVector	PGVector单表500万后性能骤降，Milvus分布式+GPU索引优势明显

一句话总结：SpringBoot负责“快”，ChatGLM负责“懂”，Milvus负责“搜”。三者组合，既能在两周内做出MVP，也能在正式环境横向扩容到几十台机器。

3. 系统分层架构：一张图看懂数据流

文字版“架构图”如下，方便复制到PPT：

接入层：Nginx+Gateway，统一做HTTPS卸载、WAF、流控
服务层：SpringBoot业务Pod，无状态，可水平扩容
语义层：
- LLM-Svc：ChatGLM3-6B，通过TorchServe暴露/gene_answer
- Embed-Svc：Sentence-Transformers，把知识库文本向量化
存储层：
- Milvus：存储1.2亿条512维向量，索引IVF_SQ8
- Redis：对话状态、热数据缓存
- MySQL：知识原文、运营后台
观察层：Prometheus+Grafana+ELK，SLA告警阈值P99>600 ms即触发

异步与流量控制细节：

用户提问先进入Kafka Topicchat.req，消费端按user_id做分区，保证同一用户顺序处理
若LLM-Svc平均RT>1 s，Gateway自动降级到“FAQ静态答案”，同时把流量镜像到影子集群做热备
关键接口/chat/send配置令牌桶500次/上限/秒，超量返回429，防止促销时段把GPU打爆

4. 核心代码落地

4.1 SpringBoot集成LLM（REST+JWT）

@RestController @RequestMapping("/api/v1/chat") @RequiredArgsConstructor public class ChatController { private final ChatService chatService; private final JwtHelper jwtHelper; @PostMapping("/send") public Reply send(@RequestHeader("Authorization") String bearer, @Valid @RequestBody ChatReq req) { String userId = jwtHelper.parse(bearer); // 限流注解，基于Redis令牌桶 return chatService.reply(userId, req.getQuery()); } } @Service public class ChatService { private final LLMClient llmClient; private final VectorSearch vectorSearch; public Reply reply(String userId, String query) { // 1. 检索Top5相关知识点 List<String> knowledges = vectorSearch.topK(query, 5); // 2. 构造Prompt，控制token在3k以内 String prompt = PromptTpl.of(knowledges, query); // 3. 调用LLM，超时2s重试一次 String ans = llmClient.generate(prompt, Duration.ofSeconds(2)); return Reply.of(ans); } }

时间复杂度分析：向量检索IVF_SQ8索引，n=1.2亿，topK=5，耗时O(log n)≈25 ms；LLM生成首字延迟400 ms，整体P80<600 ms。

4.2 Milvus向量检索（Python脚本，可跑在Embed-Svc容器）

from pymilvus import Collection, utility collection = Collection("kb_embed") collection.load() def topk_search(embed: list, k: int = 5, threshold=0.78): search_params = {"metric_type": "IP", "params": {"nprobe": 64}} results = collection.search( data=[embed], anns_field="vector", param=search_params, limit=k, output_fields=["text"] ) # 过滤相似度 return [r.entity.get("text") for r in results[0] if r.score > threshold]

说明：IP（内积）相似度阈值0.78由网格搜索+人工标注1000条得，Precision@5=0.91。

4.3 对话状态机（Java枚举实现）

public enum DialogueState { GREET, ASK_ORDER, CONFIRM_ADDR, FINISH; public DialogueState next(Event e) { switch (this)订单查询: if (e == Event.ORDER_FOUND) return CONFIRM_ADDR; if (e == Event.NOT_FOUND) return ASK_ORDER; ... } }

状态缓存到Redis Hash，TTL=15 min，key=dialog:{userId}，读写O(1)。

5. 生产环境 checklist

5.1 压力测试方案

JMeter线程组：200并发，Ramp-up 60 s，循环次数无限
通过jp@gc - Throughput Shaping Timer把峰值压到1000 TPS
监控指标：Error<0.5%，P99 Latency<800 ms，GPU Util<85%
发现瓶颈：TorchServe默认workers=1，改为gpu_count*2，TPS从260提到740

5.2 安全防护

SQL注入：MyBatis-Plus只提供QueryWrapper，禁止拼接${}；参数化绑定
速率限制：Gateway层集成Bucket4j，按IP+user双维度，突发系数1.5
内容审核：调用本地敏感词DFA过滤器，再调外部审核API双保险

5.3 Kubernetes关键YAML

apiVersion: apps/v1 kind: Deployment metadata: name: llm-svc spec: replicas: 2 template: spec: containers: - name: llm image: chatglm3:6b-torchserve resources: limits: nvidia.com/gpu: 1 # 单卡 requests: memory: "14Gi" livenessProbe: httpGet: path: /ping port: 8080 initialDelaySeconds: 300 # 模型加载慢

6. 避坑指南：上线前必须踩的坑

LLM token长度：ChatGLM3默认8k，但TorchServe一次只能收2048汉字；解决：在SpringBoot侧用gpt2-tokenizer预截断，保留最后1800字，首字延迟降30%
Milvus索引：IVF需要预训练nlist，经验公式nlist=sqrt(N)，N=1.2亿时nlist=1w最合适；别盲目上HNSW，内存翻倍，提升仅5%
Redis存上下文：刚开始用String存JSON，用户一多内存飙到30 G；改Hash+压缩（LZ4），节省60%，重启加载时间从90 s降到20 s