智能客服系统端到端实战：RAG + 意图识别 + 人工兜底的最小闭环

智能客服可以把检索、意图分类、回答生成和会话管理放到同一个案例里练习。要把范围收住，先选一类可核验的问题，明确什么时候回答、什么时候拒答或转人工。下面按这个边界设计路由和评估流程，再解释如何逐步扩展。

前置阅读：建议先读 RAG 项目复盘、RAG 进阶、Prompt 工程实战。

先想清楚：客服系统的成功标准

动手前定北极星指标：解决率（用户问题被解决且无需人工的比例）。辅助指标：转人工率、平均处理时长、满意度。注意「回复率」不是目标——句句有回应但答非所问的客服比没有更糟。

由此导出设计原则：宁可转人工，不可乱回答——错误答案损害信任的成本远高于转人工的成本。这个原则决定了后面所有的置信度设计。

三层路由：不是所有问题都该进 RAG

用户消息
  → 第一层：意图分类（LLM 小模型，毫秒级）
      ├── FAQ 高频问题（退换货/物流/改地址）→ 标准流程/固定话术
      ├── 知识咨询（怎么用/什么政策）→ RAG 问答
      ├── 闲聊/情绪安抚 → LLM 自由应答（短）
      ├── 投诉/高危（法律/金额/情绪激烈）→ 直接转人工
      └── 意图不明（置信度低）→ 澄清反问

为什么先分类：不同意图的最优处理方式完全不同——FAQ 走固定流程又快又稳，RAG 适合知识型，投诉类让 AI 碰都是事故。意图层是系统的「分流器」，用 GPT-4o-mini 级别的模型加 few-shot 就够，准确率目标 95%+。

CLASSIFY_PROMPT = """把客服消息分类为：faq_return / faq_logistics / knowledge /
chat / complaint / unclear。只输出类别名。
示例：
「我的快递三天没动了」→ faq_logistics
「你们的会员积分怎么算」→ knowledge
「我要投诉！东西坏了没人管」→ complaint

消息：「{message}」→"""

RAG 问答层：用最小可用配置

直接复用 RAG 进阶篇的配方，客服场景的特化点：

知识库结构：FAQ 对、政策文档、产品手册分库存储——FAQ 精确匹配优先（用户问法接近标准问直接给标准答案），政策文档走向量检索。
多轮改写：「那这个多少钱」→ 结合历史改写成「X 产品的会员价是多少」——客服场景几乎句句有指代，改写是刚需。
答案带出处：回答末尾附「依据：《退换货政策》第 3 条」——给用户复核入口，也给运营排查入口。

置信度分层：转人工的正确姿势

这是客服系统最体现「工程成熟度」的部分。三路信号合成一个置信度：

def should_handoff(intent_conf, retrieval_score, answer_check) -> bool:
    """任一信号亮红灯就转人工"""
    if intent_conf < 0.6:                      return True   # 意图没把握
    if retrieval_score < 0.35:                 return True   # 没检索到靠谱资料
    if not answer_check["grounded"]:           return True   # 答案与资料不符
    return False

意图置信度：分类模型的概率或 LLM 自问「你确定吗」。
检索分数：rerank 分数过低 = 知识库没有相关内容——这时候硬答就是编，必须转。
答案校验：生成后让模型自审「答案的每个事实都能在资料里找到吗」（grounded check）。

转人工不是失败，要做得优雅：把对话历史 + 已收集信息 + AI 的初步判断打包给人工坐席——用户不用重复说一遍，人工接手成本大降。

会话管理：状态机和记忆

多轮对话的状态用显式结构管理（别全扔给 prompt）：

@dataclass
class Session:
    session_id: str
    history: list[dict]          # 对话历史（滑窗 10 轮）
    slots: dict                  # 已收集信息：订单号、手机号、产品型号
    intent_path: list[str]       # 意图轨迹（投诉升级检测用）
    handoff: bool = False

slots 的价值：用户中途提供过订单号，后续流程直接用——「您刚才提供的订单 xxx」比「请提供订单号」体验好十倍。history 要滑窗截断 + 摘要压缩（Agent 篇的记忆策略）。

评估：离线 + 线上双层

离线：建 200 条真实客服日志评估集（脱敏后），测三件套——意图分类准确率、检索 Recall@5、答案 faithfulness（LLM 评测篇的裁判法）。

线上：每日看板——解决率、转人工率、每意图分布、「转人工原因」分布。最后一个最有行动价值：转人工集中在哪类，就补哪类的知识库或流程。

badcase 周会：每周抽 20 条失败对话人工归因（意图错/检索错/生成错/流程错），这是知识库和 prompt 迭代的方向盘。我在项目里的节奏：上线第一个月解决率从 41% 爬到 68%，全靠每周 badcase 驱动迭代，模型本身一次没换。

最小技术栈

组件	选型	理由
意图分类	GPT-4o-mini + few-shot	便宜够准，免训练
检索	bge-m3 + Qdrant + bge-reranker	Embedding 篇标配
生成	GPT-4o / Qwen-Max	客服场景质量优先
会话存储	Redis（TTL 24h）	NoSQL 篇的 KV 主场
服务框架	FastAPI + 异步	服务化篇

踩坑排查

现象	原因	解法
用户问法一变就答错	FAQ 只做精确匹配	FAQ 也向量化，语义匹配 + 阈值
多轮对话答非所问	指代未消解	查询改写进管道第一步
AI 编造不存在的政策	无检索置信度兜底	rerank 低分强制转人工
投诉用户被 AI 敷衍激怒	高危意图未分流	投诉/情绪类直接转人工
转人工后用户重复描述	上下文未传递	对话摘要+slots 打包给坐席
解决率上不去	只优化模型不看 badcase	每周 badcase 归因迭代知识库

练习

搭建最小闭环：50 条 FAQ + 意图分类 + RAG 问答 + 转人工规则，用 20 条测试对话跑通。
实现查询改写：构造 10 个多轮对话（含指代和省略），对比改写前后的检索命中率。
设计置信度实验：故意问 10 个知识库没有的问题，验证系统是否「知所不知」地转人工。
做一次 badcase 归因：收集 30 条失败对话，按「意图/检索/生成/流程」四类归因，画出帕累托图。

面试常问

Q：智能客服和通用 Chatbot 的架构差异？ 通用 chatbot 追求「什么都能聊」，客服追求「有限域内高解决率 + 可控」。差异：意图路由（分流到不同处理管道）、知识库强约束（答案必须有出处）、置信度兜底（不确定就转人工）、业务流程集成（查订单/改地址要调 API 不是聊天）。评估也不同：chatbot 看对话质量，客服看解决率和转人工率。

Q：怎么处理知识库覆盖不到的问题？ 三层防线：检索置信度识别（rerank 低分）→ 兜底话术（「这个问题我帮您转接专员」）→ 转人工时把该问题记入「知识库缺口清单」——运营每周按缺口清单补知识库。覆盖率的提升靠运营闭环，不靠模型变聪明。

Q：多轮对话的上下文管理方案？ 滑窗（保留最近 N 轮）+ 查询改写（消解指代）+ slots 显式状态（关键信息结构化存储）+ 长会话摘要（超窗后压缩历史）。全历史塞 prompt 的方案在长会话会：超上下文、成本爆炸、早期信息干扰当前判断（lost in the middle）。

Q：客服系统的冷启动怎么做？ 数据：历史客服日志聚类出 top50 高频问题（覆盖 80% 流量），先人工写标准答案做 FAQ 库；流程：先上「辅助人工」模式（AI 给坐席建议答案，人确认后发出）——既收集真实反馈又零风险，数据攒够再切自动应答；灰度：按问题类型灰度（先自动答物流类，观察一周再扩）。

Q：LLM 客服的合规风险点？ 承诺风险（AI 随口承诺退款/赔偿 → 生成层约束「不做任何承诺性表述」，承诺类转人工）、隐私风险（对话含个人信息 → 日志脱敏、训练数据隔离）、误导风险（错误政策解读 → 答案强制带出处）、监管风险（金融/医疗客服有专门合规要求）。上线前过一遍「AI 会说什么不该说的」红队测试。