技术架构文档AI 智能客服解决方案
AI 智能客服解决方案
AI 智能客服 (AI Customer Service) 建设方案
版本: v1.0 日期: 2026-02-02 状态: 规划完成 -> 开发实施
1. 核心功能规划 (Functionality)
智能客服作为数字员工体系中的特定职能角色(如:“金牌客服”),应具备 “听得懂、答得准、办得了、能共情” 四大维度的能力:
- 多模态交互与记忆:
- 支持文本、图片(如用户发故障截图)、语音输入。
- 具备长期记忆,能记住用户上一轮的投诉或偏好,实现连续对话。
- 私域知识精准问答 (RAG):
- 基于企业产品文档、SOP、FAQ 进行回答,严格杜绝幻觉。
- 支持“引用来源”展示,增加可信度。
- 意图识别与任务路由:
- 自动判断用户是“闲聊”、“咨询政策”还是“查询订单”。
- 将复杂需求(如退款)路由给能够调用工具的 Agent 或人工。
- 业务办理 (Action):
- 从“咨询型”进化为“交易型”。
- 通过挂载工具(Skills),直接执行查询物流、重置密码、创建工单等操作。
- 人机平滑协作 (HIL):
- 情绪检测报警(如用户愤怒值>80%)。
- 无缝转接人工坐席,并自动生成“摘要总结”给人工客服查看。
2. 解决方案设计 (Solution)
构建 “大模型 + RAG + 数字员工 Agent” 融合的方案:
A. 知识库治理方案(核心基石)
- 分层知识管理: 将知识库分为
通用知识(公司介绍)、产品知识(说明书)、话术库(高情商回复模板)。 - QA 对挖掘: 利用 LLM 自动从非结构化文档中抽取标准 QA 对,人工审核后入库,提高检索精度。
B. 意图分流与状态机 (Router)
- Level 1 (快速回答): 对于简单 FAQ(如“营业时间”),直接通过向量检索 (Vector Search) 返回。
- Level 2 (复杂推理): 对于需要分析的问题(如“为什么不管用”),调用 LLM 结合 RAG 上下文进行推理。
- Level 3 (业务办理): 识别到动词(查、改、退),触发 Function Calling,调用后端 API。
C. 千人千面 (Persona)
- 复用 数字员工 (Digital Employee) 模块,创建不同人设的客服(例如:“严谨的技术支持” vs “亲切的售后顾问”)。
- 针对不同渠道(官网、微信、钉钉)配置不同人设。
3. 系统架构设计 (Architecture)
架构上复用现有的 Enterprise AI PaaS,在应用层扩展客服业务逻辑。
4. 技术实施路径 (Technical Path)
建议分三个阶段迭代,避免“一步到位”导致的落地困难:
阶段一:咨询型客服 (The Consultant)
- 重点: 高准确率的 RAG 问答。
- 技术栈:
- 完善
KnowledgeRetriever。 - 引入 Rerank (重排序) 模型提升检索相关性。
- 调整 Prompt 让回答更拟人化。
- 完善
- 目标: 拦截 60%-70% 的通用咨询,释放人工压力。
阶段二:办事型客服 (The Operator)
- 重点: 意图识别与工具调用。
- 技术栈:
- 完善
Digital Employee的EmployeeSkill表。 - 开发
ToolRegistry,对接企业内部 CRM 或 ERP 接口 (Read-only 接口优先)。
- 完善
- 目标: 实现自助查询(查单、查积分),减少人工查询工作量。
阶段三:主动型客服 (The Proactive)
- 重点: 预判与营销。
- 技术栈:
- 结合用户画像 (User Profile),在用户进入时主动发问(“您好,是想咨询刚才查看的 X 商品吗?”)。
- 利用 AI 流程质检 模块分析对话数据,反哺知识库。
- 目标: 从成本中心转变为营销机会中心。
5. 开发建议 (For Current Codebase)
- 复用代码: 直接使用
services/digital-brain中的QwenClient(LLM) 和KnowledgeRetriever(RAG)。 - 新开发模块:
- Frontend: 开发一个 Web Widget (网页聊天挂件) 集成到
apps/official-site。 - Backend: 开发基于 Websocket 的对话服务,支持流式输出 (Streaming)。
- Frontend: 开发一个 Web Widget (网页聊天挂件) 集成到
- 数据表扩展:
- 在
models.py中增加ChatSession(会话) 和ChatMessage(消息) 表。 - 关联
DigitalEmployeeID。
- 在