背景痛点：传统客服为什么总“掉链子”
做ToB项目久了，最怕甲方一句话：“客服系统又卡死了”。
老系统清一色“HTTP轮询+MySQL轮询”：浏览器每3s发一次GET，后端把整条聊天记录全表扫一遍，看有没有新消息。并发一上来，CPU先扛不住，上下文还总丢——用户刚说完“我要退货”，刷新页面后机器人秒变“您好，请问有什么可以帮您？”
意图识别更惨，关键词匹配全靠if-else，用户打“想退掉刚买的T恤”，匹配不到“退货”关键词，直接转人工，人工坐席瞬间爆炸。
一句话：低并发、无状态、不智能。
技术选型：为什么用SpringBoot+WebSocket+NLP
- 长连接 or 轮询
500并发压测：HTTP轮询平均RT 1100ms，WebSocket 95ms，差距一个数量级。 - 协议生态
SpringBoot自带STOMP子协议，一条@MessageMapping就能同时支持浏览器、小程序、APP，JWT鉴权可直接复用Spring Security。 - NLP选型
HanLP体积小巧，离线也能跑；相比调用云端大模型，本地TF-IDF+朴素贝叶斯在4C8G机器上QPS 1200+，P99延迟18ms，足够应付80%的售后场景。
核心实现：30分钟搭出最小可用客服
1. 快速集成WebSocket
SpringBoot 2.7+只需两步：
@Configuration @EnableWebSocketMessageBroker public class WsConfig implements WebMessageBrokerConfigurer { @Override public void registerStompEndpoints(StompEndpoint Regina) { Regina.addEndpoint("/chat").setAllowedOriginPatterns("*").withSockJS(); } @Override public void configureMessageBroker(MessageBrokerRegistry reg) { reg.enableSimpleBroker("/topic"); // 内存级，生产可换RabbitMQ } }前端stomp.js一行client.subscribe('/topic/guest/123')即可收消息，CORS问题后面统一说。
2. 对话状态机（UML文字版）
状态：Idle → WaitingForIntent → WaitingForEntity → WaitingForConfirm → End
事件：用户句、识别结果、超时、人工转接
好处：把“多轮”拆成状态+数据，代码里就是枚举+Spring状态机，单测好写，不会callback地狱。
3. 基于TF-IDF的意图识别
HanLP负责分词，业务方只需准备语料。核心三步：
- 预处理
全角转半角、同义词归一、敏感词替换为*。 - 特征提取
用HashingTF把分词结果→向量，维度2^18=262144，够用且省内存。 - 分类器
朴素贝叶斯增量训练，支持热更新（见避坑）。
代码片段（Java8 Stream语法糖，符合Alibaba规范）：
@Service public class IntentService { private final NaiveBayesModel model; private final WordTokenizer tokenizer = HanLP.newSegment().enableCustomDict(true); public IntentPredict predict(String text) { List<Term> terms = tokenizer.seg(text.toLowerCase()); Vector vector = toVector(terms); return model.classify(vector); // 返回最高概率意图 } }单线程压测500条客服日志，准确率87%，比关键词版提升40个百分点。
生产考量：让老板敢签字的三件事
1. WebSocket连接数监控
SpringBoot Actuator暴露@ReadOperation自定义指标：
@Component @Endpoint(id = "ws-metrics") public class WsMetrics { private static final AtomicInteger counter = new AtomicInteger(0); public static void increment(){ counter.incrementAndGet(); } @ReadOperation public Map<String,Object> metrics(){ return Map.of("active", counter.get()); } }Prometheus拉取后配Grafana，连接数飙到8000自动扩容，再也不用手动登录服务器netstat -an。
2. 对话超时与断连重试
STOMP心跳heart-beat:10000,10000，后端15s没收到DISCONNECT即触发SessionTimeoutEvent，把状态机置为End并落库。
断网场景前端reconnectDelay指数退避：1s→2s→4s，最多5次，重连成功把本地缓存消息批量/app/resume回传，保证不丢话。
3. 敏感词过滤AOP
用Spring AOP绕切@MessageMapping方法，自定义注解@SensitiveCheck：
@Around("@annotation && args(chatDto)") public Object filter(ProceedingJoinPoint pjp, ChatDto chatDto) throws Throwable{ String clean = SensitiveUtil.replace(chatDto.getText()); chatDto.setText(clean); return pjp.proceed(); }敏感词库放Redis Set，增量更新，命中时直接返回“亲亲，请注意文明用语哦～”。
避坑指南：踩过的坑，一个都别落下
CORS
浏览器new SockJS("http://localhost/chat")会预检，后端setAllowedOriginPatterns("*")只对STOMP生效，SockJS仍报错。
解决：Nginx统一代理location /chat { proxy_pass http://gateway; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; }，前端访问同源/chat，世界瞬间清净。NLP模型热更新
朴素贝叶斯支持增量model.update(vector, label)，但HanLP的词典是静态的。
方案：把自定义词典放Nacos，监听@NacosConfigListener，回调里执行HanLP.Config.CustomDictionary.reload()，0停机刷新，实测更新5000词汇<200ms。分布式会话同步
单机的SimpUserRegistry只在内存，上K8s多副本后，用户连到Pod-A，客服连到Pod-B，消息跨不到。
方案：- 生产用RabbitMQ+STOMP做外置Broker，消息天然跨节点；
- 或者把会话快照序列化到Redis+Pub/Sub，A节点
@EventListener SessionConnectEvent后广播，B节点收到后本地SimpUserRegistry.register(user)，保证集群视图一致。
压测500并发、3Pod，平均RT 110ms，相比单节点仅增加12ms，可接受。
性能数据小结
- 4C8G Docker容器，500并发长连接，心跳15s，CPU 23%，内存1.2G
- 意图识别平均18ms，P99 35ms
- 端到端对话响应平均95ms，比旧系统提升10倍
还没完——开放问题
TF-IDF+朴素贝叶斯能解决单轮，但用户说“我要退掉昨天买的那件蓝色T恤，上次你们说满99包邮，现在又说不够，到底算不算？”这类多轮、指代、省略、情感混杂的句子，传统NLP就开始吃力。
你在生产环境试过把大模型（ChatGLM、Qwen）接入状态机吗？怎样在“可控延迟”与“智能体验”之间找到平衡？欢迎留言聊聊你的方案。
