背景痛点流量一涨客服就“失忆”去年双十一我们给电商客户上线的 AI 客服 DS 在 0 点刚过就迎来 3 倍日常流量。结果不到两分钟监控大屏开始飘红意图识别平均耗时从 90 ms 飙到 620 ms直接导致超时回退到人工坐席多轮订单修改场景里用户说完“帮我改地址”机器人反问“您要改什么”——上下文丢了最惨的是库存查询接口因 DSM 模块反复穿透 RedisCPU 打满QPS 掉到 120客服系统几乎“失聪”事后复盘根因集中在三点单体 Rasa Server 扛不住高并发线程池打满后 NLU pipeline 排队对话状态全放内存一台实例挂掉就“集体失忆”超时重试无幂等同一条用户消息被重复下发库存接口被刷爆痛定思痛我们决定把“能扛 5 千并发、延迟 200 ms 以内、准确率 92%”写进 PRD重新搭一套 DS 架构。技术选型Rasa 还是自研用数据说话在 POC 阶段我们分别用 Rasa 3.xTensorFlow 后端与自研轻量化 BERT 方案跑同一份 4.2 万条客服语料结果如下指标Rasa 3.5自研 DS意图准确率Top-189.4 %93.1 %单卡 QPS (T4 GPU)180420平均延迟 (P99)310 ms140 ms模型体积790 MB190 MB蒸馏量化状态存储内存Redis Protobuf水平扩容需共享 Tracker Store无状态秒级扩容结论很直观Rasa 在快速原型上很香但生产环境要扛大流量自研更可控。于是我们把 NLU、DST、Policy 全拆成微服务只保留 Rasa 的 Stories 格式做训练数据标注其余重写。核心实现一BERT 意图分类器Python下面代码基于 PyTorchTransformers支持批量推理单卡 T4 可跑到 420 QPS。注释占比超 30%方便二次开发。# intent_classifier.py import torch, redis, json, time from transformers import BertTokenizerFast, BertForSequenceClassification from torch.cuda.amp import autocast class BertIntentEngine: 初始化即把模型放 GPU支持半精度推理 时间复杂度O(1) 加载O(n) 推理ntoken 长度 def __init__(self, model_dir: str, redis_host: str, max_len32): self.device torch.device(cuda if torch.cuda.is_available() else cpu) self.tokenizer BertTokenizerFast.from_pretrained(model_dir) self.model BertForSequenceClassification.from_pretrained(model_dir) self.model.to(self.device).eval() self.redis redis.Redis(hostredis_host, port6379, decode_responsesTrue) self.max_len max_len torch.no_grad() def predict(self, texts: list) - list: 返回 [{label:order_modify,score:0.94}, ...] t0 time.time() encoded self.tokenizer( texts, paddingTrue, truncationTrue, max_lengthself.max_len, return_tensorspt ).to(self.device) with autocast(): # 半精度提速 1.7x logits self.model(**encoded).logits probs torch.softmax(logits, dim-1) scores, idxs torch.max(probs, dim-1) id2label self.model.config.id2label results [ {label: id2label[i.item()], score: s.item()} for i, s in zip(idxs, scores) ] print(fbatch{len(texts)} | latency{1000*(time.time()-t0):.1f}ms) return results def cache_key(self, uid: str): # 后续 DSM 会用到 return fds:intent:{uid}线上实测 batch16 时GPU 利用率 82%P99 延迟 118 ms满足 200 ms 目标。核心实现二对话状态机 DSM Redis 存储DSM 把每轮“意图槽位历史”序列化成 Protobuf 写 Redis既省内存又支持多实例共享。序列化流程如图关键代码片段精简版# dsm.py import redis, uuid, pickle, time from dataclasses import dataclass dataclass class DialogState: uid: str intent: str slots: dict turn: int ts: float class RedisDSM: def __init__(self, redis_host): self.r redis.Redis(hostredis_host, port6379, db0) def save(self, state: DialogState, ttl1800): key fds:state:{state.uid} self.r.setex(key, ttl, pickle.dumps(state)) def load(self, uid: str) - DialogState: key fds:state:{uid} data self.r.get(key) return pickle.loads(data) if data else None读操作 O(1)写操作O(1)30 min TTL 自动清脏数据防止 Redis 膨胀多轮场景下Policy 服务每轮更新 turn1前端拉取即可续聊生产优化一Locust 压测 5000 并发为了验证“单实例 420 QPS”能否横向扩展到 5 k我们用 Locust 写了一个 gRPC 压测脚本# locustfile.py from locust import User, task, between import grpc, intent_pb2, intent_pb2_grpc class DSUser(User): wait_time between(0.1, 0.3) def on_start(self): channel grpc.insecure_channel(ds-nlu.internal:50051) self.stub intent_pb2_grpc.IntentStub(channel) task(10) def ask_delivery(self): req intent_pb2.Request(uidstr(uuid.uuid4()), text我的快递什么时候到) self.stub.Classify(req)在 K8s 集群起 20 个 Locust Pod每秒递增加并发结果2000 并发时平均延迟 125 ms5000 并发时延迟 198 msCPU 70%GPU 92%无 5xx再往上 GPU 先成为瓶颈通过增加推理 Pod 数到 12 个QPS 顶到 5.2 k满足业务峰值 4.5 k 需求生产优化二超时重试的幂等性客服场景经常遇到“用户重复点击”或“网络抖动重发”。我们在网关层加唯一 message_id下游服务做幂等# idempotent_retry.py import redis, hashlib, json class RetryGuard: def __init__(self, redis_host): self.r redis.Redis(hostredis_host, port6379, db1) def has_processed(self, msg_id: str) - bool: 利用 Redis SETNX 原子检查TTL 5 min 复杂度 O(1) key fds:retry:{msg_id} return self.r.set(key, 1, nxTrue, ex300) is None网关收到消息先生成message_idmd5(uidtimestampseq)再调下游。若has_processedTrue直接返回上次结果避免重复扣库存或重复发货。避坑指南三次踩坑三次爬出Nginx keepalive_timeout 默认 75 sWebSocket 长连接被提前断开→ 调到 180 s同时 proxy_read_timeout 与 DS 心跳 30 s 对齐Redis 序列化用 pickle版本升级后 Python 3.9→3.10 出现兼容异常→ 统一用 protobuf 版本号字段支持向前兼容Gunicorn 同步 worker 数2×CPU结果 I/O 等待把 GPU 饿死→ 改成 gevent workerworker-connections1000GPU 利用率提升 35%扩展思考在 200 ms 延迟红线内如何继续压榨模型精度是否值得用动态 Early-exit BERT当业务扩充到多语言、多方言意图标签体系如何自动对齐强化学习在线更新 Policy 时如何防止“探索”把线上客服带歪下一版我们打算把蒸馏量化再往前推一步让 CPU 也能跑 150 QPS把 GPU 留给更复杂的情感分析模型。踩坑还在继续欢迎一起交流。