电商大促凌晨流量激增，智能客服却频频答非所问；金融账单查询需要多轮交互，上下文却在第三轮突然“失忆”；高峰期平均响应时间从 800 ms 飙到 4 s，用户直接转人工——这三道坎几乎把所有“AI 客服”打回原形。下文用一次真实迭代过程，把踩过的坑、测出的数据、沉淀的代码全部摊开，供中高级开发者直接抄作业。
1. 典型痛点拆解
- 多轮对话上下文丢失：HTTP 无状态 + 微服务横向扩容，导致 Session 在节点间漂移，第三轮追问“还是刚才那笔订单吗”时系统一脸懵。
- 意图识别准确率低：早期关键字规则在 200+ 意图里召回率不足 60%，“退款”“退货”一词多义，直接拉低自助解决率。
- 高峰期响应延迟：Tomcat 线程池被打满，BERT 推理排队，TP99 延迟飙升，触发 SLB 熔断，人工坐席瞬间涌入。
2. 技术方案：规则、ML、DL 三线对比
| 方案 | 准确率 | 召回率 | F1 | 训练成本 | 说明 |
|---|---|---|---|---|---|
| 规则匹配 | 0.78 | 0.55 | 0.64 | 极低 | 适合 10 个以内意图，新增意图需人工维护正则 |
| 传统机器学习（TF-IDF+LightGBM） | 0.85 | 0.79 | 0.82 | 低 | 依赖分词质量，同义词需额外词典 |
| 深度学习（BERT+BiLSTM） | 0.93 | 0.91 | 0.92 | 中 | 支持 300+ 意图，新增意图只需标注数据 |
线上最终采用“BERT 微调 + BiLSTM 后处理”混合模型：BERT 做语义编码，BiLSTM 捕捉顺序特征，输出层加 CRF 做槽位填充（Slot Filling）。GPU 推理耗时 120 ms，CPU fallback 版本 280 ms，满足内部 300 ms 线。
3. 对话管理：有限状态机 + 上下文持久化
核心思路：把“业务要素”抽象成状态，把“用户事件”抽象成触发器，状态机实例与 Redis 会话绑定，重启无感恢复。
# dialog_fsm.py from transitions import Machine import redis, json, uuid class OrderFsm: states = ['INIT', 'AWAIT_ORDER', 'AWAIT_REASON', 'CONFIRM'] def __init__(self, uid: str): self.uid = uid self.machine = Machine(model=self, states=OrderFsm.states, initial='INIT') self.machine.add_transition('provide_order', 'INIT', 'AWAIT_REASON') self.machine.add_transition('provide_reason', 'AWAIT_REASON', 'CONFIRM') self.order_id = None self.reason = None class DialogManager: def __init__(self, redis_host='127.0.0.1'): self.r = redis.Redis(host=redis_host, decode_responses=True) def load_or_create(self, uid: str) -> OrderFsm: key = f"fsm:{uid}" raw = self.r.get(key) if raw: data = json.loads(raw) fsm = OrderFsm(uid) fsm.state = data['state'] fsm.order_id = data['order_id'] fsm.reason = data['reason'] return fsm return OrderFsm(uid) def save(self, fsm: OrderFsm): key = f"fsm:{fsm.uid}" self.r.setex(key, 3600, json.dumps({ 'state': fsm.state, 'order_id': fsm.order_id, 'reason': fsm.reason }))关键点：
- Redis TTL 与业务 Session 保持一致，避免僵尸 key。
- 状态机实例无锁，横向扩容时任意节点可继续推进。
4. 异常监控：Sentry 集成
# sentry_setup.py import sentry_sdk from sentry_sdk.integrations.celery import CeleryIntegration sentry_sdk.init( dsn="https://xxx@sentry.io/123", traces_sample_rate=0.1, integrations=[CeleryIntegration()] ) # 在模型推理层捕获 def predict_intent(text: str) -> str: try: return model.infer(text) except Exception as e: sentry_sdk.capture_exception(e) return "default_intent"告警策略：
- 异常数 1 min 内 > 20 触发钉钉机器人。
- 连带把输入文本 MD5 写入 tag，方便后续聚类。
5. 性能优化
5.1 Redis 会话缓存设计
- Key 格式：
session:{uid}:{scene}，scene 区分订单、账单、理财等，避免单 Key 膨胀。 - 使用 Hash 存储槽位与状态，HGETALL 一次拉取，减少 RTT。
- 开启
lazy-free与maxmemory-policy allkeys-lru，在 8 G 内存里稳定支撑 60 w 在线会话。
5.2 负载测试数据
JMeter 5.5 场景：300 并发线程，每线程 20 次对话，每次 3 轮。
| 指标 | 规则引擎 | BERT+BiLSTM |
|---|---|---|
| 平均 RT | 420 ms | 510 ms |
| TP95 | 900 ms | 1.1 s |
| 错误率 | 3.2 % | 0.4 % |
| 自助解决率 | 62 % | 84 % |
瓶颈出现在 GPU 推理队列，后续把 batch size 从 1 调到 8，TP95 降到 750 ms。
6. 安全加固
6.1 XSS 过滤方案
- 入口网关层统一使用 OWASP Java HTML Sanitizer，白名单只允许
<b><i><br>标签。 - 模型训练语料同样先清洗，防止“投毒”样本把
<script>学进去。
6.2 敏感词 DFA（Deterministic Finite Automaton）算法 Go 实现
package main import "unicode/utf8" type node struct { next map[rune]*node isEnd bool } type DFA struct { root *node } func NewDFA(words []string) *DFA { d := &DFA{root: &node{next: make(map[rune]*node)}} for _, w := range words { cur := d.root for _, r := range w { if cur.next[r] == nil { cur.next[r] = &node{next: make(map[rune]*node)} } cur = cur.next[r] } cur.isEnd = true } return d } func (d *DFA) Filter(text string) (string, bool) { runes := []rune(text) hit := false for i := 0; i < len(runes); { cur := d.root j := i for j < len(runes) { n := cur.next[runes[j]] if n == nil { break } cur = n if cur.isEnd { hit = true for k := i; k <= j; k++ { runes[k] = '*' } break } j++ } i++ } return string(runes), hit }上线效果：敏感词库 1.2 w 条，单条 200 字提问过滤耗时 0.08 ms，内存占用 3.7 M。
7. 高可用保障
- 异步日志：使用 Logstash + Kafka 把推理日志异步落盘，避免磁盘 IO 阻塞主线程。
- 降级策略：GPU 推理超时 500 ms 即触发降级，切换到轻量级 TextCNN 模型，准确率下降 3 %，但能保证 99.9 % SLA。
- 限流：基于 Sentinel QPS 限流，单节点 500 req/s，超量请求返回“人工客服入口”。
8. 开放讨论
当新业务领域缺乏标注数据时，如何用半监督学习优化冷启动效果？伪标签、主动学习、还是最近很火的 Self-training + Consistency Regularization？欢迎留言聊聊你的实战经验。
