SpringAI智能客服实战：如何通过语义理解提升工单处理效率-编程实验室

背景痛点：工单系统“慢”在哪里

去年双十一，我们客服组被一波“我的优惠券去哪了”淹没。工单像雪片一样飞进系统，但规则引擎只会按关键词硬匹配，结果“优惠券”“红包”“折扣”被当成三类问题，分给了三个小组，重复沟通、来回转派，平均响应时间飙到 38 分钟。
更惨的是多轮对话：用户先问“怎么退款”，两分钟后追加“运费谁出”，传统 NLP 把两句话独立处理，答案前后矛盾，客户直接炸了。
总结下来就两点：

意图识别模糊 → 分类错 → 人工返工
多轮状态丢失 → 答非所问 → 人工接盘

人工干预率一度高达 81%，老板拍桌子：必须降。

技术选型：规则、NLP 还是 SpringAI？

我们拿三个月的真实工单 20 k 条做离线测评，维度就俩：准确率、平均响应时间。结果如下表：

方案	准确率	响应时间	备注
关键词规则	62%	120 ms	需要不断加“同义词”
传统 NLP（TextCNN）	74%	450 ms	训练+部署两套集群
SpringAI + 向量检索	89%	180 ms	同一套 Spring Boot 微服务

SpringAI 把“语义理解”拆成两步：

离线阶段用 EmbeddingClient 把历史工单变成向量，存内存向量库；
在线阶段用同样的模型把用户提问向量化，秒级检索 Top5 相似工单，再让 LLM 参考这些样例生成回复。
既不用重新训练，也能随时增量更新，准确率直接提升 15 个百分点，响应时间还比老 NLP 快一半，老板看完当场批预算。

核心实现：30 分钟搭一套可运行 Demo

1. 环境准备

JDK 17
Spring Boot 3.2
SpringAI 1.0 M2
Redis 7（放对话状态）
GPU 驱动 ≥ 535（跑 embedding 模型）

2. 意图向量库 5 行代码

# application.yml spring: ai: embedding: model: all-minilm-l12-v2 dimensions: 384 # 后面会调优

@Component public class IntentVectorLoader { private final EmbeddingClient client; private final VectorStore store; public void load(List<HistoricalTicket> tickets) { tickets.parallelStream() .map(t -> new Document(t.getQuestion(), Map.of("answer", t.getAnswer(), "tag", t.getTag()))) .forEach(doc -> store.add(List.of(doc))); } }

跑完服务启动，历史工单全部入库，内存占用 210 MB，检索 10 k 向量 < 50 ms。

3. 上下文感知回复：@RetrievalAugmentor

SpringAI 提供的这个注解简直神器，把“检索 + 提示词”打包成一条链：

@RetrievalAugmentor( vectorStore = "intentStore", similarityThreshold = 0.78, topK = 3, promptTemplate = """ 你是客服机器人，只能基于下列已知问答生成回复： {documents} 用户问题：{userQuestion} 如果已知问答无法回答，请说“转人工”。 """ ) public interface CustomerServiceAgent { String chat(@MemoryId String sessionId, @UserMessage String question); }

@MemoryId把同一会话的历史自动带进来，LLM 能看懂上下文，不会出现“运费谁出”答非所问的情况。

4. 完整 Controller（含 JWT 鉴权+异常兜底）

@RestController @RequestMapping("/api/v1/bot") @RequiredArgsConstructor public class ChatController { private final CustomerServiceAgent agent; private final JwtValidator jwtValidator; @PostMapping("/chat") public ResponseEntity<Reply> chat(@RequestHeader("Authorization") String bearer, @RequestBody ChatRequest req) { // 1. 鉴权 var jwt = bearer.substring(7); if (!jwtValidator.valid(jwt)) { throw new ResponseStatusException(HttpStatus.UNAUTHORIZED); } // 2. 调用 AI try { String answer = agent.chat(req.sessionId(), req.question()); return ResponseEntity.ok(new Reply(answer, "AI")); } catch (IllegalArgumentException e) { // 3. 兜底：向量检索为空 return ResponseEntity.ok(new Reply("转人工", "SYSTEM")); } } }

5. UML 时序图（AI 调用链路）

时序简述：

用户提问 → Gateway
JWT 校验
Controller 调 Agent
Agent 用 RetrievalAugmentor 检索向量库
LLM 生成回复
同时写 Redis 对话状态
返回前端

性能优化：把 GPU 内存打下来

1. 向量维度实验

我们用同一批 20 k 工单，分别测试 384 / 512 / 768 维，结果如下：

维度	显存占用	检索耗时	准确率
384	0.9 GB	38 ms	89.1%
512	1.2 GB	42 ms	89.3%
768	1.8 GB	55 ms	89.4%

384→768 只涨 0.3 个百分点，显存翻倍，果断 384 上线，单卡可并发 400 qps。

2. 对话状态 Redis 缓存方案

每轮对话把历史拼成 JSON 数组，压缩后存 Redis Hash，key 设计：

cs:session:{userId} -> zset(timestamp, compressedJson)

过期 30 min，自动清理
使用 ZSTD 压缩，平均 1 k → 180 B，节省 82% 内存
读写 < 5 ms，对总链路 RT 几乎无感

避坑指南：别让 LLM 放飞自我

1. 幻觉校验三件套

双轨答案：向量检索 Top1 的 answer 与 LLM 答案做 BLEU，< 0.35 直接转人工
置信度阈值：SpringAI 返回的finishReason若是length，大概率胡编，直接打控
关键词黑名单：出现“点击链接”“下载 exe”等高风险词，立刻拒绝并告警

2. 敏感词 AOP 过滤

@Aspect @Component public class SensitiveFilter { @Around("@annotation(SafeReply)") public Object around(ProceedingJoinPoint pjp) throws Throwable { Object raw = pjp.proceed(); if (!(raw instanceof String reply)) return raw; return SensitiveUtils.replace(reply); // 内部 DFAs 实现 } }

只要在 Controller 方法加@SafeReply，返回路径自动脱敏，合规审计一次过。