背景与痛点传统客服系统为什么“转不动”了过去两年我先后帮两家电商公司升级客服系统。老方案无一例外是“关键词正则FAQ 列表”看上去轻量真跑起来却处处踩坑用户换一种问法——“我买的手机壳啥时候发”和“订单 12345 物流状态”——规则就失效促销季并发一高MySQL 里 10 万条 FAQ 被扫得 CPU 飙红平均响应 2.3 s业务方每周上新运营同学手动补规则补到怀疑人生。一句话扩展性、泛化能力、并发成本三座大山把客服机器人压成了“人工智障”。于是团队决定直接上预训练模型用 HuggingFace 全家桶做一次彻底重构。技术选型BERT、GPT、T5 谁更适合客服场景我先把候选模型拉到同一份 5 万条脱敏对话数据上做离线评测指标F1 延迟 显存。结论先给模型意图识别 F1单句 QA BLEU延迟CPU延迟GPU显存batch8备注bert-base-chinese0.930.81120 ms18 ms1.3 G小而快微调友好gpt2-chinese-clone0.870.88450 ms70 ms4.8 G生成流畅但难控制t5-small-chinese0.910.86280 ms45 ms3.1 G生成稳需大显存最终我们采用“BERT 检索式问答” 的混合方案意图识别用 BERT——准确率高、速度快答案召回用双塔句向量Sentence-BERT Faiss避免生成模型“满嘴跑火车”若置信度低于阈值再降级到 GPT-2 做“礼貌的模糊回答”兜底。核心实现30 行代码跑通意图识别 问答下面代码全部可拷贝运行依赖写在注释里符合 PEP8。为了演示方便用 CPU 推理生产只需把devicecuda:0即可。# pip3.8, transformers4.30, torch2.0, faiss-cpu, sentence-transformers import os import json import torch from transformers import BertTokenizer, BertForSequenceClassification from sentence_transformers import SentenceTransformer import faiss import numpy as np class SmartCSBot: def __init__(self, intent_model_dir: str, sbert_model: str shibing624/text2vec-base-chinese, faiss_index_path: str faq.index, faiss_json_path: str faq.json): self.device torch.device(cuda if torch.cuda.is_available() else cpu) # 1. 意图模型 self.tokenizer BertTokenizer.from_pretrained(intent_model_dir) self.intent_model BertForSequenceClassification.from_pretrained(intent_model_dir) self.intent_model.to(self.device) self.intent_model.eval() # 2. 问答检索模型 self.sbert SentenceTransformer(sbert_model, deviceself.device) self.index faiss.read_index(faiss_index_path) with open(faiss_json_path, encodingutf8) as f: self.faq_map {int(idx): item for idx, item in enumerate(json.load(f))} def predict_intent(self, text: str, thresh: float 0.7): 返回 (intent, prob) inputs self.tokenizer(text truncationTrue truncation_sideleft, max_length64, return_tensorspt).to(self.device) with torch.no_grad(): logits self.intent_model(**inputs).logits probs torch.softmax(logits, dim-1) score, label_id torch.max(probs, dim-1) return self.intent_model.config.id2label[label_id.item()], score.item() def search_answer(self, text: str, topk: int 3): 返回 [(answer, score), ...] vec self.sbert.encode([text], normalize_embeddingsTrue, convert_to_numpyTrue) D, I self.index.search(vec.astype(float32), topk) return [(self.faq_map[i], float(d)) for d, i in zip(D[0], I[0])] def chat(self, text: str): intent, score self.predict_intent(text) if score 0.7: return 抱歉我还在学习中暂时无法回答您的问题。 if intent 物流查询: cand self.search_answer(text, topk1)[0] return cand[0] if cand[1] 0.85 else 未找到相关物流信息请稍后再试。 # 更多意图分支同理 return self.search_answer(text, topk1)[0][0] if __name__ __main__: bot SmartCSBot(intent_model_dir./intent_bert) print(bot.chat(我的订单什么时候发货))代码说明意图模型提前用setfit小样本微调 30 epoch5 万条数据 15 分钟收敛FAQ 索引用 Sentence-BERT 离线刷 20 万条商品知识库Faiss IVF1024 量化后 200 MB单句端到端延迟本地 CPU 约 180 msGPU 30 ms满足200 ms 的 SLA。性能优化让 GPU 不“冒烟”的三板斧动态量化把 BERT 的 Linear 层压成 INT8显存直接减半推理掉 8% 精度肉眼无感。torch.quantization.quantize_dynamic(model, {torch.nn.Linear}, dtypetorch.qint8)缓存策略热门问题占日常流量 60%用 Redis 缓存向量 答案TTL 300 sQPS 从 1200 提到 4200。批合并把 20 ms 内的请求合并成 batch8GPU 一次算完再拆分返回平均延迟降 35%。模型蒸馏可选用 TinyBERT 6 层蒸馏后只有 48 MBCPU 推理 60 ms适合边缘节点。生产环境考量错误处理、限流与灰度异常兜底任何模型 forward 抛异常 → 捕获 → 降级到“人工客服”按钮同时写 Kafka 日志方便离线复盘。限流基于令牌桶单 IP 30 QPS全局 2000 QPS超阈值直接返回“客服繁忙”防止 GPU 被瞬时打爆。灰度新模型按用户尾号灰度 5%对比“解决率/转人工率”两个核心指标48 小时无负向才全量。监控Prometheus 拉取 GPU 利用率、推理 P99 延迟、意图置信分分布置信分掉 0.1 以上就报警第一时间回滚。避坑指南踩过的 5 个深坑冷启动延迟首次加载 BERT Faiss 共 1.2 GB容器刚扩容时 6 s 才能 ready。解决启动时预热 100 条假请求把模型放 initContainer 提前拉取Pod 真正流量进来时已热。对话状态维护纯检索式没有“多轮记忆”用户追问“那第二件半价呢”会断片。解决用 Redis 存uid - {intent, entity, ts}30 分钟 TTL下一轮优先把历史 entity 拼进 query 再召回。标点全半角用户输入“啥时候发货” vs “啥时候发货?” 两个问号半全角向量距离差 0.08可能掉召回。解决统一unicodedata.normalize(NFKC, text)预处理。敏感词过滤生成模型偶尔“口吐芬芳”。解决用轻量级 TextCNN 做敏感二分类0.1 ms 延迟命中直接返回“亲亲我们换个话题吧”。版本回滚新模型把“退货”意图错分成“退款”导致流程直接关单。解决模型文件名带 git commit回滚脚本 30 秒完成同时离线训练集立刻补样本当晚重训。效果复盘数字说话上线 4 周核心指标对比旧系统首响延迟 180 ms → 95 ms意图准确率 78% → 93.6%转人工率 42% → 19%客服人力节省 35%双十一大促无新增坐席写在最后多轮对话还能怎么卷目前我们只做到“上下文实体继承”真正的多轮推理还没解决比如用户“北京发货吗” → 系统“支持。”用户“那上海呢” 需要模型理解“也支持吗”的省略。如果把对话历史拼成一段长文本喂给 GPT固然能生成但延迟和可控性又成了新矛盾。或许“BERT 做语义槽 小体量 Seq2Seq 做对话策略” 是更轻量的解法或者干脆用 RL 把对话策略当策略网络来训练你在业务里遇到的多轮瓶颈是什么欢迎留言一起拆坑。