AICustomerService · AI 智能客服系统

执行摘要

#

AICustomerService 是一个电商智能客服系统：目标不是「答得上一句话」，而是把接待理解、知识与决策、业务执行、风险控制、运营评估、持续优化串成闭环，按 V1–V8 里程碑逐段验收。

当前状态：

1. V1 知识问答基线已冻结（v0.1.0）：Dify Chatflow + LangGraph knowledge 节点 + FastAPI，41 项自动化测试通过，单次问答实测 10–13 秒。
2. V2 评测闭环进行中：50 条标准测试集已校准为 xq-cs-benchmark-1.2（风险分层 13 高 / 24 中 / 13 低、112 项禁止行为），但评估脚本与 Bad Case 表尚未落地。
3. V3–V8 尚未开始：业务 API、任务编排、人机协同、安全、监控与商业 ROI 仍为规划或 mock。

因此，本页只陈述已经发生的工程事实；在 V2 评估脚本产出报告之前，不声明任何意图识别率、回答准确率或转人工率数字。

背景与问题定义

#

电商客服的知识通常散落在多份文档里：退换货与退款政策、订单物流与隐私流程、商品目录与属性、优惠券支付与发票、客服 SOP 与转人工。客户的一个问题往往跨多份规则，坐席要同时判断三件事：知识是否命中、当前订单状态能否自动处理、是否越权或需要转人工。

通用聊天机器人能回答单点问题，但离「接得住」还差三层：

1. 知识层：答案有没有出处、政策版本是否最新、文档之间是否冲突；
2. 执行层：能不能查订单、能不能办理退款、失败后能不能恢复；
3. 运营层：回答得对不对、该不该转人工、每次改动到底有没有变好。

所以本项目没有从「接一个大模型」开始，而是先把目标拆成六步闭环：接待与理解 → 知识与决策 → 业务执行 → 风险控制 → 运营评估 → 持续优化。V1 只解决其中「知识与决策」的一段，其余按里程碑逐步补齐。

系统设计与口径

#

架构与运行方式

#

• 编排：Dify Chatflow（advanced-chat）负责 RAG、意图识别与回答生成；LangGraph knowledge 节点负责调用 Dify，并把结果接回状态图。
• 服务：FastAPI 提供 POST /chat 与 GET /health，另有 CLI 入口用于本地冒烟。
• 多轮：Dify 返回 conversation_id，下一轮原样带回；API 与 CLI 均支持透传。
• 模式：response_mode=blocking，当前无流式输出；引用与归属未开启，retriever_resources 为空。

失败策略

#

异常统一转人工，不把错误抛给客户。转人工原因按 handoff_reason 区分：dify_api / dify_timeout / dify_connection / dify_configuration / dify_response / dify_empty_answer。

重试只覆盖 429、5xx 与连接错误；读超时默认不重试，避免 Dify 侧产生重复消息（可用 DIFY_RETRY_ON_TIMEOUT 开启）。

数据与基准

#

• 基准包：xq-cs-benchmark，包含 50 条评测 case、6 份知识文档（商家说明 / 退换货与退款 / 订单物流与隐私 / 商品目录 / 优惠券支付与发票 / 客服 SOP 与转人工）与订单、商品、物流、政策 mock 数据；政策版本 2026-10-01。
• 测试集：2026-11-01 校准为 xq-cs-benchmark-1.2，50 条 case 全部补齐 risk_level（high 13 / medium 24 / low 13）、prohibited_behaviors（共 112 项）与 evaluation_method（rule 18 / llm 26 / human 6）；基准集与回归集分离，1.0 以 git tag 存档。
• 业务接口：订单、退款等均为 mock，没有真实业务 API。

里程碑与验收

#

完成度是相对本项目最终目标的工程进度估算，不是模型准确率，也不是业务效果。

已落地的工程事实

#

• 41 项自动化测试通过：覆盖 Dify 客户端（超时 / 重试 / 错误分类）、知识节点、图路由、意图规则与 FastAPI 接口。
• 单次问答实测 10–13 秒：blocking 模式下的基线，作为后续流式与性能优化的对照。
• 多轮会话可用：conversation_id 在 API 与 CLI 中透传。
• 异常可兜底：超时、报错、空答案统一转人工，并记录原因。
• 基线可复现：v0.1.0 tag、基线快照与测试用例均已入库。

评测框架与当前状态

#

V2 计划用六类指标判断每次知识或 Prompt 改动是否有效：

这里没有「模型已经达到多少准确率」的结论。 50 条测试集只是输入，评估脚本（scripts/evaluate.py）尚未编写，仓库中的基准报告仍为空。在实测报告产出之前，任何准确率数字都不可对外引用。

可信度与边界

#

已验证

• 知识问答链路可运行、可多轮、可降级；
• 41 项测试与 v0.1.0 tag 可复现；
• 失败原因可区分、可记录。

未验证

• 检索质量与回答准确率没有实测值；
• 并发、超时与稳定性没有压测；
• 没有鉴权、租户隔离、限流、审计与提示词注入防护；
• 没有真实业务 API，无法证明「能办事」。

已知限制

• blocking 模式 10–13 秒，无流式输出；
• 意图识别为规则版，无槽位、置信度与情绪识别；
• 引用与归属未开启，检索来源不可追溯；
• 知识文档有变更记录，但 Dify / Prompt 版本尚未系统化管理。

这些边界不是脚注，而是下一步的排期依据：先补评测，再谈调优；先有基线，再谈功能。

经验迁移

#

做这个项目最大的收获，不是跑通了一条 RAG 链路，而是确认了三件事：

1. 智能客服的瓶颈通常不在模型，而在知识质量与评测口径——知识没有版本、答案没有标准，调参就无法判断是否变好；
2. Bad Case 必须能归因——把失败拆到知识、检索、上下文、Prompt、模型、工作流、工具、安全八类，才能决定改哪里；
3. 「转人工」不是失败，是系统设计的一部分——异常、空答案与越权统一转人工，比让模型硬答更接近真实客服。

这套「定义问题 → 设计规则 → 评估效果」的方法，与质检工作里的「规则可判定、结果可统计、异常可回归」是同一套逻辑，只是对象从人工通话换成了模型对话。

在线体验

#

• Demo：https://udify.app/chatbot/gWsI6thJsdZ9i9Ff
• 代码仓库为私有，暂不公开；本页涉及的架构、测试与基线均可在面试中逐项展开。