背景痛点传统客服为什么总被吐槽做客服系统的老同学都知道规则引擎就像“写死”的 if-else 树用户说“我要退货”必须精准命中关键词“退货”换个“想退掉”就识别失败新增一条意图得重新写正则、发版、全量回归测试节奏慢到怀疑人生多轮对话一旦跳步状态机就“失忆”用户得把话再重复一遍简单 Chatbot 用开源 NLU 模型能缓解一部分但意图泛化能力依旧有限且维护知识库的成本随业务线性增长。老板一句“降本增效”团队只能熬夜加规则最后把脚本跑成“屎山”。技术选型GPT-3.5/4、Claude 还是本地化小模型先给出一张对比表方便一眼看懂数字为线上实测均值业务不同会有浮动维度GPT-3.5-turboGPT-4Claude-3本地化 7B成本(1k 会话)0.2 美元6 美元0.3 美元0.02 美元(电费)首 token 延迟0.8 s2.5 s1.2 s0.3 s意图准确率92%96%94%83%幻觉率8%3%5%12%中文闲聊友好优优良中结论速记预算充足、追求“开箱即用”GPT-4 直接上幻觉最少要平衡成本与效果GPT-3.5 本地化兜底95% 场景够用数据必须留在内网本地化 7B LoRA 微调别指望零 shots 就能打平大模型核心架构一张图看懂系统分层接入层Nginx HTTPS 白名单防刷服务层FastAPI 异步接口负责验签、限流、敏感词过滤状态机层维护会话生命周期驱动“闲聊/问答/工单”三态跳转LLM 适配层统一封装 openai/claude/本地模型可热切换缓存层Redis 存热点问答、用户画像、对话历史压缩指纹观测层Prometheus Grafana核心指标P99 延迟、意图置信度、缓存命中率对话状态机设计用“状态上下文槽位”双维度描述比纯 DAG 更易扩展状态Idle / Greeting / Inquire / Handoff / Evaluate槽位order_id、return_reason、phone、human_requested转移示例Idle ──用户输入── Inquire槽位空Inquire ──槽位补齐── Handoff生成工单Handoff ──用户点“转人工”── Evaluate满意度Evaluate ──评分完成── Idle状态图用 Mermaid 维护上线前跑 2000 组随机回归保证无死循环。上下文记忆实现方案滑动窗口保留最近 6 轮超出的做“摘要→嵌入”摘要算法LLM 二次调用temperature0.3输出≤50 字嵌入存储用 sentence-transformers 转 384 维向量放 Redis SETTTL24h检索用户新提问先 embeddingTop-3 相关历史摘要拼进 prompt控制总 token2k代码实现可直接搬走的 Python 片段以下代码均跑在 Python 3.10符合 PEP8关键行给出中文注释。1. 异步调用 LLM API 的封装类import asyncio import openai from typing import List, Dict class LLMClient: def __init__(self, model: str gpt-3.5-turbo, max_tokens: int 512): self.model model self.max_tokens max_tokens openai.api_key sk-xxx async def achat(self, messages: List[Dict[str, str]]) - str: loop asyncio.get_event_loop() # 使用 run_in_executor 把同步 SDK 转成异步 resp await loop.run_in_executor( None, lambda: openai.ChatCompletion.create( modelself.model, messagesmessages, temperature0.5, max_tokensself.max_tokens, stop[用户:, 客服:] ) ) return resp.choices[0].message.content.strip()2. 对话历史压缩算法async def compress_history(history: List[str]) - str: 把多轮对话压成≤50 字摘要减少后续 token 消耗 prompt ( 请将以下对话压缩成 50 字以内的摘要保留关键信息\n \n.join(history) ) summary await LLMClient(max_tokens60).achat([{role: user, content: prompt}]) return summary3. 敏感词过滤中间件import re from fastapi import FastAPI, Request, HTTPException app FastAPI() SENSITIVE {反动, 脏话, 广告} # 实际用 TrieDFA效率 O(1) app.middleware(http) async def filter_sensitive(request: Request, call_next): body await request.body() text body.decode(utf-8) if any(w in text for w in SENSITIVE): raise HTTPException(status_code400, detailInput contains sensitive words) response await call_next(request) return response生产考量让老板晚上能睡踏实Redis 缓存Key 设计faq:md5(question)命中率目标60%写回 TTL1h后台定时批量预热令牌桶限流每个 UID 每秒 3 次突发 10 次防脚本刷爆账单用 Redis Lua 脚本保证原子性代码示例略监控指标平均响应时间≤1.2sP99≤3s意图识别准确率≥90%幻觉率≤5%缓存命中率、限流触发次数、GPU 利用率全部接入钉钉告警避坑指南血与泪换来的 checklist模型幻觉在 prompt 里加“若知识库无答案请直接回复‘暂无相关信息’勿编造”后置置信度过滤度过滤0.85 触发“人工复核”标签多轮上下文长度优化摘要滑动窗口双保险总 token 不超模型上限 75%对超长订单列表用“只保留最近 3 条”策略用户可输入“查看更多”再全量拉取冷启动流量控制上线前灰度 5% 流量收集 1k 真实日志做离线回放动态调低 temperature 到 0.3减少“创造力”带来的不确定性开启“答案一致性检测”同一问题连续 3 次回答不一致自动降级到人工留给你思考的问题当模型效果与推理成本呈指数级矛盾时你会优先砍“准确率”还是“延迟”如果业务突然要求支持粤语、四川话你的 prompt 工程 语音识别 pipeline 会怎么改在数据无法出境的限制下本地化 13B 模型要追平 GPT-4 的 96% 准确率你会从“预训练”还是“后训练”下手把实验结果告诉我一起交流。祝你也能在下一个“618”大促前把客服机器人从“智障”升级成“智能”让值班同学安心睡个整觉。