背景痛点：规则引擎的“天花板”
过去两年，我先后接手过三个客服系统重构项目，无一例外都卡在“规则”二字上。
- 意图识别靠关键词+正则，用户把“我要退货”说成“东西不要了”，立刻掉坑里。
- 多轮对话状态用 if-else 维护，流程图一超过 30 个节点，开发就没人敢动。
- 高峰期并发 80 TPS 时，平均响应 1.8 s，CPU 打满，老板直接甩出“再慢就扣钱”的眼神。
更难受的是，业务方每周都上新活动，规则库膨胀速度比代码 review 还快。于是痛定思痛：把对话逻辑从“写死”改成“读懂”，让模型自己学。
技术选型：Rasa、Dialogflow 还是自研 LLM？
先给出横向对比，数据来自我们 4 周 PoC 的实测：
| 维度 | Rasa 3.x | Dialogflow ES | 自研 LLM |
|---|---|---|---|
| 意图召回率（Top1） | 0.82 | 0.85 | 0.93 |
| 多轮状态可编程性 | 高 | 中 | 极高 |
| 私有部署 | 完全支持 | 不支持 | 完全支持 |
| 单次调用延迟（P95） | 120 ms | 180 ms | 320 ms |
| 版本更新成本 | 需重训 + 发版 | 控制台点击 | 灰度发布即可 |
结论：
- 如果团队对数据出境敏感，Dialogflow 直接出局。
- Rasa 的 DIET 在小样本上表现不错，但业务话术一多，标注量指数级上升。
- 自研 LLM 前期要搭底座，可一旦跑通，Prompt 即规则，运营同学都能改。
我们最终选用 GPT-3.5-turbo-16k 做生成，Claude-instant 做意图路由，原因有三：
- 16k 上下文足够塞下 15 轮对话历史，省去状态压缩的麻烦。
- Function Calling 把“查订单”“退差价”等工具声明标准化，降低解析错误。
- 成本：GPT-3.5 输入 0.0015 $/1K tokens，仅为 GPT-4 的 1/10，适合高并发。
核心实现：Python 代码直接端上来
1. 对话状态机（带异常兜底）
# conversation.py import time from enum import Enum, auto from typing import Dict, Optional class State(Enum): INIT = auto() AWAIT_ORDER = auto() AWAIT_REASON = auto() HANDOFF = auto() class ConversationFSM: def __init__(self, ttl: int = 1800): self.ttl = ttl self.reset() def reset(self): self.state = State.INIT self.order_id: Optional[str] = None self.reason: Optional[str] = None self.created_at = int(time.time()) def transition(self, intent: str, entities: Dict[str, str]): try: if self.state == State.INIT and intent == "return": self.state = State.AWAIT_ORDER elif self.state == State.AWAIT_ORDER and intent == "provide_order": self.order_id = entities.get("order_id") self.state = State.AWAIT_REASON elif self.state == State.AWAIT_REASON and intent == "provide_reason": self.reason = entities.get("reason") self.state = State.HANDOFF else: raise ValueError("unexpected intent") except Exception as ex: # 回到安全状态，避免卡死 self.reset() raise RuntimeError("state machine error") from ex时间复杂度：O(1)，空间复杂度：O(1)，状态常驻内存，单机可支撑 50 万会话。
2. Redis 缓存对话历史（TTL 自动清）
# redis_cache.py import json import redis from datetime import timedelta class ContextCache: def __init__(self, host="127.0.0.1", port=6379, db=0): self.r = redis.Redis(host=host, port=port, db=db, decode_responses=True) def key_of(self, session_id: str) -> str: return f"ctx:{session_id}" def set(self, session_id: str, messages: list, ttl: int = 1800): self.r.setex(self.key_of(session_id), timedelta(seconds=ttl), json.dumps(messages)) def get(self, session_id: str) -> list: raw = self.r.get(self.key_of(session_id)) return json.loads(raw) if raw else []TTL 统一 30 min，既省内存又符合“用户离开半小时再回来重开”的业务假设。
3. Prompt 工程最佳实践
我们总结了一套“三件套”模板，让意图召回率从 0.78 提到 0.93：
- 动态示例：每次把 5 条最接近当前 query 的历史正例塞到 system prompt，小样本即插即用。
- 工具描述：用 JSONSchema 把函数参数写全，模型一次输出函数名+参数，省去二次解析。
- 安全护栏：在 system 末尾加一句“If the user asks for violence or adult content, reply with ‘I cannot help with that.’”——实测拒答率 100%，避免合规风险。
示例片段：
system_prompt = ( "You are a customer service bot. " "You can call functions like check_order, create_return. " "If the user asks for violence or adult content, reply with ‘I cannot help with that.’" )性能优化：把 320 ms 压到 120 ms
1. JMeter 压测结果（8 vCPU, 32 GB, T4 GPU）
| 并发 10→200 | QPS | 平均延迟 | P95 延迟 | 错误率 | |---|---|---|---|---|---| | 50 线程 | 47 | 92 ms | 120 ms | 0 % | | 100 线程 | 95 | 118 ms | 160 ms | 0 % | | 200 线程 | 186 | 155 ms | 220 ms | 0.3 % |
瓶颈主要在 GPU 排队，于是做了三招：
- 请求合并：把 3 句以内用户消息合并成一次模型调用，减少 35% 总 tokens。
- 缓存命中：对“查订单”这类只读函数，Redis 缓存结果 60 s，QPS 直接降 40%。
- 动态批处理：OpenAI 官方支持 max 批次 128，我们在网关层按 50 ms 滑动窗口攒包，GPU 利用率从 38% 提到 72%，平均延迟反而降 20%。
2. 成本平衡
GPT-3.5 输入+输出平均 600 tokens，按 200 TPS 算：200*60*24*600/1000*0.0015 ≈ 259 $/天
对比雇人坐席，一个客服 24 h 三班倒要 150 $/天，机器成本仅 1/6，老板当场签字。
避坑指南：上线前必须加的三道锁
1. 对话日志脱敏
用微软的 Presidio 做 PII 识别，手机号、身份证、银行卡一律替换成 ***，并存储在加密桶（SSE-KMS）。脱敏脚本放在 CI 里强制跑，未脱敏日志无法入湖。
2. 敏感问题熔断
网关层加“双关键词+向量相似”二级熔断：
- 关键词表每天离线更新；
- 向量相似度 > 0.87 直接返回“无法回答”。
熔断触发即抛 429，同步写审计队列，方便合规复查。
3. 模型版本灰度
在 Kubernetes 做 Canary：
- 新模型镜像打标
v2，先 5% 流量； - 对比“意图准确率”“平均响应”两项指标，24 h 内差异 < 1% 才全量；
- 回滚策略：只要 P99 延迟上涨 15% 或错误率 > 1%，30 s 内切回 v1。
小结与开放问题
把规则引擎换成 LLM 后，我们两周内让意图准确率提升 11%，运营零代码就能上线新话术。但硬币的另一面是：
- 一旦场景极度垂直，公开语料训练不到，模型仍会“胡说”。
- 小样本学习能否用 100 条对话就做到 90%+ 意图召回？
- 如果未来业务扩张到 5000 TPS，GPU 卡会不会成为新的“成本陷阱”？
这些问题留给你我一起思考——也欢迎把你在垂直领域做 Few-shot 的经验砸过来，一起把智能体客服做得既聪明又省钱。
