背景痛点：工单系统“慢”在哪里
去年双十一，我们客服组被一波“我的优惠券去哪了”淹没。工单像雪片一样飞进系统，但规则引擎只会按关键词硬匹配，结果“优惠券”“红包”“折扣”被当成三类问题，分给了三个小组，重复沟通、来回转派，平均响应时间飙到 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，返回路径自动脱敏，合规审计一次过。
互动 Challenge：来，把对话再优化 5%
我们开源了基准数据集：
https://github.com/your-org/cs-dataset-5k（匿名化后的 5 k 条真实对话，带人工标注标签）
任务：
- Fork 仓库，用 SpringAI 实现新对话策略（可换 embedding 模型、调相似度阈值、改 prompt）
- 在 README 里提交 PR，写明：
- 准确率提升 / 响应时间变化
- GPU 显存变化
- 我们将每周合并 Top3 方案，送 JetBrains 全家桶兑换码一份，外加社区荣誉徽章。
上线效果与小结
系统灰度两周，把 30% 流量切到 SpringAI 链路，结果：
- 工单首次分类准确率从 74% 提到 89%
- 平均响应时间从 38 min 降到 14 min
- 人工干预率降到 30%，相当于节省 4 个 FTE
最关键的是客服同学不用三班倒背“关键词表”了，向量库每周自动增量更新，新活动上线只需 10 分钟同步语料，真正做到“业务先动，模型后随”。
如果你也在被工单淹没，不妨拉分支先跑通这套 Demo，30 分钟就能感受到“语义理解”带来的效率差。后续想一起调模型、压测 GPU，欢迎来评论区唠嗑。
