智能客服与问数项目的评测实践揭示了一个关键洞察：场景分类不能一成不变。当高价值低频场景成为业务痛点时，传统的三分法评测框架遭遇挑战。本文通过四象限分析法重新定义场景分类策略，结合归集、拆分、定向优化等实战技巧，为AI产品经理提供了一套动态演进的质量保障体系。

去年我们做智能客服时，我写过一篇评测集的文章，当时用的是三分法：核心场景集（60%）、边缘场景集（20%）、高价值场景集（20%）。那会儿觉得挺完美的，分得清清楚楚，上线后准确率也涨了。

但最近做问数项目，发现还能再优化。

看来， 场景不同，做测评的方法也需要“因地制宜”。

举个例子，问数项目的场景是这样的：

业务同学问“昨天华北区的销售额是多少”，AI要理解“华北区”是哪些省份、“销售额”是含税还是不含税、“昨天”是自然日还是工作日。场景特别多，意图特别细。

我根据之前的经验搭了评测集：核心场景（查销售额、查订单量）、边缘场景（各种奇葩问法）、高价值场景（财务对账相关的）。然后推上去迭代。

但是结果很神奇：模型在评测集上准确率稳定在87%，但业务同学天天抱怨“用不了”。我一查日志，发现模型在“环比增长率”这个低频但高价值的场景上，准确率只有30%。

而这个场景，我在“核心场景”里没放，因为出现次数少；

在“边缘场景”里也没放，因为不是错别字问题；

在“高价值场景”里也没放，因为我分类太糙了。

新方案：分四个象限，把场景分清楚

先说重点： 先收先放后收的策略。

第一类：核心高频场景（归集）

业务量最大、用户问得最多的那批问题。比如问数场景里的“查销售额”“查订单量”。

怎么干：归集。 把相同意图、不同问法的用例归并到一起，形成一个稳定的“基本盘”。这个盘的准确率必须高（比如98%以上），不然产品没法用。

踩坑分享： 一开始我没做归集，标注员给“查物流”的20种说法打了20个标签，重复劳动了三天。

第二类：高价值低频场景（先拆后收）

出现次数不多，但一旦出错就是大事故。比如问数里的

怎么干：先拆后收。 一开始把这些场景拆得特别细（比如“环比”拆成“日环比”“周环比”“月环比”），让模型分别学习。等模型能力上来后，再合并成一个泛化的“环比理解”能力。这个过程是动态的，不是一次搞定。

踩坑分享： 如果把一个“环比”怼到模型里，结果它只学会了日环比，周环比完全崩了。后来拆开练就好多了。

第三类：边缘场景（定向）

我们前端接了语音识别（hi agent框架自带），用户的各种奇葩问法：错别字、方言、中英混搭、表情包。这些不解决吧，用户老骂；全解决吧，成本太高。

怎么干：定向优化。 挑出频率最高的那几个边缘类型（比如“错别字中的数字写错”），集中解决。其他的先记录，排期后面处理。

踩坑分享： 我试过一次性把所有边缘场景都塞进评测集，结果模型反而被带偏了，核心场景准确率掉了5个百分点。

第四类：可延后场景（忽略）

出现次数极少，而且就算答错了也不影响核心体验。这个是一开始就做了的，所以暂无案例。

怎么干：忽略，转人工或兜底。 不是所有场景都要硬啃。把资源和精力集中在前三类上。

踩坑分享： 不要相信业务说的“都很重要”，要有产品的决断力（数据说话也行），舍不得“丢”场景，评测集就会越滚越大，从1000条涨到5000条，跑一次要半小时，迭代效率暴跌。

实际使用案例

案例一：退款场景

之前

在原来的智能客服项目里，我们把“退款”当做一个核心场景，放了几十条同义问法。

结果发现模型分不清“破损退款”和“漏发退款”的区别，而他们后端的业务动作完全不同。

用了新框架之后

（1）先把“退款”拆成子类：refund_broke/refund_leak/refund_other

(2)分别标注、分别测评

（3）等模型在每个子类上都达到一定准确率（自定，比如90%）后，再尝试合并成一个大的refund意图，通过槽位区分

案例二：问数里的“环比”

业务同学问“昨天销售额环比增长多少”，模型经常算错，因为没理解“环比”要和昨天的昨天比。

我按照新框架：

（1）把“环比”拆成3个子场景：日环比、周环比、月环比

（2）分别标注样本，分别训练

（3）两周后，模型能处理了，我们再合并成一个泛化的“环比理解”能力

现在业务同学再问“环比”，模型不会再傻傻地只算日环比了。

需要注意的坑

坑一：拆得太碎，维护成本爆炸

有一次我把“退款”拆成了10个子类，结果标注员每天要处理上千条，成本翻了三倍。

解法： 只有后端业务动作不同的才拆；如果只是用户表达差异，用同义问法覆盖，不要拆。

坑二：忘了“归集”，导致重复劳动

我让标注员给每个同义问法单独写标签，结果“查物流”有20种说法，标注了20次。后来才意识到应该先归集：把query_logistics作为一个评测单元，它的20个问法属于同一个用例。

解法： 归集是第一步，拆是第二步。不要跳过归集直接拆。

坑三：可延后变成了“永不解决”

定了“可延后场景”后，PM每次排期都说“这个先延后”，结果三个月后积累了200多个可延后场景，变成了技术债。

解法： 设硬性门槛：单月出现少于X次才可延后，并且每个版本至少解决10个之前延后的场景。

坑四：什么时候拆，什么时候收？

根据场景（经验）来的， 没有绝对标准。比如当前我的经验是：当模型在某个大类上准确率卡在70%-80%之间、且后端业务动作有明显分支时，就拆。当子类准确率都超90%后，尝试合并。

坑五：归集需要强大的标注规范。

同一个意图的不同问法，不仔细看可能漏掉。我用了几个大模型生成同义问法，再让标注员确认，成本降了不少。

坑六：边缘场景的优先级判断。

错别字、方言、中英混搭，哪个先做？这个需要根据实际业务需求现状来思考。

结语：评测集是个活的东西

切换新项目以来，我最大的体会是：

我觉得评测集的构建不会是死的，而是一个随着业务切换/演进而不断调整的“tangle”。你不可能一次把它设计完美，但一定要有一套机制，让它能进化。

另外评测集，定期都需要跑一次，看看四类场景的准确率变化：

1. 核心高频：稳定在一定准确率（根据业务实际来定，一般90%）以上才放心
2. 高价值低频：关注“拆”和“收”的时机
3. 边缘场景：挑Top5定向优化
4. 可延后：控制数量，定期清理

同时需要关注，随着业务需求的变化，是不是场景存在跨列别的切换，比如突然从边缘到核心的情况，灵活应对即可。

评测框架我还在摸索、迭代中，如果你有更好的想法，欢迎沟通。