智能客服【评测体系】怎么搭：三层框架、四个坑、一份Day 1清单

凌青 · 人人都是产品经理 · 2026-08-11

核心观点

1. 评测跑分和业务效果是两套互不打通的账本：亚马逊 MARCO 客服系统论文评测准确率 94.48%，但无法回答”客户问题解决率是多少”。整个行业的通病是只测了第一层（模型质量），忽略了任务完成层和业务指标层。

2. “好不好用”是三个不同的问题，必须在各自那一层测量：模型质量层（答得对不对，如意图识别准确率、答案准确率、幻觉率）、任务完成层（问题解决了没有，如 FCR 首次解决率、72 小时重联系率）、业务指标层（业务变好了没有，如解决率、转人工率、客服成本、复购留存）。拿着第一层的跑分回答第三层的质询，是智能客服项目最常见的翻车原因。

3. 三种架构对应三套考卷和三层天花板：能回答阶段（FAQ 问答）→ 解决率天花板 20%-40%，北极星是答案准确率；能解决阶段（路由+诊断）→ 天花板 40%-60%，北极星是 FCR 和验证解决率；能代办阶段（API 闭环执行）→ 天花板 70%-85%，北极星是 GCR 目标完成率。架构每升一级，北极星就往”结果”方向挪一步：从答得对不对 → 问题解决没解决 → 事情办成没办成。

4. 拦截率正在被淘汰，因为它区分不了”问题被解决”和”客户被挡走”：被机器人绕了五轮、烦得直接关掉对话的客户，和问题真被解决的客户，在拦截率的分子里长得一模一样。行业风向正在从 deflection（拦截）转向 resolution（解决），Helply 等厂商推荐用验证解决率 + 72 小时重联系率取代拦截率。

5. LLM 法官 + 人工抽检校准的混合评测流水线：用 LLM-as-a-Judge 全量覆盖每一段对话，Instacart LACE 框架按精度要求分三档；法官本身要定期年检（Kappa 下降时先调评分标准而非模型）；评测需多次重复（Sierra τ-bench：GPT-4o 单次通过率 61%，连跑 8 次每次都做对的概率不到 25%）；必须有会话级指标（逐轮全对、整段无用是最常见的失败模式，逐轮打分对这种失败完全失明）。

6. 评测体系是 Day 1 埋的，不是上线后补的：三阶段实操清单——埋点清单（基础埋点 → 解决质量埋点 → 操作执行埋点按架构阶段分层启用）、节奏清单（上线前记基线、前 90 天早期预警、4-6 月混合对比、满一年全面 ROI 评估）。最关键的一条：上线前把人工客服的基线（平均处理时长、首次解决率、满意度、单次服务成本）记下来，因为”没有 AI 的时候什么样”这个状态上线那天就消失了。

7. 对标的四个坑：① 解决率口径没有行业标准（三种算法能差出二十个点，必须先问分母/判定者/观察窗口）；② 标杆案例几乎都是自报数据（网易云商 90%、一汽丰田八成都是厂商/甲方自报，无第三方统一口径审计）；③ 跨行业对标等于自欺（电商零售解决率 70%-84% 头部 93%，电信 40%-60%，差距来自问题复杂度和数据开放度而非团队能力）；④ CSAT 天生有抽样偏差（愿意填的只有特别满意和特别愤怒的两端，行为信号如重联系率和会话中途放弃率更可靠）。

实操内容保留

Day 1 埋点清单（按架构三层分层启用）

第一层：基础埋点（系统上线即必须有）

• 会话 ID 和时间戳
• 用户消息原文
• AI 响应原文
• 意图识别结果和置信度
• 响应延迟
• 是否转人工及触发原因
• 用户满意度评价
• 会话轮次数

第二层：解决质量埋点（进入”能解决”阶段追加）

• Agent 路由路径（问题经过了哪些 Agent）
• 函数调用记录（调了什么接口、参数和返回值）
• 护栏触发记录（哪道护栏拦了什么、重试结果如何）
• 重联系标记（同一客户 24 和 72 小时内是否为同一问题再次进线）

第三层：操作执行埋点（进入”能代办”阶段启用）

• 操作执行结果
• 操作前后的业务状态快照
• 回滚记录
• 用户确认记录

四阶段评测节奏清单

1. 上线前：先把人工客服基线钉死（平均处理时长、首次解决率、满意度、单次服务成本）
2. 前 90 天（早期预警期）：重点盯转人工率、答案准确性和置信度分布
3. 4-6 个月：混合对比——拿 AI+人工整体指标和上线前基线比
4. 满一年：全面评估——成本、解决率、留存、复购、客诉率关联算完整 ROI

LLM-as-a-Judge 评判流水线关键要点

• 打分分档：Instacart LACE 框架按精度要求分三档，档位越高越贵也越准
• 会话级指标：逐轮打分外必须加工整段会话为单位的指标（DeepEval 已内置）
• 多次重复：同一套考题跑多次看均值和稳定性（MARCO 每个实验重复 5 次报均值和标准差）
• 人工年检：定期抽样让人工重打一遍做校准，抽样时别让人看到 LLM 给的分

对标口径三连问

对任何”解决率”数字，先问：

1. 分母是什么（全部进线还是只算 AI 接待的）
2. 谁判定的解决（系统推断、客户确认还是行为信号）
3. 观察窗口多长（会话结束就算数，还是等 72 小时）

原文精彩摘录

跑分很高、用户在骂，几乎每个 AI 客服团队都会撞上这种拧巴。根源是一个被普遍跳过的问题：“好不好用”从来不是一个数，而是三层不同的数。只测第一层，剩下两层就永远是一笔糊涂账。

拦截率的定义是没有转人工的会话占比，它曾经是整个行业的北极星。但这个指标有个天生的毛病：它区分不了”问题被解决了”和”客户被挡走了”。被机器人绕了五轮、烦得直接关掉对话的客户，和问题真被解决的客户，在拦截率的分子里长得一模一样。

四个坑总结成一句话：对标之前先对口径，口径对不上的数字，多好看都是别人家的。

老板那句追问其实是对的，它只是来得比我的评测体系早。评测体系的价值，不是让汇报变好看，而是让你比老板先知道真相。

关键概念

• 智能客服 — 核心实体，补充评测体系部分
• AI评估计分板 — 三层评测框架是其客服场景的具体落地
• Golden Set — 新增”考题来源”和”评测重复性”细节
• LLM-as-a-Judge — 新增 LACE 三档方法、会话级指标、人工年检校准
• 拦截率 — 本文对其系统性批判，解释为何行业从 deflection 转向 resolution
• FCR（首次解决率）— 能解决阶段的北极星指标
• GCR（目标完成率）— 能代办阶段的北极星指标
• CSAT — 天生抽样偏差问题，行为信号更可靠

与其他素材的关联

• 本文是凌青智能客服系列的第三篇，前两篇分别讲了架构（“能干什么”）和护栏（“怎么不出事”），对应 2026-05-26-智能客服MVP三件事 和 2026-08-05-agent-cs-guardrails
• 三层评测框架与 AI评估计分板 的 R-U-B 模型异曲同工——模型质量层 ≈ R，任务完成层 ≈ U+B，业务指标层 ≈ B；本文把这种”分层评测”思想在客服场景做了最完整的落地
• LLM-as-a-Judge 的校准机制与 LLM-as-a-Judge 已有内容互补：本文贡献了 LACE 三档方法、Kappa 下降时”先调评分标准而非模型”、以及 Sierra τ-bench 的 pass^k 稳定性指标
• 对标四坑中的”跨行业不能对标”与 AI竞品分析 中”自建评测集三原则”形成方法论互补