01 - 智能客服系统¶

项目背景与目标¶

某综合电商平台日均会话量超过 50 万次，客服团队规模 800 人，仍难以应对大促期间的咨询洪峰。传统关键词客服机器人命中率不足 40%，用户体验差，人工转接率居高不下，单次会话平均成本约 6 元。随着大语言模型与 RAG 技术成熟，企业希望构建新一代智能客服系统，将简单咨询的自动解决率提升至 70% 以上，同时通过工具调用完成订单查询、物流追踪、退款发起等闭环操作，把人工客服从重复劳动中解放出来，专注于高价值投诉与客诉挽回。

核心目标： 1. 意图识别准确率 ≥ 92%，自动解决率 ≥ 70% 2. 支持订单/物流/库存等 10+ 工具的自动化调用 3. 复杂问题平滑转人工，上下文无损传递 4. 平均响应时间 < 1.5 秒，单次会话成本降低 50%

预期价值：降低人力成本、提升 7×24 小时服务覆盖、统一服务质量、沉淀客诉数据用于产品改进。

需求分析¶

用户角色与场景 - C 端消费者：售前咨询（商品、活动）、售中（订单、物流）、售后（退换货、投诉） - 一线客服：接管复杂会话、处理需要同理心的场景 - 运营人员：配置知识库、监控指标、调优话术

功能需求列表 - 多轮对话管理与会话状态保持 - 知识库 RAG 检索（商品 FAQ、活动规则、政策） - 工具调用（订单查询、物流查询、库存校验、发起退款、生成优惠券） - 意图识别与置信度路由（自动应答 / 转人工） - 人工转接时上下文摘要传递 - 情绪检测，负面情绪自动升级 - 会话质检与数据回流

非功能需求 - 性能：P95 响应 < 2 秒，并发 5000 QPS - 安全：脱敏存储、最小权限调用工具、敏感词过滤 - 可用性：99.95%，多可用区部署 - 可观测：全链路 trace、token 成本与命中率看板

约束条件：必须复用现有订单/物流微服务接口；知识库数据分散在 Confluence、飞书、Excel。

技术选型说明¶

层次	技术选择	选型理由
Agent 框架	LangGraph	显式状态机，适合多轮对话与人工转接分支
LLM	Qwen2.5-72B（主）+ Qwen2.5-7B（意图）	大模型负责生成，小模型做意图分类降本
向量库	Milvus	支持亿级向量、标量过滤，满足商品+FAQ 混检
后端	Python FastAPI + Redis	高并发、易与 LLM 生态集成
消息队列	Kafka	异步落库、质检回流
部署	K8s + GPU 节点池（vLLM 推理）	弹性扩缩容，大促自动扩容

架构设计¶

flowchart LR
    U[用户端 Web/App] --> GW[API 网关]
    GW --> ORCH[LangGraph 编排层]
    ORCH --> INT[意图识别 7B]
    ORCH --> RAG[RAG 检索模块]
    RAG --> EMB[Embedding 服务]
    RAG --> VEC[(Milvus)]
    ORCH --> TOOLS[工具调用层]
    TOOLS --> OMS[订单服务]
    TOOLS --> LOG[物流服务]
    TOOLS --> REF[退款服务]
    ORCH --> GEN[生成模型 72B]
    ORCH --> EMOT[情绪检测]
    ORCH --> HANDOFF{转人工?}
    HANDOFF -->|是| HUMAN[人工坐席系统]
    HANDOFF -->|否| U
    ORCH --> KAFKA[(Kafka)]
    KAFKA --> QC[质检/数据回流]

架构采用「意图先行、RAG 兜底、工具闭环、情绪兜底转人工」的四层决策。LangGraph 维护 DialogState（含历史、意图、检索结果、工具结果、情绪分），每个节点为纯函数，便于回放与调试。

关键模块实现思路¶

模块1：意图识别与路由¶

思路：用 7B 小模型做 fast path 意图分类（售前/售中/售后/闲聊/投诉），输出意图标签 + 置信度。置信度 < 0.7 时回退到 72B 模型 ReCo 模式。
关键点：意图标签需与工具、知识库子集做映射表（路由表），避免全量检索。

示意：

def route(state):
    intent, conf = intent_classifier(state.last_user_msg)
    if conf < 0.7 or intent == "complaint":
        state.need_human = True
    state.kb_scope = ROUTE_TABLE[intent]["kb"]
    state.tools = ROUTE_TABLE[intent]["tools"]

模块2：RAG 检索模块¶

思路：文档按语义分块（FAQ 单条一块，政策按章节），bge-m3 生成向量；检索时先标量过滤（类目、时效），再向量召回 Top-20，交叉重排序取 Top-5。
关键点：引入「失效时间」字段过滤过期活动；对金额/日期类敏感字段做答案校验，避免幻觉。

模块3：工具调用层¶

思路：将订单/物流等接口封装为 OpenAI Function Calling 规范的 tool schema，由 72B 模型决定调用顺序；对「发起退款」等写操作强制二次确认。
关键点：工具调用需做参数校验与幂等控制，调用结果回填到 DialogState 供生成层引用。

模块4：人工转接与会话摘要¶

思路：触发转人工时，调用摘要模型生成「用户问题+已尝试方案+情绪+订单号」结构化摘要，推送到坐席工作台，避免用户重复描述。
关键点：摘要要去 PII，仅保留业务必要字段。

核心流程详解¶

流程1：用户咨询订单物流¶

用户输入「我的订单到哪了」
意图识别 → 售后.物流查询，置信度 0.93
实体抽取订单号（缺失则反问）
调用物流工具，获取节点信息
生成模型用自然语言播报物流进度
情绪检测正常 → 直接返回用户

流程2：投诉升级转人工¶

用户多次表达不满，情绪分 < 阈值
触发转人工节点，生成会话摘要
推送至坐席系统，等待接管
坐席接管后，LangGraph 切换为「人工模式」，AI 退居辅助

部署与优化建议¶

部署架构：推理服务用 vLLM 部署 72B（A100×4）与 7B（A10×1），通过 KEDA 按 GPU 利用率自动扩缩；Milvus 独立集群。
性能优化：意图走小模型 + 缓存高频 FAQ 答案（命中直接返回，节省生成）；对 RAG 召回做批量化 embedding。
成本控制：对闲聊与高频 FAQ 启用缓存命中率看板，预估每月 token 成本下降 40%。

常见问题与解决方案¶

幻觉编造订单信息 → 生成层强制要求引用工具返回字段，后处理做正则校验，不一致则降级转人工。
多轮上下文丢失 → LangGraph 状态持久化到 Redis，超长会话用摘要压缩而非截断。
大促流量尖峰 → 7B 意图模型可水平扩容，72B 通过 vLLM continuous batching 提升吞吐。

扩展方向¶

引入多模态：支持用户上传破损商品图片做售后定损。
主动外呼：物流异常时主动通知用户，变被动为主动。
Agent 自我进化：将转人工案例回流为微调数据，持续提升自动解决率。