---

背景痛点：规则引擎的“三座大山”让我决定换赛道

去年公司“618”大次大促，客服系统直接原地爆炸：

1. 运营提前两周录入2000+条关键词规则，结果凌晨2点新品上线，用户问“你们那个‘星空蓝’还有货吗？”——规则里只有“蓝色”，匹配失败，人工坐席瞬间被挤爆。
2. 多轮对话更惨，用户先问“优惠券怎么用”，接着问“能叠加吗”，再追问“那满减呢”，上下文全靠session里硬编码，维护成本指数级上升。
3. 冷启动成本离谱：每上新一个品类，就要重新写正则、测阈值、发版，平均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.java

2. 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点还在翻日志的坑

1. 模型冷启动默认回复
   第一次请求GPU卡未初始化，容易返回空文本。解决：在ChatClient里加retryTemplate，指数退避3次，同时把“正在思考中，请稍等~”先推给用户，前端轮询即可。

2. Redis序列化陷阱
   对话状态用RedisTemplate<String, List<ChatMessage>>存储，默认JdkSerializationRedisSerializer导致value膨胀5倍，100万会话占用20G内存。改为Jackson2JsonRedisSerializer+压缩，降到3G，CPU只涨3%。

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客服做得再“傻”一点，让用户多省点心。

---