济南网站运营公司网上推广公司

张

张建站

2026/4/10 20:50:01

10分钟阅读

济南网站运营公司,网上推广公司,景点介绍网站开发设计,科技网络网站建设背景痛点#xff1a;传统客服系统“三座大山” 去年双十一#xff0c;我们给电商客户做客服升级#xff0c;原系统直接“炸”了#xff1a;高峰期平均响应 4.8 s#xff0c;意图识别准确率掉到 62%#xff0c;CRM 调一次接口 800 ms#xff0c;用户疯狂转人工。拆完代码…背景痛点传统客服系统“三座大山”去年双十一我们给电商客户做客服升级原系统直接“炸”了高峰期平均响应 4.8 s意图识别准确率掉到 62%CRM 调一次接口 800 ms用户疯狂转人工。拆完代码发现三座大山规则引擎 if-else 层层嵌套新增一个“退货”意图要改 7 个文件上线周期 3 天。多轮对话状态放在 Redis String大 key 读写全串行并发一高就“雪崩”。与 CRM 是同步 REST 调用对方超时无降级线程池打满后整个 Bot 僵死。痛点总结延迟高、状态乱、集成重——不重构AI 客服只能“人工”智能。技术选型规则引擎 vs 机器学习为什么选了 RasaTransformer我们拉了两条分支做 A/B数据集 18 万条真实对话规则引擎ArtisanF10.71新增意图开发 3 天逻辑冲突 23 处。RasaTransformerDIETF10.89新增意图只需标注 200 条样本训练 20 min。再算一笔资源账DIET 的 Transformer 层只有 2 层 hidden256推理 CPU 单核 30 ms内存 180 MB完全够跑在 2C4G 的容器里。规则引擎看似轻量可维护成本是“人”人比 GPU 贵。于是拍板Rasa 负责 NLU自研 Dialogue State TrackerDST负责多轮策略两边用 gRPC 解耦后续可独立扩容。核心实现Python 代码直接抄1. 对话状态机 / Dialogue State Tracker带持久化状态机思路每个 user_id 维护一个 State 对象回合级事件驱动状态快照异步落盘。# dst.py from __future__ import annotations import json import time from typing import Dict, Optional from redis import Redis from dataclasses import dataclass, asdict dataclass class State: user_id: str intent: str slots: Dict[str, str] None turn: int 0 ttl: int 600 # 秒 class DST: def __init__(self, redis: Redis): self.r redis def _key(self, uid: str) - str: return fdst:{uid} def get(self, user_id: str) - Optional[State]: raw self.r.get(self._key(user_id)) return State(**json.loads(raw)) if raw else None def save(self, state: State) - None: pipe self.r.pipeline() pipe.set(self._key(state.user_id), json.dumps(asdict(state)), exstate.ttl) pipe.execute() def update_intent(self, user_id: str, intent: str) - State: state self.get(user_id) or State(user_iduser_id) state.intent intent state.turn 1 self.save(state) return state时间复杂度get/set 都是 O(1)Redis 单线程写内存操作10 万 QPS 无压力。2. 异步消息端点 / FastAPI用 FastAPI 的BackgroundTasks把耗时操作调 CRM、落日志丢后台接口立刻返回减少排队。# main.py from fastapi import FastAPI, BackgroundTasks from pydantic import BaseModel import httpx app FastAPI() dst DST(Redis(hostredis, decode_responsesTrue)) class WebhookReq(BaseModel): user_id: str text: str async def call_crm(user_id: str, intent: str): async with httpx.AsyncClient(timeout3.0) as client: await client.post(http://crm/api/event, json{user: user_id, intent: intent}) app.post(/webhook) async def webhook(req: WebhookReq, bg: BackgroundTasks): intent rasa_parse(req.text) # 伪代码返回 str state dst.update_intent(req.user_id, intent) bg.add_task(call_crm, req.user_id, intent) return {reply: f收到已为您记录【{intent}】, turn: state.turn}压测结果4 核 8 G 容器单实例 1200 RPSP99 延迟 65 msCPU 70%内存 1.1 G。生产考量压测、脱敏、灰度一个都不能少1. JMeter 脚本示例线程组500 并发Ramp-up 30 s循环 300 次。HTTP Header 带X-User-ID做分片方便后台按用户路由到同一 Pod避免状态漂移。HTTPSamplerProxy stringProp nameHTTPSampler.path/webhook/stringProp stringProp nameHTTPSampler.methodPOST/stringProp boolProp nameHTTPSampler.follow_redirectstrue/boolProp elementProp namearguments collectionProp nameArguments.arguments elementProp stringProp nameArgument.value{user_id:${__RandomString(8)},text:我要退货}/stringProp /elementProp /collectionProp /elementProp /HTTPSamplerProxy监控指标QPS、RT、Error%、CPU、Pod 重启次数。RT 突增 20% 即触发自动回滚。2. 敏感信息过滤用正则先跑匹配再白名单兜底防止误杀订单号。import re PHONE re.compile(r(1[3-9]\d{9})(?!\d)) BANK re.compile(r(\d{16}|\d{19})(?!\d)) REPLACE *** def mask(text: str) - str: text PHONE.sub(REPLACE, text) text BANK.sub(REPLACE, text) return text时间复杂度单条正则 O(n)n512 字符单次 0.02 ms可放网关统一处理。避坑指南对话超时、标签清洗血泪史1. 对话超时 3 种模式对比固定 TTLRedis key 600 s 后过期实现简单但用户回来再聊就“失忆”。滑动窗口每次消息重置 TTL适合高频场景内存占用 30%。业务失效订单关闭即清状态需要业务方发事件最省内存对接最复杂。线上采用“滑动窗口”给 30 min 缓冲兼顾体验与内存。2. 意图标签清洗技巧同义归并把“退款”“退钱”“给我退”映射到 refund用聚类人工复核两周把标签从 312 压到 98。负样本补充每个意图至少 10% 负样本防止“退货”被“我要退换货”误触发。时间切分双 11 前 30 天数据单独训练避免促销话术污染日常模型。代码规范小结全项目强制mypy --strict类型缺失直接阻断 CI。所有 I/O 函数加tenacity重试限流异常按“用户可见/不可见”分级后者写 Sentry用户侧返回统一 200错误码。关键路径打debug日志采样率 1%方便线上排障。延伸思考拥抱大模型也看看账单GPT-4 做客服Zero-shot 准确率就能到 0.93但算一笔账输入 500 token、输出 150 token每轮 650 token。官方价 $0.03/1k token每轮 $0.0195。日活 10 万平均 3 轮对话每天 30 万次调用 ≈ $5,850一个月 17 万刀。结论大模型做“兜底”“冷启动”最划算日常 90% 流量仍走 Rasa小模型成本只有 LLM 的 1/50。未来路线Rasa 负责高频意图LLM 负责长尾与情绪安抚混合路由成本可控体验再上一个台阶。踩坑一年最大的感受是客服 AI 拼的不是算法有多炫而是状态管理、集成细节和成本算得精不精。把超时、灰度、压测这些“脏活”做扎实模型差一点用户也感知不到反过来状态一丢再好的 LLM 也救不了场。希望这份避坑笔记能帮你少熬几个通宵项目早日上线安稳睡个好觉。