客服质检
作者：Ai Flowi · 发布于
客服质检是依据明确标准，对客服互动进行可重复的审核。建立评分标准，据此检查已有对话，并记录每项判断背后的证据。如果 AI 提出分数或标签，应由人工审核人员确认结果，再将其用于辅导或服务决策。
本指南重点介绍对话记录质检和聊天机器人回答验证。设置与培训服务涵盖客服用例的范围界定；下方工作流增加审核数据集、证据字段和可重复使用的回归用例。
1. 明确当前队列的质量标准
选择能从对话中观察到的标准。可以审核回复对政策的表述是否正确、后续步骤是否相关、是否保护隐私，以及是否明确表示已理解客户诉求。除非有独立证据，否则友善回复不能证明“客户非常满意”。应区分沟通质量与最终业务结果。
为每项标准设置 pass、fail 和 not_assessable 状态。缺少记录不能证明某项操作做得不好，礼貌措辞也不能证明操作已完成。审核第一份对话记录前，先写明各状态需要的最低证据。
在小屏幕上，可在支持聚焦的横向滚动区域内移动评分表，对比各项标准与证据可能不足的原因。
| 标准 | 需要检查的证据 | 判定为 not_assessable 的原因 |
|---|---|---|
| 事实准确性 | 将回复中的陈述与所提供的案例记录核对。 | 无法取得账户或交易记录。 |
| 政策依据 | 适用的政策版本及其支持的句子。 | 审核资料包未包含相关政策。 |
| 后续步骤清晰度 | 明确的下一步行动及负责角色。 | 对话在讨论后续步骤之前结束。 |
| 隐私处理 | 回复是否不必要地索取或泄露敏感细节。 | 所提供的摘录未包含相关交流。 |
| 升级处理判断 | 将已观察到的问题与已批准的升级处理条件比较。 | 缺少升级处理政策或后续交接记录。 |
将严重不合格项单独记录，不要只放在综合评分中。否则，平均值可能让多项表达风格检查的合格结果掩盖一项严重且缺乏依据的承诺。如果选择权重，应将其记录为团队规则，并在应用前审核结果是否有用。
相关内容：AI 客户分群。
2. 整理可追溯的审核资料包
使用您获准处理的已有对话记录。保留 conversation_id、消息顺序、说话者角色、policy_version 和相关案例证据。移除不必要的个人标识符，同时保留足以作出质检判断的上下文。完整原件的访问权限应比审核摘要更严格。
从不同问题类型和结果中选取样本，不要只审核简单案例。在质检报告中说明选样规则，让读者了解覆盖范围。因包含投诉而选出的样本，不能衡量所有对话的整体质量。
即使当前回复看起来有误，也应保留。编码前修改对话记录，会移除说明质检结论所需的证据。修正后的措辞应放在独立的 suggested_revision 字段中。
相关内容：数据质量指标：衡量缺陷，不臆测缺失事实。
3. 配置一轮审核
示例配置，并非测试记录
输入包括获准使用的对话导出数据、已批准的评分标准和相关政策文本。如果数据量或敏感性使自动建议没有必要，人工依据评分标准审核可能已足够。
如需依据评分标准生成评估建议，请使用您的服务提供方账户和 API 密钥完成认证，另行承担费用，并按照 Language Model 参考进行设置。
| 组件 | 需要设置的组件目录输入 | 声明的输出与检查事项 |
|---|---|---|
| Load CSV | 将 csv_file 设为准备好的质检导出文件。 | data_list：JSON；检查加载后多行对话文本和标识符是否完整保留。 |
| Data → DataFrame | 将已检查的来源对象连接到 data_list。 | dataframe：Table；使用按行调用模型的方式前，检查每行是否包含一份完整审核资料包。 |
| Batch Run | 在 column_name 中选择 review_packet，并通过 df 传入对话 Table。将 system_message 设为“仅依据所提供的证据对照评分标准评估；引用消息标识符；证据缺失时使用 not_assessable”。通过 output_column_name 将新字段命名为 qa_suggestion。必需输入 model 连接到 Language Model 的 model_output。 | batch_results 中的 Table 保存按行生成的建议；评定某项标准是否满足前，检查每项 conversation_id 关联和引用的消息。 |
| Structured Output | 进行独立的单次对话试验时，input_value 包含审核资料包，system_prompt 包含评分标准。在 schema_name 中将此结构命名为 service_qa。将模式 Table 传入 output_schema 前，先检查其中包含 criterion、suggested_state、evidence_message_ids、reason 和 suggested_revision。将必需端口 model 连接到 Language Model 的 model_output。 | 检查 structured_output 中的各项标准评估结果的 JSON 是否使用允许的状态并附有支持判断的消息标识符。对应的 dataframe_output Table 是审核视图，并非已接受的质检结论。 |
对于导出的 Batch Run 和 Structured Output 接口，应先检查组件目录，再选择按行试验或单资料包试验。
4. 用人工标注的对话校准
让审核人员在不依赖模型建议的情况下，对同一组对话进行编码。逐项讨论标准上的分歧，尤其是将“不正确”与“缺乏证据”混淆的情况。更新评分标准，明确边界，并保留旧版本，确保历史结果仍可理解。
随后将模型建议与这些标签比较。记录误判为通过、误判为不通过、缺失引用和无效输出状态。仅有总体一致率，可能掩盖模型未能发现团队关注的具体隐私或政策错误。
保留模糊案例供讨论。审核过程应揭示不确定性，而非根据不完整对话生成看似精确的分数。任何会影响员工的质检结论，都必须由获授权的审核人员批准。
5. 保留聊天机器人回归用例集
使用回复模板测试用例作为回归审核的输入集。
为每个用例保存 case_id、input_revision、rubric_version、模型选择、提示词版本，以及每项标准的预期状态。将所提供的政策资料包与输入一起冻结，避免来源变化被误当作模型结果变化。将各项标准的实际判定状态和证据标识符记录在独立运行记录中；保留分歧用于校准。
修改提示词、模型或政策资料包后，重新运行相同用例。比较证据处理和禁止作出的承诺，而非只比较语言流畅度。模型回复可能听起来更好，却悄然漏掉必需的例外或披露内容。
6. 比较不同评分标准版本中的同一项标准
在一个模拟审核资料包中，回复解释了退款政策，并指出正在调查请求的团队，但缺少付款记录。依据要求交易证据的评分标准，付款完成应为 not_assessable；如果已有政策支持该解释，政策依据仍可判定为 pass。这是两项独立判断。仅因缺少一个来源就将整条回复判为不合格，会丢失评分标准原本要保留的区别。
如果修订后的评分标准将缺乏依据的付款声明归为严重不合格项，应同时保留新旧标准定义。在同一组冻结资料包上比较运行结果，并明确结果变化来自规则、来源证据，还是模型建议。不要把更严格评分标准带来的新增的不合格项，表述为经测量证实的员工表现下降。
7. 如何报告质检结论与限制？
将质检结论保存在登记表中，关联对话、标准状态、证据片段、评分标准版本和审核人员决策。归纳反复出现的不合格项，并说明其发生范围及建议修正。为每项修正关联一个后续用例，用于发现问题是否仍然存在。
使用持续维护的回复模板应用已批准的措辞修改，并通过客户反馈分析检查反复出现的体验主题。配置细节请查阅组件目录和用例参考。不要将生成的质检标签用于自动员工排名，也不要把它们当作今后每个回答都会正确的证明。
证据状态与节点用量
此客服质检方案已在组件目录中说明；未经 Ai Flowi 生产环境测试。
套餐：Go 年付方案每月 USD8 起（月付 USD10），Plus 年付方案每月 USD16 起（月付 USD20），Pro 100 年付方案每月 USD80 起（月付 USD100），Pro 200 年付方案每月 USD160 起（月付 USD200），Pro 500 年付方案每月 USD400 起（月付 USD500），每月包含 5,000 至 250,000 个 Flowi Tokens，并支持充值；每次节点运行消耗 1 个 token；不包含第三方 API 和模型使用费用。