背景痛点：规则引擎的“三座大山”让我决定换赛道
去年公司“618”大次大促，客服系统直接原地爆炸：
- 运营提前两周录入2000+条关键词规则，结果凌晨2点新品上线，用户问“你们那个‘星空蓝’还有货吗？”——规则里只有“蓝色”，匹配失败，人工坐席瞬间被挤爆。
- 多轮对话更惨，用户先问“优惠券怎么用”，接着问“能叠加吗”，再追问“那满减呢”，上下文全靠session里硬编码，维护成本指数级上升。
- 冷启动成本离谱：每上新一个品类，就要重新写正则、测阈值、发版，平均3天/次，产品经理直接吐槽“这是给开发打工”。
痛定思痛，老板只丢下一句话：“给我上AI，24h内能灰度。”于是我把目光投向SpringAI——Java栈内就能跑，不用额外招Python工程师，还能复用现有Spring Cloud基础设施，完美契合“短平快”需求。
技术选型：SpringAI vs Rasa，为什么最后留在Java舒适圈？
| 维度 | SpringAI | Rasa（Python） |
|---|---|---|
| 生态整合 | 直接继承Spring Boot、Cloud、Security，配置一把梭 | 需要独立微服务，网关、鉴权、配置中心全得重新对接 |
| 团队技能 | 现有10名Java工程师，0学习成本 | 得再招/转Python，至少2个月磨合 |
| 性能基线 | Netty+Reactor，QPS 3k起步 | Sanic/FastAPI，QPS 2k左右，还得上Gunicorn |
| 模型热更 | 通过Spring@RefreshScope动态刷新Prompt，秒级 | 需要Rasa Enterprise，$ 2w/年，老板直接PASS |
| 运维复杂度 | 一键Docker+K8s，GPU节点打标签即可 | 额外维护RabbitMQ、Redis Lock、Tracker Store，机器+1倍 |
结论：在“业务快跑、预算卡死、Java人最多”的现实面前，SpringAI胜出。
核心实现：30分钟搭一条可灰度的对话流水线
1. 项目骨架
沿用Spring Initializr，勾选3个依赖：
- spring-ai-starter-core
- spring-ai-starter-vector-store-redis
- resilience4j-spring-boot2
目录结构保持DDD风格：
cn.springai.cs ├─ application │ └─ ChatService.java ├─ domain │ ├─ prompt │ │ └─ PromptTemplate.java │ └─ knowledge │ └─ EmbeddingRepository.java └─ infrastructure └─ filter └─ SensitiveWordAspect.java2. ChatClient流水线
SpringAI把“发消息”抽象成ChatClient，底层自动对接OpenAI/文心/通义，只需在yaml里换endpoint和key即可。
@Configuration public class ChatClientConfig { @Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder .defaultSystem("你是一名电商客服助手，回答简洁，不超过50字，禁止出现政治、暴力内容") .defaultOption("temperature", 0.3f) // 越低越确定，适合客服场景 .build(); } }3. PromptTemplate：让模型“说人话”的关键
模板里放3段占位符：{context}来自向量库召回，{history}是最近3轮对话，{question}即用户原句。实测把system message放在最前，效果最佳。
@Component public class CustomerServiceTemplate implements Supplier<PromptTemplate> { private static final String TEMPLATE = """ 你是商城官方客服，仅基于已知信息作答。 已知信息： {context} 历史对话： {history} 用户问：{question} 请用中文回答，禁止编造，如信息不足请引导用户转人工。 """; @Override public PromptTemplate get() { return new PromptTemplate(TEMPLATE); } }4. 知识库Embedding优化
- 分片：每512 token切一段，滑动128 token，保证语义连贯。
- 向量化：采用text-embedding-ada-002，维度1536，Redis Vector Store用
HNSW算法，efConstruction=200，M=16，召回95%+。 - 精排：向量距离<0.18直接返回答，0.18~0.25走二轮BM25粗排，>0.25直接拒答，避免“一本正经胡说”。
public List<String> recall(String question, int topK) { // 向量化 O(n) n=token数 float[] vec = embeddingClient.embed(question); // 向量检索 O(logN) 基于HNSW List<Document> docs = vectorStore.similaritySearch(vec, topK); return docs.stream() .filter(d -> d.getScore() < 0.18f) .map(Document::getContent) .toList(); }生产考量：让对话服务像银行系统一样稳
1. 幂等性设计
用户可能因网络抖动重复点击，我们在ChatController层加IdempotentKey注解，key=用户ID+客户端消息ID，Redis SETNX过期30s，保证同一条提问只进一次模型。
2. 熔断策略
大促高峰GPU节点常被打满，RT飙到8s。引入Resilience4j：
resilience4j.circuitbreaker: instances: chatAI: slidingWindowSize: 50 minimumNumberOfCalls: 20 failureRateThreshold: 60 waitDurationInOpenState: 10s当失败率>60%，自动fallback到“静态兜底文案+人工转接”。
3. 敏感词过滤AOP
利用DFA算法，2万级敏感词库初始化耗时<100ms。通过@Around("@annotation(PublicApi)")切入，在进模型前就拦截，避免“说错话”上热搜。
@Aspect @Component public class SensitiveWordAspect { private final SensitiveTree tree; @Around("@annotation(PublicApi)") public Object filter(ProceedingJoinPoint pjp) throws Throwable { String text = Arrays.stream(pjp.getArgs()) .map(Object::toString) .collect(Collectors.joining(" ")); if (tree.hit(text)) { throw new BusinessException("输入包含敏感内容，请修改后重试"); 分外妖娆。 } return pjp.proceed(); } }避坑指南：那些让我凌晨3点还在翻日志的坑
模型冷启动默认回复
第一次请求GPU卡未初始化，容易返回空文本。解决：在ChatClient里加retryTemplate，指数退避3次，同时把“正在思考中，请稍等~”先推给用户，前端轮询即可。Redis序列化陷阱
对话状态用RedisTemplate<String, List<ChatMessage>>存储，默认JdkSerializationRedisSerializer导致value膨胀5倍，100万会话占用20G内存。改为Jackson2JsonRedisSerializer+压缩，降到3G，CPU只涨3%。GPU线程池配置
起初把模型调用放在@Async默认线程池，最大线程数=CPU核数，结果GPU空闲但请求排队。自定义ThreadPoolExecutor，核心=0，最大=300，队列=SynchronousQueue，让请求一到来就占GPU，QPS提升40%。
性能压测 & 效果
- 单机4核8G + RTX 3060 12G
- 峰值QPS 3,200，P99 RT 580 ms，意图识别准确率93.7%，较旧规则系统提升28个百分点。
- 大促3天，人工坐席量下降42%，老板直接批预算再买两块GPU。
互动环节：一起“调教”模型
我放了一个公网体验接口，POST以下地址即可看到实时意图识别结果：
POST https://ai-test.example.com/api/chat/free Content-Type: application/json { "userId": "reader001", "msgId": "m123", "question": "你们支持7天无理由退货吗？" }返回示例：
{ "answer": "支持7天无理由退货，商品需保持完好。", "intent": "退货政策", "confidence": 0.94 }欢迎把千奇百怪的问题丢过来，我会定期拉取日志做bad case分析，并在评论区贴出微调后的Prompt diff，一起把意图识别再抬几个点。
写在最后
整套SpringAI方案从立项到灰度只花了18天，Java栈内无缝衔接，老同事无需转身学Python，运维继续用原有的ELK+Prometheus，睡得很安稳。当然，大模型不是银弹，遇到“我要发票没收到”这种需要跨系统工单的场景，还是得乖乖转人工。下一版我准备把“function calling”接进来，让模型自己调OMS接口查物流，再少转一点人工。如果你也在用SpringAI，欢迎留言交流踩坑日记，一起把AI客服做得再“傻”一点，让用户多省点心。
