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

guozi

AI客服跑分高但用户骂声不断，根源在于评测体系只测了模型质量层，忽略了任务完成层和业务指标层。本文提出三层评测框架、Day 1 埋点清单及四个对标陷阱，教你如何把老板要的解决率、完成率报清楚，告别“跑分很高、用户投诉”的尴尬。



亚马逊的 MARCO 客服系统，在论文评测里跑出了 94.48% 的准确率。但你要是问：用它的客户，问题解决率是多少？论文答不了，因为压根没测。

这不是亚马逊的疏忽，是整个行业的通病：评测跑分和业务效果，是两套互不打通的账本。

我自己交过学费。AI 客服上线三个月，我在例会上报了拦截率 75%，老板只问了一句”客户的问题到底解决了没有”，我当场卡住。手里每个数字都是真的，但没有一个能回答这个问题，系统里根本没埋那个数。

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

这是智能客服系列的第三篇。前两篇讲了架构（它能干什么）和护栏（它怎么不出事），这一篇给你一套能落地的评测体系：三层评测框架、一份 Day 1 就要埋的数据清单、四个对标的坑。整篇只回答一个问题：怎么把老板要的那三个数报清楚。
一、好不好用其实是三个问题
先把话说透：当老板问”AI 客服好不好用”的时候，这句话里其实压着三个完全不同的问题。

第一个问题：它答得对不对？这是模型质量层。意图识别准了没有，答案跟知识库对不对得上，有没有一本正经地胡说八道。绝大多数团队的评测停在这一层，因为这一层最好测：拉一批测试问题，跑一遍，算个分。

第二个问题：客户的问题解决了没有？这是任务完成层。它跟第一个问题不是一回事：AI 可以每一句都答得对，但整段对话没有用。

第三个问题：业务变好了没有？这是业务指标层。解决率、转人工率、客服成本、复购留存，这些才是老板真正关心的东西，也是立项时写在 PPT 里的承诺。



三层之间不是递进关系那么简单，而是每一层的高分都不能保证下一层：开头那个跑出 94.48% 的 MARCO 答不了自己的解决率，句句答得对的对话也可能整段没用。所以评测体系的第一性问题不是”用什么指标”，而是：你想回答哪一层的问题，就必须在那一层测量。拿着第一层的跑分去回答第三层的质询，就是我在例会上翻车的原因。
二、测什么：指标跟着架构走
第一篇讲过智能客服的三种架构：能回答、能解决、能代办。现在可以补上当时没说的另一半：这不只是三种技术方案，也是三套完全不同的考卷。三套考卷的全景如下（各项基准的出处见文末参考资料），先看图，再逐段拆：



能回答阶段，考卷的核心是答案准确率。这个阶段系统的全部工作就是听懂问题、给出正确答案，所以盯三个数：意图识别准确率（听懂了没有）、答案准确率（答对了没有）、幻觉率（有没有编）。心理预期也要有：只做 FAQ 问答的系统，解决率天花板在 20% 到 40%，这是架构决定的，调参数调不上去。

能解决阶段，北极星换成首次解决率（FCR）和验证解决率。系统开始路由问题、查询后端、诊断原因，考核重点从”答得对”变成”一次搞定”。路由准确率是关键过程指标，Router 分错了，后面的专项 Agent 再强也白搭；还要加一个专查”假解决”的 72 小时重联系率，客户几天内又为同一件事回来，就说明上次没真解决。这个架构的天花板在 40% 到 60%。

能代办阶段，北极星是目标完成率（GCR）：事办成了没有。退款到账了吗，订单改了吗，服务开通了吗。配套盯解决持久性（办完 7 到 10 天客户没再回来，才算真办好）和单次解决成本（代办的经济账在这里算，AI 和人工的具体区间见上图）。天花板能到 70% 到 85%。

架构每升一级，北极星指标就往”结果”的方向挪一步，从答得对不对，到问题解决没解决，到事情办成没办成。评测体系最常见的错配就是考卷拿错了：系统已经升级到能代办，考核指标还停在答案准确率；或者反过来，系统只是个 FAQ 机器人，却背着”解决率 70%”的 KPI，那是下一代架构才够得着的数字。

最后说一个正在被淘汰的指标，也是我在开头那次例会上栽跟头的真正原因：拦截率。

拦截率的定义是没有转人工的会话占比，它曾经是整个行业的北极星。但这个指标有个天生的毛病：它区分不了”问题被解决了”和”客户被挡走了”。被机器人绕了五轮、烦得直接关掉对话的客户，和问题真被解决的客户，在拦截率的分子里长得一模一样。这也是为什么行业风向正在从 deflection（拦截）转向 resolution（解决），Helply 等厂商已经在推荐用”验证解决率”（经后续行为信号确认客户没有再回来的解决）搭配 72 小时重联系率，取代拦截率做核心考核指标。

我在例会上报出”拦截率 75%”时答不上老板的追问，不是数据不够多，是这个指标本身就回答不了”解决了没有”。选错北极星的评测体系，做得越认真，离真相越远。
三、怎么测：从人工抽检到 LLM 法官
测什么定了，下一步是怎么测。上一篇讲护栏时埋过一句话：同一套检测技术，在线拦截是护栏，离线批量跑历史对话就是评测。这条流水线一头进的是历史会话和新版本的输出，另一头要出一个敢拿去发版的结论，中间隔着四个问题：



四个问题有先后，也互相牵制：考题错了，后面打得再准也是白测；打分方式不对，分数越多反而越误导。

考题从哪来：先攒一套 Golden Set。Golden Set 是一组人工标注过标准答案的测试对话，整个评测体系的地基。来源有两块：

• 刻意构造的测试集：覆盖高频意图、边界情况、知识库管不到的域外问题（MARCO 的评测集就是域外查询、操作类、咨询类多轮对话的混合）
• 真实历史对话抽样标注：保证考题长得像真实客户说的话，而不是产品经理想象中客户会说的话


攒好之后三个用途：冷启动时定义什么叫好；版本迭代前后做回归对比；校准后面要说的自动评估。

谁来打分：LLM 法官，但要分档用。人工打分最准但又贵又慢，全量人工不现实，主流做法是让另一个大模型当法官（LLM-as-judge），全量覆盖每一段对话。打分方法最完整的公开方案是 Instacart 的 LACE 框架：按精度要求分三档，档位越高越贵也越准。选完机器怎么打，还有一件独立的事要定：这段会话要不要人来看。



法官本身要定期年检。LLM 打的分不能盲信，要定期抽一批会话让人工重打一遍做校准。抽样时别让打分的人看到 LLM 给的分，否则人会被带跑、校准就白做了。Kappa 掉下来的时候，回炉调的通常不是模型，是评分标准本身——标准写得太模糊，人和机器各理解各的。人工不是被 LLM 法官取代了，是从流水线工人升级成了质检科长。

按什么颗粒度打：必须有会话级指标。智能客服最常见的失败方式是逐轮全对、整段无用：AI 每句话单独看都答得对，客户的问题却原地没动，逐轮打分对这种失败完全失明。解法是在逐轮打分之外，再加一批以整段会话为单位的指标，开源评测框架 DeepEval 已经内置：

打几次才算数：一次不算数。大模型是概率系统，单次跑分带着运气成分。Sierra 的客服 Agent 基准 τ-bench 测出：GPT-4o 在零售客服任务上跑一次的通过率是 61%，同一批任务连跑 8 次、每次都做对的概率不到 25%。所以正经的评测要同一套考题跑多次，看均值也看稳定性（MARCO 每个实验重复 5 次，报均值和标准差）；版本迭代的回归测试尤其如此，跑一次就下”新版本更好”的结论，很可能只是抽了个好签。

那么最终我们用一张图总结一下这一套打分流水线：



这套东西听起来比护栏还重，值得吗？可以这么算账：护栏在线拦住的是一条条具体的事故，评测在离线回答的是更贵的问题，这个版本能不能上线，上线之后有没有变好。没有评测体系的迭代，每次发版都是在赌。
四、实操清单：评测体系是 Day 1 埋的，不是上线后补的
评测体系最贵的错误，是等到想评的时候才发现数据没埋。回到开头那次例会：我答不上”客户的问题到底解决了没有”，本质不是我没准备好，是系统里压根没有那个数。会话有没有在 72 小时内重来、客户是解决了还是放弃了，这些字段上线时没记，事后花多少钱都补不回来。

所以这一步，是一份抄走就能用的清单，分两部分：埋什么，什么节奏看。

埋点清单：跟着架构分三层，每层在对应阶段启用。

第一层是基础埋点，只要系统上线就必须有：会话 ID 和时间戳、用户消息原文、AI 响应原文、意图识别结果和置信度、响应延迟、是否转人工及触发原因、用户满意度评价、会话轮次数。这一层撑起答案准确率、转人工率和所有会话级指标的计算，少一个字段就瘸一个指标。

第二层是解决质量埋点，系统进入”能解决”阶段就要加上：Agent 路由路径（问题经过了哪些 Agent）、函数调用记录（调了什么接口、参数和返回值）、护栏触发记录（哪道护栏拦了什么、重试结果如何）、重联系标记（同一客户 24 和 72 小时内是否为同一问题再次进线）。注意重联系标记是算验证解决率的命根子，而它需要跨会话关联用户和问题，这个关联逻辑上线后再补最痛苦。

第三层是操作执行埋点，进入”能代办”阶段启用：操作执行结果、操作前后的业务状态快照、回滚记录、用户确认记录。这一层同时服务两个主人：评测体系用它算目标完成率，出了事故之后追责回溯也全靠它。



节奏清单：四个时间点，各看各的数。

上线前，先把基线钉死：人工客服现在的平均处理时长、首次解决率、满意度、单次服务成本，一个个记下来。这一步最容易被省略，但没有基线，一年后你就算不出 AI 到底带来了多少提升，ROI 汇报只能靠感觉。

前 90 天是早期预警期，重点盯转人工率、答案准确性和置信度分布，这个阶段的任务不是证明系统好，是尽快发现哪里不对。

4 到 6 个月做混合对比，拿 AI 加人工的整体指标和上线前基线比，回答”AI 到底有没有让整件事变好”。

满一年做全面评估，把成本、解决率和业务指标（留存、复购、客诉率）关联起来算完整 ROI，这是立项时那页 PPT 的最终对账。

如果只能记住一件事：上线前把基线记下来。埋点漏了还能补一部分，基线错过了就永远没有了，因为”没有 AI 的时候什么样”这个状态，上线那天就消失了。
五、对标的坑：别人家的 93% 和你没关系
选型会上供应商说”我们客户平均解决率 85%”，老板转发一篇文章问”人家做到 93%，我们为什么才 60%”。对标时最容易踩的坑有四个，每个都给破法。

坑一：解决率的口径没有行业标准，三种算法能差出二十个点。这是所有坑里最深的一个。同样叫”解决率”，有的厂商算”没转人工就算解决”（这其实是拦截率换了个名字），有的要客户明确确认问题解决，有的用”72 小时内没有再回来”当解决信号。三种口径宽严差距极大，同一批会话能算出差二十个点的”解决率”。破法是口径三连问：分母是什么（全部进线还是只算 AI 接待的），谁判定的解决（系统推断、客户确认还是行为信号），观察窗口多长（会话结束就算数，还是等 72 小时）。任何解决率数字，先问完这三问再决定要不要信。供应商答不上来或者含糊其辞的，这个数字直接作废。

坑二：标杆案例几乎都是自报数据。行业报道里的漂亮数字，绝大多数出自厂商或甲方自己之口，没有第三方审计。网易云商宣传的”机器人平均问题解决率 90%”，出处是极客公园对其九周年发布活动的报道；一汽丰田”独立解决率从三四成提到八成”，出自沙丘智库的最佳实践报告。这些数字都是公开报道、可以查证，但都没有第三方按统一口径审计过。不是说它们假，而是它们天然带着口径最宽松、场景最有利的滤镜。破法有两个：对外的数字只当方向参考，不当对标基线；选型时别看宣传页，要求供应商用你自己的历史对话数据跑 POC，用你的口径算给你看。

坑三：跨行业对标等于自欺。行业基准数据显示，AI 客服解决率电商零售能做到 70% 到 84%（头部品牌 93%），而电信只有 40% 到 60%，医疗保险也在 40% 到 60% 徘徊。差距不是因为电商团队更强，而是两个结构性因素：问题复杂度（退货改地址高度标准化，保险理赔高度个性化还压着合规）和数据开放度（电商的订单物流数据随便接，医疗数据动一下都要过合规）。拿电商的 93% 给医疗业务立 KPI，唯一的效果是逼着团队把口径改宽。破法：只对标同行业分位数，先按这两个因素给自己的业务定位，再看自己该在哪个区间。

坑四：CSAT 没有你以为的那么硬。满意度问卷天生有抽样偏差，愿意填的多是特别满意和特别愤怒的两端，中间沉默的大多数不出声。行业数据也打架：一个来源的统计说 92% 的企业报告引入 AI 后满意度提升了，另一个来源的基准却是 AI 处理的会话满意度通常比同团队的人工低 5 到 10 分（百分制）。两个都是真数据，但一个在问企业、一个在量会话，口径根本对不上。破法：CSAT 继续收，但只当参考项，别当北极星；真正硬的体验信号是行为，比如重联系率和会话中途放弃率，客户用脚投的票不受问卷疲劳影响。

四个坑总结成一句话：对标之前先对口径，口径对不上的数字，多好看都是别人家的。
最后
写到这里，这个系列的三篇就完整了：第一篇架构，回答它能干什么；第二篇护栏，回答它怎么不出事；这一篇评测，回答它到底有没有用。三件事对应产品经理在 AI 客服项目里迟早要顶住的三次质询：立项时的”方案为什么这么设计”，上线前的”出了事怎么办”，和上线后那句一定会来的”到底好不好用”。

回到开头那次例会。如果现在再被问”AI 客服到底好不好用”，我不会再报拦截率了。我会说：它答得对不对、客户的问题解决没解决、业务变好没变好，是三个不同的数，我一个一个报给你。能把这三个数一个一个报清楚，就是评测体系存在的全部意义。

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

参考资料

• mazon MARCO 论文（任务准确率定义、护栏贡献、重复实验方法）：https://arxiv.org/html/2410.21784v1
• Sierra τ-bench 论文（pass^k 稳定性指标）：https://arxiv.org/abs/2406.12045 ；官方博客：https://sierra.ai/blog/benchmarking-ai-agents
• Instacart LACE 框架（LLM 自动评估三档方法）：https://company.instacart.com/tech-innovation/turbocharging-customer-support-chatbot-development-with-llm-based-automated-evaluation
• Confident AI / DeepEval（会话级评估指标定义）：https://www.confident-ai.com/blog/llm-chatbot-evaluation-explained-top-chatbot-evaluation-metrics-and-testing-techniques
• Helply AI 客服 KPI 基准（B2B SaaS 指标基准、验证解决率、三档解决率天花板）：https://helply.com/blog/ai-customer-support-kpi
• Yellow.ai 指标演进框架（GCR、解决持久性等新指标，厂商视角）：https://yellow.ai/blog/customer-service-metrics/
• Aissist 2026 行业 Benchmark（六大行业解决率与成本）：https://aissist.io/industries/ai-customer-service-benchmark-2026
• Lorikeet AI 客服统计汇编（92% 企业报告满意度提升等采纳数据）：https://www.lorikeetcx.ai/articles/ai-customer-service-statistics
• Udesk 客服指标定义（CSAT/FCR/AHT 计算公式）：https://www.udesk.cn/ucm/faq/67970
• 极客公园对网易云商的报道（解决率 90% 为厂商自报）：https://www.geekpark.net/news/348095
• 沙丘智库最佳实践转述（一汽丰田案例，二手来源）：https://blog.csdn.net/m0_59164520/article/details/155805035


本文由 @凌青 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/pd/6443229.html