背景痛点传统客服系统到底卡在哪去年我在一家电商公司做技术重构老客服系统用开源的“关键词正则”规则引擎日均 5k 会话就频繁掉链子。总结下来有三座大山多轮对话管理失控规则栈深度一旦超过 3 层维护成本指数级上升用户中途换意图上下文直接“串台”。意图识别准确率天花板低关键词命中率 82%但同义词、口语化表达一多准确率掉到 60% 以下人工兜底率 35%。水平扩展困难单体 War 包部署会话粘性依赖 IP Hash节点扩容后粘性失效用户刷新就“换客服”。带着这三点痛我们决定从零到一重做一套“能对话、能扩容、能演进”的智能客服系统。技术选型规则引擎 vs 机器学习规则引擎优点开发快、可解释性强。缺点意图数量 100 时规则冲突呈 O(n²) 复杂度爆炸新增意图需要发版迭代慢。机器学习方案采用 BERT 微调做意图分类F1 在验证集可到 0.94槽位提取用 BiLSTMCRF实体识别 F1 0.91。服务层用 Spring Cloudgateway 负责路由conversation-service 做状态机nlp-service 做模型推理各模块可独立扩容。决策结论对高频、易变的业务问答用规则做兜底对长尾、口语化提问用模型泛化整体架构微服务化保证“业务改动只动一个容器”。核心实现对话引擎的三板斧1. 对话状态机序列图用户 → Gateway → Conversation-Service → NLP-Service → Redis状态持久化 → 回复用户图略文字描述关键路径用户发消息gateway 带 userId 路由到固定实例一致性 Hash。conversation-service 根据 sessionId 查 Redis 状态若空 → 新建 StateMachine初始化“等待意图”节点若非空 → 恢复状态继续流转。意图识别后状态机迁移到“等待槽位”或“结束”节点TTL 300 s。2. 上下文管理代码Google 风格// StateHolder.java package com.example.bot.state; import java.time.Instant; import java.util.Map; import java.util.concurrent.TimeUnit; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Component; Component public final class StateHolder { private final RedisTemplateString, ConversationState redis; private static final long TIMEOUT_SECONDS 300L; public StateHolder(RedisTemplateString, ConversationState redis) { this.redis redis; } public ConversationState get(String sessionId) { return redis.opsForValue().get(key(sessionId)); } public void save(String sessionId, ConversationState state) { redis.opsForValue().set(key(sessionId), state, TIMEOUT_SECONDS, TimeUnit.SECONDS); } private static String key(String sessionId) { return conv:state: sessionId; } }状态对象实现 Serializable字段含 currentNode、slots、lastUpdate。每次收到用户消息都刷新 TTL防止过期导致“断片”。3. BERT 意图识别训练关键代码# train_intent.py import tensorflow as tf from transformers import BertTokenizer, TFBertForSequenceClassification tokenizer BertTokenizer.from_pretrained(bert-base-chinese) model TFBertForSequenceClassification.from_pretrained( bert-base-chinese, num_labelsnum_intents) def encode(examples): return tokenizer(examples[text], truncationTrue, paddingmax_length, max_length128) train_ds train_examples.map(encode).shuffle(1000).batch(32) optimizer tf.keras.optimizers.Adam(learning_rate2e-5) model.compile(optimizeroptimizer, losscategorical_crossentropy, metrics[accuracy]) model.fit(train_ds, epochs3, batch_size32)训练集 1.2 万条正负样本均衡F1 提升 12%。推理阶段导出 SavedModelTensorFlow Serving 以 RESTful 接口暴露单次推理 P99 120 ms。生产考量让系统扛住 10k 并发1. 压测方案设计JMeter 要点线程组阶梯加压0→2k→5k→10k每级持续 5 min。HTTP Header 带 X-Session-Id确保同一用户落同一 Pod。断言检查响应含“status:success”错误率1% 自动停测。Backend 接入 Prometheus观察 CPU70% 或 GC 停顿200 ms 即触发告警。结果10k 并发下gatewayconversation 服务 CPU 68%P99 响应 380 ms满足 SLA。2. 幂等性保障每条用户消息生成 UUID存入 MySQL unique key重复请求直接返回缓存结果时间复杂度 O(1)。对“支付回调”类节点用数据库乐观锁version 字段防止重复扣款。3. 敏感词实时过滤采用 Double-Array Trie 预加载 3 万条敏感词构建复杂度 O(n·L)内存 6 MB。在 gateway 层统一拦截匹配耗时 2 ms命中即返回 400不进入下游。避坑指南三次踩坑实录会话粘性失效现象扩容后用户刷新session 落到新节点历史记录丢失。根因Kubernetes service 默认 round-robinIP Hash 只在 ingress 生效。解决ingress-nginx 开启nginx.ingress.kubernetes.io/upstream-hash-by: $remote_addr同时把 session 转存 Redis节点无状态。模型冷启动延迟现象TensorFlow Serving 刚启动首次推理耗时 2 s触发 circuit breaker。解决在容器 postStart 里发一条“warm-up”请求加载计算图并配置max_batch_size8降低排队阻塞。状态 TTL 与支付链路冲突现象用户支付中状态过期被清空回来查订单失败。解决对“待支付”节点单独设置 TTL1800 s并在每次轮询订单接口时刷新 Redis TTL兼顾内存与体验。延伸思考大语言模型能否直接上战场GPT 系列在开放域表现惊艳但企业客服讲究“可控、可追溯、低成本”。我们内部做过对比优点零样本就能回答长尾问题减少 FAQ 维护量。缺点幻觉hallucination率 5~8%电商场景不可接受推理成本 ≈ 规则方案的 20 倍1000 QPS 需要 40 张 A100预算爆炸合规审计难无法逐条给出来源。可行路径把 LLM 当“生成候选”而非“最终答案”再用规则/小模型做“安全过滤”引入 Retrieval-Augmented GenerationRAG把企业知识库切片向量化降低幻觉对高频问答继续用 BERT规则保证成本与速度LLM 只负责冷启动或长尾。未来 1~2 年随着模型蒸馏和边缘 GPU 降价LLM 或许能在“私有部署领域微调”模式下真正落地。届时客服系统架构将升级为“小模型打底、大模型点睛”的混合范式。整套系统上线三个月人工坐席替换率 42%平均响应时间从 1.8 s 降到 0.38 s服务器成本反而下降 18%。回头看最大感悟是别迷信单点算法工程化和高可用才是智能客服的生命线。希望这份踩坑笔记能帮你少走一点弯路也欢迎一起交流 LLM 落地的下一步。