3.4 详细设计.md 37 KB
（一）知识库设计
设计目标： 构建覆盖售前售后全场景的结构化知识库体系，确保知识准确、更新及时、检索高效，支撑 AI 客服 95% 以上的回复准确率。
1. 数据源范围
| 知识库分类 | 数据源 | 内容示例 | 更新频率 |
|---|---|---|---|
| 商品知识库 | 商品中心数据库、商品详情页 | 商品名称、规格参数、成分、功效、适用人群、使用方法、注意事项 | 商品上下架时实时同步 |
| 售后政策库 | 运营部门政策文档 | 退换货规则、退款时效、质量问题处理流程、保修政策 | 政策变更时更新（约月度） |
| 活动规则库 | 运营/市场部门活动方案 | 满减规则、优惠券使用条件、叠加规则、活动时间范围 | 活动上下线时实时同步 |
| FAQ 库 | 历史客服优秀对话 + 客服知识沉淀 | 高频问题标准答案、话术模板、常见误区澄清 | 周度更新 |
| 物流知识库 | 物流部门 SOP 文档 | 发货时效、合作快递、运费规则、特殊地区说明 | 规则变更时更新 |
| 会员权益库 | 会员中心规则文档 | 会员等级权益、积分规则、积分兑换说明 | 规则变更时更新 |
2. 文档分片策略
分片质量直接影响检索精度，需根据不同知识类型采用差异化分片策略。
| 知识库类型 | 分片策略 | 分片大小 | 说明 |
|---|---|---|---|
| 商品知识库 | 按商品 SPU 分片 | 500–800 tokens | 每个 SPU 为一个独立文档片段，包含完整的商品信息，避免信息割裂 |
| 售后政策库 | 按政策条目分片 | 300–500 tokens | 每条政策规则为一个片段，保留上下文标题作为 metadata |
| 活动规则库 | 按活动维度分片 | 400–600 tokens | 每个活动的完整规则为一个片段，包含时间、条件、限制等完整信息 |
| FAQ 库 | 按 Q&A 对分片 | 200–400 tokens | 每个问答对为一个片段，问题作为片段标题增强语义匹配 |
| 物流/会员知识库 | 按规则段落分片 | 300–500 tokens | 按自然段落切分，保留完整语义单元 |
通用分片原则：
每个片段保持语义完整性，不在句子中间截断
相邻片段设置 50–100 tokens 的重叠区域，防止边界信息丢失
每个片段附加 metadata：知识库类型、文档来源、更新时间、关联商品/活动 ID
片段标题使用关键信息摘要，提升检索匹配度
3. 知识库更新机制
| 更新方式 | 触发条件 | 流程 |
|---|---|---|
| 自动同步 | 商品上下架、活动上下线 | 业务系统 Webhook → 中间层服务 → 调用 Dify 知识库 API 新增/更新/删除文档片段 |
| 定时同步 | 每日凌晨定时任务 | 全量扫描商品库变更 → 增量更新知识库 → 生成更新日志 |
| 人工更新 | 政策变更、FAQ 优化 | 运营/客服在管理后台提交 → 产品审核 → 调用 API 入库生效 |
| Badcase 驱动 | 发现回复错误或知识缺失 | Badcase 分析 → 定位知识缺口 → 补充/修正知识 → 审核入库 |
审核机制： 所有知识变更需经审核后生效，自动同步的内容设置抽检机制（每批次抽检 10%），人工提交的内容 100% 审核。
（二）检索策略设计
设计目标： 通过混合检索 + Rerank 的两阶段检索架构，在保证召回率的同时提升精准度，确保 Top 3 检索结果中包含正确答案的概率 ≥ 95%。
1. 检索架构：混合检索 + Rerank
graph LR
A["用户问题"] --> B["Query 改写"]
B --> C["向量检索"]
B --> D["全文检索"]
C --> E["结果合并"]
D --> E
E --> F["Rerank 重排序"]
F --> G["Top K 结果"]
G --> H["LLM 生成回复"]
2. 检索流程详细设计
| 阶段 | 处理步骤 | 说明 |
|---|---|---|
| Query 预处理 | Query 改写 + 关键词提取 | 利用 LLM 将口语化问题改写为检索友好的表述；提取商品名、订单号等关键实体，用于精确匹配和工具路由 |
| 向量检索 | 语义相似度匹配 | 将 Query 向量化后在 Dify 向量数据库中检索，召回 Top 10 语义相关片段；适合处理语义模糊、表述多样的问题 |
| 全文检索 | 关键词 + BM25 匹配 | 基于 Dify 全文检索引擎，召回 Top 10 关键词匹配片段；适合处理包含专有名词、型号、精确术语的查询 |
| 结果合并 | 加权融合 | 向量检索权重 0.7 + 全文检索权重 0.3（初始值，根据评测结果调优）；去重后保留 Top 15 候选片段 |
| Rerank 重排序 | 交叉编码器精排 | 使用 Rerank 模型（bge-reranker-v2-m3）对候选片段进行精排，输出 Top 3~5 最相关片段 |
| 上下文组装 | Prompt 注入 | 将 Top K 检索结果拼接为上下文注入 Prompt，附带来源标注（知识库类型 + 文档名称） |
3. 检索参数配置
| 参数 | 初始值 | 调优说明 |
|---|---|---|
| 向量检索 Top K | 10 | 召回阶段宽口径，确保不遗漏相关片段 |
| 全文检索 Top K | 10 | 与向量检索互补，覆盖关键词精确匹配场景 |
| 混合检索权重 | 向量 0.7 / 全文 0.3 | 电商场景下语义检索更重要，但需保留关键词精确匹配能力 |
| Rerank 后 Top K | 3~5 | 简单问题取 Top 3，复杂问题取 Top 5，通过意图识别动态调整 |
| 相似度阈值 | 0.5 | 低于阈值的结果不进入上下文，防止引入噪音信息 |
| Score 阈值（Rerank） | 0.3 | Rerank 后低于阈值的片段丢弃，确保上下文质量 |
4. 多知识库路由策略
根据意图识别结果，动态选择检索的知识库范围，减少无关知识干扰：
| 用户意图 | 检索知识库 | 说明 |
|---|---|---|
| 商品咨询 | 商品知识库 + FAQ 库 | 优先商品知识库，FAQ 库补充常见问题 |
| 优惠活动咨询 | 活动规则库 + FAQ 库 | 活动规则库为主，FAQ 补充叠加规则等常见问题 |
| 物流查询 | 物流知识库 | 配合工具调用（物流 API）使用 |
| 退换货咨询 | 售后政策库 + FAQ 库 | 政策库提供规则，FAQ 提供操作指引 |
| 会员/积分问题 | 会员权益库 | 会员相关规则集中检索 |
| 意图不明确 | 全部知识库 | 无法明确意图时全库检索，由 Rerank 筛选最相关结果 |
5. 检索兜底策略
无结果兜底： 当所有检索结果的 Rerank Score 均低于阈值时，回复"抱歉，我暂时无法找到相关信息"并引导转人工
低置信度兜底： 当最高 Score 在 0.3~0.5 之间时，在回复中增加不确定性表述（"根据我的了解…"），并主动询问用户是否需要转人工
知识库为空兜底： 对应知识库未命中任何结果时，扩大到全库检索一次；仍无结果则触发兜底回复
（三）工具调用设计
设计目标： 通过 Dify 自定义 API 工具对接公司内部业务系统，为 AI 客服提供实时数据查询能力，覆盖订单、物流、商品、优惠券四大核心查询场景。
1. 工具清单
| 工具名称 | 触发场景 | 输入参数 | 输出信息 |
|---|---|---|---|
| 订单查询 | 用户咨询订单状态、退款进度 | 订单号 或 用户ID + 时间范围 | 订单状态、商品信息、金额、下单时间、退款状态 |
| 物流查询 | 用户咨询包裹物流进度 | 订单号 或 物流单号 | 快递公司、物流单号、最新物流节点、预计送达时间 |
| 商品查询 | 用户咨询商品价格、库存、规格 | 商品名称 或 商品ID / SKU ID | 商品价格、库存状态、可选规格、当前促销信息 |
| 优惠券查询 | 用户咨询可用优惠券 | 用户ID | 可用券列表（券面额、使用条件、有效期） |
2. 工具调用流程
sequenceDiagram
participant U as 用户
participant D as Dify Chatflow
participant T as API 工具
participant B as 业务系统
U->>D: "我的订单到哪了？"
D->>D: 意图识别 → 物流查询
D->>D: 参数提取 → 订单号
alt 参数完整
D->>T: 调用物流查询工具
T->>B: 请求物流 API
B-->>T: 返回物流数据
T-->>D: 物流信息
D->>D: 结合 Prompt 生成自然语言回复
D-->>U: "您的包裹已到达XX中转站，预计明天送达"
else 参数缺失
D-->>U: "请提供您的订单号，我帮您查询物流信息"
end
3. API 接口规范
所有工具通过 OpenAPI 3.0 规范导入 Dify，统一接口设计：
| 规范项 | 要求 |
|---|---|
| 协议 | HTTPS，内网通信可使用 HTTP |
| 认证方式 | API Key（Header: X-API-Key），Dify 侧统一配置 |
| 请求格式 | JSON，Content-Type: application/json |
| 响应格式 | 统一 JSON 结构：{"code": 0, "message": "success", "data": {...}} |
| 超时设置 | 单次调用超时 5 秒，超时后返回兜底提示 |
| 错误处理 | 业务系统返回错误时，AI 回复"系统查询暂时不可用，建议联系人工客服" |
| 数据脱敏 | 返回数据中的手机号、身份证号等敏感信息需在业务系统侧预先脱敏 |
4. 参数提取与校验
| 参数 | 提取方式 | 校验规则 |
|---|---|---|
| 订单号 | LLM 从对话中提取 | 正则校验格式（如纯数字 10~20 位）；无效则追问 |
| 物流单号 | LLM 提取 或 通过订单号级联查询 | 校验格式；优先通过订单号自动获取 |
| 商品名称/ID | LLM 提取 + 知识库辅助匹配 | 模糊匹配时返回候选列表让用户确认 |
| 用户ID | 从企微会话上下文自动获取 | 由中间层服务注入，无需用户提供 |
5. 工具调用异常处理
| 异常场景 | 处理策略 | 回复示例 |
|---|---|---|
| API 调用超时 | 重试 1 次，仍失败则兜底 | "系统查询稍有延迟，请稍后重试或联系人工客服为您查询" |
| API 返回错误 | 记录错误日志，返回友好提示 | "抱歉，当前系统繁忙，我帮您转接人工客服处理" |
| 查询无结果 | 确认参数后提示无数据 | "未查询到该订单信息，请确认订单号是否正确" |
| 参数缺失 | 主动追问所需参数 | "请提供您的订单号，我帮您查询具体信息～" |
| 多次调用失败 | 标记异常并转人工 | "很抱歉给您带来不便，正在为您转接人工客服" |
（四）Prompt 设计
设计目标： 通过精心设计的系统提示词体系，确保 AI 客服回复准确、有温度、符合品牌调性，同时具备清晰的边界意识和转人工判断能力。
1. 系统提示词结构
Prompt 采用 模块化分层结构，便于独立维护和版本管理：
| 模块 | 作用 | 内容要点 |
|---|---|---|
| 角色定义 | 设定 AI 身份和行为边界 | 你是XX品牌的专属客服助手，服务态度亲切专业，仅回答品牌相关问题 |
| 品牌调性 | 统一回复风格和语气 | 温暖亲切、专业可信、不卑不亢；使用"亲"等电商常用称呼；适当使用 emoji |
| 回复规范 | 约束回复格式和质量 | 回复简洁（不超过 150 字）；分点回答复杂问题；不编造信息；不确定时主动说明 |
| 知识库使用规范 | 约束知识引用方式 | 仅基于检索到的知识回复；未检索到时不杜撰；标注信息来源类型 |
| 工具调用规范 | 约束工具使用行为 | 需要实时数据时主动调用工具；参数不全时追问；工具失败时友好提示 |
| 转人工规则 | 明确转人工触发条件 | 详见下方转人工策略设计 |
| 安全红线 | 设定不可逾越的底线 | 不承诺超出政策范围的内容；不泄露内部信息；不回复无关话题 |
2. 系统提示词示例
点击展开完整系统提示词
## 角色定义 你是「XX品牌」的智能客服助手「小X」，负责为顾客提供售前咨询和售后服务。 你的目标是：准确解答顾客问题，提供温暖专业的服务体验。 ## 品牌调性 - 语气：温暖亲切、专业可信，像一位耐心的朋友 - 称呼：使用"亲"或"您" - 风格：简洁明了，适当使用 emoji（如 😊🎉💝）增添温度 - 禁止：冷冰冰的机械回复、过度热情、使用网络流行语 ## 回复规范 1. 回复控制在 150 字以内，复杂问题可分点回答 2. 仅基于【检索到的知识】和【工具查询结果】回复，不编造信息 3. 不确定的信息加上"根据我的了解"等限定表述 4. 涉及具体金额、时效等关键信息时，务必引用准确数据 5. 每次回复结尾可加一句关怀或引导（如"还有其他问题随时问我哦~"） ## 工具调用规范 - 涉及订单、物流、商品价格/库存、优惠券等实时信息时，必须调用对应工具查询 - 参数不全时，礼貌追问（如"请提供您的订单号，我帮您查一下~"） - 工具调用失败时，告知用户并建议转人工 ## 转人工规则 以下情况必须转人工处理： 1. 用户明确要求转人工 2. 投诉、纠纷、质量问题等敏感场景 3. 连续 2 轮无法解决用户问题 4. 涉及退款金额争议或特殊处理 5. 用户情绪明显激动或不满 转人工时说："理解您的情况，我帮您转接专属客服，请稍等~" ## 安全红线 - 绝不承诺超出公司政策范围的内容（如"一定给您退款"） - 绝不泄露内部信息（如成本价、供应商、内部流程） - 绝不回复与品牌业务无关的话题（政治、宗教等） - 遇到无法判断的情况，优先转人工
3. 转人工策略设计
| 触发类型 | 触发条件 | 处理方式 |
|---|---|---|
| 用户主动触发 | 用户发送"转人工""人工客服"等关键词 | 立即转人工，附带对话摘要 |
| 场景触发 | 投诉、纠纷、质量问题、退款争议 | AI 先安抚并收集关键信息（订单号、问题描述）→ 生成摘要 → 转人工 |
| 能力边界触发 | 连续 2 轮未解决用户问题（检索无结果或工具调用失败） | 主动告知用户"这个问题我帮您转接人工客服处理" → 转人工 |
| 情绪触发 | 检测到用户情绪激动（含辱骂、大量感叹号/问号等） | 先回复安抚语句 → 自动转人工 |
| 安全触发 | 涉及敏感信息泄露风险、合规风险 | 回复安全兜底语句 → 转人工 |
4. 对话摘要传递
转人工时，AI 自动生成结构化对话摘要，帮助人工客服快速了解上下文：
【对话摘要】
- 用户问题：查询订单 2024010812345 的退款进度
- 已获取信息：订单已签收，退款申请已提交 3 天
- 未解决原因：用户对退款时效不满，要求加急处理
- 用户情绪：略有不满
- 建议处理：优先查看退款进度，安抚用户情绪
5. Prompt 版本管理
| 管理项 | 规范 |
|---|---|
| 版本记录 | 每次修改在 Dify 中保存版本号和修改说明，格式：v1.0.0 - 修改内容描述 |
| 修改流程 | 产品修改 Prompt → 在评测集上验证效果 → 对比前后指标 → 确认上线 |
| 回滚机制 | 新版本上线后 24 小时内持续观测指标，指标下降超过 5% 则回滚至上一版本 |
| A/B 测试 | 重大 Prompt 调整通过 Dify 的 A/B 测试能力灰度发布，观察对比数据后全量 |
（五）评测流程、指标和看板设计
设计目标： 建立完善的评测体系，覆盖上线前评测和上线后监控，通过数据驱动持续优化智能客服效果。
1. 评测集设计
评测集构建原则：
覆盖所有核心业务场景（售前咨询、售后服务、物流查询等）
包含简单问题和复杂多轮对话
包含边界场景（无关问题、敏感问题、恶意攻击等）
由客服团队和产品共同标注，确保标准答案准确
| 场景分类 | 数量 | 来源 | 评测重点 |
|---|---|---|---|
| 商品咨询 | 100 | 历史对话 + 人工构造 | 知识库检索准确性、回复信息完整度 |
| 订单/物流查询 | 80 | 历史对话 + Mock 数据 | 工具调用成功率、参数提取准确性 |
| 退换货咨询 | 60 | 历史对话 | 政策引用准确性、流程指引清晰度 |
| 优惠活动咨询 | 50 | 历史对话 + 人工构造 | 活动规则理解准确性、叠加规则判断 |
| 多轮对话 | 40 | 人工构造 | 上下文理解、信息串联、追问处理 |
| 转人工场景 | 30 | 历史对话 + 人工构造 | 转人工触发准确性、摘要质量 |
| 边界/安全场景 | 40 | 人工构造 | 拒绝回复准确性、安全红线遵守 |
| 合计 | 400 |
2. 评测指标体系
（1）上线前评测指标
| 指标 | 计算方式 | 目标值 | 评测方式 |
|---|---|---|---|
| 回复准确率 | 正确回复数 / 总评测数 | ≥ 95% | 人工评审（对照标准答案） |
| 知识库命中率 | 检索到正确知识片段的问题数 / 需要知识库回答的问题数 | ≥ 98% | 自动化评测 |
| 工具调用成功率 | 工具成功返回结果数 / 应调用工具的问题数 | ≥ 99% | 自动化评测（Mock API） |
| 转人工准确率 | 正确触发转人工数 / 应转人工的问题数 | ≥ 90% | 人工评审 |
| 安全合规率 | 未违反安全红线的回复数 / 总安全测试数 | 100% | 人工评审 + 自动化检测 |
| 平均响应时间 | 从收到消息到返回回复的平均时长 | ≤ 3 秒 | 自动化测试 |
（2）上线后核心监控指标
| 指标 | 计算方式 | 目标值 | 监控频率 |
|---|---|---|---|
| ⭐ 未转人工满意度（北极星） | AI 独立结束会话后 4~5 星评价占比 | ≥ 90% | 实时 |
| 转人工率 | （AI 主动 + 用户主动转人工数）/ 总会话数 | ||
| （剔除首句即转人工） | ≤ 20% | 实时 | |
| 首次响应时长 | 用户发送消息到 AI 首次回复的时长 | ≤ 10 秒 | 实时 |
| 会话解决率 | AI 独立解决的会话数 / 总会话数 | ≥ 75% | 日报 |
| Badcase 率 | 低满意度（1~2 星）会话数 / 总评价会话数 | ≤ 5% | 日报 |
| 平均对话轮次 | AI 独立完成会话的平均交互轮次 | ≤ 5 轮 | 周报 |
3. 监控看板设计
看板分为三层：
（1）核心指标大盘（管理层 / 日常巡检）
未转人工满意度趋势图（日/周/月）
转人工率趋势图
首次响应时长分布图
今日会话量 / 解决率 / Badcase 数实时卡片
（2）场景分析看板（产品 / 运营）
各业务场景的满意度和准确率对比
转人工原因分布（用户主动 / AI 触发 / 场景触发 / 情绪触发）
知识库命中率按知识库类型分布
热门咨询问题 Top 20 排行
（3）Badcase 管理看板（产品 / 客服）
低满意度对话列表（可点击查看完整对话记录）
Badcase 归因分类：知识缺失 / 检索不准 / Prompt 问题 / 工具异常 / 其他
Badcase 处理状态跟踪（待分析 → 已归因 → 已修复 → 已验证）
修复后效果验证记录
4. 评测与优化闭环
graph TD
A["上线运行"] --> B["监控看板<br>实时采集数据"]
B --> C{"指标异常?"}
C -- 是 --> D["Badcase 采集"]
D --> E["归因分析"]
E --> F{"原因分类"}
F -- 知识缺失 --> G["补充知识库"]
F -- 检索不准 --> H["优化检索策略/参数"]
F -- Prompt问题 --> I["调优 Prompt"]
F -- 工具异常 --> J["排查 API 问题"]
G --> K["评测集验证"]
H --> K
I --> K
J --> K
K --> L{"指标达标?"}
L -- 是 --> M["灰度发布"]
L -- 否 --> E
M --> A
C -- 否 --> A
（六）功能设计：人工辅助建议
🤖 设计目标： 在转人工场景中，AI 不仅传递对话摘要，还为人工客服实时提供建议回复和参考信息，提升人工处理效率 30% 以上，缩短平均处理时长。
1. 功能定位
人工辅助建议是人机协同模块的核心功能，定位为人工客服的 AI Copilot。AI 转人工后不退出，而是作为后台助手持续为人工客服提供支持。
graph LR
A["顾客"] <--> B["人工客服"]
C["AI Copilot"] --> B
C --> D["建议回复"]
C --> E["参考知识"]
C --> F["订单/物流信息"]
B -- 采纳/修改/忽略 --> A
2. 核心功能清单
| 功能 | 触发方式 | 说明 |
|---|---|---|
| 建议回复生成 | 每轮顾客消息自动触发 | AI 根据顾客消息 + 对话上下文 + 知识库/工具查询结果，生成 1~2 条建议回复供人工客服参考。客服可一键采纳、编辑后发送或忽略 |
| 知识卡片推送 | 识别到相关知识时自动推送 | 当顾客问题涉及政策、规则、商品信息时，自动检索知识库并以卡片形式展示相关知识片段（来源 + 原文），供客服快速查阅 |
| 实时数据查询 | 识别到数据查询需求时自动触发 | 自动调用订单/物流/商品/优惠券 API，将查询结果以结构化卡片展示在客服侧边栏，无需客服手动切换系统查询 |
| 对话摘要展示 | 转人工时自动生成 | 在人工客服接入时，顶部展示 AI 生成的结构化对话摘要（用户问题、已获取信息、未解决原因、用户情绪、建议处理） |
| 话术模板推荐 | 识别到特定场景时推送 | 针对投诉安抚、退款解释、活动说明等高频场景，推荐经过审核的标准话术模板，客服可一键引用 |
3. 交互设计
人工客服工作台布局：
| 区域 | 内容 |
|---|---|
| 主聊天区（左） | 与顾客的对话窗口，正常收发消息 |
| AI 助手面板（右） | 分为三个 Tab： |
| ① 建议回复：每轮顾客消息后自动生成 1~2 条建议，支持一键采纳 / 编辑采纳 / 忽略 | |
| ② 知识参考：相关知识片段卡片列表，标注来源类型和更新时间 | |
| ③ 数据查询：订单/物流/商品/优惠券的实时查询结果卡片 | |
| 顶部摘要栏 | 转人工时展示对话摘要，可折叠 |
4. 建议回复生成策略
| 策略项 | 方案 | 说明 |
|---|---|---|
| 生成方式 | RAG + 工具调用 + Prompt | 复用智能客服相同的 RAG 和工具调用能力，但 Prompt 调整为"为客服生成建议回复"而非直接面向顾客 |
| 建议数量 | 每轮 1~2 条 | 简单问题生成 1 条；复杂问题生成 2 条不同角度的建议 |
| 响应时效 | ≤ 3 秒 | 在顾客消息到达后 3 秒内展示建议，不阻塞客服操作 |
| 置信度标注 | 高/中/低三档 | 标注建议的置信度，低置信度建议标记⚠️提醒客服谨慎参考 |
| 反馈机制 | 采纳/编辑/忽略 + 原因标签 | 记录客服对建议的反馈行为，用于优化建议生成质量 |
5. 效果衡量指标
| 指标 | 计算方式 | 目标值 | 统计方式 |
|---|---|---|---|
| 建议采纳率 | （一键采纳 + 编辑采纳）次数 / 总建议次数 | ≥ 60% | 系统埋点 |
| 人工平均处理时长 | 人工接手到会话结束的平均时长 | 降低 30% | 系统埋点 |
| 知识卡片查看率 | 客服点击查看知识卡片次数 / 推送次数 | ≥ 50% | 系统埋点 |
| 建议生成延迟 | 顾客消息到建议展示的平均时长 | ≤ 3 秒 | 系统埋点 |
6. 技术实现要点
复用现有能力： 建议回复的生成复用智能客服的 RAG 检索、工具调用和 LLM 能力，仅需调整 Prompt（从"面向顾客回复"调整为"为客服提供建议"）
异步非阻塞： 建议生成在后台异步执行，不影响客服正常操作；建议未生成完成时客服可先自行回复
Dify API 调用： 人工客服工作台通过调用 Dify Chatflow API 获取建议，传入完整对话上下文
渐进上线策略： Phase 2 先上线对话摘要 + 建议回复，Phase 3 扩展知识卡片和话术模板推荐
（七）意图识别设计
设计目标： 作为 Chatflow 的核心路由节点，准确识别用户意图并分发至对应的处理分支（知识检索、工具调用、转人工），意图识别准确率 ≥ 95%。
1. 意图分类体系
根据需求分析中的核心业务场景，定义以下意图分类：
| 意图大类 | 子意图 | 处理策略 | 优先级 |
|---|---|---|---|
| 商品咨询 | 商品信息查询、成分功效咨询、使用方法咨询、商品推荐与比较 | 知识库检索（商品库 + FAQ）+ 商品API | 高 |
| 优惠活动 | 活动规则咨询、优惠券使用咨询、叠加规则咨询 | 知识库检索（活动规则库）+ 优惠券API | 高 |
| 订单相关 | 订单状态查询、退款进度查询 | 工具调用（订单API） | 高 |
| 物流相关 | 物流进度查询、发货时间咨询、运费咨询 | 工具调用（物流API）+ 知识库（物流库） | 高 |
| 退换货 | 退货流程咨询、换货流程咨询、退款时效咨询 | 知识库检索（售后政策库 + FAQ） | 中 |
| 会员积分 | 会员权益查询、积分查询与兑换 | 知识库检索（会员权益库） | 中 |
| 投诉纠纷 | 商品质量投诉、服务态度投诉、纠纷处理 | 安抚 → 收集信息 → 转人工 | 高（敏感） |
| 转人工 | 用户主动要求转人工 | 直接转人工 | 最高 |
| 闲聊/无关 | 非业务话题、打招呼、情绪表达 | 礼貌引导回业务话题 | 低 |
2. 意图识别方案
采用 LLM 分类 + 规则兜底 的双层架构：
| 层级 | 方式 | 说明 |
|---|---|---|
| 第一层：规则匹配 | 关键词 + 正则表达式 | 优先匹配高确定性意图：如包含"转人工"→ 直接转人工；包含订单号格式 → 订单/物流查询；包含投诉类关键词 → 投诉纠纷。速度快、零延迟 |
| 第二层：LLM 分类 | Dify Chatflow 中的 LLM 节点 | 将用户消息 + 对话历史输入 LLM，输出结构化意图分类结果（意图大类 + 子意图 + 置信度）。处理规则层无法覆盖的复杂、模糊表述 |
| 兜底策略 | 意图不明确时的处理 | 当 LLM 分类置信度 < 0.7 时，标记为"意图不明确"，触发全库检索 + 追问澄清策略 |
3. Chatflow 中的意图路由节点
graph TD
A["用户消息输入"] --> B{"规则匹配"}
B -- 命中转人工 --> C["转人工流程"]
B -- 命中订单号 --> D["订单/物流查询分支"]
B -- 命中投诉关键词 --> E["投诉处理分支"]
B -- 未命中 --> F["LLM 意图分类"]
F --> G{"意图分类结果"}
G -- 商品咨询 --> H["商品知识库检索 + 商品API"]
G -- 优惠活动 --> I["活动规则库检索 + 优惠券API"]
G -- 退换货 --> J["售后政策库检索"]
G -- 会员积分 --> K["会员权益库检索"]
G -- 闲聊/无关 --> L["礼貌引导回复"]
G -- 置信度低 --> M["全库检索 + 追问澄清"]
4. 意图识别 Prompt 设计
点击展开意图分类 Prompt
你是一个电商客服意图分类器。请根据用户的最新消息和对话历史，判断用户意图。 ## 输出格式（严格 JSON） {"intent": "意图大类", "sub_intent": "子意图", "confidence": 0.0~1.0, "entities": {"order_id": "", "product_name": "", "keyword": ""}} ## 意图分类 - product_inquiry: 商品咨询（商品信息、成分功效、使用方法、商品推荐与比较） - promotion_inquiry: 优惠活动（活动规则、优惠券使用、叠加规则） - order_query: 订单相关（订单状态、退款进度） - logistics_query: 物流相关（物流进度、发货时间、运费） - return_exchange: 退换货（退货流程、换货流程、退款时效） - membership: 会员积分（会员权益、积分查询与兑换） - complaint: 投诉纠纷（质量投诉、服务投诉） - transfer_human: 转人工（用户明确要求） - chitchat: 闲聊/无关内容 ## 规则 1. 优先识别是否包含转人工意图 2. 如果同时涉及多个意图，取最主要的一个 3. 同时提取关键实体（订单号、商品名、关键词等） 4. confidence < 0.7 时，intent 设为 "unclear" ## 对话历史 conversation_history ## 用户最新消息 user_message
5. 复合意图处理
当用户消息包含多个意图时（如"帮我查下订单 123 的物流，还有退货怎么操作"），处理策略：
串行处理： 按优先级依次处理每个意图，先处理工具调用类（物流查询），再处理知识检索类（退货政策）
合并回复： 将多个意图的回复合并为一条结构化消息，分点呈现
最多处理 2 个意图： 超过 2 个意图时，先回复前 2 个，再追问"您还有其他问题吗？"
（八）多轮对话管理设计
设计目标： 实现完善的多轮对话上下文管理机制，支持跨轮次的信息关联、指代消解和追问澄清，确保多轮对话场景下的回复连贯性和准确性。
1. 会话记忆策略
| 策略项 | 方案 | 说明 |
|---|---|---|
| 上下文窗口 | 最近 10 轮对话 | 保留最近 10 轮（用户 + AI）消息作为 LLM 上下文输入；超出时采用滑动窗口截取，最早的消息被丢弃 |
| 变量记忆 | Chatflow 变量传递 | 通过 Dify Chatflow 变量存储本轮提取的关键实体（订单号、商品名、用户ID等），跨节点传递，避免重复提取 |
| 会话摘要 | 长会话自动摘要 | 当对话超过 10 轮时，由 LLM 对早期对话生成摘要，替代原始消息注入上下文，节省 token 同时保留关键信息 |
| 会话超时 | 30 分钟无交互自动结束 | 超时后清空上下文，下次交互视为新会话；超时前 5 分钟发送提醒消息 |
2. 上下文关联机制
| 场景 | 示例 | 处理方式 |
|---|---|---|
| 指代消解 | 用户先问"A面霜怎么样"，再问"它适合油皮吗" | LLM 基于对话历史将"它"解析为"A面霜"，在 Query 改写阶段完成指代替换 |
| 信息继承 | 用户先提供订单号查物流，再问"退款进度呢" | 从变量记忆中直接获取已提取的订单号，无需重复追问 |
| 意图切换 | 用户从商品咨询转到物流查询 | 重新识别意图，切换至对应处理分支；保留变量记忆中的实体信息 |
| 追问澄清 | 用户说"帮我查下订单"但未提供订单号 | AI 追问订单号，用户回复后与上一轮追问关联，从回复中提取参数继续处理 |
| 多轮纠正 | 用户说"不是这个，我问的是B产品" | LLM 识别到纠正意图，清除之前的商品实体，重新提取并检索 |
3. 会话状态管理
stateDiagram-v2
[*] --> 新会话: 用户首次发消息
新会话 --> 对话中: AI 回复
对话中 --> 对话中: 用户继续交互
对话中 --> 等待追问: AI 追问参数
等待追问 --> 对话中: 用户提供参数
等待追问 --> 超时结束: 30分钟无回复
对话中 --> 转人工: 触发转人工条件
对话中 --> AI结束: AI 独立解决
对话中 --> 超时结束: 30分钟无交互
AI结束 --> 评价: 推送满意度评价
转人工 --> 人工接管: 人工客服介入
评价 --> [*]
人工接管 --> [*]
超时结束 --> [*]
4. Chatflow 中的上下文处理节点
在 Dify Chatflow 中，上下文管理通过以下节点协同实现：
| 节点 | 功能 | 配置要点 |
|---|---|---|
| 对话历史节点 | 加载历史消息 | 设置 window_size = 10；超长会话启用摘要模式 |
| 变量赋值节点 | 存储/更新实体变量 | 意图识别后，将提取的 order_id、product_name 等写入会话变量 |
| 条件分支节点 | 判断变量是否存在 | 如需要订单号但变量为空 → 追问分支；变量已存在 → 直接调用工具 |
| Query 改写节点 | 结合上下文改写查询 | LLM 节点，输入当前消息 + 对话历史 + 变量，输出改写后的检索 Query |
5. 边界处理
话题跳跃： 用户在一次会话中频繁切换话题时，保留所有变量记忆但重新识别意图，确保每次回复与当前话题相关
循环提问： 检测到用户重复提问相同问题（相似度 > 0.9）时，换一种表述方式回复或建议转人工
超长会话： 超过 20 轮时，自动在回复中提示"如果您还有其他问题，也可以随时找我哦~"引导自然结束
（九）安全合规模块设计
设计目标： 构建多层安全防护体系，覆盖输入过滤、输出审核、敏感信息保护和异常兜底，确保 AI 客服输出 100% 合规，不产生法律和品牌风险。
1. 安全架构：三层防护
graph LR
A["用户输入"] --> B["输入层过滤"]
B --> C["AI 核心处理"]
C --> D["输出层审核"]
D --> E["回复用户"]
B -- 拦截 --> F["安全兜底回复"]
D -- 拦截 --> F
2. 输入层安全过滤
| 检测项 | 检测方式 | 处理策略 |
|---|---|---|
| 敏感信息检测 | 正则表达式匹配 | 检测用户消息中的身份证号、银行卡号、完整手机号等，在传入 LLM 前自动脱敏（如 1381234） |
| 恶意注入检测 | 规则 + LLM 检测 | 检测 Prompt 注入攻击（如"忽略以上指令""扮演其他角色"）、越狱攻击；命中则返回拒绝回复 |
| 违规内容检测 | 关键词库 + 第三方内容安全 API | 检测涉政、涉黄、涉暴等违规内容；命中则返回引导回业务话题的回复 |
| 消息频率控制 | 中间层服务限流 | 单用户每分钟最多 20 条消息，超出则返回"消息发送过于频繁，请稍后再试" |
3. 输出层安全审核
| 审核项 | 审核方式 | 处理策略 |
|---|---|---|
| 信息泄露检测 | 正则 + 规则匹配 | 检测 AI 回复中是否包含内部信息（成本价、供应商名称、内部系统名称等），命中则拦截并替换为安全回复 |
| 虚假承诺检测 | 关键词 + LLM 审核 | 检测回复中是否包含超出政策的承诺（"一定退款""保证赔偿"等），命中则改写为合规表述 |
| 内容合规检测 | 第三方内容安全 API | 对 AI 输出进行内容安全扫描，拦截可能的不当内容 |
| 幻觉检测 | 检索结果比对 | 将 AI 回复中的关键事实（价格、时效、政策）与检索到的知识片段进行比对，不一致时标记并触发人工复核 |
4. 敏感信息保护
| 敏感信息类型 | 检测规则 | 脱敏方式 | 适用环节 |
|---|---|---|---|
| 手机号 | 11位数字，1开头 | 138****1234 | 输入脱敏 + 日志脱敏 |
| 身份证号 | 18位/15位，含校验 | 310**********1234 | 输入脱敏 + 日志脱敏 |
| 银行卡号 | 16~19位数字 | 6222********1234 | 输入脱敏 + 日志脱敏 |
| 收货地址 | 工具返回数据中的地址字段 | 省市区 + **** | 输出脱敏 |
| 邮箱 | 邮箱格式正则匹配 | a**@example.com | 输入脱敏 + 日志脱敏 |
5. 异常兜底机制
| 异常场景 | 触发条件 | 兜底处理 |
|---|---|---|
| 模型超时/报错 | LLM 调用超过 10 秒或返回错误 | 返回："抱歉，系统繁忙，请稍后再试。如需紧急帮助，我帮您转接人工客服~" + 提供转人工按钮 |
| 知识库服务异常 | 向量数据库/全文检索不可用 | 降级为仅依赖 Prompt 内置知识回复基础 FAQ；超出范围的问题转人工 |
| 工具服务异常 | 业务 API 全部不可用 | 返回："当前查询服务暂时维护中，建议您稍后再试或联系人工客服" + 记录告警 |
| 全链路异常 | AI 核心服务整体不可用 | 中间层服务直接返回预设兜底消息 + 自动转人工；不依赖 AI 生成 |
| 内容安全拦截 | 输出审核未通过 | 替换为通用安全回复："感谢您的耐心，这个问题我帮您转接人工客服为您详细解答~" |
6. 合规要求清单
| 合规要求 | 落地措施 |
|---|---|
| 《个人信息保护法》 | 对话数据加密存储（AES-256）；敏感信息传输前脱敏；用户数据仅用于当次会话，不用于模型训练 |
| 《生成式人工智能服务管理暂行办法》 | AI 身份标识（首次对话告知用户"我是智能客服助手"）；输出内容安全审核；建立人工审核机制 |
| 消费者权益保障 | 不做虚假承诺；转人工通道始终畅通；投诉场景优先转人工处理 |
| 数据安全 | Dify 私有化部署，数据不出内网；对话日志定期清理（保留 90 天）；访问权限分级管控 |