当前位置：首页 > news >正文

智能体客服搭建实战：基于LLM的高效对话系统设计与避坑指南

news 2026/5/12 17:23:53

背景痛点：规则引擎的“天花板”

过去两年，我先后接手过三个客服系统重构项目，无一例外都卡在“规则”二字上。

意图识别靠关键词+正则，用户把“我要退货”说成“东西不要了”，立刻掉坑里。
多轮对话状态用 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%。