RAG——Agent“记忆” 与 “规划”（二）

RAG——Agent“记忆” 与 “规划”（二） RAG——Agent“记忆” 与 “规划”（二） Modified July 30, 2025 召回策略：从索引中 “精准捞出” 所需知识 召回策略是指通过技术手段从构建好的索引中筛选出与用户问题最相关的内容，客服场景中需兼顾 “速度”（紧急问题快速响应）和 “精准度”（复杂问题准确匹配）。 SQL 类（结构化知识增强） 适用于知识库中包含结构化数据的场景（如用户订单信息、物流进度表、产品库存表），通过 SQL 查询快速获取精确数据，再结合非结构化知识生成答案。 • 客服场景应用：用户问 “我的订单 12345 什么时候发货？”，系统先通过 SQL 查询订单表中 “订单 12345” 的 “预计发货时间”（结构化数据），再结合非结构化的 “发货延迟处理规则”（如 “延迟超过 24 小时可申请补偿”），生成完整回答：“您的订单 12345 预计今日 18 点前发货，若延迟超过 24 小时，可联系客服申请 5 元无门槛券。” 向量数据库（非结构化知识核心检索） 通过向量计算匹配用户问题与索引片段的语义相似度，是客服场景中非结构化知识（如产品手册、故障处理指南）的主要召回方式，核心参数需结合场景调整： • 参数类： ◦ rerank 模型：对初召回的片段（通常 5 10 个）二次排序，优先保留与问题语义最相关的内容。例如用户问 “手机充不上电”，初召回可能包含 “充电线故障”“电池老化”“充电器规格” 等片段，rerank 模型会根据 “充不上电” 的核心语义，将 “充电线故障排查” 排在首位。 ◦ 相似度阈值：设置最低匹配分数（如 0.7），过滤低相关片段（避免无关知识干扰大模型生成）。客服场景中故障类问题需更高阈值（如 0.75），避免错误引导用户（如将 “安卓充电问题” 的知识用于苹果手机）。 ◦ 召回数量：简单问题（如 “如何查物流”）召回 2 3 个片段即可，复杂问题（如 “系统报错 502 且无法重启”）需召回 5 8 个，确保覆盖完整解决方案。 知识图谱（实体关系密集型知识检索） 适用于包含大量实体关系的知识（如产品型号 故障 解决方案、用户等级 权益对应关系），通过实体关联快速定位相关知识。 • 客服场景应用：用户问 “我的 VIP 会员为什么不能用优惠券？”，知识图谱中存储 “VIP 会员 可使用优惠券类型 限制条件” 的关系（如 “VIP1 级可用于满 100 减 10，不可用于特价商品”），系统可直接通过实体 “VIP 会员”“优惠券” 的关系，召回对应的限制条件，避免遗漏规则细节。 三、系统主流程：从 “问题输入” 到 “答案输出” 的全链路设计 系统主流程需结合客服场景的业务逻辑（如响应速度、合规性要求），设计 “大模型生成” 与 “业务流程” 的结合方式，确保输出符合客服场景的效率与规范。 直接使用大模型生成：快速响应 “标准化问题” 适用场景：用户问题简单、知识库中存在明确答案（如 FAQ 中的 “查询订单步骤”“修改收货地址方法”）。 • 流程：用户提问→系统检索相关索引片段→将片段与问题一起输入大模型→大模型按 “简洁、步骤清晰” 的 prompt 生成答案。 • 示例：用户问 “怎么取消订单？”，系统召回 “取消订单步骤” 的索引片段，prompt 设置为 “用 1、2、3 步骤说明取消订单的操作，每步不超过 20 字”，大模型直接输出：“1. 打开我的订单；2. 找到对应订单点取消；3. 确认取消原因即可。” 基于业务逻辑构建 workflow+prompt：处理 “复杂 / 合规性要求高” 的问题 适用场景：用户问题涉及多步骤流程（如投诉处理）、合规性要求（如法律条款、政策说明）或需跨知识源整合（如结合订单数据 + 售后规则）。 • 流程设计：按业务逻辑拆分步骤，每个步骤调用对应知识或工具，再通过 prompt 引导大模型按步骤生成答案。 ◦ 示例 1（投诉处理流程）： i. 调用用户信息接口获取 “用户历史投诉记录”（判断是否重复投诉）； ii. 检索 “投诉处理规则”（如 “首次投诉 24 小时内响应”）； iii. 结合用户问题（如 “物流延迟 5 天”），调用 “物流延迟补偿政策” 的索引片段； iv. prompt 设置为 “先安抚用户（参考‘投诉话术库’第 2 条），说明处理时效（24 小时内），告知补偿方案（延迟 5 天可获 10 元券）”，大模型按步骤输出合规且完整的回复。 ◦ 示例 2（合规性要求高的场景）： 对政府机关、法律类客服场景，需严格按知识库原文输出（如 “退款政策” 一字不差），workflow 中加入 “合规校验节点”，大模型生成后，自动比对输出与知识库原文的一致性，确保无篡改。 总结 😀 客服场景的 RAG 系统搭建需围绕 “精准、高效、合规” 三个核心：索引构建需根据知识库类型（结构化 / 非结构化、简单 / 复杂）选择切分方法，召回策略需结合向量检索与业务标签提升精准度，系统主流程需匹配问题复杂度（简单问题直接生成，复杂问题按业务流程分步处理）。通过全链路的精细化设计，才能让 RAG 系统真正成为客服场景的 “智能助手”，既提升响应效率，又保证回答质量。 三、数据收集与反馈 RAG 的构建实战（客服场景）：数据收集与数据库构建 😀 数据是 RAG 系统的 “基石”，客服场景的知识库质量、用户需求理解精度直接依赖于数据的完整性与针对性。本节聚焦 “数据收集”“数据库结构设计”“数据场景化分析”“回答效果评估” 及 “用户真实需求提取”，为客服场景 RAG 系统提供数据层的实战指南。 一、数据收集：明确来源与核心内容 客服场景的数据收集需覆盖 “知识库原始素材”“用户交互记录”“业务规则文档” 三类核心数据，确保后续数据库既能支撑基础问答，又能适配真实业务场景。 1. 核心数据来源 1. 知识库原始素材（静态数据） ◦ 产品相关：说明书（如家电操作步骤、软件功能说明）、参数表（如手机配置、保修期限）、常见问题 FAQ（如 “如何连接 WiFi”“退款条件”）。 ◦ 业务流程：售后故障处理手册（如 “系统报错代码 502 排查步骤”）、物流规则（如 “配送时效、延迟赔付标准”）、投诉处理规范（如 “投诉响应时效、升级流程”）。 ◦ 合规性文档：法律条款（如用户协议中 “隐私权限说明”）、企业对外话术（如 “客服禁用语”“官方承诺话术”）。 2. 用户交互记录（动态数据） ◦ 历史对话：用户与人工客服的聊天记录（如 “我买的冰箱不制冷了，怎么办？”“订单显示已发货但查不到物流”）、用户与旧系统的问答记录。 ◦ 行为数据：用户咨询的时间（如 “夜间 22 点后咨询物流问题较多”）、咨询渠道（APP / 小程序 / 电话）、问题类型分布（如 “售后故障占比 40%，物流查询占 30%”）。 3. 业务规则补充（支撑数据） ◦ 内部业务逻辑：如 “VIP 用户投诉优先处理”“新用户首单退款无需审核” 等规则，需转化为结构化数据存入数据库，用于后续 workflow 判断。 2. 数据筛选原则 客服场景数据需满足 “精准、简洁、场景化”： • 剔除冗余信息：如产品说明书中与用户无关的 “生产工艺细节”（用户仅关心操作步骤）。 • 保留关键场景数据：如物流场景中 “暴雨天气配送延迟的特殊处理规则”（高频真实场景）。 • 标注时效性：如 “2025 年退款政策” 需明确时间，避免用过期规则回答用户。 二、数据场景化分析：针对性优化知识库 客服场景的需求差异显著（如 “物流查询” vs “售后投诉”），需按场景拆解数据特征，为索引构建、召回策略提供依据。 1. 按场景划分数据特征 1. 物流查询场景 ◦ 数据特点：用户问题多含 “物流”“快递”“发货” 等关键词，核心信息为 “订单号”“物流状态”“延迟原因”；知识库数据以 “物流流程”“延迟处理规则” 为主。 ◦ 分析结论：索引切分优先用 “标记符式”（按 “订单状态 处理步骤” 拆分），召回时增加 “订单号” 等实体过滤（结合知识图谱）。 2. 售后故障场景 ◦ 数据特点：用户问题常含 “故障”“报错”“不工作” 等描述，可能附带 “错误代码”“设备型号”；知识库数据以 “故障现象 排查步骤 解决方案” 为主，逻辑链严密。 ◦ 分析结论：索引切分需用 “语义式”（确保 “现象 步骤 方案” 完整），召回时提高相似度阈值（避免错误匹配不同型号的故障处理步骤）。 3. 投诉建议场景 ◦ 数据特点：用户情绪倾向明显（如 “愤怒”“不满”），真实需求可能包含 “道歉”“补偿”“改进建议”；知识库数据以 “投诉处理规范”“赔付政策” 为主，需兼顾合规性与情感安抚。 ◦ 分析结论：索引需添加 “情感标签”（如 “安抚话术”“赔付标准”），回答流程中优先调用 “情感安抚” 相关片段（结合 workflow）。 2. 数据分布分析 通过统计各场景的问题占比、高频关键词、未解决问题类型，指导知识库补充： • 例：若 “物流延迟” 问题占比 30%，但知识库中 “延迟赔付规则” 的片段不足，则需补充该类数据； • 若 “老年用户” 对 “步骤类回答” 的解决率仅 60%（低于平均 80%），则需优化该群体的索引切分（如将步骤拆分为更简单的短句）。 三、回答效果打标：量化评估与系统优化 对系统生成的回答进行打标，是验证 RAG 效果、迭代优化的核心环节，需明确打标维度与应用方式。 1. 打标维度设计（客服场景适配版） 1. 解决率：核心指标，判断回答是否满足用户真实需求（如用户问 “快递延迟怎么办”，回答若包含 “查询延迟原因 + 申请赔付步骤” 则打 10 分，仅说 “已记录” 则打 3 分）。 2. 准确性：回答是否与知识库一致（如 “退款时效 7 天” 若错写为 “15 天”，则准确性 0 分），合规场景（如法律条款）需严格打标。 3. 完整性：是否覆盖用户需求的所有维度（如用户同时问 “退款步骤 + 到账时间”，回答若漏了 “到账时间”，则完整性打 6 分）。 4. 可读性：回答是否符合用户画像（如老年用户的回答是否简洁易懂，专业用户的回答是否包含技术细节）。 2. 打标实施方式 • 自动化打标：大模型基于预设规则评分（如对比回答与真实需求的匹配度），适用于批量初筛； • 人工打标：针对高优先级场景（如投诉、大额订单问题）或自动化打标存疑的案例（如模糊需求），由客服专员二次校验，确保打标精准。 3. 打标结果应用 • 低解决率案例：分析原因（如索引缺失、召回错误），补充知识库或调整召回策略（如增加该类问题的召回数量）； • 低准确性案例：检查索引内容是否错误，或大模型生成时是否篡改知识，优化 prompt（如 “严格按知识库原文输出”）。 四、数据优化与 Bad Case 迭代 😀 在客服场景的 RAG 系统中，“上线” 并非终点 —— 随着用户问题多样化、业务规则更新，系统难免出现 “回答不准确”“未解决需求” 等 Bad Case。因此，需建立 “Bad Case 分析 根因定位 针对性优化” 的闭环，通过数据反馈持续迭代系统。本节聚焦 “Bad Case 产生原因” 与 “优化手段”，结合数据模块与系统模块形成完整优化链路。 一、Bad Case 分析：定位问题根源 Bad Case（失效案例）是指 “用户问题未被解决” 或 “回答不符合预期” 的场景（如 “用户问‘退款多久到账’，系统回答‘如何申请退款’”）。需通过数据记录（如用户对话表、评价表）筛选高频 Bad Case，再从 “数据层”“系统层” 拆解根因。 1. 数据层：知识 “无” 或 “错” 1. 数据库无收录（知识缺失） 表现：用户问题涉及的知识未进入知识库，系统无法召回有效信息，导致回答泛化（如 “抱歉，暂未找到相关信息”）。 ◦ 典型案例：新上线产品的 “激活流程” 未录入知识库，用户问 “刚买的会员怎么激活”，系统无对应索引，只能模糊回复。 ◦ 根因：数据收集阶段遗漏 “新业务 / 新功能” 相关知识；或用户问题属于 “长尾场景”（如 “海外用户退款流程”），初始知识库未覆盖。 2. 知识库内容错误（知识失真） 表现：知识库中存在错误信息（如 “退款时效写为‘7 天’，实际业务规则为‘3 天’”），导致系统生成错误回答。 ◦ 典型案例：用户问 “退款什么时候到账”，系统依据错误知识库回答 “7 天内”，但实际 3 天未到账引发二次投诉。 ◦ 根因：数据录入时未校验业务规则更新（如企业调整退款时效后，知识库未同步）；或原始素材本身存在歧义（如手册中 “工作日” 未明确 “不含节假日”）。 2. 系统层：知识 “找错” 或 “用错” 1. 索引构建失败（知识拆分不合理） 表现：索引切分导致关键信息断裂，召回的片段不完整，大模型生成的回答 “缺漏核心步骤”。 ◦ 典型案例：知识库中 “退货流程” 原文为 “1. 申请退货；2. 等待审核（24 小时内）；3. 寄回商品（审核通过后 7 天内）”，但切片式切分时按固定长度拆分，前半段仅保留 “1. 申请退货；2. 等待审核”，后半段 “3. 寄回商品” 被拆分到另一索引。用户问 “退货后多久要寄回”，系统仅召回前半段，回答缺失 “7 天内” 的关键信息。 ◦ 根因：切分方法与文本特性不匹配（如强逻辑的 “流程类知识” 误用切片式切分，而非语义式）；标签法未补充 “步骤完整性” 标签，无法识别断裂的索引。 2. 召回策略失效（知识匹配错误） 表现：系统召回的索引与用户问题语义偏差大，或遗漏更相关的知识，导致回答 “答非所问”。 ◦ 典型案例：用户问 “系统报错 502 怎么解决”（属于 “服务器故障”），但向量数据库召回了 “报错 404”（页面不存在）的索引，大模型基于错误片段生成 “检查 URL 是否正确” 的回答，与用户需求无关。 ◦ 根因：向量数据库参数不合理（如相似度阈值设置过低，导致低相关片段被召回）；未结合业务标签过滤（如 “错误代码 502” 未关联 “服务器故障” 标签，无法精准过滤）；知识图谱中 “错误代码 故障类型” 的实体关系缺失，无法通过实体匹配校正召回结果。 3. 生成模块偏差（知识使用不当） 表现：大模型未按用户画像或场景需求生成回答，导致 “风格不符”“信息过载 / 不足”。 ◦ 典型案例：老年用户问 “怎么连 WiFi”，系统用技术术语回答 “进入设备后台，配置 SSID 与密码”（未口语化），用户无法理解；或专业用户问 “API 接口调用失败的日志分析”，系统仅回答 “检查网络”（未提供技术细节）。 召回策略：从索引中 “精准捞出” 所需知识 召回策略是指通过技术手段从构建好的索引中筛选出与用户问题最相关的内容，客服场景中需兼顾 “速度”（紧急问题快速响应）和 “精准度”（复杂问题准确匹配）。 SQL 类（结构化知识增强） 适用于知识库中包含结构化数据的场景（如用户订单信息、物流进度表、产品库存表），通过 SQL 查询快速获取精确数据，再结合非结构化知识生成答案。 • 客服场景应用：用户问 “我的订单 12345 什么时候发货？”，系统先通过 SQL 查询订单表中 “订单 12345” 的 “预计发货时间”（结构化数据），再结合非结构化的 “发货延迟处理规则”（如 “延迟超过 24 小时可申请补偿”），生成完整回答：“您的订单 12345 预计今日 18 点前发货，若延迟超过 24 小时，可联系客服申请 5 元无门槛券。” 向量数据库（非结构化知识核心检索） 通过向量计算匹配用户问题与索引片段的语义相似度，是客服场景中非结构化知识（如产品手册、故障处理指南）的主要召回方式，核心参数需结合场景调整： • 参数类： ◦ rerank 模型：对初召回的片段（通常 5 10 个）二次排序，优先保留与问题语义最相关的内容。例如用户问 “手机充不上电”，初召回可能包含 “充电线故障”“电池老化”“充电器规格” 等片段，rerank 模型会根据 “充不上电” 的核心语义，将 “充电线故障排查” 排在首位。 ◦ 相似度阈值：设置最低匹配分数（如 0.7），过滤低相关片段（避免无关知识干扰大模型生成）。客服场景中故障类问题需更高阈值（如 0.75），避免错误引导用户（如将 “安卓充电问题” 的知识用于苹果手机）。 ◦ 召回数量：简单问题（如 “如何查物流”）召回 2 3 个片段即可，复杂问题（如 “系统报错 502 且无法重启”）需召回 5 8 个，确保覆盖完整解决方案。 ◦ rerank 模型：对初召回的片段（通常 5 10 个）二次排序，优先保留与问题语义最相关的内容。例如用户问 “手机充不上电”，初召回可能包含 “充电线故障”“电池老化”“充电器规格” 等片段，rerank 模型会根据 “充不上电” 的核心语义，将 “充电线故障排查” 排在首位。 ◦ 相似度阈值：设置最低匹配分数（如 0.7），过滤低相关片段（避免无关知识干扰大模型生成）。客服场景中故障类问题需更高阈值（如 0.75），避免错误引导用户（如将 “安卓充电问题” 的知识用于苹果手机）。 ◦ 召回数量：简单问题（如 “如何查物流”）召回 2 3 个片段即可，复杂问题（如 “系统报错 502 且无法重启”）需召回 5 8 个，确保覆盖完整解决方案。 知识图谱（实体关系密集型知识检索） 适用于包含大量实体关系的知识（如产品型号 故障 解决方案、用户等级 权益对应关系），通过实体关联快速定位相关知识。 • 客服场景应用：用户问 “我的 VIP 会员为什么不能用优惠券？”，知识图谱中存储 “VIP 会员 可使用优惠券类型 限制条件” 的关系（如 “VIP1 级可用于满 100 减 10，不可用于特价商品”），系统可直接通过实体 “VIP 会员”“优惠券” 的关系，召回对应的限制条件，避免遗漏规则细节。 三、系统主流程：从 “问题输入” 到 “答案输出” 的全链路设计 系统主流程需结合客服场景的业务逻辑（如响应速度、合规性要求），设计 “大模型生成” 与 “业务流程” 的结合方式，确保输出符合客服场景的效率与规范。 直接使用大模型生成：快速响应 “标准化问题” 适用场景：用户问题简单、知识库中存在明确答案（如 FAQ 中的 “查询订单步骤”“修改收货地址方法”）。 • 流程：用户提问→系统检索相关索引片段→将片段与问题一起输入大模型→大模型按 “简洁、步骤清晰” 的 prompt 生成答案。 • 示例：用户问 “怎么取消订单？”，系统召回 “取消订单步骤” 的索引片段，prompt 设置为 “用 1、2、3 步骤说明取消订单的操作，每步不超过 20 字”，大模型直接输出：“1. 打开我的订单；2. 找到对应订单点取消；3. 确认取消原因即可。” 基于业务逻辑构建 workflow+prompt：处理 “复杂 / 合规性要求高” 的问题 适用场景：用户问题涉及多步骤流程（如投诉处理）、合规性要求（如法律条款、政策说明）或需跨知识源整合（如结合订单数据 + 售后规则）。 • 流程设计：按业务逻辑拆分步骤，每个步骤调用对应知识或工具，再通过 prompt 引导大模型按步骤生成答案。 ◦ 示例 1（投诉处理流程）： i. 调用用户信息接口获取 “用户历史投诉记录”（判断是否重复投诉）； ii. 检索 “投诉处理规则”（如 “首次投诉 24 小时内响应”）； iii. 结合用户问题（如 “物流延迟 5 天”），调用 “物流延迟补偿政策” 的索引片段； iv. prompt 设置为 “先安抚用户（参考‘投诉话术库’第 2 条），说明处理时效（24 小时内），告知补偿方案（延迟 5 天可获 10 元券）”，大模型按步骤输出合规且完整的回复。 ◦ 示例 2（合规性要求高的场景）： 对政府机关、法律类客服场景，需严格按知识库原文输出（如 “退款政策” 一字不差），workflow 中加入 “合规校验节点”，大模型生成后，自动比对输出与知识库原文的一致性，确保无篡改。 ◦ 示例 1（投诉处理流程）： i. 调用用户信息接口获取 “用户历史投诉记录”（判断是否重复投诉）； ii. 检索 “投诉处理规则”（如 “首次投诉 24 小时内响应”）； iii. 结合用户问题（如 “物流延迟 5 天”），调用 “物流延迟补偿政策” 的索引片段； iv. prompt 设置为 “先安抚用户（参考‘投诉话术库’第 2 条），说明处理时效（24 小时内），告知补偿方案（延迟 5 天可获 10 元券）”，大模型按步骤输出合规且完整的回复。 i. 调用用户信息接口获取 “用户历史投诉记录”（判断是否重复投诉）； ii. 检索 “投诉处理规则”（如 “首次投诉 24 小时内响应”）； iii. 结合用户问题（如 “物流延迟 5 天”），调用 “物流延迟补偿政策” 的索引片段； iv. prompt 设置为 “先安抚用户（参考‘投诉话术库’第 2 条），说明处理时效（24 小时内），告知补偿方案（延迟 5 天可获 10 元券）”，大模型按步骤输出合规且完整的回复。 ◦ 示例 2（合规性要求高的场景）： 对政府机关、法律类客服场景，需严格按知识库原文输出（如 “退款政策” 一字不差），workflow 中加入 “合规校验节点”，大模型生成后，自动比对输出与知识库原文的一致性，确保无篡改。 总结 😀 客服场景的 RAG 系统搭建需围绕 “精准、高效、合规” 三个核心：索引构建需根据知识库类型（结构化 / 非结构化、简单 / 复杂）选择切分方法，召回策略需结合向量检索与业务标签提升精准度，系统主流程需匹配问题复杂度（简单问题直接生成，复杂问题按业务流程分步处理）。通过全链路的精细化设计，才能让 RAG 系统真正成为客服场景的 “智能助手”，既提升响应效率，又保证回答质量。 客服场景的 RAG 系统搭建需围绕 “精准、高效、合规” 三个核心：索引构建需根据知识库类型（结构化 / 非结构化、简单 / 复杂）选择切分方法，召回策略需结合向量检索与业务标签提升精准度，系统主流程需匹配问题复杂度（简单问题直接生成，复杂问题按业务流程分步处理）。通过全链路的精细化设计，才能让 RAG 系统真正成为客服场景的 “智能助手”，既提升响应效率，又保证回答质量。 三、数据收集与反馈 RAG 的构建实战（客服场景）：数据收集与数据库构建 😀 数据是 RAG 系统的 “基石”，客服场景的知识库质量、用户需求理解精度直接依赖于数据的完整性与针对性。本节聚焦 “数据收集”“数据库结构设计”“数据场景化分析”“回答效果评估” 及 “用户真实需求提取”，为客服场景 RAG 系统提供数据层的实战指南。 数据是 RAG 系统的 “基石”，客服场景的知识库质量、用户需求理解精度直接依赖于数据的完整性与针对性。本节聚焦 “数据收集”“数据库结构设计”“数据场景化分析”“回答效果评估” 及 “用户真实需求提取”，为客服场景 RAG 系统提供数据层的实战指南。 一、数据收集：明确来源与核心内容 客服场景的数据收集需覆盖 “知识库原始素材”“用户交互记录”“业务规则文档” 三类核心数据，确保后续数据库既能支撑基础问答，又能适配真实业务场景。 1. 核心数据来源 1. 知识库原始素材（静态数据） ◦ 产品相关：说明书（如家电操作步骤、软件功能说明）、参数表（如手机配置、保修期限）、常见问题 FAQ（如 “如何连接 WiFi”“退款条件”）。 ◦ 业务流程：售后故障处理手册（如 “系统报错代码 502 排查步骤”）、物流规则（如 “配送时效、延迟赔付标准”）、投诉处理规范（如 “投诉响应时效、升级流程”）。 ◦ 合规性文档：法律条款（如用户协议中 “隐私权限说明”）、企业对外话术（如 “客服禁用语”“官方承诺话术”）。 ◦ 产品相关：说明书（如家电操作步骤、软件功能说明）、参数表（如手机配置、保修期限）、常见问题 FAQ（如 “如何连接 WiFi”“退款条件”）。 ◦ 业务流程：售后故障处理手册（如 “系统报错代码 502 排查步骤”）、物流规则（如 “配送时效、延迟赔付标准”）、投诉处理规范（如 “投诉响应时效、升级流程”）。 ◦ 合规性文档：法律条款（如用户协议中 “隐私权限说明”）、企业对外话术（如 “客服禁用语”“官方承诺话术”）。 2. 用户交互记录（动态数据） ◦ 历史对话：用户与人工客服的聊天记录（如 “我买的冰箱不制冷了，怎么办？”“订单显示已发货但查不到物流”）、用户与旧系统的问答记录。 ◦ 行为数据：用户咨询的时间（如 “夜间 22 点后咨询物流问题较多”）、咨询渠道（APP / 小程序 / 电话）、问题类型分布（如 “售后故障占比 40%，物流查询占 30%”）。 ◦ 历史对话：用户与人工客服的聊天记录（如 “我买的冰箱不制冷了，怎么办？”“订单显示已发货但查不到物流”）、用户与旧系统的问答记录。 ◦ 行为数据：用户咨询的时间（如 “夜间 22 点后咨询物流问题较多”）、咨询渠道（APP / 小程序 / 电话）、问题类型分布（如 “售后故障占比 40%，物流查询占 30%”）。 3. 业务规则补充（支撑数据） ◦ 内部业务逻辑：如 “VIP 用户投诉优先处理”“新用户首单退款无需审核” 等规则，需转化为结构化数据存入数据库，用于后续 workflow 判断。 ◦ 内部业务逻辑：如 “VIP 用户投诉优先处理”“新用户首单退款无需审核” 等规则，需转化为结构化数据存入数据库，用于后续 workflow 判断。 2. 数据筛选原则 客服场景数据需满足 “精准、简洁、场景化”： • 剔除冗余信息：如产品说明书中与用户无关的 “生产工艺细节”（用户仅关心操作步骤）。 • 保留关键场景数据：如物流场景中 “暴雨天气配送延迟的特殊处理规则”（高频真实场景）。 • 标注时效性：如 “2025 年退款政策” 需明确时间，避免用过期规则回答用户。 二、数据场景化分析：针对性优化知识库 客服场景的需求差异显著（如 “物流查询” vs “售后投诉”），需按场景拆解数据特征，为索引构建、召回策略提供依据。 1. 按场景划分数据特征 1. 物流查询场景 ◦ 数据特点：用户问题多含 “物流”“快递”“发货” 等关键词，核心信息为 “订单号”“物流状态”“延迟原因”；知识库数据以 “物流流程”“延迟处理规则” 为主。 ◦ 分析结论：索引切分优先用 “标记符式”（按 “订单状态 处理步骤” 拆分），召回时增加 “订单号” 等实体过滤（结合知识图谱）。 ◦ 数据特点：用户问题多含 “物流”“快递”“发货” 等关键词，核心信息为 “订单号”“物流状态”“延迟原因”；知识库数据以 “物流流程”“延迟处理规则” 为主。 ◦ 分析结论：索引切分优先用 “标记符式”（按 “订单状态 处理步骤” 拆分），召回时增加 “订单号” 等实体过滤（结合知识图谱）。 2. 售后故障场景 ◦ 数据特点：用户问题常含 “故障”“报错”“不工作” 等描述，可能附带 “错误代码”“设备型号”；知识库数据以 “故障现象 排查步骤 解决方案” 为主，逻辑链严密。 ◦ 分析结论：索引切分需用 “语义式”（确保 “现象 步骤 方案” 完整），召回时提高相似度阈值（避免错误匹配不同型号的故障处理步骤）。 ◦ 数据特点：用户问题常含 “故障”“报错”“不工作” 等描述，可能附带 “错误代码”“设备型号”；知识库数据以 “故障现象 排查步骤 解决方案” 为主，逻辑链严密。 ◦ 分析结论：索引切分需用 “语义式”（确保 “现象 步骤 方案” 完整），召回时提高相似度阈值（避免错误匹配不同型号的故障处理步骤）。 3. 投诉建议场景 ◦ 数据特点：用户情绪倾向明显（如 “愤怒”“不满”），真实需求可能包含 “道歉”“补偿”“改进建议”；知识库数据以 “投诉处理规范”“赔付政策” 为主，需兼顾合规性与情感安抚。 ◦ 分析结论：索引需添加 “情感标签”（如 “安抚话术”“赔付标准”），回答流程中优先调用 “情感安抚” 相关片段（结合 workflow）。 ◦ 数据特点：用户情绪倾向明显（如 “愤怒”“不满”），真实需求可能包含 “道歉”“补偿”“改进建议”；知识库数据以 “投诉处理规范”“赔付政策” 为主，需兼顾合规性与情感安抚。 ◦ 分析结论：索引需添加 “情感标签”（如 “安抚话术”“赔付标准”），回答流程中优先调用 “情感安抚” 相关片段（结合 workflow）。 2. 数据分布分析 通过统计各场景的问题占比、高频关键词、未解决问题类型，指导知识库补充： • 例：若 “物流延迟” 问题占比 30%，但知识库中 “延迟赔付规则” 的片段不足，则需补充该类数据； • 若 “老年用户” 对 “步骤类回答” 的解决率仅 60%（低于平均 80%），则需优化该群体的索引切分（如将步骤拆分为更简单的短句）。 三、回答效果打标：量化评估与系统优化 对系统生成的回答进