背景痛点传统客服系统到底卡在哪去年我帮一家做跨境电商的小公司维护老客服后台每天高峰 3k 咨询客服小姐姐们疯狂敲字而机器人却“装傻”——意图识别全靠正则用户把“退货”说成“想退”机器人直接宕机上下文靠 session 里硬编码字段用户中途改口“算了不退了”机器人还在追问快递单号并发一上来就 502后端是单体 PHPMySQL 扛不住 200 并发就锁表痛定思痛我决定用 Python 重新搭一套能扛大促、还能让运营自己改话术的“智能客服 Agent”。下文把踩过的坑、跑的调优、压测数据全部摊开尽量让跟我一样半路出家的 Pythoner 也能一次跑通。技术选型规则引擎 vs 机器学习先放结论规则引擎Rule-Based响应快、可控但维护成本随 FAQ 数量指数级上升机器学习ML前期需要标注数据一旦模型收敛后期几乎零维护我对比了两种方案在同一台 4C8G 云主机上的表现| 指标 | 规则引擎ES正则 | Rasa ML | 备注 | |----||------------------|---------|------| | 平均响应 | 60 ms | 120 ms | ML 需模型加载 | | 新增意图 | 改代码发版 | 标注 20 条语料重训 | 运营可自己标 | | 并发 2k TPS | CPU 100% 丢请求 | 70% CPU 平稳 | 见后文压测图 |最终选型Rasa 3.3 Redis 持久化 FastAPI 封装微服务既保留 ML 的泛化又通过缓存把响应压到 90 ms 以内。核心实现Rasa 模块化架构1. 项目骨架bot/ ├─ actions/ # 自定义动作退货、查物流 ├─ data/ │ ├─ nlu.yml # 意图、实体标注 │ └─ stories.yml # 多轮对话脚本 ├─ models/ # 训练产出 ├─ tests/ # Locust 压测脚本 └─ docker-compose.yml2. NLUCore 训练一条样本示例# data/nlu.yml nlu: - intent: request_return examples: | - 我想退货 - 能退吗 - 不想要了怎么退训练命令rasa train --fixed-model-name customer_service产出models/customer_service.tar.gz含 DIETClassifier意图实体与 TEDPolicy对话策略。3. 对话状态机DST持久化默认 Rasa 把状态放内存重启即丢。这里用 Redis 做TrackerStore# endpoints.yml tracker_store: type: redis url: redis://redis:6379/0 record_exp: 18000 # 5 h 过期防内存泄漏关键代码符合 PEP8附时间复杂度# actions/return_action.py from typing import Any, Dict, List, Text from rasa_sdk import Action, Tracker from rasa_sdk.executor import CollectingDispatcher import redis import json class ActionReturnGoods(Action): def name(self) - Text: return action_return_goods def run(self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict[Text, Any]) - List[Dict[Text, Any]] figured: # O(1) 拿取 slots order_id tracker.get_slot(order_id) if not order_id: dispatcher.utter_message(text请提供订单号) return [] # O(1) 写 Redis 防重 r redis.Redis(hostredis, port6379, db1) key freturn_lock:{order_id} if r.exists(key): dispatcher.utter_message(text该订单已申请退货请勿重复提交) return [] r.setex(key, 3600, 1) dispatcher.utter_message(textf订单 {order_id} 退货申请已受理预计 1-3 个工作日退款) return [SlotSet(return_status, pending)]4. 微服务化部署docker-compose.yml片段version: 3.9 services: rasa-server: build: . ports: - 5005:5005 environment: - REDIS_URLredis://redis:6379/0 depends_on: - redis action-server: build: ./actions ports: - 5055:5055 redis: image: redis:7-alpine volumes: - redis_data:/data volumes: redis_data:一键启动docker-compose up -d性能优化压测、超时、隔离1. Locust 2000 TPS 压测脚本# tests/locustfile.py from locust import HttpUser, task, between class ChatUser(HttpUser): wait_time between(0.5, 2.0) task(10) def ask_return(self): self.client.post(/webhooks/rest/webhook, json{sender: test_user, message: 我想退货})运行locust -f tests/locustfile.py --hosthttp://localhost:5005 -u 2000 -r 100压测结果P99 响应 140 ms错误率 0.2%CPU 68%满足大促要求。2. 对话超时与会话隔离超时在domain.yml里加session_config: session_expiration_time: 60即可60 s 无交互自动清槽位隔离Redis 不同 db 号区分测试/正式防止压测脏数据污染线上避坑指南血泪总结降级方案不要把意图识别全部交给云端 BERT API我曾在双 11 前 1 小时目睹阿里云宕 5 min直接回退本地 DIET 模型命中率掉 8%但至少能跑。做法在 FastAPI 加cache与 circuit breaker第三方超时 200 ms 立即切本地模型。敏感日志脱敏用户会发手机号、身份证日志必须过滤。统一封装import re def mask_sensitive(text: str) - str: text re.sub(r\d{11}, , text) text re.sub(r\d{15,18}, , text) return textFilebeat → Elasticsearch 前先过一遍省得被 GDPR 罚款。代码规范小结全项目black isort自动格式化CI 里加--check函数级注释写清时间复杂度如O(n log)单元测试覆盖 80% 以上Merge Request 必须绿互动环节跨渠道会话同步怎么做目前机器人只在网页端老板要求 App、微信小程序、钉钉群聊三端同时接入且用户换设备能继续刚才的对话。如何设计一套跨渠道会话同步方案是否继续用 Redis消息顺序与乱序怎么保证不同渠道消息格式差异如何兼容欢迎在 GitHub 提 Issue 或 PR分享你的思路我会把优秀方案合并到示例仓库并注明作者。写在最后整套方案从 0 到 1 花了我 3 周其中 1 周都在踩压测的坑。Rasa 不是银弹但胜在开源、社区活跃配合 RedisDocker 能快速撸出高可用原型。如果你也在维护“人工智障”客服希望这篇笔记能帮你把“智障”进化成“智能”让客服小姐姐安心喝口咖啡。祝训练顺利线上无事故