## （一）知识库设计

**设计目标：** 构建覆盖售前售后全场景的结构化知识库体系，确保知识准确、更新及时、检索高效，支撑 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

```mermaid
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\. 工具调用流程

```mermaid
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** | <br> | <br> |

### 2\. 评测指标体系

**（1）上线前评测指标**

| **指标** | **计算方式** | **目标值** | **评测方式** |
| --- | --- | --- | --- |
| 回复准确率 | 正确回复数 / 总评测数 | ≥ 95% | 人工评审（对照标准答案） |
| 知识库命中率 | 检索到正确知识片段的问题数 / 需要知识库回答的问题数 | ≥ 98% | 自动化评测 |
| 工具调用成功率 | 工具成功返回结果数 / 应调用工具的问题数 | ≥ 99% | 自动化评测（Mock API） |
| 转人工准确率 | 正确触发转人工数 / 应转人工的问题数 | ≥ 90% | 人工评审 |
| 安全合规率 | 未违反安全红线的回复数 / 总安全测试数 | 100% | 人工评审 + 自动化检测 |
| 平均响应时间 | 从收到消息到返回回复的平均时长 | ≤ 3 秒 | 自动化测试 |

**（2）上线后核心监控指标**

| **指标** | **计算方式** | **目标值** | **监控频率** |
| --- | --- | --- | --- |
| ⭐ 未转人工满意度（北极星） | AI 独立结束会话后 4~5 星评价占比 | ≥ 90% | 实时  |
| 转人工率 | （AI 主动 + 用户主动转人工数）/ 总会话数 | <br> | <br> |
| （剔除首句即转人工） | ≤ 20% | 实时  | <br> |
| 首次响应时长 | 用户发送消息到 AI 首次回复的时长 | ≤ 10 秒 | 实时  |
| 会话解决率 | AI 独立解决的会话数 / 总会话数 | ≥ 75% | 日报  |
| Badcase 率 | 低满意度（1~2 星）会话数 / 总评价会话数 | ≤ 5% | 日报  |
| 平均对话轮次 | AI 独立完成会话的平均交互轮次 | ≤ 5 轮 | 周报  |

### 3\. 监控看板设计

**看板分为三层：**

**（1）核心指标大盘（管理层 / 日常巡检）**

-   未转人工满意度趋势图（日/周/月）
    
-   转人工率趋势图
    
-   首次响应时长分布图
    
-   今日会话量 / 解决率 / Badcase 数实时卡片
    

**（2）场景分析看板（产品 / 运营）**

-   各业务场景的满意度和准确率对比
    
-   转人工原因分布（用户主动 / AI 触发 / 场景触发 / 情绪触发）
    
-   知识库命中率按知识库类型分布
    
-   热门咨询问题 Top 20 排行
    

**（3）Badcase 管理看板（产品 / 客服）**

-   低满意度对话列表（可点击查看完整对话记录）
    
-   Badcase 归因分类：知识缺失 / 检索不准 / Prompt 问题 / 工具异常 / 其他
    
-   Badcase 处理状态跟踪（待分析 → 已归因 → 已修复 → 已验证）
    
-   修复后效果验证记录
    

### 4\. 评测与优化闭环

```mermaid
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
```

## （六）功能设计：人工辅助建议

<aside> 🤖

**设计目标：** 在转人工场景中，AI 不仅传递对话摘要，还为人工客服实时提供建议回复和参考信息，提升人工处理效率 30% 以上，缩短平均处理时长。

</aside>

### 1\. 功能定位

人工辅助建议是**人机协同模块**的核心功能，定位为人工客服的 **AI Copilot**。AI 转人工后不退出，而是作为后台助手持续为人工客服提供支持。

```mermaid
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 条建议，支持一键采纳 / 编辑采纳 / 忽略 | <br> |
| ② **知识参考**：相关知识片段卡片列表，标注来源类型和更新时间 | <br> |
| ③ **数据查询**：订单/物流/商品/优惠券的实时查询结果卡片 | <br> |
| **顶部摘要栏** | 转人工时展示对话摘要，可折叠 |

### 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 中的意图路由节点

```mermaid
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\. 会话状态管理

```mermaid
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\. 安全架构：三层防护

```mermaid
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](mailto:a**@example.com) | 输入脱敏 + 日志脱敏 |

### 5\. 异常兜底机制

| **异常场景** | **触发条件** | **兜底处理** |
| --- | --- | --- |
| **模型超时/报错** | LLM 调用超过 10 秒或返回错误 | 返回："抱歉，系统繁忙，请稍后再试。如需紧急帮助，我帮您转接人工客服~" + 提供转人工按钮 |
| **知识库服务异常** | 向量数据库/全文检索不可用 | 降级为仅依赖 Prompt 内置知识回复基础 FAQ；超出范围的问题转人工 |
| **工具服务异常** | 业务 API 全部不可用 | 返回："当前查询服务暂时维护中，建议您稍后再试或联系人工客服" + 记录告警 |
| **全链路异常** | AI 核心服务整体不可用 | 中间层服务直接返回预设兜底消息 + 自动转人工；不依赖 AI 生成 |
| **内容安全拦截** | 输出审核未通过 | 替换为通用安全回复："感谢您的耐心，这个问题我帮您转接人工客服为您详细解答~" |

### 6\. 合规要求清单

| **合规要求** | **落地措施** |
| --- | --- |
| 《个人信息保护法》 | 对话数据加密存储（AES-256）；敏感信息传输前脱敏；用户数据仅用于当次会话，不用于模型训练 |
| 《生成式人工智能服务管理暂行办法》 | AI 身份标识（首次对话告知用户"我是智能客服助手"）；输出内容安全审核；建立人工审核机制 |
| 消费者权益保障 | 不做虚假承诺；转人工通道始终畅通；投诉场景优先转人工处理 |
| 数据安全 | Dify 私有化部署，数据不出内网；对话日志定期清理（保留 90 天）；访问权限分级管控 |

<br>