生成式AI在客服场景的系统化实践 02 ｜ 从规则到生成式（二）：评测飞轮与指标体系的建立

全文共 5367 字

前言

在上一篇文章中，我更多分享的是从规则客服走向LLM客服的一些阶段性取舍，包括模型选择、能力分层以及提示词工程的治理。

但当模型真正进入线上环境之后，一个更现实的问题很快浮现出来：

我们如何判断它是在变好，还是在悄悄退化？

在小规模调试阶段，评估模型效果并不困难。挑几条典型对话，做对比分析，甚至凭经验判断，都能大致得出结论。但当模型开始频繁迭代、场景逐渐复杂，单纯依靠“感觉”已经不再可靠。

此时问题的重心，开始从“模型能力本身”转向“如何让模型更稳地演进”。这篇文章，我打算系统地梳理一下：在真实项目中，我们是如何搭建评测飞轮，如何设计分层指标，以及如何在上线过程中控制目标与风险。

评测飞轮：让产品优化进入闭环

在引入大模型之后，团队很快意识到一个问题：如果没有稳定的评测体系，模型优化会变成主观判断。

“感觉变好了”“看起来更自然”这些表达，在真实业务场景中是不够的。尤其在客服场景，任何策略调整都需要可验证依据。

于是，评测飞轮成为后续推进中最核心的一环。

构建“黄金评测集”

所谓黄金评测集，本质上是一组具有代表性的对话样本，用于持续验证模型效果是否退化或改进。

评测集的构建并不是简单抽取历史对话，而是需要刻意筛选。在连续几周的摸索当中，团队逐渐总结出以下几个原则：

在样本分布上，我们逐渐形成一个相对稳定的比例结构：

| 样本类型 | 比例 | 备注 |

这类样本往往不是自然产生的，而是被专门设计或整理出来的。有时候我们会刻意让不同角色参与设计问题，去“刁难”模型。只有在这种压力下，评测才有意义。

冷启动阶段：评测集不够怎么办？

在冷启动阶段，历史样本往往不足，尤其是边界和对抗数据缺乏。

团队当时主要采取了三种方式补充样本：

第一，通过人工构造。由产品、运营和业务方（客服部）共同设计“极端问题”，例如不同的负面情绪、复合意图、规则绕行等场景。

第二，从历史 bad case 中抽取。持续性建设的系统留下了大量人工接管的案例，这些往往是复杂表达的集中区域。

第三，参考投诉与质检记录。用户投诉往往集中在表达不清或规则解释不充分的场景，是天然的边界样本来源。

冷启动阶段时团队追求的目标并非覆盖所有场景，而是优先保证结构完整。

打标不只是算法团队的事情

打标很容易被误解为算法团队或者数据标注团队的工作。但在客服场景里，判断“好不好”并不是一个单一维度。基于此认知，我们逐渐形成了一个多方参与的打标流程：

所有AI产品评测中，打标是一个不得不做的工作，这里的打标通常有两种，所属产品构建的两个不同阶段，第一种指制作黄金评测集时，设计标准答案或参考答案的打标，这一部分通常由业务和产品共同完成，第二种则是指在点评模型所交出的“答卷”时，对于存在严格标答的客观题，通常由算法团队使用跑测工具进行“改卷评分”；而对于诸如流畅度之类的主观评分项，则通常需要业务、算法、合规三方协作完成。

每一条评测用例，通常包含多个核心维度，它们通常长这个样子：

每条用例都会拆解为若干评价点，比如是否命中核心问题、是否存在过度承诺、是否补充了不存在的信息、是否应该转人工等。

这种拆解过程很重要。如果只有一个“总体分数”，很难知道模型到底在哪个维度退化。

从简单脚本到框架工具

最开始的评测是用简单脚本跑的。优点是快而不失灵活，适合提示词频繁调整时期。

后来团队开始尝试接触像 LangSmith、Langfuse 这类工具。它们最大的价值不在于功能多，而在于“可追溯”。每一次 Prompt 修改、每一次模型升级，都可以清楚看到差异。且它们能够天然集成到开发框架 Langchain 当中。

但这并非意味着所有团队都需要追求大而全的工具，这取决于产研团队规模和产品所处的阶段（概念验证？or 优化迭代）

什么时候需要上这类工具？当评测从“阶段性动作”变成“长期能力”时，就需要工具支撑。

真正推动模型进步的是 bad case

评测过程中最有价值的，不是总分，而是 bad case。

几乎每一次优化，都是从某个具体错误开始。可能是一次过度承诺，或者一次对情绪的误判。

这些问题会被分类整理，由产品侧猜想初步解法，并在会上达成共识，然后反向推动提示词修改、知识补充或分流策略调整。

模型优化并不是一次大升级，而是大量小问题被逐步修正。

这也是我们后来理解的“飞轮”：评测发现问题 → 调整策略 → 再评测 → 再调整。当这个循环稳定下来，模型才算真正迈过工程化的门槛。

指标设计：上线前的最后一公里

当评测体系逐渐稳定下来之后，团队发现另一个问题：即便评测集能告诉我们“模型表现是否退化”，但它并不能回答一个更关键的问题——

这套能力，是否真的在推动业务变好？

如果没有指标分层，很容易出现一种情况：模型在技术评测上持续优化，但业务侧几乎没有感知变化。于是团队接下来着手于重新梳理指标体系。

从北极星指标出发

在客服场景中，北极星指标通常不会是“模型准确率”。下面有一些在实际业务当中会参考的指标：

不同团队可能选择不同的北极星指标，但核心原则是——它必须与业务价值直接相关，而不是技术结果。

公司的业务部门坚信一个很有意思的理念：最好的客户服务就是没有客户服务，这就是为什么智能客服产品的建设要以CPO为出发点。以人工CPO为例，假设公司的人工CPO为10%，这代表着每一百个订单必须联系十次左右人工客服，放大到公司业务每个月上百万的新增订单量，这对于人工客户团队来说成本压力是巨大的。

再从北极星指标拆分业务指标

确定了北极星指标后，再往下就是进一步地拆解，这里依旧以 人工CPO 为例，那么它背后可以拆成几个业务指标：

这些指标开始反映真实用户感知。比如，自助解决率提高了，但二次咨询率也上升，说明问题并未真正解决。业务指标的作用，是让技术能力与用户结果建立连接，团队大部分脑暴的时间都是用在围绕几个业务指标的异动做分析和提出猜想。

再往下挖，则是技术指标

真正用于短期迭代的，是技术指标。

当我们把客服流程拆解成若干节点之后，模型能力就不再是一个整体，而是分散在每个环节。

这里也分享一些实际工作常用的：

技术指标可以展开的部分有很多，也远不止上面提到的这些，项目的技术团队可以根据自身的需要进行选择。

在实践的过程中需要避开一个重要的误区，即技术指标绝不能直接等同于业务效果。例如，意图识别准确率提高，并不一定意味着自助解决率提升；回答忠诚度的优化，也未必带来投诉率下降。

技术指标更适合作为短周期反馈工具，用于定位问题和指导优化方向。

业务指标则用于判断是否真正带来了用户感知变化。

而产品长期评价，则必须回到业务指标。

上线目标不是拍脑袋定的

评测体系逐渐稳定之后，另一个绕不开的问题是——

上线目标应该怎么定？模型能力在离线评测中表现不错，而“不错”只是一个主观评价，并不意味着可以直接放量。

客服场景不是流量实验场，一次明显退化可能带来投诉波动，甚至引发严重的舆情问题影响品牌信任，所以确定一个合适的上线目标尤为重要。

团队通常有一个比较稳妥的方式：先找参照，再定目标。，第一层参照，是行业标杆。

如果行业内头部公司在某项能力上最高只能做到 40 多分，而我们贸然定到 70 分，往往在实现的过程中会挫败团队的信心。但现实是，行业标杆的数据往往很难获取。很多数据并不公开，即便公开，也未必口径一致。这时可以退一步，找公司内部的大盘数据。所谓大盘数值，是指当前公司整体的平均水平。

无论是自助解决率、二次咨询率，还是投诉率，大盘数据都是一个最真实的参照。如果连大盘均值都明显低于行业均值，那么模型优化的目标应该是先追平；

如果已经接近均值，则目标应该设定在“均值上下的合理波动区间”，而不是一开始就追高。

从北极星指标到可执行指标

上线目标不能是单一指标，而是组合结构。在实践中，我们通常会设计至少一个正向/负向指标以及至少一个围栏指标；正向指标，是希望提升的指标，例如自助解决率、NPS。负向指标，是希望下降的指标，例如二次咨询率、投诉率、转人工率。

围栏指标，是必须严格控制的底线指标。在客服场景中，红线率就是典型的围栏指标。

例如违规承诺、金额误导等，围栏指标的要求通常比正向指标更严格。

我们在实践中采取过一个相对保守的规则：红线类问题必须在离线黄金评测集上达到 0 才允许上线灰度。

这听起来严格，但一旦红线问题在线上放大，代价往往更高。

围栏指标的存在，是为了避免模型在追求效果时越界从而造成不可预见的损失。

目标设定不是一锤子买卖

上线目标也不是一次性设定。

在灰度阶段，目标往往是区间型，而不是绝对值。例如，在保证投诉率不升高的前提下，允许自助解决率在 3%–5% 的区间内波动，且具有统计学意义上的显著性。随着能力稳定，目标才会逐步收紧或提高。

与此同时，新模型的流量释放，也同样应该是渐进的，而不是一次性放开全部。

结语

写到这里，其实有一个挺直观的感受——模型本身并不是最难的部分。难的是，当模型开始频繁迭代之后，系统还能不能保持稳定。

评测飞轮解决的是“如何持续优化”的问题，让模型调整不再依赖直觉； 指标体系解决的是“优化朝哪个方向走”的问题，让技术能力与业务结果保持一致。这两件事单独看都不复杂，但真正建立起来，需要不少耐心。它不像模型切换那样能立马看到效果，而更像一个基础设施工程。

下一节会聊一个同样重要、甚至更复杂的话题——知识工程。

推荐阅读

如果对评测体系设计感兴趣，Langfuse 关于评测核心概念的文档提供了比较系统的思路，尤其在“可追溯与持续评测”方面值得参考：

https://langfuse.com/docs/evaluation/core-concepts

如果你对本文提到的“评测飞轮”感兴趣，强烈建议阅读 OpenAI 官方的这份实操手册。它详细拆解了如何通过构建端到端的评估流程，让提示词在不断的“测试-反馈-优化”循环中变得更加稳健，你可以把类似的工作模式复制到你熟悉的工具或者平台上：

Building resilient prompts using an evaluation flywheel

此外，Ragas 的指标体系中对多个技术指标的完整定义也很有启发性：

https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/#natural-language-comparison

这些内容并不一定要全部照搬，但在构建自己的评测飞轮时，可以作为设计参考。