客服 Agent 优秀测评方案

客服 Agent 优秀测评方案

核心结论

客服 Agent 的测评不应只看“回答像不像”或“有没有转人工”，而要证明：用户问题真的被解决、该转人工时能及时转人工、体验不变差、成本可控、版本升级不退化。

一个成熟方案应采用三层闭环：

  1. 离线 eval：用真实客服任务构建 Golden Set，按 Task / Trial / Grader / Transcript / Outcome 评估。
  2. 灰度与线上监控：跟踪解决率、转人工质量、CSAT、重复联系、成本、延迟和安全事件。
  3. Eval-Driven Development：把线上 bug、投诉、人工接管 bad case 持续转成回归 eval。

本方案综合了我本地知识库中两类笔记：一类是 Agent 测评通用方法，另一类是 AI Agent eval 工程指南。为了方便公开阅读，文中的本地引用已整理为可理解的概念说明：Transcript（完整对话与工具调用记录）用来解释过程，Outcome（外部系统状态与任务结果）用来判定事实。

一、指标体系：四层评价，不迷信单一解决率

1. 结果层：是否真的解决问题

指标 定义 说明
Verified Resolution Rate 用户确认解决 + 后端状态验证成功 + 短期无重复联系 客服 Agent 的主指标，比单纯“未转人工”更可靠
Resolution Rate / 自动解决率 AI 参与会话中最终被确认或推断为解决的比例 Microsoft 与 Zendesk 都将 resolution rate 作为核心结果指标
First Contact Resolution, FCR 首次接触即解决，且短期内没有再次联系 防止表面解决
Re-contact Rate 7 天内同一问题再次联系比例 衡量“假解决”的反指标
Outcome State Check 工单、退款、订单、账户状态是否真实变化 对有副作用任务必须检查外部系统状态

Microsoft Copilot Studio 将 resolution rate 定义为 engaged sessions 中 resolved outcome 的比例；Zendesk AI metrics 也将 resolution rate 定义为 resolved conversations / all conversations。见 Microsoft 指标参考与 Zendesk AI 指标文档：https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/agent-business-value-metrics-reference、https://support.zendesk.com/hc/en-us/articles/6961660060186-Metrics-and-attributes-for-Zendesk-AI。

2. 分流层：该自助时自助，该转人工时转人工

指标 定义 说明
Escalation / Handoff Rate 会话被转给人工的比例 不能简单越低越好
Deflection / Containment Rate 原本可能进入人工的问题被 AI 自助解决的比例 必须与 verified resolution 同看
Correct Handoff Rate 应该转人工的 case 是否及时转人工 高风险客服场景的硬门槛
Abandon Rate 用户未解决、未转人工就离开 静默失败信号
False Deflection Rate Agent 拦住用户但没有真正解决 需要重点压低

优秀客服 Agent 不是追求最低转人工率，而是追求：低错误自助 + 高正确转人工 + 低静默流失。

Intercom Fin AI Agent 文档也区分 resolution、confirmed resolution、assumed resolution、escalated rate 与 deflection rate，说明“解决”和“未升级”不能混为一谈：https://www.intercom.com/help/en/articles/7022438-reporting-metrics-attributes。

3. 体验层：用户是否感到被理解和帮助

指标 评价方式
CSAT 会话后满意度评分
Tone / Empathy LLM Judge 或人工按 rubric 评估礼貌、共情、不推责
Clarity 回答是否清楚，步骤是否可执行
Trust / Confidence 用户是否愿意按 Agent 建议行动
Sentiment 负面情绪比例，尤其是“已解决但负面”的会话

Microsoft 指标库将 CSAT、thumbs up/down reactions、sentiment、themes、customer-experience narrative 都列为 Voice-of-Customer 信号。Intercom 与 Zendesk 也提供 AI conversation CSAT / satisfaction score。相关来源：https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/agent-business-value-metrics-reference、https://www.intercom.com/help/en/articles/8368157-analyze-and-report-on-fin-ai-agent-csat、https://support.zendesk.com/hc/en-us/articles/6961660060186-Metrics-and-attributes-for-Zendesk-AI。

4. 工程层：成本、延迟、稳定性、安全

指标 用途
p50 / p95 / p99 latency 客服体验强依赖响应速度，尾延迟尤其重要
Average Handle Time, AHT 从 session 开始到 resolution 的耗时
First Reply Time / Full Resolution Time 首次回复与完整解决耗时
Cost per Verified Resolution 单次已验证解决的模型、工具、人工复核成本
Tool Success Rate 查订单、退款、改地址、建工单等工具是否成功
Policy Violation Rate 是否错误承诺退款、泄露隐私、编造政策
Human Takeover Quality 转人工摘要是否完整，是否减少人工重复询问

生产中必须保留 Agent Event Log（事件日志）：用户输入、模型输出、工具调用、工具结果、转人工、错误与恢复事件都应可回放。它的作用不是替代最终结果判断，而是支持失败归因、审计和回归测试。

二、Golden Set：客服 Agent 至少覆盖 6 类任务

类型 示例 评估重点
高频简单问题 退货政策、物流查询、发票开具 快速准确、自助解决
需要工具的问题 查订单、改地址、取消订阅、退款状态 工具选择、参数正确、后端状态一致
多轮澄清问题 “我的东西还没到”但缺订单号 槽位追问、少问废话
必须转人工的问题 投诉、法律风险、VIP 客户、复杂账单 正确升级，不强行自动化
对抗 / 越权问题 查看他人订单、诱导泄露隐私、套取内部政策 安全拒绝、权限边界
情绪化用户 愤怒、焦虑、讽刺、重复抱怨 同理心、安抚、解决路径

一个 eval task 应包含初始状态、用户目标、成功标准、失败条件，而不是只有一句 prompt：

task:
  id: refund-delay-003
  user_profile: existing_customer_vip
  initial_state:
    order_status: delivered
    refund_status: pending_7_days
    policy: refund_should_complete_within_5_days
  user_goal: 了解退款为何未到账并获得处理方案
  success_criteria:
    - 正确识别退款超时
    - 查询退款工具参数正确
    - 给出真实状态，不编造到账时间
    - 必要时创建人工工单
    - 用户收到 case id
  fail_conditions:
    - 承诺无法保证的到账时间
    - 要求用户重复提供系统已有信息
    - 未解释下一步
    - 未转人工且问题未解决

这里的关键是把“客服对话”改写成可重复运行的 eval task：不仅写用户会怎么问，还要写清初始状态、用户目标、成功标准、失败条件和 expected outcome（预期结果）。

三、Grader：混合 code-based、model-based、human

Grader（评测器）建议分成三类组合使用：

  • code-based grader：用程序检查事实，例如订单状态是否改变、退款工单是否创建、是否发生越权操作；
  • model-based grader：用另一个模型按 rubric 判断开放式质量，例如共情、清晰度、是否违反政策；
  • human grader：人工抽检，用来校准模型评审并处理高风险样本。

客服 Agent 不应只依赖 LLM Judge，而应把事实性 outcome 交给程序或后端状态检查，把表达质量交给模型或人工。

graders:
  - name: outcome_resolution
    type: code-based
    required: true
    checks:
      - ticket_created_or_closed_correctly
      - order/refund/account_state_matches_expected
      - no_unauthorized_state_change

  - name: policy_compliance
    type: code-based + model-based
    required: true
    checks:
      - no_forbidden_refund_promise
      - no_privacy_leak
      - no_unsupported_policy_claim

  - name: handoff_correctness
    type: code-based + model-based
    required: true
    checks:
      - escalates_when_required
      - does_not_escalate_when_self_service_sufficient
      - handoff_summary_complete

  - name: conversation_quality
    type: model-based
    weight: 0.25
    rubric:
      - empathy
      - clarity
      - concision
      - next_step_actionability

  - name: efficiency
    type: code-based
    weight: 0.15
    metrics:
      - turns_to_resolution
      - tool_calls
      - latency
      - cost

  - name: human_audit
    type: human
    sampling_rate: 0.05

LLM Judge 设计要求

LLM Judge（用大模型做评审）适合评价开放式质量，但不能替代 outcome 验证。客服场景中，LLM Judge 应拆维度：

  • 只评估是否共情；
  • 只评估是否清楚说明下一步；
  • 只评估是否违反退款政策；
  • 只评估是否应该转人工。

推荐结构化输出：

{
  "verdict": "PASS | FAIL | INSUFFICIENT_INFO",
  "evidence": ["引用 transcript 中的具体句子"],
  "reason": "简短原因"
}

关键点是：单一维度、明确边界、证据要求、结构化输出、定期与人工标注校准。

四、运行方式：客服 Agent 更应看 pass^k

这里需要区分两类经常被混用的稳定性指标：

  • pass@k：运行 k 次，只要至少一次成功就算成功，适合“生成多个候选，再由人挑选”的场景。
  • pass^k：运行 k 次，每一次都必须成功才算成功，适合自动客服、支付、下单、内容审核等无人值守场景。

客服 Agent 属于生产自动化系统，因此 release gate 应优先看 pass^k。

场景 Trial 次数 关注指标
Prompt 快速验证 每 task 3 次 是否明显可用
Release gate 每 task 10 次 pass^10、失败类型分布
高风险任务 20+ 次 + 人审 稳定性、误转人工、越权风险

建议上线门槛：

  • 高频低风险问题：Verified Resolution Rate ≥ 85%；
  • 必须转人工场景：Correct Handoff Rate ≥ 98%；
  • 隐私、越权、政策红线：0 critical violation；
  • pass^10 达标，而不是只展示 pass@10；
  • p95 延迟、单次成本在预算内。

五、可参考 benchmark 与数据集

公开数据集只能做通用参考，最终仍需企业自有 Golden Set。

资源 用途
ABCD 10K+ 人类客服对话、55 intents，提出 Action State Tracking 与 Cascading Dialogue Success，适合评估客服流程和任务完成。https://aclanthology.org/2021.naacl-main.239/
EVA-Bench 企业语音 Agent benchmark，213 个场景，覆盖航空客服、医疗 HR、企业 ITSM，包含 task completion、faithfulness、conversation experience 等维度。https://huggingface.co/datasets/ServiceNow-AI/eva-bench
NatCS 更自然的客户支持对话数据，适合补足传统 task-oriented dataset 不够真实的问题。https://arxiv.org/abs/2305.03007
MAIA 关注客服对话质量与情绪维度。https://arxiv.org/abs/2311.13910

企业内部应优先把历史工单、人工客服优秀样本、投诉记录、转人工记录、退款/售后/账户高风险流程、线上失败 case 转成私有 Golden Set。这就是 Eval-Driven Development：每次线上失败都沉淀成回归测试，防止下一版再次犯同样错误。

六、线上监控 Dashboard

1. 业务结果

  • Verified Resolution Rate
  • FCR
  • Re-contact Rate
  • Refund / order / ticket outcome success
  • CSAT

2. 分流质量

  • Escalation Rate
  • Correct Handoff Rate
  • False Deflection Rate
  • Abandon Rate
  • Human agent “AI summary useful?” 评分

3. 体验质量

  • CSAT / DSAT
  • Negative sentiment
  • 用户 thumbs down / free-text feedback
  • 坏案例主题聚类

4. 工程效率

  • First reply time
  • Full resolution time
  • AHT
  • p95 / p99 latency
  • Cost per verified resolution
  • Tool error rate

5. 安全合规

  • 隐私泄露
  • 越权查询
  • 错误政策承诺
  • Prompt injection / jailbreak 命中
  • 高风险操作人工审批率

七、最终评分卡

硬门槛

门槛 要求
安全红线 0 个 critical privacy / policy violation
工具副作用 不允许错误退款、错误改订单、错误关闭工单
必须转人工 高风险场景正确转人工率 ≥ 98%
Outcome 验证 核心流程必须查后端状态，不只看回复
回归集 新版本不得降低关键 Golden Set 指标

加权得分

维度 权重
Verified Resolution 30%
Correct Handoff / Deflection 20%
Conversation Quality 15%
Policy / Groundedness 15%
Efficiency / Cost / Latency 10%
Human Agent Productivity 10%

版本迭代时可用 win rate（胜率） 比较新旧 prompt、模型或 workflow 的相对质量：让新旧版本在同一批任务上对比，由 grader 或人工判断哪个更好。但 win rate 只能衡量相对偏好，不能替代 outcome 验证。

八、最小落地路线

  1. 收集 100 条真实历史客服 case，覆盖 Top 20 高频问题、高风险问题、投诉问题。
  2. 写成结构化 eval task：初始状态、用户目标、成功标准、失败条件。
  3. 建立混合 grader：code-based 查状态和规则，LLM Judge 评体验，人工抽检校准。
  4. 每个 task 跑 3–10 次 trial，客服 Agent 重点看 pass^k。
  5. 读失败 transcript，归因到意图识别错、工具参数错、知识缺失、政策误解、该转人工没转等类别。
  6. 修复后进入 Golden Set。
  7. 上线灰度，监控 verified resolution、CSAT、re-contact、handoff correctness、cost、latency。
  8. 把线上投诉继续转 eval，形成 Eval-Driven Development 闭环。

相关概念说明

  • Agent evaluation：评估 Agent 是否完成任务，而不是只评估单轮回答质量。
  • AI Agent evaluation guide：把任务拆成 Task、Trial、Transcript、Grader、Outcome 的工程化测评方法。
  • Agent graders：用 code-based、model-based、human 三类评测器组合判断结果。
  • pass@k / pass^k：分别衡量“多次尝试至少一次成功”和“多次尝试每次都成功”。
  • Eval-Driven Development：把线上失败案例持续沉淀为回归 eval，用评测驱动迭代。
  • LLM Judge：用大模型按明确 rubric 评价开放式质量，但不能替代事实校验。
  • win rate：用同一批任务比较两个版本的相对表现。
  • Agent Event Log：记录对话、工具调用、转人工和错误恢复事件，便于回放与审计。
  • Agent production engineering：面向生产环境的延迟、成本、可靠性、监控和回归体系。
  • Intent routing：识别用户意图并路由到自助、工具调用或人工接管。

Sources

本地知识库参考

本文整合了我本地知识库中关于 Agent 测评、Agent eval 工程、评测器设计、pass@k / pass^k、Eval-Driven Development、LLM Judge、win rate、事件日志、生产工程与意图路由的系列笔记。为便于公开阅读，正文已将这些本地概念展开为解释性文字。

Web verification

posted @ 2026-07-05 15:22  crabin88  阅读(24)  评论(0)    收藏  举报