AI 智能客服系统设计

整体架构

基于多维特征信号的多阶段意图分类引擎，结合规则状态机将问题路由至三种执行模式（统一 Agent、通用生成、混合生成），覆盖售前咨询、售后处理、投诉转人工、工单申请、订单查询等 9 个业务领域和 13 种服务意图的精准识别。

系统核心由四个模块组成：意图识别与路由、RAG 多级检索、实体抽取与业务执行、流式交互与异步处理。

---

一、智能意图识别与多模式路由

多维特征信号融合

输入不止是用户当前消息，还融合了：

• 历史对话上下文（最近 3 轮）
• 用户画像标签（会员等级、历史工单类型）
• 当前页面来源（如从订单详情页发起）
• 客服场景下的业务阶段（售前/售后）

这些信号被编码为文本前缀或拼接进分类模型输入。

多阶段意图分类

第一阶段：领域粗分类

使用轻量文本分类模型（如蒸馏版 BERT 或 fastText），将问题归入 9 个业务领域：

public enum Domain {
    PRE_SALES("售前咨询"),
    AFTER_SALES("售后处理"),
    COMPLAINT("投诉转人工"),
    WORK_ORDER("工单申请"),
    ORDER_QUERY("订单查询"),
    GENERAL("通用闲聊");
}

public enum Intent {
    // 售前
    PRODUCT_INFO("商品咨询"),
    PRICE_QUERY("价格查询"),
    // 售后
    REFUND("退款申请"),
    EXCHANGE("换货申请"),
    REPAIR("维修申请"),
    // 投诉
    COMPLAINT_HUMAN("投诉转人工"),
    // 工单
    WORK_ORDER_APPLY("工单提交"),
    // 订单
    ORDER_STATUS("订单状态"),
    ORDER_CANCEL("取消订单"),
    // 兜底
    UNKNOWN("未知意图");
}

第二阶段：意图细分类

每个领域下挂载专属小模型，进一步识别服务意图。置信度判断逻辑：

• 置信度 > 0.85 → 直接调用对应模型，跳过细分类
• 置信度过低 → 调用细分类模型进一步判断
• 特别低 → 回退至强规则（关键词 + 正则）兜底

规则状态机与模式路由

对话状态由有限状态机维护：{领域, 意图, 槽位, 对话阶段}。根据识别结果路由至三种模式：

模式	适用场景	特点
统一 Agent	多步工具调用（如订单查询需调 API）	LLM 完成「思考 → 调工具 → 整合结果」
通用生成	纯闲聊或简单 FAQ	直接由 LLM 生成回复，不涉及外部调用
混合生成	需要知识库辅助 + 总结	先检索片段，再交由 LLM 融合生成

---

二、RAG 多级检索引擎

设计"向量召回 → 关键词补召 → 上下文融合"三层容错体系。

第一层：pgvector 向量语义检索

将用户问题通过 Embedding 模型转换为向量，在 PostgreSQL 的 pgvector 扩展中执行余弦相似度搜索，快速返回 Top-K 相关文档块。

第二层：无阈值回退逻辑

当向量检索最高相似度低于阈值（如 0.7）时，自动触发关键词模糊匹配：

-- PostgreSQL 全文检索：直接用用户提问做模糊查询
to_tsvector(text) @@ plainto_tsquery('用户输入内容')

• to_tsvector(text)：将文档文本转换为词位向量（分词索引）
• plainto_tsquery()：将用户输入自动分词，生成 AND 逻辑查询
• @@：全文匹配操作符

第三层：合并与重排序

将两层结果合并，按文档 ID 去重，基于相似度分数或关键词相关度排序，取 Top 片段注入上下文。

上下文承接与跨文档继承

文档继承机制：维护活跃文档上下文栈。用户从文档 A 切换到文档 B 时，从 A 的问答历史中提取摘要或实体，与针对 B 的新查询拼接，防止意图漂移。

跨会话传递：利用 Redis 存储最近对话中涉及的文档 ID 及槽位信息。新会话开始时预注入系统提示词，让模型"记得"上次聊到的文档内容。

---

三、业务动作识别与实体抽取

实体自动抽取

正则表达式作为高精度抽取器：

• 订单编号：ORD-\d{8,}、\b[A-Z]{2}\d{12}\b
• 数量：\d+\s*(个|件|台|kg)
• 手机号、工单号等

复杂实体（商品描述、地址）辅助使用 NER 模型或 LLM 做实体识别。

跨轮次槽位解析

使用 Redis 维护每个会话的动态槽位表：

{意图: "退款", 订单号: None, 数量: None, 原因: None}

流程：用户说"我要退款" → 检查槽位 → 订单号为空 → 追问"请提供订单号" → 正则提取补全 → 所有必填槽位填满 → 触发 API 调用。

提示词注入

槽位信息最终拼入系统提示词：

String systemPrompt = String.format(
    "你是客服Agent，用户意图为：【%s】。已提取的订单信息：%s。...",
    intent.getChineseName(),
    slots.toString()
);

LLM 在 Function Calling 时利用这些槽位去调用对应工具。

---

四、流式交互与异步处理

SSE 流式问答

后端采用 Server-Sent Events 协议，调用大模型流式生成接口，每收到一个 token 封装为 data: {token} 写入响应流，前端用 EventSource 实时渲染打字机效果。

关键点：API 网关需关闭对该接口的缓冲，支持长连接。

基于 RabbitMQ 的异步文档处理

上传文件 → 存对象存储 → 返回"正在处理" → 发消息到队列 → Worker 异步处理

后台 Worker 按序执行：解析（Unstructured/LangChain 提取文本）→ 分块（RecursiveCharacterTextSplitter） → 嵌入（批量向量化） → 入库（pgvector，更新状态为 ready）。

失败则进入死信队列重试或告警。非阻塞设计让上传接口响应时间从数秒降至几十毫秒。

---

总结

模块	核心技术	解决的问题
意图识别	级联分类 + 状态机	高精度路由，避免答非所问
RAG 检索	三层容错 + 上下文继承	多轮跨文档场景的检索稳定性
实体抽取	槽位填充 + 正则 + 跨轮记忆	从"能说"到"能做"的业务闭环
流式 & 异步	SSE + RabbitMQ	交互实时性与系统伸缩性